e-INSIDER

— November 15, 2006

Business Process Management Notations within Business Process Management
From Technology Evaluation/Hans Mercx
Business process management notation (BPMN) is the latest standard for modeling business processes and Web services. The Business Process Management Initiative (BPMI) (www.bpmi.org) was established to develop, support, and encourage the use of BPMN. The BPMI Notation Working Group (BPMN-WG) worked for over two years to develop BPMN before its 1.0 release in May 2004. The primary goal of the BPMN initiative was to develop a standard notation methodology, understandable to all business people, throughout the process of defining, designing, deploying, executing, and optimizing processes. BPMI also created BPMN to ensure that the actual extensible markup language (XML) used in execution languages such as business process execution language (BPEL), business process execution language for Web services (BPEL4WS), and business process modeling language (BPML) can be represented within the notation of the processes.

The BPMN-WG, a member of the BPMI organization, created BPMN to provide businesses with the ability to define and understand their own internal processes, and to communicate these processes and procedures in a standard manner. This notation standard increases the understanding of business transactions within the organization, and ensures that organizations will be able to communicate internally. Furthermore, it will also enable integration with third parties that the organizations deal with, to enhance business-to-business (B2B) processes.

BPMN enables better use of business process management (BPM) by standardizing the notation method used to assist in process automation. BPM refers to the systems and methods used to define, monitor, report, and continually improve processes aiming at meeting customer requirements. BPM includes the development and automation of new and integrated business processes to assist in real-time business visibility and decision-making. It includes workflow design and modeling, and automated process integration and management. Even though organizations have been modeling and managing processes for years, these activities have often fallen short, due to a lack of standards, control, and guidance during the design and execution phase of the processes. BPMN provides these standards for business process modeling and business execution languages in order to resolve the shortcomings. BPMN can't solve all problems as it is purely a notation method that vendors and organizations can use. Software vendors still need to integrate the execution engine in their solutions for an organization to be able to automate processes instead of just modeling the processes.

BPMN is a specification for a business process diagram (BPD). BPD is used to model business process operations graphically, in a readable and understandable way for non-technical users, even for complex processes. BPDs can map processes to business execution languages in order to automate these processes. Within the BPD, the user creates the business process model, which is represented by a network of graphical objects. These objects display activities and work flow in the order of execution. The user simply models the events that occur from the start of a process, all the way through to the end result, with the notations defined by BPMN standards.

To be able to understand the principle of BPMN, organizations should know what makes a business process diagram BPMN-compliant. What are the basic elements used within BPMN? These graphical objects enable easy development of business diagrams and flow charts. Flowchart diagrams, such as those created in Microsoft Visio, often have similar icons. The shapes of these elements have been chosen by the BPMI-WG because they are recognizable to business users; this enables business users to understand the entire process.

Within BPMN, different elements are categorized, providing an organized overview of the basic elements available. Within these categories, there are variations of elements, identifying more complex requirements (which does not change the look and feel of the diagrams). These categories include flow objects, connecting objects, swimlanes, and artifacts.

Process modelers use flow objects when defining business processes. Within a BPD, BPMN defines three main elements: events, activities, and gateways. With these three main elements only, business users can fully define processes.

Events indicate something that happens within the process, and that influences the process (the event being a trigger or result of an action). BPMN uses circles to notate events. There are three types of events: starting, intermediate, and end events. Specifying triggers within the events puts constraints on the processes, and these constraints can be messages, timers, links, rules, exceptions, or even multiple triggers.

Activities are represented by a rectangle, and indicate work performed. An activity can be a business process, sub-process, or task. They all have the same shape--it is only the order in which they appear (or a small indication within the shape, such as a plus sign [+]) that differentiates the activity as a process, sub-process, or task. In this way, different activities are easily recognizable within the diagram, and the diagram will be understandable to the business analysts.

Gateways are indicated by a diamond-shaped element representing decisions, mergers forks, or joins within the diagram. Gateways can be seen as questions asked within the process flow (with alternative answers), through which the process is pushed through the organization. There are numerous examples of gateway decisions:

ADVERTISEMENT

Exclusive decisions (in logic, the exclusive or [XOR]), used to model data- or event-based decisions. Based on the condition of the activity, the flow continues towards one option or the other.

Exclusive merges (XOR), indicating that one of the inputs provided will become the output of the gateway

Inclusive or decisions, meaning that one or more outputs can result (at least one). There is always a default output indicated.

Inclusive or merges, where the first of any incoming inputs is processed

Complex decisions--based on the decision, the expression triggers a specific outgoing flow

Complex merges, where the complex conditions within the expression determine when the process moves forward (based on incoming events)

Parallel forking (and), where all sequence flows are executed based on this gateway

Parallel joining (and), where all incoming events must be completed prior to the execution of the next event, based on this gateway.

Having different connecting objects helps business people more clearly identify what kind of communication exists between different objects. The connecting objects link all other objects to create the structure and flow of the business process. These connectors also make sure that the information can be pushed forward throughout the organization. There are three different types of flows:

Sequence flows, used to show the order of events performed within the business process. The sequence flow is indicated by a solid line with a solid arrowhead.

Message flows, used to indicate the message flow between different process entities. This sequence is indicated by a dashed line with an open arrowhead.

Association flows, used to associate different artifacts with flow objects. The association is represented by a dotted line with an outlined arrowhead.

Business analysts prefer to see who does what within a business process, to demonstrate the different capabilities and responsibilities. To identify this in an orderly way, BPMN uses so-called swimlanes. Swimlanes categorize the different responsibilities by visual class. To differentiate businesses and different roles, users, or systems, BPMN uses two types of swimlanes: pools and lanes. Pools identify the participants within a work flow, and are distinct from activities in other pools. Often, pools represent different organizations in B2B situations. Within a pool, lanes indicate who executes what within the organization, and where the activities occur, in order to give a better overview of the process.

Sequence flows cannot exceed the boundaries of a pool, as a pool represents a self-contained process.

However, sequence flows can cross lanes within a defined pool. Message flows define the communications between the different pools (organizations), but cannot be used within the same pool or lane.

One caveat: swimlanes can make the process overly rigid. Certain tasks may be performed by different roles, which is difficult (if not impossible) to portray in swimlanes. Swimlanes work well in a system-centric process flow, but for human-centric processes they may put artificial constraints on the design. That is why vendors such as Pegasystems have the ability to disable or enable swimlanes within the modeling tool.

BPMN provides additional context for specific situations (for example, by identifying vertical markets). This additional information can clarify the process within the modeling phase. BPMN created three types of artifacts to provide additional context within the workflow:

Data objects explains how data is used or required for activities and connected by associations.

Groups (indicated by a dashed rectangle line) have no effect on the sequence flow, but are primarily used for analysis purposes and documentation.

Annotations provide additional text to explain certain processes within the diagram.

The BPMN-WG created structure in the chaos that can exist between modeling tools and notations (as well as between IT and business people) by developing BPMN as a unified notation method. For the development of this unified method, the BPMN-WG used the best elements of different notation methods such as unified modeling language (UML) activity diagrams, integrated computer-aided manufacturing definition languages (IDEF), activity decision flow (ADF) diagrams, RosettaNet, and event process chains (EPCs). This has created a wide acceptance of different business process management systems, such as Lombardi, Ultimus and Vision Software.

BPMN maps directly into BPEL4WS. This bridges the gap between process modeling notations and execution languages, enabling business users to take care of the execution part of the workflow without the involvement of IT departments.

Even though BPMN is a relatively new concept, it has gained great support from vendors and users. Both vendors and end users see the benefit of having a unified methodology that enables better understanding of (and integration with) other systems and standards. Feedback on its ease of use and on problems concerning integration and modeling (as well as suggestions regarding better performance, new functionality, and integration) will contribute to the improvement of the specifications and integrations with execution engines. The BPMN-WG of BPMI will continue working on standardizing elements of BPMN and sets of artifacts supporting verticals. It will also work on the ability to model business rules and business strategies in order to continuously improve organizational efficiency.

