End to End Business

8/2/2019 End to End Business

1/14

ndustrial Management & Data Systemsmerald Article: End-to-end business process scenarios

ouglas W. Frye, Thomas R. Gulledge

rticle information:

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

rmanent link to this document:

p://dx.doi.org/10.1108/02635570710758707

ownloaded on: 02-04-2012

ferences: This document contains references to 15 other documents

copy this document: [email protected]

his document has been downloaded 1877 times.

ccess to this document was granted through an Emerald subscription provided by Maastricht University

r Authors:

you would like to write for this, or any other Emerald publication, then please use our Emerald for Authors service.

formation about how to choose which publication to write for and submission guidelines are available for all. Additional help

r authors is available for Emerald subscribers. Please visit www.emeraldinsight.com/authors for more information.

bout Emerald www.emeraldinsight.com

ith over forty years' experience, Emerald Group Publishing is a leading independent publisher of global research with impact in

siness, society, public policy and education. In total, Emerald publishes over 275 journals and more than 130 book series, as


2/14

End-to-end business processscenariosDouglas W. Frye

Enterprise Integration, Inc., Alexandria, Virginia, USA, and

Thomas R. GulledgeEnterprise Integration, Inc., Alexandria, Virginia, USA and

George Mason University, Fairfax, Virginia, USA

Abstract

Purpose Enterprise integration endeavors are complex because they compel an organization tounderstand how its cross-organizational business processes are enabled by multiple systems. For anylarge-scale implementation project, specific business process and system information is included in the

enterprise-solution architecture. To understand the totality of any organizations business processes,managers must define and document all core and support processes.

Design/methodology/approach The examples used in this paper are from large public sectororganizations, but the underlying methodology and conceptual basis for the paper apply to anycomplex organization.

Findings The main conclusion of this paper is that end-to-end (E2E) business process scenariosmust be used for defining the requirements for any system implementation project in any organization.If the new system does not align with the E2E-business processes, then management requirementscannot be realized. We also note that E2E scenarios must be considered when implementing enterprisesoftware in a non-enterprise environment.

Originality/value The paper notes that E2E scenarios represent the requirements definition levelfor composite applications enabled in a service-oriented architecture (SOA). Traditionalimplementation 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

IntroductionThe typical enterprise implementation environment is highly complex. Seldom does anorganization implement all of its business processes using a single software product,and this compels organizations to understand how their business processes are enabledby multiple systems within the enterprise. Enterprise systems are designed to containmost enterprise business processes, in a manner in which Gulledge (2006b) hastermed 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, evenby multiple-enterprise systems, which Gulledge terms Little I integration. In fact, wefind this to be the norm as opposed to the exception. Companies implement enterprisesoftware products, but they seldom implement them across the entire enterprise.We refer to this situation as implementing enterprise software in a non-enterpriseenvironment.

Most enterprise system initiatives begin as a conceptual rendering of requiredbusiness functions. As initiatives mature, additional information on requirements

The current issue and full text archive of this journal is available at

www.emeraldinsight.com/0263-5577.htm

End-to-endbusiness process

scenarios

749

Industrial Management & Data

Systems

Vol. 107 No. 6, 2007

pp. 749-761

q Emerald Group Publishing Limited

0263-5577

DOI 10.1108/02635570710758707


3/14

becomes available, but to understand the requirements completely the totality of thebusiness processes must be defined, documented and validated. The examples used inthis paper are from public-sector organizations, but the underlying methodology andconceptual basis for the paper apply to any organization defining system requirements

within a complex technology landscape. Our findings relate directly to implementationsuccess. Information systems enable business processes, and if the business processesare not formally aligned with systems, then it is unlikely the systems will meetmanagement expectations. As noted by Gulledge (2006a), this is a major source ofrequirements-definition 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 anoverriding task (relating to certain objects) is carried out fully (Kirchmer, 1999). In layterms, a business process is a sequence of activities executed to perform a particulartask. Since, sequences are ordered with respect to time a business process is, bydefinition, dynamic.

