SEO Marketing Research

Most businesses have a significant amount of sensitive information, including trade secrets, business plans, and proprietary business knowledge.

Safeguarding critical business information is a concern, even in the United States. Threats to information security, such as theft by company insiders, former employees, and computer hackers, abound.

Offshore outsourcing presents different and in some cases more potent threats than the domestic variety.

Legal standards and business practices governing whether and how sensitive information should be guarded vary around the world.

Some industry groups, such as banks and financial services firms, have developed stringent guidelines for organizations to follow to secure their proprietary information.

The Bank Industry Technology Secretariat (BITS), for instance, released security guidelines as an addendum to an existing framework for managing business relationships with IT service providers.

The BITS goal is to help financial services firms streamline the outsourcing evaluation process and better manage the risks of handing over control of key corporate systems to vendors.

The BITS IT Service Providers Working Group developed the BITS Framework for Managing Technology Risk for IT Service Provider Relationships (Framework) in 2001.

Although the original Framework provides an industry approach to outsourcing, additional regulatory and industry pressures and issues have emerged.

To address these changes, the Working Group updated the Framework with further considerations for disaster recovery, security audits and assessments, vendor management, and cross-border considerations.

The Framework is intended to be used as part of, and in supplement to, the financial services company’s due diligence process associated with defining, assessing, establishing, supporting, and managing a business relationship for outsourced IT services.

The U.S. Federal Trade Commission (FTC) has developed so-called Safeguard Rules to govern the security of customer information as it is used and managed by domestic firms.

These rules implement the provisions of the Gramm-Leach-Bliley Act that requires the FTC to establish standards of information security for financial institutions.

Penalties for failure to comply with FTC rules are up to $11,000 pen violation (which may be assessed daily) and exposure to lawsuits claiming any harm to customers as a result of noncompliance.

The Health Insurance Portability and Accountability Act (HIPAA) has led to a host of security risk management concerns for health care institutions that outsource processes that require electronic transmission of patient information.

Passed in 1996, HIPAA is designed to protect confidential health care information through improved security standards and federal privacy legislation.

It defines requirements for storing patient information before, during, and after electronic transmission.

It also identifies compliance guidelines for critical business tasks such as risk analysis, awareness training, audit trail, disaster recovery plans, and information access control and encryption.

There are 18 information security standards in three areas that must be met to ensure compliance with the HIPAA Security Rule. The three areas are as follows:

1. Administrative safeguards. Documented policies and procedures for day-to-day operations; managing the conduct of employees with electronic protected health information (EPHI); and managing the selection, development, and use of security controls.

2. Physical safeguards. Security measures meant to protect an organization’s electronic information systems, as well as related buildings and equipment, from natural hazards, environmental hazards, and unauthorized intrusion.

3. Technical safeguards. Security measures that specify how to use technology to protect EPHI, particularly controlling access to it.

The most effective information security risk management strategy is to adopt and comply with best practices and standards.

Tort law in the United States includes four possible means by which a firm may be found liable for information security lapses: duty, negligence, damage, and cause.

Duty refers to whether the organization has a responsibility to safeguard information. That duty is not in doubt in today’s security-conscious environment.

Negligence refers to an outright breach of the duty to safeguard information. It asks: “Is there evidence that the organization did not fulfill its duty of care?”

Damage refers to whether there is harm to someone (the plaintiff) as a result of negligence. Cause refers to the question of whether the negligence led to or was the primary cause of the damage.

To manage the information security risk, business process outsourcing (BPO) vendor organizations should adopt and be able to prove compliance with global best practices and standards.

Many firms turn to managed-security providers (MSPs) to assist them in managing this risk. Good MSPs provide valuable analysis and reporting of threat events, supplementing the efforts of in-house security personnel.

They do this by sifting through vast amounts of data with the goal of uncovering, identifying, and prioritizing security vulnerabilities that must be addressed. The best MSPs provide BPO buyers with the following:

• The ability to compare and correlate multiple monitoring points and to distinguish between false positives and actual threats

• Skilled experts on duty around the clock to assess and react to each threat in real time

• The ability to combine existing technology with expert analysis to look for anomalous behavior

• The ability to develop custom monitoring for specific networks on systems, including the development of an “attack signature” for each new vulnerability threat.

Using a third party to manage information security helps relieve the organization of information security concerns, but it does not remove liability if there is a security breach.

Liability cannot be transferred to a third party, unless the buyer invests in appropriate insurance policies.

A good source of security risk management guidelines, policies, and best practices is the SANS Institute Web site at www.sans.org.

The SANS (SysAdmin, Audit, Network, Security) Institute was established in 1989 as a cooperative research and education organization.

Report This Post

Project risks are defined as the potential that the business process outsourcing (BPO) initiative may not provide the cost savings, strategic advantages, on productivity improvements anticipated.

The reasons for this potential risk are too numerous to list. Unexpected incompatibilities between software infrastructures could prove intractable and lead to delays, cost overruns, and lost business.

The cultures of the two companies may pose unyielding challenges that become more trouble than they are worth. Changes in U.S. or foreign labor laws could upend the cost equations that had been the primary reason for the offshore outsourcing.