The BPMI has merged with the Object Management Group (OMG) with respect to its BPM activities, in order to provide leadership and standards throughout the industry. This merger helps the development of BPMN, as OMG is an international industry consortium that develops enterprise integration standards. The OMG manages an open, vendor-neutral process which proposes technologies, and invites proposals and feedback from any member company before coming to a consensus on a final specification (which then becomes an adopted standard). Some of the standards the OMG has developed include common object request broker architecture (CORBA), UML, and Internet inter-object request broker protocol (IIOP).

Standardizing modeling notations used by vendors, business analysts, and IT departments will improve the management of business processes (along with collaboration between business and IT) by providing a better integration with legacy systems. Using BPMN enables the communication of processes throughout the organization. BPMN extends towards other modeling methodologies, such as relational data modeling, XML schema designs, and system designs, which enables organizations to design the full enterprise architecture. In the long term, BPMN will provide a solid notation methodology, as almost all major BPM vendors have already adapted this technology into their solution. Even though BPMN is relatively new, thanks to the support it receives from both vendors and end users, it will lead the development of modeling notation standardization.

BPMN will also impact software selection for end users. Organizations currently evaluating BPM applications should consider whether vendors are using (or plan to use) the BPMN notation method, as BPMN is the best available notation method at the moment. BPMN enables easier design, implementation, and communication between different parties, both internally and externally. In particular, for organizations that need to communicate within their business processes with third party organizations, a standard notation methodology becomes essential to optimize and increase efficiency in the processes. During the selection process, organizations should focus on vendors that are BPMN-compliant. BPMN compliance alone is not enough, however, as organizations need to make sure that the solution integrates its modeling notation with a business rules engine, for process automation, and to fully benefit from these standards. This way, business users can develop the business process directly to the BPM rules engine, instead of switching to other modeling and notation languages to automate the process.

Organizations with purely internal business processes (in other words, with no interactions with third parties) should focus on vendors that are either BPMN-compliant, or that have it in scope to become compliant. Even though using a standard is beneficial, it's not essential for such organizations.
Organizations that have many interactions and data transfers between themselves and third parties should consider vendors that use BPMN in combination with integration to execution languages such as BPEL4WS, to improve the quality of interactions between the different organizations, and to increase the efficiency business processes by virtue of the fact that all parties will be talking the same language.
http://www.technologyevaluation.com/

ADVERTISEMENT

Splitting Demand from Supply in IT
From McKinsey Quarterly/David Mark and Diogo P. Rau
Many companies, in their zeal to improve IT's ability to meet business needs, have brought teams of IT developers into the business units they serve, even as those companies are centralizing the larger core of basic IT services. Although moving IT into the business helps to align development efforts with business goals, it also has the unfortunate consequence of fragmenting IT developers across business and functional units, so coordinating and prioritizing projects becomes harder. In two business units separate teams, using different vendors and technologies, may simultaneously be creating similar applications. Business units may be satisfied with the short-term results, but the company as a whole may suffer from high development costs, poorly managed performance, and difficulties deploying cross-group functionality.

At the other end of the spectrum, companies that have focused on efficiency through centralization have struggled with agility and speed in developing applications. Business units can become frustrated by long delays in the deployment of needed capabilities, and IT may be viewed as an unresponsive bureaucracy, a black hole for business requests.

So how can companies achieve both agility and efficiency in application development? Some leading-edge companies are disaggregating the problem by splitting supply from demand. They create both IT supply units (such as centers of excellence or shared application-development groups) and demand units that act as tech-savvy intermediaries between the business and IT to coordinate requests across business units (Exhibit 1). In this model demand units typically reside within IT, officially reporting to the CIO, although they have responsibilities to the business and IT and may be run by both jointly. They work closely with each business to understand its needs and opportunities. They then work with IT suppliers--in some cases, internal application-development teams, in others outsourced providers--to translate the business's needs and opportunities into specifications for new IT projects.

