Industrial Management & Data Systems

Emerald Article: End-to-end business process scenarios Douglas W. Frye, Thomas R. Gulledge

Article information:
To cite this document: Douglas W. Frye, Thomas R. Gulledge, (2007),"End-to-end business process scenarios", Industrial Management & Data Systems, Vol. 107 Iss: 6 pp. 749 - 761 Permanent link to this document: http://dx.doi.org/10.1108/02635570710758707 Downloaded on: 02-04-2012 References: This document contains references to 15 other documents To copy this document: permissions@emeraldinsight.com This document has been downloaded 1877 times.

Access to this document was granted through an Emerald subscription provided by Maastricht University For Authors: If you would like to write for this, or any other Emerald publication, then please use our Emerald for Authors service. Information about how to choose which publication to write for and submission guidelines are available for all. Additional help for authors is available for Emerald subscribers. Please visit www.emeraldinsight.com/authors for more information. About Emerald www.emeraldinsight.com With over forty years' experience, Emerald Group Publishing is a leading independent publisher of global research with impact in business, society, public policy and education. In total, Emerald publishes over 275 journals and more than 130 book series, as well as an extensive range of online products and services. Emerald is both COUNTER 3 and TRANSFER compliant. The organization is a partner of the Committee on Publication Ethics (COPE) and also works with Portico and the LOCKSS initiative for digital archive preservation.
*Related content and download information correct at time of download.

The current issue and full text archive of this journal is available at www.emeraldinsight.com/0263-5577.htm

End-to-end business process scenarios

Douglas W. Frye
Enterprise Integration, Inc., Alexandria, Virginia, USA, and

End-to-end business process scenarios 749

Thomas R. Gulledge
Enterprise Integration, Inc., Alexandria, Virginia, USA and George Mason University, Fairfax, Virginia, USA
Abstract
Purpose Enterprise integration endeavors are complex because they compel an organization to understand how its cross-organizational business processes are enabled by multiple systems. For any large-scale implementation project, specic business process and system information is included in the enterprise-solution architecture. To understand the totality of any organizations business processes, managers must dene and document all core and support processes. Design/methodology/approach The examples used in this paper are from large public sector organizations, but the underlying methodology and conceptual basis for the paper apply to any complex organization. Findings The main conclusion of this paper is that end-to-end (E2E) business process scenarios must be used for dening the requirements for any system implementation project in any organization. If the new system does not align with the E2E-business processes, then management requirements cannot be realized. We also note that E2E scenarios must be considered when implementing enterprise software in a non-enterprise environment. Originality/value The paper notes that E2E scenarios represent the requirements denition level for composite applications enabled in a service-oriented architecture (SOA). Traditional implementation methodologies that enable standard software modules (or integration scenarios across modules) are not effective in non-enterprise environments. Keywords Process management, Business enterprise, Control systems Paper type Research paper

Introduction The typical enterprise implementation environment is highly complex. Seldom does an organization implement all of its business processes using a single software product, and this compels organizations to understand how their business processes are enabled by multiple systems within the enterprise. Enterprise systems are designed to contain most enterprise business processes, in a manner in which Gulledge (2006b) has termed Big I integration. We have found, however, that this is seldom the case. Most enterprises have business processes enabled by many systems, and in some cases, even by multiple-enterprise systems, which Gulledge terms Little I integration. In fact, we nd this to be the norm as opposed to the exception. Companies implement enterprise software products, but they seldom implement them across the entire enterprise. We refer to this situation as implementing enterprise software in a non-enterprise environment. Most enterprise system initiatives begin as a conceptual rendering of required business functions. As initiatives mature, additional information on requirements

Industrial Management & Data Systems Vol. 107 No. 6, 2007 pp. 749-761 q Emerald Group Publishing Limited 0263-5577 DOI 10.1108/02635570710758707

IMDS 107,6

750