To mitigate project risks, the BPO buyer should first assess its readiness to undertake the outsourcing project before making the leap.

This includes assessing the organization’s ability to adapt to change, the presence of an internal BPO champion, and the time that is available to make the transition and ramp the project to full operational mode.

Organizations that have a poor track record in managing large-scale change are at a higher risk of project failure than those that have a record of successful change management.

An organization’s record of success in this area is indicative of its organizational culture and is likely to be consistent in the BPO initiative.

The presence of an internal BPO champion, especially one with broad influence within the organization, can reduce project risk.

The internal BPO champion can be relied on to work long hours and lay awake nights thinking about solutions to project problems when other members of the RMT are sleeping well.

The time available to transition a process from buyer to vendor can also affect the risk profile of the project.

In general, the less time available for the transition, the higher the risk. It is often not practical to move all of a process to an offshore BPO vendor at once.

Buyers should increase the time available to implement a BPO transition, building on successes along the way.

A technique that can be used to mitigate risks associated with project timing is to develop a reasonable value horizon.

The term value horizon refers to the amount of value the organization expects to receive from the BPO project in a specific amount of time.

For instance, an organization that expects to reduce costs by 25 percent within three months may not be able to realize that value horizon because of project implementation costs.

Nevertheless, a 25 percent cost savings within two years may be achievable and would set the appropriate value expectations.

The project management team (PMT) often ignores the risks associated with unrealistic expectations on the part of the BPO buyer’s executive team.

Project expectations must be managed from a variety of perspectives: up, down, horizontal, and external.

Upward expectations management refers to the procedures the PMT follows to ensure that the organization’s executive team (and the BPO project steering team) is informed about project risks, their potential costs, and mitigation strategies.

Downward expectations management refers to the challenge of managing employee expectations as the project unfolds.

The PMT must also manage the expectations of managers in nonoutsourced functions and those of customers, suppliers, and other stakeholders external to the organization who have a need to know.

Managing senior leadership expectations is critical to the BPO project. Too-high expectations among senior managers can lead to overly critical feedback and potential plug pulling on a project that cannot meet excessively lofty expectations.

Elevated and maybe even unreasonable expectations among senior management should be expected with the current level of media attention and hype that surrounds outsourcing.

The PMT must ensure that senior managers are aware of the many challenges a BPO project faces and manage expectations accordingly. Some have called this process “managing up.

There are many effective techniques for managing up. Of course, this can be a delicate process because managing expectations up the chain of command may also often require that senior leaders be educated on technical or other issues.

To manage the expectations of senior leaders, the PMT should develop a project plan that articulates not only the problems and challenges likely to be encountered, but also those that have a lower probability of occurring.

A good technique for communicating risk and managing expectations is to develop a BPO risk-probability matrix.

The matrix will include as many reasonable risks as the PMT can envision, including those that are classifiable as worst-case risks.

The BPO risk-probability matrix will also include the mitigation tactics that are either in place on that would be mobilized in the event that the risk became real.

The BPO risk-probability matrix should be widely circulated and updated is needed. This document will serve as the starting point for understanding the wide range of potential risks associated with the project and their potential costs.

Managing horizontally means ensuring that managers of functions not being outsourced are informed and aware of potential risks.

We have spoken before of the potential for a BPO project to have cross-functional impact on organizational processes and workflow.

Regardless of the process outsourced, it is likely that the output of that process is utilized by others within the organization.

Changes to that output, whether in quality, quantity, or timing, can affect the ability of internal functional units to maintain their standard operating procedures.

Managing expectations horizontally means minimizing workflow surprises and bringing managers from the nonoutsourced functions into the workflow redesign process.

It would be disastrous to simply launch a BPO project without first determining in detail the effects of process output changes on units that depend on that output.

Managers who are surprised by changes in data quality, quantity, or timing will defend the integrity of their wonk units and may become obstructionists to the BPO project.

Customers, suppliers, and others external to the organization may also have a vested interest in the BPO project.

Customer reactions to BPO have been precipitated by several different factors. Some customers are concerned about BPO from a political perspective-they are worried about outsourcing jobs to offshore workers, for example.

Dell responded to such political pressures when it pulled some of its technical support work in-house after outsourcing most of it to India.

Organizations need to consider BPO as a political issue that may affect customer perceptions.

Communications with customers who are concerned about outsourcing jobs should include a recitation of the benefits they are likely to receive as a result of the outsourcing project.

It may also include a statement about the domestic jobs that the company has created and the number of new opportunities that may be generated as a result of moving some of the lower value-adding jobs to foreign labor markets.

Suppliers should be managed in much the same way as the PMT manages the expectations of internal managers whose functions are linked via workflow to the outsourced process.

Suppliers linked to the outsourced process should also be included in workflow redesign so they are aware of changes and who to contact in the case of disruptions or inefficiencies.

Managing expectations is not difficult, but this process is often overlooked because it involves proactive decision making and confronting problems before they arise. Engaging everyone-internally and externally-whose responsibilities, livelihood, or performance capabilities may be affected by the BPO project is the goal of the PMT.

The PMT must communicate with these individuals (and groups, in some cases) to manage their expectations and to increase the amount of slack available in the event that some things go wrong (and they almost always will).