Creating this kind of demand management offers several advantages. First, it introduces internal market discipline by providing the business units with expert buyers--tech-savvy managers who combine an intimate understanding of client needs and a familiarity with the supply market. At a major financial institution, business users felt that IT was responsive, but developers were spending too much time implementing low-value enhancements, and no one had been looking at the larger issues of how the institution's technology investments should evolve. The company solved these problems by creating an IT demand organization, which improved its ability to plan a technology path and to track the commitments between IT and each of the business units.

A second benefit of this structure is better coordination of requests from various business units. As a result the demand managers can purchase IT services and supplies in larger volumes, increasing the efficiency of a company's IT resources, avoiding duplication, and encouraging standards and reuse. The near-term benefits include better coordination and prioritization of efforts; the longer-term benefits include faster deployment of enterprise-wide capabilities and a well-defined technology road map. In a European telco that moved to this type of demand model for IT and network management, a typical project's return on investment increased by an order of magnitude.

Furthermore, because the IT suppliers, whether internal or external, are working with a more technologically savvy customer, the speed and quality of delivery improve. A software provider that split its supply and demand organizations improved its customers' satisfaction significantly within six months, largely because the demand organization, as a well-prepared customer advocate for the business, could work more effectively with the supply organization.

Benefits accrue to IT professionals as well. When developers are consolidated into fewer supply organizations, centered on their expertise, professional development improves and broader career paths become available to IT staffers, who also like working with more technically sophisticated customers.

Beyond the operational benefits, several trends are helping to accelerate the division of supply and demand. The growing availability of outsourcing and offshoring options increases the attractiveness of the model, since suppliers can be either internal or external. Organizations are no longer limited by the size of their in-house staff, so solid demand management becomes even more important, lest business units overspend on multiple external providers. Another trend is the increasing "productization" of IT; in other words, IT standardizes its operations by using a limited portfolio of infrastructure products rather than building systems to order. With this approach, the designers, who create the specifications for a system or product, can focus on the business problem, letting the supplier determine the requirements for hardware, software, and storage. Third, IT and its evolving capabilities increasingly shape business processes, so that work flow changes go hand in hand with IT changes. Implementing a modern customer relationship management (CRM) system for a sales force, for example, almost certainly requires a change in the work flow, and a demand organization would be well positioned to harmonize the process and IT changes.

Our early work with a number of companies has allowed us to identify several factors for success in setting up demand-management and supply organizations. First, companies must understand the common ways to manage demand, as well as how the new organization can improve them. Also, the new organization should be structured correctly and must get the right type of talent into the important new roles. Demand managers must understand the business processes of the internal customer and the capabilities of the IT organization. Aligned with the business units and processes, demand managers should be accountable for fulfilling business requirements. Finally, the demand organization should be centralized to coordinate demand requests across various parts of the company while managing a range of IT suppliers, from in-house staff to outsourcers around the globe.

ADVERTISEMENT

When splitting demand and supply, some companies focus on improving the supply organization. The demand one, however, is what distinguishes this model from the traditional IT setup, and getting demand right is more difficult.

In most cases, business customers and IT are quick to see the potential benefits of a demand organization, so making the necessary changes is usually easy. Defining priorities and areas of responsibility can take more time (and more negotiating), but these often evolve as the demand group begins to work with IT and its internal customers. In our experience, four practices make it easier for the demand organization to succeed in its mission.

Demand organizations align with the business to act as the true voice of customers in clarifying what they mean--which is not always the same as what they say. Consequently, the best structure provides for one demand organization for each business unit, and these demand groups are managed jointly to coordinate requests. Demand managers should have a deep knowledge of their customers' processes and a solid understanding of application development. The ideal background for such a manager includes experience as an application developer and a desire to pursue a management career track. The development of these managers should involve ongoing training in general-management skills or practices, such as Six Sigma, project management, and developing a business case.