becomes available, but to understand the requirements completely the totality of the business processes must be dened, documented and validated. The examples used in this paper are from public-sector organizations, but the underlying methodology and conceptual basis for the paper apply to any organization dening system requirements within a complex technology landscape. Our ndings relate directly to implementation success. Information systems enable business processes, and if the business processes are not formally aligned with systems, then it is unlikely the systems will meet management expectations. As noted by Gulledge (2006a), this is a major source of requirements-denition failure in implementation projects. A business process is a sequence of functions executed by organizational units, according to appropriate process logic, using necessary data. This ensures that an overriding task (relating to certain objects) is carried out fully (Kirchmer, 1999). In lay terms, a business process is a sequence of activities executed to perform a particular task. Since, sequences are ordered with respect to time a business process is, by denition, dynamic. Since, managers are interested in how work is performed, business process knowledge is critical for controlling and improving work performance and output. Optimized-business processes result in lower cost, and in many cases, competitive advantage (Bose, 2006). Some business processes are executed manually, but others can be automated. In fact, the management information systems discipline is by and large about how to best automate business processes. Information technologies and systems can be used to eliminate manual steps, making processes more efcient, reducing errors, and improving cycle times. Perhaps, most important is that automating business process steps also produces information which may be used to measure performance and provide input for decision support. Business processes enable enterprise productivity, and technologies and systems enable business processes. However, aligning business processes with technologies and systems is often a challenge. Executives dene organizational priorities and objectives, and managers are responsible for ensuring that the business processes are executed to meet priorities and objectives. Alignment involves ensuring the systems and technologies are properly aligned with the business processes. Understanding and documenting end-to-end (E2E) business-process scenarios is consistent with a three-tiered solution framework, as shown in Figure 1. The alignment shown in Figure 1 is not automatic, and misalignment is the source of many organizational problems. A properly designed enterprise integration framework must include alignment across all three levels. Enterprise integration is the alignment of strategies, business processes, information systems, technologies, and data across organizational boundaries to provide competitive advantage. The process of achieving enterprise integration includes all managerial and technological factors that enable cross-functional process integration. The result is a customer-oriented management structure with information systems formally linked to processes and the integration of processes needed to establish and retain customer satisfaction. This denition of enterprise integration also means that business processes ow across organizational boundaries, which adds signicant complexity to business-process management. Managers manage business processes implicitly or explicitly. Even if no explicit documentation and management approaches are in place, work is still accomplished,

Vision

Strategic Goals Objectives

Business Strategies are formally linked to Business Processes

STRATEGY
y l ic Po

End-to-end business process scenarios 751

gs Re

Information Systems are formally aligned with Business Processes

PROCESS

SYSTEMS
I

rma nfo tio

rma nfo tio

n
Data

Sy

st e m

Tec y hnolo g

Figure 1. Enterprise integration solution framework

so the processes are managed implicitly; even if that means responsibility shifts from one manager to another with no attempt to coordinate. Explicit management and improvement is desirable, however, so the discipline of business-process improvement is core to the management disciplines. E2E scenarios dened For the purposes of this paper, an E2E scenario documents the ow of event-driven functions across one or more organization and system boundaries. For documentation, we use the event-driven process chain (EPC) as described by Scheer (1998). Our approach recognizes that systems may be responsible for enabling multiple functions, providing a natural requirements denition layer for composite applications. E2E scenarios help answer three key questions for an enterprise in transition: where are we? Where do we want to go? How do we go about getting there? In enterprise architecture terms, E2E scenarios help dene the As-Is the To-Be and the migration path from one to the other. At its most basic level, an E2E scenario shows the high-level functions to be executed in realizing a complex-business process owing across organization boundaries as enabled by multiple-information systems. Bubak et al. (2006) has discussed these relationships with a particular orientation to SAP. In this section, the concepts are presented in general terms from an architecture-driven enterprise integration perspective. A true enterprise-management approach demands an E2E viewpoint that ows unimpeded by the constraints of information systems and organizational boundaries. An example of an E2E scenario is shown in Figure 2. In the gure, the business process ow is documented in swim lanes and, in this case, ows

IMDS 107,6

E2E Scenario for Unserviceable Reparable Processing

752

Figure 2. An example end-to-end scenario