If the goodwill of these stakeholders is won early in the process, and expectations are appropriately managed along the way, the PMT will have more latitude and time to fix problems that arise.

Failure to properly manage expectations means that some will be out to kill the project at the first signs of trouble.
 

Report This Post

Most of the problems employees will experience during a BPO project will not be related to the hardware or software infrastructure associated with BPO.

They will more likely be related to failures in understanding new workflows, work procedures, and work responsibilities.

From the apocryphal user who cannot find the “Any” key (“Press any key to continue”) to the individual struggling to find data that, without warning, now appears under a new field name, there are always problems with human adaptation to new systems.

When the buyer and vendor system architectures come together in a BPO project, there will be workflow and responsibility changes.

To avoid some of the problems that arise from process-related changes, and to ensure a smooth transition to the new system, training should be provided to everyone-even those who are adamant that they do not need to be trained.

One hurdle that many BPO project managers face with respect to training employees and getting them to be more self-sufficient is obtaining support from midlevel managers, because the middle manager is trying to learn the new processes while maintaining the unit’s productivity.

This juggling act can be challenging in the throes of a major BPO-based business transformation.

Perhaps the most compelling argument in favor of a thorough training infrastructure to support the BPO transition is that employee training has been shown to be an important differentiator between BPO projects that succeed and those that fail.

When training is neglected, the chance that buyer-side employees will be surprised and/or disappointed with new procedures and workflows increases.

BPO project managers will have a small window of opportunity during the transition phase to win converts to the new routines and work patterns.

We referred to two different types of obstructionists who may block on sabotage the BPO project.

Some of these people can be won over via a vigorous training and support regimen. Asking people to participate and take on a leadership role in some aspect of the BPO transition is an excellent way to counter their obstruction.

For instance, delegating responsibility for training others on the new procedures, along with appropriate levels of accountability for the success of the transition, is an effective project management tactic.

It is nearly impossible for someone to be involved in training others without developing enthusiasm for and interest in the training topic.

Public performance, even if not necessarily freely chosen, leads to a phenomenon known as “social facilitation.” People-even those who have a tendency toward obstructionism-simply perform at a higher level when they are in a social setting.

BPO project managers can co-opt potential obstructers by getting them involved in the training and support offered to employees in the BPO transition phase.

The content of employee training offered during the BPO transition should include a detailed and thorough review of new work procedures, responsibilities, and expectations.

Design of the training should be modular, with each module independently constructed and each focusing on a specific aspect of the new standard operating procedures.

Modularization of the training enables managers and employees to determine who needs to attend which training modules.

It also enables greater training depth in each module. If training is not modularized, if often is either too detailed for some users who already understand a process or not detailed enough for those who are unfamiliar with on new to the process.

Modularization allows training designers to deliver both depth and scope, while ensuring that employees have opportunities to select the training sessions (or for managers to appoint them to training sessions) from which they can truly benefit.

No one enjoys sitting though a training session that relays information he or she has already well understood.

Carefully developed two- to four-hour training modules help avoid training overkill, while providing adequate coverage of the knowledge gaps.

Considerations for the BPO-Related Training Program
• Develop a clear set of standard operational procedures (SOPs),
• The training program should revolve around the SOPs.
• Conduct multiple training sessions:
1. Train in a group setting.
2. Train while working alongside the employees during their workday.
3. When answering questions, always refer back to the SOP.
4. Final training should be completed after 60 days (refresher)
• Do not take training highly

A common error that hampers BPO projects is a failure to train vendor side employees, probably because of the erroneous assumption that the vendor is expert in the business process and therefore does not have a need for training.

This is true in some cases-especially those that involve an onshore outsourcing relationship-but it is prudent to review training needs of the BPO vendor.

Some types of vendor-side training that are being provided to accelerate the transition to the BPO operating phase include the following:

• Cultural adaptation training to help buyer and vendor employees adapt to one another
• Language training, including voice and accent modification training, to reduce communication barriers
• Training on laws and customs of the BPO buyer
• Training on culture and lifestyles of the BPO buyer’s customers
• Training on differing management and leadership styles of the BPO buyer

Besides, training should be designed to integrate the cultures of the BPO buyer and vendor.

This may include some training offered at each location so that key employees are able to experience the culture and work habits of their BPO partner firm.

In some cases, BPO, buyer and vendor employees work side-by-side for a period of time in a form of on-the-job training that facilitates cross-enterprise understanding.

The BPO transition phase is the most difficult of the life cycle and the one where future operating patterns, routines, and procedures and established and frozen into place.

In the best of all possible worlds, the procedures established lead to a highly efficient interorganizational system that runs trouble-free for years.

Of course, we do not live in the best possible world, and problems arise in even the most carefully crafted systems.

To deal with ongoing challenges to system integrity caused by breakdowns or other factors, a systematic support system, troubleshooting approach, and record-keeping strategy should be established.

The support system established for the BPO transition and operating phases must be adequate to meet the needs of the buyer and vendor organizations alike.

Each will face unique challenges based on exposure to new operating procedures, in addition to the challenges associated with the merging of two independent work cultures.

