Software compatibility is often a difficult issue within an organization. Compatibility issues are amplified iii a BPO relationship when attempting to bring buyer and vendor applications into alignment.
Database issues will confront nearly every BPO relationship, as data sharing is the backbone of most BPO projects.
This book is not intended to be a treatise on how to get disparate databases to talk to one another, hut BPO project managers should be alert to the difficulties often encountered when two systems attempt to connect at the database level.
Organizations that use BPO to improve their service levels-as opposed to seeking mere cost savings-are those most likely to encounter difficulties because their internal systems are likely to lag behind the latest technology upgrades.
The BPO vendor, however, has chosen to focus on the specific business process as its core business competence and is likely to be current in its software infrastructure, including its database systems.
The greater the gap between buyer and vendor software maturity, the greater will be the challenges in database integration and data sharing.
It is reasonable, if not expected, that the burden will be on the vendor to manage database integration, but the cost is likely to be borne, at least in part, by the buyer.
In addition to the initial data integration challenges-which focus on getting the buyer and vendor systems to communicate with one another- another important challenge concerns data and information distribution and publishing.
During the operating phase of the BPO Life Cycle, the vendor is performing service-related transactions that generate new business data and information.
That information needs to be distributed to relevant databases and published to relevant screens for others in both the buyer and vendor organizations to use.
Thorough analysis of data flows is required to ensure, at a minimum, that the people who need the information generated by the outsourced transactions continue to receive it-and receive it in a familiar format and at the right time.
Besides, the BPO buyer must be conscious of the potential hidden value in transaction information that is not destined for immediate additional processing and that is stoned in a data warehouse.
Data mining is the term that is used to refer to the process of analyzing an organization’s collected data that has not been immediately routed for additional processing.
These data are stored in the data warehouse and often contain insights into customers and competitors that would otherwise have gone unnoticed.
The BPO buyer should ensure that the vendor captures and stores all transactional data that can later be mined for strategic insights.
Once the two systems have established database connectivity, their respective software applications must be able to communicate.
This can pose a problem if there are a large number of applications because many of them will not recognize one another. If the two software systems are unable to communicate, then an independent piece of software-called middleware-may be necessary.
Middleware is software that enables two noncompatible applications to communicate, acting as a data translator between the applications.
If executable commands are needed, the logic scripts can be written and executed off the middleware platform, while delivering data via what is known as ODBC drivers to existing back-office databases.
ODBC stands for open database connectivity, which is a standard database access method developed by Microsoft.
The goal of ODBC is to make it possible to access any data from any application, regardless of which database management system (DBMS) is handling the data.
ODBC manages thus by inserting a middle layer, called a database driver, between an application and the DBMS. The purpose of this layer is to translate the application’s data queries into commands that the DBMS understands.
This is as much technical information as we intend to discuss on the issue of software compatibility.
Suffice it to say that a BPO buyer’s technical support staff may point to the necessity of a middleware package to facilitate software integration with the vendor.
This adds costs, of course, but the goal is to create as much interorganizational transparency as is required to perform services at the highest levels-and to support transactional data capture, storage, and mining.
In addition to the details of software and database compatibility, the BPO buyer must be concerned about the method that will be used to connect its systems with those of the vendor.
One alternative is to have a single on multiple servers connecting with the vendor’s system via a wide area network (WAN), or sending the necessary information via electronic fiat file.
One effective method that many BPO projects adopt is the use of active server pages on an application server.
Under this approach, the application server allows the BPO partners to see and use familiar screens to conduct their jobs. The application servers usually utilize ODBC drivers to map into the back-office databases, enabling both companies to interact with real-time data.
In some cases, the BPO vendor’s services may be so tightly integrated into the buyer’s back office that the vendor requires full access to data systems.
If full access is required, a common technique to facilitate that is through a global virtual private network (VPN).
VPNs have become popular over the last several years, and third-party companies offer support services at reasonable prices.
If the BPO vendor is providing the buyer with services that do not require access to the buyer’s computer system, it is recommended that a file transfer method be used.
This can be as simple as the vendor sending a weekly e-mail outlining all activity, sending a flat file, on setting up a basic electronic data interchange (EDI) translator.
With today’s technology, two companies around the world can fairly easily select a reliable and secure method of exchanging data.
Another issue that must be managed is the licensing agreement that governs usage of the BPO buyer’s software.
Purchasing a software license, in most cases, does not legally authorize the buyer to use the software in every given networking scenario.
For example, when a third party joins a network, the software company may require a client access license (CAL) for each additional party that accesses the system.