across four systems. If the process is optimized relative to one system while ignoring the others, the E2E scenario as a whole is sub-optimized. As mentioned earlier, it is the totality of the organizations business processes and the optimal combination of system functionalities that should dictate which functions each system executes, as opposed to designating systems to perform functions based on organizational (articial) boundaries. Figure 2 also shows the high-level requirements for a composite application that would enable the E2E process, and it clearly demonstrates the process cannot be decoupled from the systems. In fact, many additional processes may be enabled by the same systems, so it is very difcult to selectively improve any one process without affecting another. This fact is often ignored in enterprise initiatives and portfolio analyses, leading to poorly-scoped projects and portfolios that are impossible to implement. One cannot rank systems for investment purposes without understanding completely the impacts the systems have on all business processes they enable. The gure also illustrates the fallacies of the family of systems approach. Once the systems are built, the processes are bound and there is no potential for additional-process improvement. The main result of this discussion is that collections of scenarios dene solutions. Software boundaries must be aligned with these collections of scenarios, and once the systems are built, the processes are bound. That is, the opportunities for business-process improvement are limited since individual systems are usually tied to multiple processes. This means that even the smallest business process improvement initiatives must consider collections of scenarios and all systems that enable the collection. This certainly has implications for the literature in business process reengineering, but it is often overlooked by process analysts who do not have a good understanding of the underlying systems.

Example: joint deployment and distribution architecture For enterprise-level issues such as how an organizations supply chain should be governed, it is critical to develop a schema which business managers, rather than technology experts, are able to easily understand. There are two key elements impacting how a supply chain is implemented in an organization: complexity and variability (Taylor, 2004). While it is necessary for all parts of a major-business process to be dened, not every detail needs to be shown to all levels of decision makers. Senior executives likely neither know nor care about every detail of how their supply chain works; they simply want to know the supply chain is working as demonstrated in the targets for timeliness, quality, price, and other service-level key performance indicators (KPIs). At the operational level, however, line and mid-level managers must understand the exact functions to be executed in every possible scenario, as within an enterprise environment logistics is handled as a process rather than several independent functions (Bowersox et al., 2002). In the case of a supply chain, the supply chain operations reference (SCOR) model has been developed to provide a best practice denition for supply chain management (Kirchmer et al., 2002). It consists of ve components: plan, source, make, deliver, and return, as shown in Figure 3 (These ve-value chain activities represent Level 1 of the SCOR model). The chevron above the ve components (the JDDA), represents US Transportation Commands Joint Deployment and Distribution Architecture, the case study for this paper. The small symbols to the right of each chevron on the second row are the equivalents of hyperlinks, and indicate there is additional content relevant to the object available at a lower level of decomposition. This is not enough detail for an organization to understand how it manages its supply-chain processes; additional granularity is required. The SCOR model, for example, encompasses three levels of detail, with Deliver Stocked Products (part of Deliver levels 2 and 3) shown in Figure 3, which would have been accessed by clicking on the small icon to the right of the Deliver chevron shown in Figure 4. With the reference model established, an organization is able to align its unique processes, what may be considered Level 4 to the reference model, as shown in Figure 5. The next level of detail Once the reference architecture and the high-level SCOR business processes have been aligned with the organizational-specic processes at level-4, E2E process analysis is possible, perhaps including external organizations that comprise the Extended Enterprise. In Figure 6, an actual E2E-business process produced in workshops with the US Army shows the process steps accomplished (the green boxes), the systems used to accomplish them (the blue boxes at the top of the gure), and the organizations

End-to-end business process scenarios 753

JDDA

Plan Plan

Source Source

Make Make

Deliver Deliver

Return Return

Figure 3. SCOR reference model level 1

IMDS 107,6

754