The support system established to manage the technical issues that arise should be modeled on the common help desk approach used by many IT departments.

The only consideration unique to a BPO project is which firm will manage the help desk function.

The vendor should inherit most of the responsibility from troubleshooting and supporting the outsourced process.

This should be part of the contract and should have its own SLAs. However, because the BPO vendor is usually geographically distant from the buyer-maybe overseas-the buyer should have on-site support personnel who may be on the vendor payroll but accountable to a buyer-side manager.

Report This Post

Change management is a human resource issue, involving a well-understood pattern of overcoming resistance, instituting changes, and reestablishing standard operating procedures.

Some change management consultants have expressed this as unfreezing-moving–refreezing the organization.

In this section we are not addressing the risks associated with change management; rather, we focus on the technical risks involved with the thorny issues of equal employment, immigration, and foreign trade regulations.

Each of these topics touches the BPO project on the margins and must be understood and managed.

Onshore outsourcing usually has minimal human capital risks because it is strongly in the domestic BPO vendor’s interest to understand and comply with all U.S. employment laws and regulations.

Moreover, the vendor is highly motivated to assist clients with any labor issues they may face as a result of engaging vendors in an outsourcing relationship.

The human capital issues most likely to arise in an onshore outsourcing project are those associated with equal employment opportunity regulations.

For instance, BPO buyers must be especially careful when outsourcing results in reductions in force reduction-in-force (RIF).

Such reductions must be handled in a manner that is transparently related to business interests and has not selectively targeted a protected class of individuals.

Other human capital risks associated with onshore outsourcing concern those that stem from collective bargaining and labor relations laws and regulations.

For instance, the U.S. Supreme Court has established basic guidelines governing whether and when subcontracting should be deemed a mandatory subject of bargaining under the National Labor Relations Act (NLRA).

Beginning in the early 1980s, the National Labor Relations Board (NLRB) issued several decisions that created additional uncertainty when evaluating the bargaining status of outsourcing on subcontracting decisions.

The NLRB’s lack of clarity on the obligations of employers to the collective bargaining process is unlikely to be resolved any time soon.

To reduce risk, companies should consult with labor attorneys as part of the BPO opportunity analysis to determine the likely disposition of their preferred strategy and its implications for possible liability exposure.

BPO buyers that use an offshore outsourcing vendor can benefit from an absence of many of the employment liabilities that are present in the United States.

Many foreign countries do not have laws governing employee matters such as those in the United States, including workplace discrimination, sexual harassment, on privacy.

At the same time, companies must understand the labor laws that govern their outsourcing vendor. India, for example, has a radically different system of employment law than the United States.

“At will” employment, which allows employees in the United States to easily terminate or lay off employees, does not exist there. Under a much more restrictive concept called “termination indemnity,” employers must follow a lengthy notification process before letting Indian employees go.

They must also indemnify employees for some of the wages they would have earned if they had remained under their employment.

Failure to follow the appropriate process can result in fines for an employer operating in India. Additionally, employers cannot enter into contracts under which individual workers sign away suck rights.

Similar employment laws restricting an employer’s right to terminate workers exist in many countries that are hotbeds of outsourcing.

Report This Post

LDV started out as a division of British Leyland. When the U.K. manufacturing giant closed its doors, many industry observers believed that LDV, which builds commercial vehicles, would soon follow suit.

But LDV was saved by a management buyout and today employs more than 1,000 people at its Birmingham factory.

LDV has extensive expertise in the automotive market, but its niche also presents management with significant challenges.

“We specialize in custom-designed vehicles, and rely heavily on our supply chain applications, which run on IBM mainframes,” stated Chris Linfoot, LDV’s IT director.

“The problem is that those mainframes were designed to be used by Leyland, which had a far larger IT staff than we can afford.”

For five years LDV had outsourced the maintenance of its mainframes to IBM, but Linfoot felt the company was not getting enough benefits from the arrangement.

When the contract ended, Linfoot switched the outsourcing deal to Gedas, the information services arm of Volkswagen.

The outsourcing contract has allowed LDV to focus on what it does best-manufacturing vans and other commercial vehicles-while still benefiting from the mainframe applications.

LDV has already benefited from Gedas’s expertise in automobile manufacturing. For example, Gedas has helped develop new processes that will eliminate the need for batch processing and enable the factory to operate 24 hours a day.

“The result is that we are now on the verge of a major growth spurt which will see volume quadruple,” says Linfoot.

“Outsourcing one part of our business to a company which understands it so much better than a traditional service provider is a key part of that process.”

Sources: Adapted from Sally Whittle, “Who Can You Trust to Take Care of Business?” Computer Weekly (October 21, 2003), pp. 48-49.

An additional consideration in the knowledge infrastructure of a BPO project is cross-enterprise knowledge management.

In many cases, BPO buyers share mission-critical information with their BPO vendor-information that is not only important for organizational processes but that also may be of high interest to competitors.

The criticality of this information creates two worries: maintaining information integrity and maintaining information security.

Maintaining information integrity means that the information shared between buyer and vendor organizations does not get corrupted on reconfigured.