Since, managers are interested in how work is performed, business processknowledge is critical for controlling and improving work performance and output.Optimized-business processes result in lower cost, and in many cases, competitiveadvantage (Bose, 2006). Some business processes are executed manually, but otherscan be automated. In fact, the management information systems discipline is by andlarge about how to best automate business processes. Information technologies andsystems can be used to eliminate manual steps, making processes more efficient,reducing errors, and improving cycle times. Perhaps, most important is thatautomating business process steps also produces information which may be used tomeasure performance and provide input for decision support.

Business processes enable enterprise productivity, and technologies and systemsenable business processes. However, aligning business processes with technologies

and systems is often a challenge. Executives define organizational priorities andobjectives, and managers are responsible for ensuring that the business processes areexecuted to meet priorities and objectives. Alignment involves ensuring the systemsand technologies are properly aligned with the business processes. Understanding anddocumenting end-to-end (E2E) business-process scenarios is consistent with athree-tiered solution framework, as shown in Figure 1.

The alignment shown in Figure 1 is not automatic, and misalignment is the sourceof many organizational problems. A properly designed enterprise integrationframework must include alignment across all three levels.

Enterprise integration is the alignment of strategies, business processes,information systems, technologies, and data across organizational boundaries toprovide competitive advantage. The process of achieving enterprise integration

includes all managerial and technological factors that enable cross-functional processintegration. The result is a customer-oriented management structure with informationsystems formally linked to processes and the integration of processes needed toestablish and retain customer satisfaction. This definition of enterprise integration alsomeans that business processes flow across organizational boundaries, which addssignificant complexity to business-process management.

Managers manage business processes implicitly or explicitly. Even if no explicitdocumentation and management approaches are in place, work is still accomplished,

IMDS107,6

750


4/14

so the processes are managed implicitly; even if that means responsibility shifts fromone manager to another with no attempt to coordinate. Explicit management andimprovement is desirable, however, so the discipline of business-process improvementis core to the management disciplines.

E2E scenarios definedFor the purposes of this paper, an E2E scenario documents the flow of event-drivenfunctions across one or more organization and system boundaries. For documentation,we use the event-driven process chain (EPC) as described by Scheer (1998). Ourapproach recognizes that systems may be responsible for enabling multiple functions,providing a natural requirements definition layer for composite applications. E2Escenarios 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 architectureterms, E2E scenarios help define the As-Is the To-Be and the migration path fromone 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 flowing across organizationboundaries as enabled by multiple-information systems. Bubak et al. (2006) hasdiscussed these relationships with a particular orientation to SAP. In this section, theconcepts are presented in general terms from an architecture-driven enterpriseintegration perspective. A true enterprise-management approach demands an E2Eviewpoint that flows unimpeded by the constraints of information systems andorganizational boundaries. An example of an E2E scenario is shown in Figure 2. In thefigure, the business process flow is documented in swim lanes and, in this case, flows

Figure 1.Enterprise integration

solution framework

STRATEGYVision

Regs

Policy

Objectives

PROCESS

SYSTEMS

Data

Informa

tionSystems

areformal

lyalignedwith

BusinessProcesses

BusinessStrategies

areformallylinke

d

toBusinessProcesses

Systems

Technolog

y

Strategic Goals

Informatio

nInformatio

n


scenarios

751


5/14

across four systems. If the process is optimized relative to one system while ignoringthe others, the E2E scenario as a whole is sub-optimized. As mentioned earlier, it is thetotality of the organizations business processes and the optimal combination of systemfunctionalities that should dictate which functions each system executes, as opposed todesignating systems to perform functions based on organizational (artificial)

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 bedecoupled from the systems. In fact, many additional processes may be enabled by thesame systems, so it is very difficult to selectively improve any one process withoutaffecting another. This fact is often ignored in enterprise initiatives and portfolioanalyses, leading to poorly-scoped projects and portfolios that are impossible toimplement. One cannot rank systems for investment purposes without understandingcompletely the impacts the systems have on all business processes they enable.

The figure also illustrates the fallacies of the family of systems approach. Once thesystems are built, the processes are bound and there is no potential foradditional-process improvement. The main result of this discussion is that