to which the systems belong (found at the top of the gure). This builds the connection to the system level, and it also shows the organization how to align the data that are used to enable the E2E business processes. A private sector example of long-range direct shipping (LRDS) logistics is explored by Caputo et al. (2005). This is an important point. True E2E scenario analysis begins at level-4 of the SCOR model. Levels 1-3 of the SCOR model provide a neutral reference mapping that all organizations in the extended enterprise can agree upon, and the SCOR model provides KPIs that can applied across enterprises. This last point is the most critical reason for using the SCOR model. If the KPIs delivered with the SCOR model are adopted, then cross-organizational performance benchmarking is possible. If each organization denes its own KPIs, then it is unlikely they will agree, and benchmarking for the extended enterprise is impossible. This is especially true in a tightly-coupled, just-in-time (JIT) environment (Kros et al., 2006), one example of which is the American information technology seller Dell (Frye, 2004). This E2E business-process scenario approach provides a unique capability to drive solutions from strategy, through business process, and all the way down to the actual data that enable the systems. Some organizations are able to support two of our three levels and do their best to support the third or perhaps partner with another rm to meet the need, but a complete solution requires that all levels be simultaneously architected and managed throughout the solution process.

Deliver Stocked Products

Figure 4. SCOR reference model levels 2 and 3

Plan and Build Loads (m-t-s) D15

Route Shipments (m-t-s) D16

Select Carriers and Rate Shipments (m-t-s) D17

Receive Product at Warehouse D18

Pick Product (m-t-s) D19

Ship Product (m-t-s) D1.12

Figure 5. Aligning organization-unique processes to the SCOR-based reference architecture

Schedule movements D1.12.2

Position transportation resources D1.12.3

Move conveyance to intermediate / transit point D1.12.4

Process shipment at intermediate / transit point D1.12.5

Move shipment to final delivery point D1.12.6

End-to-end business process scenarios 755

Figure 6. Part of an actual inter-organizational order fulllment E2E scenario

Applying the E2E business-process approach We have tested the architecture-driven approach using E2E business-process scenarios on several international and US organizations, in both government and commercial settings. We believe this architecture-driven methodology addresses an organizations strategic, process, and data priorities. To understand how the business processes are executed and to set the stage for analysis, the entirety of each distinct process variant must be documented, including how the processes interact with each other and the enabling information systems. Functions executed by people who belong to organizations use systems to do their individual jobs. Each function uses, creates and/or transforms data. There are several key elements involved in developing high-quality E2E scenarios. Without any of the following, the E2E-design process will be less likely to produce accurate results: Senior leadership support Ultimately, what is important to senior leaders will be important to those who work for them. The rst goal of any effort is to convince decision makers that a proposed course of action is the best way to proceed. The benets of drafting E2E-business processes will be discussed in more detail later in the paper.

IMDS 107,6

756

Access to subject matter experts (SMEs) While it is often possible for non-experts to draft business processes from sources such as an SAP solution map, the only way to compose an accurate, organization-unique business process is through leveraging the knowledge of experts who perform the organizations business every day. The SMEs can dene processes using the terminology of the business. In many organizations, business processes that are currently targeted for reengineering are not enabled by commercial-enterprise software, and the SMEs are the only ones who know precisely how the work is executed inside the organization. It is imperative to bring in experts from all business processes during the denition phase, as SMEs will often know their own function very well but will not have a complete grasp of how their segment ts within the business process as a whole. A common repository of the functions to be performed and of the systems used in enabling the business processes In many cases, there is no lexicon in an organization describing which functions are enabled and which systems are used. The implication of this shortcoming on an architecture whose true strength is based on its ability to serve as a decision-support system to leadership is substantial. Without a common reference to functions and systems throughout an architecture, the reporting functionality of architecting software tools is severely limited. As indicated by Gulledge (2006a, b), the true strength of any architecture methodology and its associated tool is its ability to demonstrate how required business processes are enabled and to show how standard software may be leveraged to replace legacy systems. This replacement process must be accomplished with some level of comfort that the new standard software can actually satisfy the organizations business-process requirements. In the business process gap is too wide, then custom development or a search for third-party vendor applications may be required. Facilitators In workshops, it has become clear that the mindset required for successfully documenting an E2E-business process at the relatively high level of abstraction required for management-decision support is not an easy task for SMEs. Rather, their job requires them to know everything there is to know about their concentrated area. If the SMEs are forced out of that frame of reference, signicant discomfort is the typical result. In order to overcome this limitation, a facilitator with a patient but OK, lets keep our eye on the ball mentality is required. Facilitators with this skill-set are an absolute requirement. Methodology Given the dynamics of facilitated workshops, it is critical to have a valid methodology established in advance of the workshops. We have found that it is worthwhile to clearly explain the focus of the analysis at the 10,000-foot level, and it is also desirable to create a strawman initial scenario as opposed starting with a blank computer screen, and composing a narrative of the business process being modeled and any assumptions to be used to guide the scenario composition.