Supply organizations, in contrast, may be structured around broader competencies and business processes (such as sales, operations, and back-office functions) or around technologies like online transactions and data warehousing rather than business units. Because supply organizations work with their demand counterparts, which coordinate similar requests among business units, they can make broad decisions in the best interests of the entire organization rather than a single business unit. Getting a single view of the customer, for example, is often a tough challenge in multibusiness enterprises. A sales-focused supply organization, however, could successfully shepherd the CRM platform for the entire company, even if business units continue to operate with separate sales forces.

Since business processes are increasingly shaped by IT solutions, businesses should assign the responsibility for work flow designs to a group that understands the underlying technology as well as the key business pain points. The demand organization has expertise in defining business needs and requirements, so it is well suited to work with business leaders to use IT realistically and effectively to enable processes, avoiding the costly fixes that become necessary when processes fail.

Although this structure may be challenging to implement, placing the responsibility for business process designs in the demand organization is worth the effort: it assigns the definition of processes and requirements to a group that balances the interests of the business with technical knowledge. When technologists write requirements, the designs can be excessively complicated; when business needs are overemphasized, designs can focus on exception cases, becoming excessively specific and inflexible as business needs change. Consider many of the disaster recovery designs implemented by banks in the United States after September 11, 2001. Decision makers, in their haste to improve business continuity, favored redundancy over improved architectures. Because these decisions were shaped by short-term business concerns, banks might not have maximized the value of the large investments they made. A well-positioned process architect, such as a demand organization, could have managed demand effectively, balancing short-term needs and long-term health.

Most companies have too many applications doing similar things, so they periodically have to prune their application portfolio--a costly and time-consuming process. Demand organizations can help prevent this situation from developing in the first place by minimizing the number of IT projects and applications at the time of funding. Managers should avoid silo effects by holding regular meetings among demand organizations to review the project pipeline and identify opportunities for collaboration. In doing so, they help the organization spread investments responsibly. Without such fiduciary behavior, profitable business lines may spend too much on IT or fail to share solutions with other parts of the organization.

The demand organization should free the business units from the complex task of managing a broad range of IT suppliers, both internal and external. Typically, people with the right skills are already in the IT supply organization, where they manage internal teams or outsourced resources. The best option usually is to bring such people into the demand organization, but even this approach is not always straightforward: they will require new training in the needs of the business and skills in managing a broad range of relationships collaboratively. At a logistics company, a manager who moved from IT supply to IT demand was accustomed to fine-grained management (such as how best to operate the servers). He needed several months to learn that his new role required him to focus instead on much broader service levels and efficiency.

In addition to providing for these success factors, the organization must refine the metrics for success and some key processes of project management. Metrics for demand organizations should center on their effectiveness and customer satisfaction. For supply organizations, metrics continue to address cost efficiency and quality. The organization also must change its processes, especially those for project funding and software development.

In the traditional models, business units frequently finance their own application-development projects. While they're often satisfied with their return on investment, the company as a whole may spend more than it should. With the introduction of a demand-management organization, the business and its demand group should work together to define a capabilities strategy that shows how the application portfolio must change to achieve business goals. The entire demand organization should then coordinate with the business units to make enterprise-wide funding decisions, based on this strategy, that include not only individual projects but also longer-term decisions on architectures and application portfolios.

The demand-supply model also requires changes in the software-development process. Typical projects go through five phases: envision, design, build, test, and deploy (Exhibit 2). In traditional models, the business customer envisions and then IT designs, builds, tests, and deploys. Unfortunately, what is delivered may not be what the business envisioned. In the demand-supply model, the demand organization drives this envisioning phase regardless of whether the original idea came from the business, the demand organization, or the supply organization. The demand group brings the business and the supply organization into one conversation to explore ideas, which the demand organization ultimately translates into a business requirements document. The supply organization then manages the next phases: technical design, building, and testing. The demand organization will be involved during those phases and draw in the business as needed. For developers, this approach provides the best proxy for the business customer whenever they have questions or ideas. At deployment, the business carries out acceptance testing, as in the traditional model, but the demand organization provides expertise if problems arise.