collections of scenarios define solutions. Software boundaries must be aligned withthese collections of scenarios, and once the systems are built, the processes are bound.That is, the opportunities for business-process improvement are limited sinceindividual systems are usually tied to multiple processes. This means that even thesmallest business process improvement initiatives must consider collections ofscenarios and all systems that enable the collection. This certainly has implications forthe literature in business process reengineering, but it is often overlooked by processanalysts who do not have a good understanding of the underlying systems.

Figure 2.An example end-to-endscenario

E2E Scenario for Unserviceable

Reparable Processing

IMDS107,6

752


6/14

Example: joint deployment and distribution architectureFor enterprise-level issues such as how an organizations supply chain should begoverned, it is critical to develop a schema which business managers, rather thantechnology experts, are able to easily understand. There are two key elements

impacting how a supply chain is implemented in an organization: complexity andvariability (Taylor, 2004). While it is necessary for all parts of a major-business processto be defined, not every detail needs to be shown to all levels of decision makers. Seniorexecutives likely neither know nor care about every detail of how their supply chainworks; they simply want to know the supply chain is working as demonstrated in thetargets for timeliness, quality, price, and other service-level key performance indicators(KPIs). At the operational level, however, line and mid-level managers mustunderstand the exact functions to be executed in every possible scenario, as within anenterprise environment logistics is handled as a process rather than severalindependent functions (Bowersox et al., 2002).

In the case of a supply chain, the supply chain operations reference (SCOR) modelhas been developed to provide a best practice definition for supply chain

management (Kirchmer et al., 2002). It consists of five components: plan, source, make,deliver, and return, as shown in Figure 3 (These five-value chain activities representLevel 1 of the SCOR model). The chevron above the five components (the JDDA),represents US Transportation Commands Joint Deployment and DistributionArchitecture, the case study for this paper. The small symbols to the right of eachchevron on the second row are the equivalents of hyperlinks, and indicate there isadditional 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 itssupply-chain processes; additional granularity is required. The SCOR model, forexample, encompasses three levels of detail, with Deliver Stocked Products (part ofDeliver levels 2 and 3) shown in Figure 3, which would have been accessed byclicking on the small icon to the right of the Deliver chevron shown in Figure 4. Withthe 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 detailOnce the reference architecture and the high-level SCOR business processes have beenaligned with the organizational-specific processes at level-4, E2E process analysis ispossible, perhaps including external organizations that comprise the ExtendedEnterprise. In Figure 6, an actual E2E-business process produced in workshops withthe US Army shows the process steps accomplished (the green boxes), the systemsused to accomplish them (the blue boxes at the top of the figure), and the organizations

Figure 3.SCOR reference model

level 1

Plan Source Make

JDDA

Deliver Return

ReturnDeliverMakeSourcePlan


scenarios

753


7/14

to which the systems belong (found at the top of the figure). This builds the connectionto the system level, and it also shows the organization how to align the data that areused to enable the E2E business processes. A private sector example of long-rangedirect shipping (LRDS) logistics is explored by Caputo et al. (2005).

This is an important point. True E2E scenario analysis begins at level-4 of theSCOR model. Levels 1-3 of the SCOR model provide a neutral reference mapping thatall organizations in the extended enterprise can agree upon, and the SCOR modelprovides KPIs that can applied across enterprises. This last point is the most criticalreason for using the SCOR model. If the KPIs delivered with the SCOR model areadopted, then cross-organizational performance benchmarking is possible. If eachorganization defines its own KPIs, then it is unlikely they will agree, andbenchmarking for the extended enterprise is impossible. This is especially true in atightly-coupled, just-in-time (JIT) environment (Kros et al., 2006), one example of whichis the American information technology seller Dell (Frye, 2004).

This E2E business-process scenario approach provides a unique capability to drivesolutions from strategy, through business process, and all the way down to the actualdata that enable the systems. Some organizations are able to support two of our threelevels and do their best to support the third or perhaps partner with another firm tomeet the need, but a complete solution requires that all levels be simultaneouslyarchitected and managed throughout the solution process.

Figure 4.SCOR reference modellevels 2 and 3

Plan and

Build Loads

(m-t-s)

D15 D16 D17 D18 D19

Route

Shipments

(m-t-s)

Select Carriersand Rate