Enterprise architect While a supporting role, the architect in charge of actually documenting the business process is very important. If the architect does not possess sufcient experience or mastery of the modeling tool mistakes will be made and the business-process architecture will suffer. We can only say that from personal experience, the E2E-business process workshops have beneted from a strong modeling team supporting the workshops. These are the steps we have followed with success. Step 1: Dening the As-Is Once the stage is set for the workshops to occur, actual scenario modeling may begin. The rst task in documenting the business processes is to determine how the organization currently accomplishes its mission and strategic goals. In doing so, business processes, if not already dened, must be documented in workshops. The modeling literature is quite clear on how much effort should applied in this case. The As-Is is only documented to a level that ensures a baseline for measuring improvement. This means the processes are high level and include KPIs. To properly dene the As-Is environment, the following questions must be answered in workshops: . What are the core business processes executed by the organization? . Which groups and individual positions within the organization execute the core business processes? . Which groups outside of the organization are required to execute the core business processes? . How do the groups and individuals inside and outside the organization (also known as the extended enterprise) work together to execute the core business processes? . How do the information systems that enable core business process execution interact with each other, and what information do they exchange? . What are the processes KPIs, and how do they relate to organizational objectives? Step 2: where do we want to go? Dening the To-Be Once the As-Is is dened, the To-Be should then be determined. A common trap organizations fall into is that they ask business process owners to describe how they would execute their processes in a perfect world without a proper understanding that it will almost certainly not be possible for those desires to be fullled. If the perfect world approach is pursued in determining the To-Be environment, it should be made clear that while every effort will be made to accommodate a perfect world, budget and technical realities will force decisions to be made as to what the realized environment will be. Another approach is to dene the business processes based on internal and external requirements, such as organizational policies, laws, regulations and, in the case of the military, doctrine. This is somewhat of a moving target, as these items have the potential to change at any time, but also because waivers may be granted, exempting the project from needing to comply with mandates. Our recommendation is that only those constraints that are almost assuredly going to be in place be considered.

End-to-end business process scenarios 757

IMDS 107,6

An alternative would be to dene the perfect world and then determine whether mandates constraining its realization are still relevant or could be changed. If so, steps may be taken to change the policies or obtain waivers. Once the To-Be scenarios are completed, the portfolio of systems may be mapped to the E2E-business process scenarios, and informed decision support can be provided to the investment decision process. Step 3: How do we move from the As-Is to the To-Be? The migration path Once the As-Is and To-Be are dened, the next step is to determine the transition plan. When developing the migration path, the rst consideration is to understand the timelines of upcoming system implementation projects/upgrades and the functions they perform. The considerations, discussed below in the context of portfolio management (PfM), are key in making funding and system switchover decisions. Two analytical techniques are particularly useful in envisioning the road to the To-Be end-state. IT evolution diagram. This diagram shows the systems currently in operation, their shutdown dates, the systems replacing them and the new systems deployment dates. This diagram is a high-level tool for management to use when analyzing when signicant periods of transition will be taking place and allows decisions to be made for matters such as ensuring key personnel will be available during switchovers. If this type of analysis is not completed, E2E business-process alignment is problematic. Gap-t/gap-overlap. This analysis shows how the systems replacing the legacy systems accomplish the organizations objectives through the business processes. If the processes are engineered to align with the objectives, then organizational effectiveness is enhanced. A properly executed analysis shows where gaps in functionality may exist as well as where the same function may be performed by more than one system. With this information, a decision may be made to turn off the duplicative functionality or, when that is not possible, to be certain that one of the alternatives is designated as ofcial, and is used as the single source of truth for that functionality. PfM a critical activity enabled by E2E-business processes PfM is the practice of determining the set of information systems to be functioning at a particular time and their associated business process requirements. A key element of PfM is to ensure that systems enable the processes as aligned with organizational objectives. A common-business process and system repository is absolutely required for successful PfM. As mentioned earlier in the paper, all employees in an organization must have common naming conventions for business processes and systems. When the same business process or system means different things to different people, the ability to execute PfM is extremely difcult. With a properly accounted-for portfolio, senior leadership is able to consult a single source to evaluate the state of its ability to implement business processes based on current and projected capabilities. Additional-analytical power comes in the ability to evaluate from a high level the impacts and likely solutions for problems that occur when there is a break in a business process. In many organizations, there is no easily-understood resource for senior management to consult when something goes wrong, and this approach shifts the emphasis of PfM. One still has visibility into the