Creating a demand organization requires patience and persistence, and it isn't for every company; those with highly stable business needs or a single core business, for example, may not need this model. To make sure IT demand gets off on the right foot, companies should clearly define the role and scope of the demand group and make sure the details are understood by everyone involved--the business as well as the demand and supply groups.

Common mistakes include letting the demand organization focus too closely on a single business unit or on the supply organization's processes. Either pitfall can distract the demand group from its higher mission of enterprise-wide efficiency. Transparent communication of key metrics is, of course, critical--not just between demand and supply but also with senior managers who will be tracking the new organization's success.

As organizations implement and experiment with this approach, we expect to see extensions of the model. Consumer companies with complex products could introduce a customer advocate organization that represents the customers' needs to the supply organization. Or business functions other than IT could adapt the model; for example, a legal department could serve internal customers in the same way. In these and other cases, sound demand management would help many organizations improve their total productivity.

Organizations that are switching to the demand-supply model enjoy significant gains in productivity and prioritization of investments. Organizational complexity decreases, requirements are better defined, and even the perception of IT improves. Most important, business customers should begin to receive the most value for the resources invested.

David Mark, a director in McKinsey's global IT practice, is based in the Silicon Valley office. Diogo Rau, a consultant who focuses on IT governance issues, is based in San Francisco. The authors wish to thank Sam Marwaha, Joe Newsum, Roger Roberts, Jeff Schumacher, and Paul Willmott for their contributions to this article.
http://www.mckinseyquarterly.com/


Understanding Supply Chain Risk: A McKinsey Global Survey
From McKinsey Quartley
Nearly two out of three executives who responded to the latest global survey of business executives conducted by The McKinsey Quarterly say they face increasing risks to their ability to supply their customers with goods and services cost effectively. The McKinsey Quarterly conducted the survey in September 2006 and received 3,172 responses from a worldwide panel of executives at publicly and privately held businesses across a full range of industries. Here is a brief summary.

The executives identify a wide variety of risks; topping the list is the availability of well-trained labor. Few executives express confidence in their company's ability to manage these risks successfully, and companies are making surprisingly little use of some well-known tools that could help.
Notes

Rising risk: Most of the surveyed executives say supply chain risk is growing. The executives most likely to say that their company's level of risk has risen are those in retailing, manufacturing, and energy; those in the energy industry are by far the most likely to say their risk has increased significantly. Professional-services executives are the least likely to have seen an increase in risk, but even there, nearly half have done so. Executives at all levels share the view that risk is on the rise.

Labor tops the list: The executives rank labor, regulation, and suppliers as the top three supply chain risks on which they focused during their most recent round of planning. Among all risks, the clear leader is the availability, cost, and quality of labor. Labor is the concern cited most often in every region of the world except Latin America, where regulatory issues are by far the biggest concern. Executives at the smallest companies (those with annual revenues under $500 million and with fewer global resources) are also particularly likely to say that labor is a problem. Among respondents who identify labor as a significant issue, almost two-thirds are primarily concerned about the availability of well-trained labor. Indeed, though the level of concern varies somewhat, a shortage of high-quality employees remains the top issue among those concerned about labor, regardless of their company's size or location. Among those concerned about labor, labor cost is their biggest worry; only 3 percent of them cite labor disruptions and less than 1 percent of this group cite diseases or pandemics.

Too many risks, too little time: What are companies doing to mitigate their increasing risk? Executives cite a range of actions; of these, entering into performance contracts with suppliers is cited most often. Actions that could mitigate labor-related risk are rarely mentioned.

What might help: Executives say they're making surprisingly little use of some well-known tools and techniques that could help them assess the business landscape and manage risks more effectively. For example, more than half of all respondents say their company either undertakes no formal risk assessment or conducts only a qualitative assessment. Even when companies do use quantitative assessments, most executives are not using tools tailored to their specific circumstances. Executives who consider their company to be extremely capable of managing risk, however, are more than twice as likely to say they use detailed analyses of cash flow at risk--36 percent say so--and are far more likely to use tools tailored to their company's risks.