Shipments(m-t-s)

Pick

Product

(m-t-s)

Receive

Product at

Warehouse

Deliver

Stocked

Products

Figure 5.Aligningorganization-uniqueprocesses to theSCOR-based referencearchitecture

Ship Product(m-t-s)

D1.12

D1.12.2

Schedulemovements

Positiontransportation

resources

Moveconveyance tointermediate /transit point

Processshipment at

intermediate /transit point

Moveshipmentto final

delivery point

D1.12.3 D1.12.4 D1.12.5 D1.12.6

IMDS107,6

754


8/14

Applying the E2E business-process approachWe have tested the architecture-driven approach using E2E business-process scenarioson several international and US organizations, in both government and commercialsettings. We believe this architecture-driven methodology addresses an organizationsstrategic, process, and data priorities. To understand how the business processes areexecuted and to set the stage for analysis, the entirety of each distinct process variantmust be documented, including how the processes interact with each other and theenabling information systems. Functions executed by people who belong toorganizations use systems to do their individual jobs. Each function uses, createsand/or transforms data. There are several key elements involved in developinghigh-quality E2E scenarios. Without any of the following, the E2E-design process will

be less likely to produce accurate results:

Senior leadership supportUltimately, what is important to senior leaders will be important to those who work forthem. The first goal of any effort is to convince decision makers that a proposed courseof action is the best way to proceed. The benefits of drafting E2E-business processeswill be discussed in more detail later in the paper.

Figure 6.Part of an actual

inter-organizational orderfulfillment E2E scenario


scenarios

755


9/14

Access to subject matter experts (SMEs)While it is often possible for non-experts to draft business processes from sources suchas an SAP solution map, the only way to compose an accurate, organization-uniquebusiness process is through leveraging the knowledge of experts who perform

the organizations business every day. The SMEs can define processes usingthe terminology of the business. In many organizations, business processes that arecurrently targeted for reengineering are not enabled by commercial-enterprisesoftware, and the SMEs are the only ones who know precisely how the work isexecuted inside the organization. It is imperative to bring in experts from all businessprocesses during the definition phase, as SMEs will often know their own function verywell but will not have a complete grasp of how their segment fits within the businessprocess as a whole.

A common repository of the functions to be performed and of the systems used inenabling the business processes

In many cases, there is no lexicon in an organization describing which functions areenabled and which systems are used. The implication of this shortcoming on anarchitecture whose true strength is based on its ability to serve as a decision-supportsystem to leadership is substantial. Without a common reference to functionsand systems throughout an architecture, the reporting functionality of architectingsoftware tools is severely limited. As indicated by Gulledge (2006a, b), the true strengthof any architecture methodology and its associated tool is its ability to demonstratehow required business processes are enabled and to show how standard software maybe leveraged to replace legacy systems. This replacement process must beaccomplished with some level of comfort that the new standard software canactually satisfy the organizations business-process requirements. In the businessprocess gap is too wide, then custom development or a search for third-party vendor

applications may be required.

FacilitatorsIn workshops, it has become clear that the mindset required for successfullydocumenting an E2E-business process at the relatively high level of abstractionrequired 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, significant discomfort is thetypical 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 arean absolute requirement.

MethodologyGiven the dynamics of facilitated workshops, it is critical to have a valid methodologyestablished in advance of the workshops. We have found that it is worthwhile toclearly explain the focus of the analysis at the 10,000-foot level, and it is alsodesirable to create a strawman initial scenario as opposed starting with a blankcomputer screen, and composing a narrative of the business process being modeledand any assumptions to be used to guide the scenario composition.

IMDS107,6

756


10/14

Enterprise architectWhile a supporting role, the architect in charge of actually documenting the businessprocess is very important. If the architect does not possess sufficient experience ormastery of the modeling tool mistakes will be made and the business-process

architecture will suffer. We can only say that from personal experience, theE2E-business process workshops have benefited from a strong modeling teamsupporting the workshops.

These are the steps we have followed with success.