758

investment dollars, but now one can see how an investment actually impacts the business. When the processes are documented fully, the As-Is and To-Be architectures are dened, and the portfolio of systems and the series of functions within the organizations business processes are known, senior leadership is able to determine optimal courses of action without need to issue an urgent data call to understand after the fact what has happened. Instead, in a properly dened architecture, reports may be run to determine which business processes are impacted by actual events and what if analysis may be undertaken to see what would likely happen in a given scenario. This is the major benet of combining portfolio analysis with E2E-business process scenarios that are embedded in an enterprise solution architecture. Through the IT-evolution diagram, leadership knows that, unless schedules change, a system will begin shutting off and another will begin standing up at a particular date. This allows for funding that would have been used for the legacy system to be transferred to the new system. The gap-t/gap-overlap analysis enables decision making on which business processes and systems are critical for continued-operational execution. If, for instance, two systems are required for executing the same function within a business process, but for one it cannot be turned off without impacting its other functionality, and for the other it can be turned off without implication, the potential savings in maintenance costs would be a major consideration in making the portfolio decision. Service-oriented architecture (SOA) implementation When the As-Is and To-Be E2E-business processes have been identied, it is possible for an organization to move beyond simple point-to-point interfacing among systems and design more sophisticated information system environments, such as documented in a SOA, in which process segments are bundled as enterprise services, listed in a registry and made available to authorized users throughout the enterprise (Cerami, 2002). In an SOA, the organization must understand not only what its business processes are in great detail but also which chunks of business processes should be made available as services. The role of the enterprise architecture is to ensure there is a blueprint-like depiction of how the business of the organization are executed by new and existing systems, and to what extent business-process segments are denable as enterprise services for use by those who need them to do their jobs. (Kano et al., 2005) Our experience with our clients has shown us that some organizations are more ready than others to develop a SOA and realize it via web services and composite applications. The most basic requirement for an SOA-enabled environment is that people from various parts of an enterprise must be able to access and use services that belong to another part of the organization. When the organizational culture of the enterprise is such that these boundaries are allowed to dictate who has access to which systems, services, and data; agreement from all involved parties must be obtained before an SOA can be implemented. Because, organizations with a diverse culture determine status by data, functional and system ownership, it is a signicant challenge to gain agreement from all involved to make an SOA work. In organizations willing to force collaboration, the challenges, while still substantial, are less.

End-to-end business process scenarios 759

IMDS 107,6

As we noted earlier:
To understand how the business processes are executed and to set the stage for analysis, the entirety of each distinct process variant must be documented, including how the processes interact with each other and the enabling information systems. Functions executed by people who belong to Organizations use Systems to do their individual jobs. Each function uses, creates and/or transforms Data.

760