Data corruption would result in inappropriate conclusions and errant actions as a result of analysis of altered-and possibly false-data.

Data reconfiguration refers to the potential that raw data has been altered in some way that makes it unreadable and simply unable to be converted into usable knowledge. Altered display screens are an example of data reconfiguration.

Often, a BPO vendor uses proprietary data displays for internal use. These displays, if published to the BPO buyer as replacements for familiar screens, may render the data useless to the end user although the integrity of the data interface been carefully maintained.

Displaying data in a new and unfamiliar user interface can befuddle-or at least frustrate-even the most adaptable users.

When entering into an outsourcing partnership, the two organizations, in effect, become one. In order for the outsourcing project to produce results that meet and exceed expectations, there must be transparency between both entities.

Nevertheless, when two computer systems situated in separate locations begin interfacing, security becomes a major issue.

BPO buyers must ensure that the vendor will adhere to the buyer’s security policies and that all work done adheres to up-to-date security procedures.

In many cases, BPO buyer and vendor communicate with one another via the Internet. When entering into a new BPO relationship, both organizations should review their Internet security policies.

When developing an Internet security policy, BPO buyers should keep the following points in mind:

Security Issues for the BPO Vendor
• What is its security policy?
• What are its data backup and disaster-recovery procedures?
• How is its data safeguarded from that of other customers?
• How is its data safeguarded from the vendor’s own employees?
• How is it insured with regard to security breaches?

? Limit access. Many security breaches come from within an organization; thus, the fewer people with access to the inner workings of the system, the better.

? Establish granting privileges. A rigorous procedure should be in place for granting and revoking rights of access, and granting privileges should be recorded and made available to both client and BPO partner.

? Streamline hardware and software between the two organizations because a complex system is more open to attack.

? Develop a password policy, and do not allow users to choose simple or obvious passwords.

? Have procedures for data backup and disaster recovery in place before going live.

? Have procedures for responding to security breaches in place, and determine actions to be taken.

? Have your security policy audited by an external professional organization, and have them on call in case a major breach occurs.

Although system backups may seem like a common task for the average: IT department, the backup process becomes very important when executing a BPO project.

There are going to be times during the process redesign phase when both groups will overlook an important procedure, data interface issue, or technology support opportunity.

There are so many factors to be managed during a BPO project that there will be times when the backup system is critical. The three most important factors involved in backup systems are as follows:

1. Scheduling backups
2. Tape rotation
3. Tape restoration

When conducting a tape backup, the administrator must determine type of backup he or she is going to conduct:

? Full. Copies all files in a selected volume and/or directories, clearing the archive bit for each file.

? Differential. Copies all files changed since the last backup and does not clear the archive bits.

? Incremental. Copies all files changed or added since the last full or incremental backup, clearing the archive bit for each.

The BPO project managers should mix and match backup methods on successive days. Differential and incremental sessions have the advantage of speed because they do not work on all files and may be suitable on a daily basis.

But the most complete method is a full backup that may be run weekly or on a bi-weekly basis. It is also possible that the BPO buyer already has an adequate tape rotation strategy.

The daily tapes are used over a two-week period. For instance, on Monday the seventh day of the month, the Monday-Odd tape is used. On Monday the 14th day of the month, the Monday-Even tape is used.

On the first Friday of the month, the Friday-First tape is used; on the second Friday of the month, the Friday-Second tape is used, and so on.

The two parties should select a regular date on which to conduct the monthly backup (e.g., the 15th of each month).

If the system includes an accounting, order entry, on some other type of application that executes a month-end close, the partners may want to select either the day before or the day after that close occurs to conduct the backup. The parties may also want to keep a few blank tapes around for emergency occasions.

Tape restoration goes hand in hand with tape backups. However, many companies do not have policies for tape restoration. Before developing a tape restoration procedure, the PMT should ask a few basic questions:

? What should be hacked up each day?
? How many tapes should be used?
? Is just doing a backup enough?
? Where should the tapes be stored?

Tape Restoration Guidelines
• Before starting the BPO project, test all tape backup options. Run large backups and try restoring random files.
• Rotate backup media.
• Do not exceed the tape life. Check how many times the manufacturer suggests reuse.
• Purchase high-quality backup rapes.
• Check backup logs daily.
• Always conduct a verification pass when data is backed up.

These important questions provide a starting point for managing data restoration. Even if the BPO project never needs to restore a single byte of data, it is better to be prepared.

Report This Post

We have already discussed the data and information infrastructure that is important part of any BPO relationship.

Competitive businesses are data driven, and in many cases a large part of their overall value is derived from industry and market data they have collected, stoned, and analyzed.

A company’s knowledge infrastructure is even more important because knowledge refers to the practical application of the analyzed data and information.

The knowledge infrastructure of the BPO buyer refers to several components, some of which are directly affected by the BPO relationship.

Knowledge is defined as “analyzed and applied information that helps the organization compete and grow.” Data and information are generated by raw transactions knowledge is generated by analysis and reflection on aggregated transactions.

Organizational knowledge comes from a variety of sources. One common source is analytic software that seeks patterns in transactional data and reports these patterns to human users.

For instance, the balanced scorecard approach used by many companies today conveys aggregated and analyzed transactional information to the desktops of users who can apply that knowledge to their work.