Step 1: Defining the As-IsOnce the stage is set for the workshops to occur, actual scenario modeling may begin.The first task in documenting the business processes is to determine how theorganization currently accomplishes its mission and strategic goals. In doing so,business processes, if not already defined, 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 measuringimprovement. This means the processes are high level and include KPIs. To properlydefine 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 corebusiness processes?

. Which groups outside of the organization are required to execute the corebusiness processes?

. How do the groups and individuals inside and outside the organization (alsoknown as the extended enterprise) work together to execute the core businessprocesses?

.

How do the information systems that enable core business process executioninteract with each other, and what information do they exchange?

. What are the processes KPIs, and how do they relate to organizationalobjectives?

Step 2: where do we want to go? Defining the To-BeOnce the As-Is is defined, the To-Be should then be determined. A common traporganizations fall into is that they ask business process owners to describe how theywould execute their processes in a perfect world without a proper understanding that itwill almost certainly not be possible for those desires to be fulfilled. If the perfectworld approach is pursued in determining the To-Be environment, it should bemade 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 realizedenvironment will be.

Another approach is to define the business processes based on internal and externalrequirements, such as organizational policies, laws, regulations and, in the case of themilitary, doctrine. This is somewhat of a moving target, as these items have thepotential to change at any time, but also because waivers may be granted, exemptingthe project from needing to comply with mandates. Our recommendation is that onlythose constraints that are almost assuredly going to be in place be considered.


scenarios

757


11/14

An alternative would be to define the perfect world and then determine whethermandates constraining its realization are still relevant or could be changed. If so, stepsmay 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 beprovided to the investment decision process.

Step 3: How do we move from the As-Is to the To-Be? The migration pathOnce the As-Is and To-Be are defined, the next step is to determine the transitionplan. When developing the migration path, the first consideration is to understand thetimelines of upcoming system implementation projects/upgrades and the functionsthey perform. The considerations, discussed below in the context of portfoliomanagement (PfM), are key in making funding and system switchover decisions.Two analytical techniques are particularly useful in envisioning the road to theTo-Be end-state.

IT evolution diagram. This diagram shows the systems currently in operation, theirshutdown dates, the systems replacing them and the new systems deployment dates.This diagram is a high-level tool for management to use when analyzing whensignificant periods of transition will be taking place and allows decisions to be madefor matters such as ensuring key personnel will be available during switchovers. If thistype of analysis is not completed, E2E business-process alignment is problematic.

Gap-fit/gap-overlap. This analysis shows how the systems replacing the legacysystems accomplish the organizations objectives through the business processes.If the processes are engineered to align with the objectives, then organizationaleffectiveness is enhanced. A properly executed analysis shows where gaps infunctionality may exist as well as where the same function may be performed by morethan 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 ofthe alternatives is designated as official, and is used as the single source of truthfor that functionality.

PfM a critical activity enabled by E2E-business processesPfM is the practice of determining the set of information systems to be functioning at aparticular time and their associated business process requirements. A key element ofPfM is to ensure that systems enable the processes as aligned with organizationalobjectives. A common-business process and system repository is absolutely requiredfor successful PfM. As mentioned earlier in the paper, all employees in an organizationmust have common naming conventions for business processes and systems. When thesame business process or system means different things to different people, the ability

to execute PfM is extremely difficult.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 oncurrent and projected capabilities. Additional-analytical power comes in the ability toevaluate from a high level the impacts and likely solutions for problems that occurwhen there is a break in a business process. In many organizations, there is noeasily-understood resource for senior management to consult when something goeswrong, and this approach shifts the emphasis of PfM. One still has visibility into the

IMDS107,6

758


12/14

investment dollars, but now one can see how an investment actually impacts thebusiness.

When the processes are documented fully, the As-Is and To-Be architectures aredefined, and the portfolio of systems and the series of functions within the

organizations business processes are known, senior leadership is able to determineoptimal courses of action without need to issue an urgent data call to understandafter the fact what has happened. Instead, in a properly defined architecture,reports may be run to determine which business processes are impacted by actualevents and what if analysis may be undertaken to see what would likely happen in agiven scenario. This is the major benefit of combining portfolio analysis withE2E-business process scenarios that are embedded in an enterprise solutionarchitecture.

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 betransferred to the new system. The gap-fit/gap-overlap analysis enables decisionmaking on which business processes and systems are critical for continued-operationalexecution. If, for instance, two systems are required for executing the same functionwithin a business process, but for one it cannot be turned off without impacting itsother functionality, and for the other it can be turned off without implication, thepotential savings in maintenance costs would be a major consideration in making theportfolio decision.