Sarbanes-Oxley and risk: Only 18 percent of respondents believe that the Sarbanes-Oxley reporting requirements help them reduce their supply chain risks. Executives below the top level of their organization, who are more likely to be dealing with the details of meeting these reporting requirements, are nearly three times as likely as those at the top to say that Sarbanes-Oxley has been helpful.
For the complete survey and exhibits, go to:
http://www.mckinseyquarterly.com/

ADVERTISEMENT

Offshoring of Back-Office Functions Could Generate $58 Billion in Annual Savings for Fortune 500
From Hackett Research
The Fortune 500 could potentially save $58 billion annually, or over $116 million on average per company, by offshoring many of their back office activities, according to research from The Hackett Group, a strategic advisory firm and an Answerthink company. Advances in technology, along with increasingly educated global work forces, enable the portability of business support activities across information technology (IT), finance, human resources (HR) and procurement to take advantage of labor arbitrage. Hackett estimates that the increased use of offshore resources may impact up to 1.47 million general and administrative (G&A) jobs, or nearly 3,000 at a typical Fortune 500 company.

According to Hackett's research, globalization has created an environment where executives must constantly re-evaluate their cost structures for general & administrative (G&A) operations against a new host of emerging global resources. Hackett also found that the best companies are strategically improving performance in finance, IT, HR, procurement, working capital, and other areas in ways that help them respond to the pressures of globalization.

However many companies are relying on outdated sourcing analysis techniques that lead them to materially underestimate the benefit available through off-shoring back office operations. With labor arbitrage savings nearing 60%, Hackett finds that executives must analyze their process optimization opportunities to capture the potential value of centralization. Many organizations fail to examine the characteristics of business processes, allowing activities that provide no competitive advantage to remain decentralized in industrialized countries at a higher cost. Distributed activities are generally not portable, and therefore not included within the scope of a globalization initiative. The education base and skill sets available in India, China, The Philippines, Pakistan, Eastern Europe, Brazil, and other emerging countries continues to expand, offering a new level of savings combined with improved quality and talent, significantly strengthening the business case for globalization.

Companies have long been aware that they can take out cost and improve back office efficiency by streamlining businesses processes, improving the way they use technology, and centralizing operations, either in a shared service center or with an outsourcer. But over the past few years, the resources available offshore have matured rapidly, creating immediate opportunities to materially reduce companies' cost structures," said Hackett Managing Director Julio Ramirez.

According to Hackett Managing Director Michel Janssen, "Today, companies can turn to established offshore resources that deliver labor costs reductions while maintaining or even improving the skill level of staff. The potential savings of up to $116 million annually for a company are simply too compelling to ignore. Yet most executives will miss the potential impact of service globalization due to the under-scoping of initiatives.Taking full advantage of service globalization requires a deep understanding of the nature of business processes and how they can be optimally organized and delivered."

Having said this, companies still must use a well-balanced assessment methodology that fully considers the business strategy, culture, transactional characteristics and readiness for change. By taking the broadest logical view of the processes in scope combined with a holistic evaluation methodology firms can ensure that they are maximizing the benefit opportunities available through global markets while managing the risk associated with these progressive transformation initiatives.

Hackett's analysis of the Fortune 500 draws upon ongoing benchmark studies that have captured outsourcing costs since 1992. While IT represents the largest functional opportunity, significant savings can be generated in other G&A areas, including finance, HR, and procurement. Hackett's analysis of the savings opportunity breakdown for a typical Fortune 500 company is based upon the median number of FTEs per process group, labor arbitrage cost differential, and the potential degree for offshoring by process group.To see the full version of this research, please go to:
http://www.thehackettgroup.com/


Click here to subscribe or renew your subscription to Global Logistics & Supply Chain Strategies magazine