Sales managers who receive daily reports that aggregate real-time sales data will know when to crack the whip and when it is acceptable to relax a bit.

BPO buyers and vendors should ensure that the output provided by the buyer’s analytic software systems before the BPO project is not corrupted on changed without intent.

The systems used by the buyer before the BPO project may need to be upgraded on replaced, but such upgrades should not be made without a full understanding of who is using the generated knowledge and how it is being used.

Knowledge output from an analytic software application may be distributed to multiple databases.

If a new analytic package is introduced, each output database should be identified to ensure minimal disruption of internal workflows.

Too often a reengineering process in one business unit results in an unexpected loss of essential data in another unit.

BPO project managers must always be mindful of the interdependence of data flows within an organization and between an organization and its various stakeholders.

For example, many organizations routinely share data with suppliers and customers to create efficiencies and, in the case of customers, to increase perceived value and switching costs. The integrity of these data flows must be maintained.

Though analytic software is a common source of organizational knowledge, it often goes unrecognized that another common source is wetware.

Wetware is the term used to refer to the analytic resource between the ears of organizational employees (i.e., their brains).

Far too often, organization leaders neglect to recognize the knowledge-generating capacity of their human resources.

It is easy to maintain the perspective of people as knowledge repositories, but their key role as knowledge generators is too often underappreciated.

Outsourcing a business process means that the organization will not be exposed to the raw data that used to be transformed into knowledge by people within the organization.

For instance, as a result of outsourcing the firm may no longer employ front-line employees who used to recognize data patterns and call attention to outliers, anomalies, and opportunities.

The outsourcing vendor can generate the knowledge that used to be generated by internal staff if appropriate incentives are established.

Internal staff were motivated to recognize and react to data patterns based on their commitment to the organization’s strategic objectives, their interest in receiving greater compensation, and their desire to simplify their jobs.

These incentives may not exist for the offshore agent, who may not even be aware of nor deeply care about the industry or market of the BPO buyer.

To ensure that this valuable source of organizational knowledge is not lost in the operating phase of the BPO Life Cycle, the buyer and vendor should establish incentives for front-line agents (vendor employees) to seek and report data patterns that may result in process improvements.

One way to address this issue is by specifying incentive terms in the BPO contract. However, the establishment of knowledge-generation incentives may be too granular for the BPO contract and may be better established in the project management plan.

This provides greater flexibility to both parties to determine where the likely points of mission-critical knowledge generation are within the workflow and how to properly arrange incentives for individuals at those critical points.

The Case Study illustrates how British automobile manufacturer LDV switched its IT outsourcing vendor and gained valuable new insights into its manufacturing processes.

Report This Post

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.
 

Report This Post

The first issue to consider with respect to the hardware infrastructure underlying the BPO project is whose systems to use.

Because providing high levels of service in the specific business process is the vendor’s core competence, their hardware capabilities usually outstrip those of the buyer.

Despite this common circumstance, the decision to use the vendor’s hardware system should not be based on technology maturity alone.

Buyer and vendor must also consider other factors when determining whether to shift processes to the vendor’s hardware.

Among the considerations that affect this decision is the intent of the BPO agreement. Firms that outsource primarily to save costs should leverage the vendor’s systems, eliminating depreciating assets from the balance sheet and converting them to monthly pretax expenses.

Nevertheless, BPO buyers seeking to develop strategic advantages through the BPO project may elect to leverage and/or build their own hardware systems utilizing the vendor’s knowledge and experience to design the necessary systems.

This ensures that any competitive advantages realized through hardware advances will be retained within the buyer organization in the event that the contract with the BPO vendor is terminated on not renewed.

The extent of the BPO buyer’s interest in developing and retaining new capacities in the outsourced process is a major determinant of whose hardware to use in the BPO project.

Another consideration that affects this decision is the potential to develop synergies with other business units as a result of budding internal hardware maturity and capacity for the BPO project.

While scaling systems to meet the demands of the enhanced business process, the BPO buyer creates capacities that may be applicable to other units within the organization.

These additional capacities are often unexpected and can result in improved performance across the organization.

Relying on the vendor’s hardware means forgoing development of internal capacities and the possibility of unexpected process improvements in other business units.

Of course, this risk can be mitigated through a deep, collaborative buyer-vendor relationship that seeks to leverage hardware advances for process improvements no matter where the hardware resides on who has title to it.

A final consideration when assessing whose hardware to use to manage the BPO process is location.

When a BPO buyer decides to use the vendor’s hardware, that hardware is often located off the buyer’s site.

This is usually not a problem if the vendor is local on onshore in the United States. Problems may arise, however, when the vendor is offshore.

As the BPO revolution continues, offshore locations may include increasingly remote regions of the world.

BPO buyers must confirm the vendor’s ability to obtain technical support and spare parts to maintain their systems and minimize downtime, Systems that are state-of-the-art but that have been damaged by an earthquake, political uprising, on other unexpected event are not much use if they cannot be repaired and placed back online in a hurry.

Regardless of whose hardware systems are used, the infrastructure compatibility between both organizations must be reviewed and managed.