Service-oriented architecture (SOA) implementationWhen the As-Is and To-Be E2E-business processes have been identified, it is possiblefor an organization to move beyond simple point-to-point interfacing among systemsand design more sophisticated information system environments, such as documented

in a SOA, in which process segments are bundled as enterprise services, listed ina registry and made available to authorized users throughout the enterprise(Cerami, 2002). In an SOA, the organization must understand not only what itsbusiness processes are in great detail but also which chunks of business processesshould be made available as services. The role of the enterprise architecture is toensure there is a blueprint-like depiction of how the business of the organization areexecuted by new and existing systems, and to what extent business-process segmentsare definable 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 moreready than others to develop a SOA and realize it via web services and compositeapplications. 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 thatbelong to another part of the organization. When the organizational culture of theenterprise is such that these boundaries are allowed to dictate who has access to whichsystems, services, and data; agreement from all involved parties must be obtainedbefore an SOA can be implemented. Because, organizations with a diverse culturedetermine status by data, functional and system ownership, it is a significantchallenge to gain agreement from all involved to make an SOA work. In organizationswilling to force collaboration, the challenges, while still substantial, are less.


scenarios

759


13/14

As we noted earlier:

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

In an SOA-enabled environment, it is critical to note that people who execute functionsusing systems and being involved with data will have different levels of entitlement tothe systems and the data they contain. Many of these levels of access may be definedbased on the position a person occupies. These roles may be defined and simplify theIT departments ability to control how systems are accessed. Exceptions to traditionalroles should be exactly that and should only be given out in rare circumstances.

In the world of the extended enterprise, in which business processes flow acrossmultiple parts of an organization and even external organizations, such as suppliers,the need to define exactly which roles have access to which parts of the enterprise must

be defined carefully. Only through defining each requirement in a way that is uniformand understood by all, namely the present methodology for constructing an E2Escenario, can this be accomplished. So, at a high level, the E2E business-processscenarios represent the requirements for any composite applications that consumethe services that are documented in a SOA. Furthermore, for the E2E scenarios to beconsistent in enabling business-process integration, the business-process scenariosmust be embedded in an enterprise-solution architecture. Otherwise, the relationshipsamong the business-process scenarios are not defined, and the associated informationsystem 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 islikely to result.

ConclusionsWhen properly constructed, E2Es make a major contribution in showing visually howbusiness 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 thescenarios are accurate, however, it is necessary to have skilled facilitators charged withgathering the information from SMEs.

Because, the process is not natural for the participants providing the expert input, caremust be taken to have skilled facilitators follow a coherent methodology. Finally, E2Ebusiness-process scenarios serve as a decision-support system for senior leaders, enablingthem to view the organizations mission as business processes and to see how a break inthe process could impact the organization as a whole. Furthermore, E2E business-process

IMDS107,6

760


14/14

analysis cannot be executed in a vacuum. To understand the relationships among theprocesses and to ensure consistency, the business processes must be embedded in theenterprise solution architecture. And, if the organization has a strategy for transitioning toa 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 performancemanagement, 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-rangedirect 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, doctoraldissertation, Fairfax, VA.

Gulledge, T. (2006a), ERP gap-fit analysis from a business process orientation, InternationalJournal of Services and Standards, Vol. 2 No. 4, pp. 339-48.

Gulledge, T. (2006b), What is integration?, Industrial Management & Data Systems, Vol. 106Nos 1/2, pp. 5-20.

Kano, M., Koide, A., Liu, T.K. and Ramchandran, B. (2005), Analysis and simulation of businesssolutions 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 fore-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 OEMsuppliers, 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 authorDouglas W. Frye can be contacted at: [email protected]


scenarios

761

To purchase reprints of this article please e-mail: [email protected] visit our web site for further details: www.emeraldinsight.com/reprints

End to End Business

Documents

Transcript of End to End Business