In an SOA-enabled environment, it is critical to note that people who execute functions using systems and being involved with data will have different levels of entitlement to the systems and the data they contain. Many of these levels of access may be dened based on the position a person occupies. These roles may be dened and simplify the IT departments ability to control how systems are accessed. Exceptions to traditional roles should be exactly that and should only be given out in rare circumstances. In the world of the extended enterprise, in which business processes ow across multiple parts of an organization and even external organizations, such as suppliers, the need to dene exactly which roles have access to which parts of the enterprise must be dened carefully. Only through dening each requirement in a way that is uniform and understood by all, namely the present methodology for constructing an E2E scenario, can this be accomplished. So, at a high level, the E2E business-process scenarios represent the requirements for any composite applications that consume the services that are documented in a SOA. Furthermore, for the E2E scenarios to be consistent in enabling business-process integration, the business-process scenarios must be embedded in an enterprise-solution architecture. Otherwise, the relationships among the business-process scenarios are not dened, and the associated information system portfolio cannot be managed. The main point is that the following concepts must be examined holistically: . E2E business process scenarios; . enterprise-solution architectures; . SOAs; . composite applications; and . PfM for system investment decisions. If the concepts are separated, consistency is lost, and a less than optimal decision is likely to result. Conclusions When properly constructed, E2Es make a major contribution in showing visually how business processes in an organizations As-Is and To-Be states will be accomplished. They are also a powerful tool in enabling PfM at the enterprise level. To be certain the scenarios are accurate, however, it is necessary to have skilled facilitators charged with gathering the information from SMEs. Because, the process is not natural for the participants providing the expert input, care must be taken to have skilled facilitators follow a coherent methodology. Finally, E2E business-process scenarios serve as a decision-support system for senior leaders, enabling them to view the organizations mission as business processes and to see how a break in the process could impact the organization as a whole. Furthermore, E2E business-process

analysis cannot be executed in a vacuum. To understand the relationships among the processes and to ensure consistency, the business processes must be embedded in the enterprise solution architecture. And, if the organization has a strategy for transitioning to a service-oriented landscape, the E2E business-process scenarios represent the high-level requirements for any resulting composite applications.
References Bose, R. (2006), Understanding management data systems for enterprise performance management, Industrial Management & Data Systems, Vol. 106 Nos 1/2, pp. 43-59. Bowersox, D.J., Closs, D.J. and Cooper, M.B. (2002), Supply Chain Logistics Management, McGraw-Hill, Boston, MA. Bubak, O., Farley, R.L., Goebels, C., Gonzalez, P., Gulledge, T.R. and Russell, R. (2006), Implementing SAP from end-to-end business process scenarios, International Journal of Management and Enterprise Development, Vol. 3 No. 5, pp. 419-37. Caputo, A.C., Fratocchi, L. and Pelagagge, P.M. (2005), A framework for analysing long-range direct shipping logistics, Industrial Management & Data Systems, Vol. 105 No. 7, pp. 876-99. Cerami, E. (2002), Web Services Essentials, OReilly, Beijing. Frye, D.W. (2004), Electronic procurement in the private and public sectors, doctoral dissertation, Fairfax, VA. Gulledge, T. (2006a), ERP gap-t analysis from a business process orientation, International Journal of Services and Standards, Vol. 2 No. 4, pp. 339-48. Gulledge, T. (2006b), What is integration?, Industrial Management & Data Systems, Vol. 106 Nos 1/2, pp. 5-20. Kano, M., Koide, A., Liu, T.K. and Ramchandran, B. (2005), Analysis and simulation of business solutions in a service-oriented architecture, IBM Systems Journal, Vol. 44 No. 4, pp. 669-90. Kirchmer, M. (1999), Business Process Oriented Implementation of Standard Software, Springer-Verlag, Berlin. Kirchmer, M., Brown, G. and Heinzel, H. (2002), Using SCOR and other reference models for e-business process networks, in Scheer, A.-W., Abolhassan, F., Jost, W. and Kirchmer, M. (Eds), Business Process Excellence: ARIS in Practice, Springer-Verlag, Berlin, pp. 45-64. Kros, J.F., Falasca, M. and Nadler, S.S. (2006), Impact of just-in-time inventory systems of OEM suppliers, Industrial Management & Data Systems, Vol. 106 Nos 1/2, pp. 224-41. Scheer, A-W. (1998), ARIS-Business Process Frameworks, 2nd ed., Springer-Verlag, Berlin. Taylor, D.A. (2004), Supply Chain: A Managers Guide, Addison-Wesley, Boston, MA. Further reading Erl, T. (2004), Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services, Prentice-Hall, Upper Saddle River, NJ. Corresponding author Douglas W. Frye can be contacted at: douglas.frye@eiisolutions.net

End-to-end business process scenarios 761

To purchase reprints of this article please e-mail: reprints@emeraldinsight.com Or visit our web site for further details: www.emeraldinsight.com/reprints