This is a critical step because both organizations will be relying on the combined system to provide transparency.

One distinction that is important for BPO project managers to appreciate is that between a system’s infrastructure its architecture.

Infrastructure refers to the system’s hardware components and their functionalities. The hardware infrastructure hosts a variety of applications that rely on the components of the infrastructure and management procedures (i.e., software distribution, backup, recovery, and capacity planning) to provide reliable and efficient services.

A system’s architecture refers to the configuration of the components- the way they are structured and the way they interact with one another.

In other words, an infrastructure model provides a description of hardware resources and their individual functions, whereas the architecture describes their interrelationships and the services that can be delivered.

For example, a system’s infrastructure may include e-mail servers and network cabling. Their arrangement into a specific architecture enables delivering e-mail services to specific groups of employees.

When considering the hardware needed for a BPO project, the project management team (PMT) must be cognizant of both infrastructure and architecture issues.

Because BPO projects will require resource sharing regardless of where the bulk of the components reside, a complete audit of the available resources and their current configuration should be conducted. The IT resource audit enables the PMT to do the following:

? Avoid needless duplication of systems and services.
? Pinpoint any gaps in infrastructure capability.
? Ensure infrastructure/business alignment.
? Ensure adequate scope of IT components to accommodate service enhancements.
? Assess security issues associated with data and knowledge sharing over networks.
? Reengineer processes that are obviously inefficient on anachronistic.

Highlights some key infrastructure and architecture questions that a BPO buyer should pose to vendors.

Key Questions for Infrastructure Management
• What operating system, Web server, commence server, database management system, payment system, and proxy server does the vendor use?
• What are the service level arrangements, in terms of availability, performance, and security?
• How scalable is the BPO infrastructure? What are the scalability constraints?
• What is the aggregate bandwidth at the site locations?
• Is there any load-balancing scheme in the site?
• What type of redundancy is available at the site (i.e., server redundancy, uninterrupted power service, RAID disks, and multiple Internet backbone providers)?

The system architecture designed for the BPO initiative will most often be based on the vendor’s systems.

At the same time, it is important to note that many BPO projects uncover inefficiencies in noncore processes and systems that are linked to the business process slated for outsourcing.

The PMT should be trained to identify such inefficiencies as candidates for reengineering. Many outsourcing contracts allow for buyer-vendor cooperation to reengineer processes that are coupled to the outsourced process.

Such cross-enterprise collaboration on reengineering buyer-side processes and systems is a vital component of transformational BPO.

Each reengineering initiative can be managed independently on as pant of the PMT’s charter.

As the buyer systems interact with the more efficient vendor services, opportunities for reengineering will undoubtedly emerge.

The PMT wants to stay vigilant for such opportunities, striving to ensure that buyer-side systems do not become the chief bottlenecks in constantly improving process flows.
 

Report This Post

Although a mature and seamless relationship would most likely enhance the benefits of outsourcing, failure in the BPO relationship can lead to negative and potentially irreparable consequences.

The business literature is rife with stories about BPO relationships gone had, and there will be many more in the coming years.

As the BPO revolution picks up steam, no doubt many new vendor firms entering the market will make claims about capabilities and capacities they do not possess. Unwary BPO buyers will get burned, and large amounts of money will go to waste.

It is impossible to control the way the BPO market will evolve, but organizations can control with whom they partner and how that relationship evolves.

There is ample experience among BPO buyer and vendor firms alike to highlight some of the more common pitfalls of failed BPO relationships. Seven common pitfalls have been identified as follows:

• Lack of appropriate buyer control
• Cultural differences
• Inflexibility in BPO agreements
• Inadequate Service Level Agreements (SLA) specifications and/or metrics
• Inadequate governance
• Lack of goal alignment
• Lack of integration

Lack of Appropriate Buyer Control
Organizations that undertake an outsourcing initiative must recognize that outsourcing is not the same as abdication.

When an activity is outsourced, the buyer should dedicate a manager (BPO Champion) on team (PMT) to interact with the vendor.

This relationship will work best when both sides seek to provide value-added service to the operations and strategy of each other.

However, a buyer that tries to maintain complete control over the outsourced process will undermine the leverage the vendor can employ to deliver satisfactory services.
The danger in an outsourcing relationship lies in the inability of the buyer to develop an appropriate level of relationship control.

An appropriate control level is one that allows the vendor the freedom to provide the services for which it was contracted without ceding the ability to prevent small problems from becoming large ones.

This is a delicate balancing act that will undoubtedly need to be adjusted over time. For example, at the beginning of the relationship, the vendor is focused on performing at a high level and pleasing the new client.

At this point, the buyer may not need as much control as later in the relationship when the enthusiasm wanes and performing on the contract becomes routine.

Problems are most likely to arise when the vendor unconsciously shifts to viewing performance on the buyer’s contract as routine and reduces its level of internal oversight. A proactive relationship management approach will anticipate these fluctuations in vendor diligence and will establish metrics and reporting regimes to counteract these variations.

Cultural Differences
Differences in culture and work styles between the client and the BPO provider can result in severe misunderstanding and mistrust.

Organizational culture is defined as the operating principles and norms that are embodied in an organization’s policies, decisions, and actions.

Problems can arise when a BPO buyer initiates a project with a vendor whose culture and operating style are vastly different.

Such differences can and often are bridged. What matters is whether the two firms recognize the cultural differences and takt proactive steps to deal with them.

Differences between buyer and vendor cultures are exacerbated if one or both parties is unable to listen to and understand the other.

BPO buyers should be especially sensitive during the vendor selection process to how well the various bidders listen to their needs and whether they ask the penetrating questions that reveal their awareness of the potential for problems arising from cultural differences.

A vendor that does not listen well or ask the right questions during the selection phase should probably be eliminated from consideration.

Of course, it is impossible to uncover all cultural differences during the vendor selection phase; some will only become manifest during the operating phase.

The project management framework should include inducements for each side to identify and detect problems that are a direct result of cultural differences.

Report This Post

SLA specifications and metrics measure the provider’s performance during the operating phase of the business process outsourcing (BPO) Life Cycle.

They must be clearly defined and effectively designed into the contract because this is what allows the buyer a comfort level in turning over control of its business processes to the vendor.

The metrics associated with SLAs indicate whether the company is receiving the services it is paying for.

Many organizations have learned that the business process they have been performing for years is exceedingly difficult to describe in precise written terms.

Yet, clear specification of the manner in which a process must be performed is critical to ensure effective vendor performance.

Too often, firms turn over a business process to a vendor and expect them to deliver services that conform to expectations, without providing a clear statement of those expectations.

The task of specifying a process in detail is difficult. It requires discussions with people involved in the process, mapping the process, and specifying acceptable service levels and remedies.

Most organizations will find that, no matter how careful they are in specifying expectations for vendor performance on a given process, there will always be a few details that slip through the cracks.

In addition, vendors are not in perfect control of their employees, many of whom may decide unilaterally that the specifications they receive can be ignored.

They will simply do things their own way because they do not agree with the specifications or believe they have a better idea.

Carefully structured SLAs and rigorously applied metrics will ensure that none of these potential corrupters of vendor performance levels result in adverse consequences.

Inadequate Governance
Informal, unstructured, and/or inadequate attention given to relationship governance issues often leads to relationship difficulties.

There is adequate contractual attention given to compliance to service levels, but attention is rarely given to governance and achieving relationship maturity levels. We described the concept of a project management team project management team (PMT).

It is important to note that this team performs both judiciary and legislative roles in the oversight and implementation of the executive document-the contract.

In its judicial role, the PMT specifies how often the parties will share information and measure performance. It will also specify what will be done in the event of nonperformance.

In its legislative role, the project management team will develop and deliberate changes to the project management plan. This ongoing process should be conducted in the spirit of the contract, which serves as the constitution to the judicial and legislative roles of the PMT.

Lack of Goal Alignment
An outsourcing relationship is bound to fail in a situation where the parties do not align goals, objectives, and interests.

As separate economic entities, the parties are not naturally aligned. In fact, there are market incentives for one or both parties to suboptimize on the contract, as mentioned previously.

Goal alignment means that both parties take action, including investment of time and financial resources, toward the goals they articulate to one another.

Merely stating goals is not enough. Both firms must demonstrate commitment to those goals through actions.

Many BPO relationships fail when one on the other party perceives that the other is not acting on its articulated goals – or is not acting in a manner consistent with its goals.

This can be observed through a back of investment in new technologies on innovations that might further the stated goals or a lack of interest in pursuing joint development projects.

When one party feels the other is not living up to its stated goals, resentment and other negative emotions can arise.

If left untreated, these negative emotions can rot the spirit of a healthy and enduring relationship, heading both parties to develop mistrust for one another.

A strong project management plan will require each party not only to articulate its organizational goals and objectives, but also to demonstrate how it is pursuing them.

Regularly updating each other on goal attainment and aspirations for the future is a strong antidote to fear and mistrust that can arise from uncertainty about the other party’s commitment to the BPO relationship.

Lack of Integration
The development of an effective BPO relationship is not only a process or infrastructure issue but also requires cultural replication, and sharing of vision and values.

The integration of IT will carry unique challenges, especially if the process is to be outsourced offshore.

At the same time, anyone who has even initiated a major software installation on hardware changeover will readily cite integration as a major challenge.

From that perspective, the IT integration issues associated with a BPO project are not unique.

Even more, most vendors are prepared for the data and information integration challenges based on their experience with other clients and their desire for economic survival.

BPO buyers should leverage the market pressures that force integration responsibilities and costs primarily onto vendors.

Additionally, third-party firms that specialize in getting disparate databases to talk to one another can be hired to assist in the process. Again, the buyer should seek to shift the integration cost burden to the vendor.

Integrating cultures, work styles, and policies and procedures is a less specific science and will pose difficult challenges for BPO buyer and vendor alike.

We have already discussed the need for the PMT to consider questions of “whose culture?” and “whose assets?” in the BPO transition and operating phases.

These are pragmatic questions, but the process of transitioning from one cultural style to another requires change management tactics.

Overlooking the cultural transition, as well as the policy and procedure transition issues, is a leading cause of BPO project failure.

Report This Post