Chapter 10Business Process Management Implementation MethodologyIn Chapter 2, we brie?y discussed the process management lifecycle. Inthis chapter, we will expand on the concepts in Chapter 2 and focus onthe essential elements needed to successfully implement a business processmanagement (BPM). We will discuss the steps an organization seeking toimplement BPM can perform. BPM is simply not a technology proposition.We will take a holistic view and look into organizational, functional, andtechnical aspects of implementing BPM.Lessons from Business Process Reengineering (BPR)BPM management practices owe their origins to previous managementpractices. Two in?uential management practices are Total Quality Man-agement (TQM) and BPR. The latter is more relevant because of BPM’sreliance on technology as a key enabler. While BPR had a large followingamong large organizations, it achieved mixed results as discussed inChapter 1. Several factors contributed to BPR implementation failures.238 Several of the factors are related to the BPR enabling technologies. Tohelp formulate a BPM implementation methodology, it is helpful to learnfrom the BPR lessons.In their formulation of BPR management concepts, Hammer, Champy,and Davenport discussed the implementation of BPR at a high level. Themarketplace relied on project methodologies designed by various consult-ing ?rms and ERP companies. These methodologies are based on thetraditional systems of engineering methodologies. There are typically fourphases. The ?rst phase usually involves an analysis of the current state.This includes understanding the current business processes, mapping theseprocesses to the applications that support them, and documenting anyunique requirements that need to be addressed. Areas of opportunity arealso identi?ed. The next phase is designing an Information Technology(IT)–centric solution for the future state. The reason it is IT–centric is thecurrent business processes are compared to the business processes ofthe Enterprise Resource Planning (ERP) system that is to be implemented.The ERP system essentially provides the best practice business processesthe organization should adopt. In cases where there are gaps, workaroundsor custom solutions are designed. At the end of the design phase, theproject should have written design speci?cations for how the systemshould be con?gured and what customized solutions should be built. Afterthe design phase comes the development phase. During this phase,systems are con?gured to the design speci?cations, customizations aredeveloped, and organizational changes are enforced. The last phase is thedeployment of the solution. The deployment phase involves testing thesystems and processes and training the users. The phases are dependentand sequenced. Each phase usually takes one month to six months. Atsome point in the design phase, business requirements are frozen, becausefuture business changes are dif?cult to include in project scope. Thismethodology is typically called waterfall, presumably for its relative in?ex-ibility to revisit completed phases and start work on a subsequent phaseprior to completion of the current phase. As most ERP projects are complexand time consuming, they force the businesses to freeze their businessprocesses until the projects have been implemented. The freeze couldtake from three months to one year, depending on the length of theproject. This is obviously hard for businesses to stomach because mostindustries face changes much more frequently than the imposed freezeperiods. This is one of the major drawbacks of the ERP waterfall imple-mentation methodology.Another common problem of ERP and other IT–enabled businesschange methodologies is the lack of emphasis on change management.Lynne Markus and Robert Benjamin published an excellent article, “TheMagic Bullet Theory in IT–Enabled Transformation,” on this topic in 1997.1Business Process Management Implementation Methodology 239In their article, the authors describe the common belief that the IT solutionis the magic bullet that always ?nds its target. Because the bullet always?nds its target, IT specialists do not feel the responsibility for ensuringthat users are adopting the technology solution. Senior managers also takecomfort in knowing the bullet is always on target, and they turn theprojects over to the IT specialists, who also serve as the convenientscapegoat if the projects fail. The point the authors want to make withthe magic bullet theory is most projects do not follow change managementpractices. In most IT–enabled business process change projects, the usersare assumed to be docile, submissive beings who always succumb to themagic bullet. In fact, the authors say users are anything but. They knowhow to dodge the bullet by ?nding faults with the IT solution. They mayuse the solution but still fail to reach management’s intended results, andthey also may ?ght back by blaming IT and questioning the value of IT.The authors suggest two change management alternatives. The ?rst alter-native is based on an organizational development theory they call the ITchange facilitator model. While everyone should share the responsibilityfor change, this model calls for change facilitators to be part of the changeeffort. The change facilitators should be neutral to any proposed solutionand serve to empower the business users and IT to arrive at a solution.The second alternative that Markus and Benjamin propose is the IT changeadvocate model. In this model, the change advocates are people withinthe organization who have visions for the future and can in?uence peopleto these visions. Change advocates are usually charismatic people whoknow how to affect people to change. Markus and Benjamin concludetheir article by recommending that IT specialists and line managers adoptand embrace change management practices. After all, it is usually thepeople, not the technology, that decide whether business change projectswill succeed or fail. They follow with the second recommendation thatall organizational members involved in business change projects shouldlearn and practice change management skills.Readers who have experienced IT–enabled business change projectswould probably agree with Markus and Benjamin’s comments on theimportance of change management and the lack of it in most projects.This is relevant to BPR and other IT–enabled business process projects. Thisis validated by a study of BPR projects, discussed in Chapter 1, that foundprocess transformation and social design as two of the top three stagesfor achieving project success based on a survey of BPR participants.Change management should be the number one priority of any IT–enabledbusiness change implementations. The change management team musthave a direct relationship to the executive champion of the project, andits members must be in?uential senior managers who are respected withinthe business. Ideally, change management team members should engage240 in all process designs. In the design phase, they actively engage thebusiness to understand their concerns about proposed process changes,and they collaborate with process team members to design processes thatwill be easier for the employees and the corporate culture to adopt. Ifthere are disagreements, they are the facilitators to resolve any con?ictsand issues. In addition to process work, change management specialistsshould be engaged in designing organizational changes that facilitate thechanges accompanying the business change implementations. The role ofchange management is to make sure the changes are tolerated, if not wellreceived, and accepted by the organization as a whole. This goes a longway to ensuring the success of the project. It has often been said thatIT–enabled business change, especially ERP projects, are all about peopleand much less about technology and systems. Technological issues are alot easier to overcome than people issues. While broken systems can bereplaced, it is a lot harder to replace an organization that is resisting thechange. Unfortunately, the role of change management has been reducedto user training and project communication in most business changeimplementations. This project methodology de?ciency is probably due tothe systems engineering origin of most IT–enabled business change meth-odologies. The end product of systems engineering does not involvehumans after all.The third most common complaint about IT–enabled business changeprojects is the lack of executive ownership. IT project managers who donot represent the business usually manage ERP projects. Projects managedby IT managers could give the perception that the projects are IT–driven.This perception automatically raises resentment from the business. Evenon ERP projects that are managed by senior managers from the business,there is usually a considerable gap between project management andexecutive management. This slows down the issue escalation processwhen tough cross-functional issues, such as transfer price and productcosting, have to be addressed. The ideal setup is to have either the ChiefExecutive Of?cer (CEO), President, or another senior executive of thecorporation be the project champion. Project management should have adirect relationship to the project champion. Issues are resolved with thefull participation of the steering committee, which includes the projectchampion and the various business stakeholders.Business Process Management (BPM) Implementation MethodologyThe complaints discussed above are not only relevant to BPR and ERPimplementations. These are common complaints that are relevant to anyBusiness Process Management Implementation Methodology 241technology-enabled change projects. Undoubtedly, most lessons from BPRor any other technology-enabled change practices will be relevant toimplementation of BPM. In the following sections, we will discuss a genericBPM implementation methodology that contains commit, research, ana-lyze, design, implement, and support phases.Figure 10.1 illustrates the various phases of BPM methodology. Duringthe commit phase, the organization commits to process managementthrough organizational alignments and strategic direction. The researchphase is for the organization to determine existing business processes,research, and select a process management product (e.g., Business ProcessManagement System (BPMS)), and prepare for business change. The nextFigure 10.1 BPM Implementation Methodology.1 Commit2 Research3 Analyze6 Support 4 Design5 ImplementBusiness Process ManagementMethodology 242 four phases form an iterative cycle for implementing a process manage-ment project, focusing on one or a small set of processes identi?ed inthe research phase. The analyze phase starts the cycle with the projectteam, project charter, and the current process performance metrics. In thedesign phase, the to-be process is optimized and architected. Any neces-sary organizational adjustment and employee reward metrics are madeduring this phase. The process solution is built and tested, and users aretrained during the implement phase. The end of implement phase marksthe go live of the process solution. The last phase of the cycle, the supportphase, is to measure the new process for comparison to performancegoals and perform the project closeout with lessons learned. From theprocess perspective, the support phase does not stop. The new processwill be continually monitored and controlled using BPMS. However, theprocess management implementation team can focus on new tasks orprojects after project go live and a period of go live support. Because thisis not a book on project management, we will discuss the BPM method-ology on a high level. In formulating this generic methodology, weincorporate generally accepted project management practices, changemanagement practices, lessons from ERP implementations, and practicesfrom TQM and Six Sigma methodologies. The blending of these practices ismade to take advantage of BPMS features. Hopefully, readers looking toimplement BPM and BPMS will ?nd this methodology useful as a startingpoint for their implementation plan.Phase 1: CommitOnce an organization has decided to adopt BPM practices, the organizationhas to be committed to this decision. Too often business improvementinitiatives are pet projects initiated by executive management that neverreceive the proper executive attention and organizational support theyneed to be successful. What usually happens is a project team will beformed to implement the business improvement initiative. The executivesponsors take a hands-off approach, and their only involvement is inoccasional project status brie?ngs. It is up to the project team to engenderculture change, suggest organizational adjustments, design the businessimprovements, and implement the business improvements. This approachmight work in an organization that has a change-friendly culture and hasthe organizational framework already in place so major reorganization isnot necessary. In a change-friendly organization, the scope of the businessimprovement project is usually small and most issues do not requireexecutive decisions.Business Process Management Implementation Methodology 243Business change projects in organizations not accustomed to changeare risky undertakings. Some projects fail because of the overwhelmingresistance from the organizations to adopt the business changes the projectteams want to implement. There will always be resistance in organizations.Most people are happy with status quo; this is general human nature. Weadopt ideas quickly, and we loath to adjust the ideas we have adopted.That is probably why children learn faster than adults do. As humanbeings, once we are set in our ways, we do not want to disrupt thoseways and have to rearrange our lives. Thus, it takes effort, sometimesexternal motivation, and time to prepare humans for change. This extendsto all organizations made of humans. Implementing a project in anorganization that has not been properly prepared for change carries theadditional burden of having to introduce the concept of change to theorganization. This undoubtedly will create tremendous organizationalupheaval, which means additional risk to the project.Major organizational alignment is best done outside the scope of abusiness improvement project. By organizational alignment, we are refer-ring to changes in organizational model, such as from a functionallyoriented to a process-oriented model. This kind of organizational changeis a complex endeavor that deserves dedicated attention from executivemanagement. Even if all the executives agree on the alignment, there willoften be strong resistance from senior managers reporting directly toexecutives. These senior managers will ?ght with teeth and nails to protecttheir turf and positions. It takes conviction and planning to convince thesenior managers and business unit heads to the necessity for organizationalalignment.Therefore, in our BPM methodology, we introduce the commit phaseto address the larger strategic, cultural, and organizational aspects of themajor business change initiative. This is the phase in which the organi-zation makes a serious commitment to BPM from the top-level executives.We divide the tasks into two major groups: set strategic direction andeffect organizational alignment. Figure 10.2 illustrates the tasks that needto be accomplished during this phase.Set Strategic DirectionThere is usually a champion for every business change initiative. Thechampion is the person who pushes for the business change initiative. Inthe case of BPM, that champion should be the CEO. BPM, implementedthroughout the organization affects so many departments, that only theperson overseeing the various departments, typically the CEO, has the244 in?uence to generate support in the executive ranks. Before they canconvince others, the executives must ?rst be convinced themselves. Thisparaphrase of a quote from Thomas Carlyle is appropriate for any situationsthat call for persuasion. Prior to embarking on business process, organi-zational executives have to buy into BPM as a management practice.Despite the common belief humans possess individuality and make inde-pendent decisions, the reality is other people of higher perceived statureor in?uence, in?uence most of us. Employees on the lower portion oforganizational hierarchy look to their executives for guidance. Unity atthe top of the organization illustrates determination for the BPM initiativefrom the executive ranks. The show of determination and unity can helppersuade employees to support the new initiative.After the executive ranks agree and support BPM initiative, the next taskis to cultivate an environment that is conducive for BPM. This can be initiatedby setting process management as a guiding principle for the organization.The effect of a guiding principle is it will impress, on the management levels,that executives see process management as a key management practiceFigure 10.2 Tasks for Phase 1 — Commit.Set Strategic Direction • Unite executives to support BPM initiative • Include process management as management guiding principle • Link strategic business goals to BPME?ect Organizational Alignment • Adjust organizational structure to be compatible with process management • Appoint an executive to be the process czar • Implement process management organizational unit with process implementation o?ce, process support o?ce, and process managers • Articulate employee reward strategy based on process performanceParticipants • Executive Management • Process CzarPhase 1 Commit—OverviewBusiness Process Management Implementation Methodology 245for achieving strategic goals. This will likely generate attention and developsupport from the senior management and mid-level management levels.Another method to engender organizational support for a BPM initiativeis to tie the initiative to strategic goals. Strategic goals are important tosteering the organization toward a clear destination. When they are pas-sionately communicated throughout the organization, they can galvanizethe employees with a sense of purpose and soften resistance to changesassociated with the business initiative. It serves the BPM initiative well toset strategic goals that use the business process as the key enabler. Astrategic goal might be to achieve 10 percent productivity improvementper year by continuously improving the business process. At the veryleast, this sort of pronouncement should prepare the organization for theBPM initiative. Any business change initiative requires enormous amountsof communication. Most people do not register the information given tothem the ?rst time. As humans, the more mature we become, the moretimes information needs to be reinforced for our minds to accept theinformation. It is important for the organization to hear from the executiveson the process management strategic direction and the goals that BPMwill enable the organization to achieve. This information needs to bereinforced multiple times, either by executive management or by othermanagement levels.As we mentioned previously, there are often challenges in convertingsenior managers to embrace any initiative that changes the organizationalstructure. It is never good to mandate certain behaviors. People can bein?uenced and mindsets can change when a case for change is successfullybuilt and precisely communicated. There are books written on how toin?uence and change organizational mindsets.2 These books presentapproaches that could help any organization deal with business change.It might also help to present a sense of urgency for change. Businesschanges swiftly. There are mergers, acquisitions, and changes in businessenvironments. Given these dynamics and the centrality of processes indealing with these dynamics, executive management has to present a clearcase for change to deal with the urgent business challenges.Effect Organizational AlignmentAside from strategic direction, the organization should commit to BPMthrough a process-focused organizational structure. In Chapter 2, we dis-cussed various process-focused organizational structures. Most organiza-tions are organized along functional departments. It is extremely painfulfor an organization to change to a pure process-based organizational model.In the pure process-based organization, there are no functional depart-ments. Every employee is part of a process unit. While this organizational246 model might react quicker to changes in business processes, it also createsduplicate functions within different process units. Thus, there is produc-tivity loss from this redundancy. Not to mention the business risks andorganizational turmoil a functional organization faces while it is undergoingtransformation to a pure process-based organizational model. A popularalternative is a matrix, or network, organization that retains functionaldepartments, but it also contains process units that interact with thefunctional departments. Employees in a matrix organization have director indirect reporting relationships to functional departments and processunits. Although a matrix organization requires more managerial attentionand communication, it is probably the preferred organizational model fororganizations not familiar with process-focused management practices.Just as departments have department heads and business units havebusiness unit leaders, processes should have process leaders. A seniorexecutive should be in charge of the business processes. This leadershould serve as a process management czar who oversees process man-agement activities. To help establish credibility, this process czar shouldreport to the CEO. Processes do not know departmental or business unitboundaries. Having a senior executive as the process czar ensures thereis enough political clout to manage the business processes effectively.Serving under the process czar are a process implementation of?ce, aprocess support of?ce, and process managers. We will discuss more aboutthese subunits in our discussion of the research phase. At a high level,the process implementation of?ce is responsible for implementation ofprocess management projects and maintaining knowledge relating to theimplementation of these projects. The process support of?ce is responsiblefor monitoring, controlling, and reporting on processes. Process managersare the process owners who are responsible for the performance ofbusiness processes. In this phase, the process implementation of?ce shouldbe created and ready for operation at the beginning of the research phase.In the next phase, the process implementation of?ce will participate inproduct selection and cataloging of current business processes. Afterprocess management projects have been implemented, the process supportof?ce should be ready to control and measure these processes.People behave the way they are measured and compensated. Employeecompensation strategy is an important factor for making process manage-ment work. During the commit phase, an employee compensation strategythat takes into account process performance should be formulated. Obvi-ously, this can only be stated at a high level because no process man-agement projects have been implemented at this stage. The formulationand broadcast of process-based performance evaluation serves to attractattention to the BPM initiative from employees. The more attentionemployees pay to the BPM initiative, the easier it is to communicate theBusiness Process Management Implementation Methodology 247bene?ts of the BPM initiative. Communication is the key to winningsupport.Phase 2: ResearchThe commit phase requires work from the executive management level.After the executives set the strategic direction and initiated the organiza-tional alignment, the next set of tasks falls on the process managementorganizational unit and senior managers. While executive managementplanted the seeds for BPM, much work remains to be done. In this phase,we divide the tasks into three major groups: prepare organization forchange, determine current business processes, and establish process man-agement technology infrastructure. Figure 10.3 illustrates the tasks belong-ing to these major groups.Figure 10.3 Tasks for Phase 2 — Research.Determine Current Business Processes • Catalog existing business processes • Identify core business processes • Prioritize business processes for process management implementationsEstablish Process Management Technology Infrastructure • Organize product selection committee • Conduct product selection competition • Establish process management technology group • Start to build process management frameworkParticipants • Process Implementation O?ce • Change leaders • Subject matter experts from the business unitsPhase 2 Research—OverviewPrepare Organization for Change • Establish training program for change leaders • Establish training program for process design techniques and BPMS design tools248 Determine Current Business ProcessesOnce the organization is committed to BPM, one of the ?rst processmanagement tasks is to determine the current business processes. Thiscan be done by the process implementation of?ce. Even organizationsthat are not process-focused have business processes. Maybe that is notthe phrase people are used to. Processes are steps that workers followto conduct business. In nonprocess focused organizations, the processesmight end at the departmental boundary. Once the task has been handedto another department, the previous department is no longer concernedwith the outcome. Understanding of current business processes is criticalto BPM. First, this exercise would help identify unique business require-ments to the organization or the industry the organization belongs to.Without surveying the current processes, these unique requirements mightbe left out. Second, organizations accumulate knowledge as they evolve.In the growth of an organization, processes might become needlesslycomplicated because old methods of doing things were never challenged.Some processes might have evolved to be exemplary, ef?cient, and confercompetitive advantage. Again, without canvassing current processes, theseexemplary processes might have been neglected. Third, one of the bene?tsof process management is to measure process performance and improve-ments. Improvements cannot be measured unless current processes areidenti?ed and their performance measured. To catalog current processes,process implementation team members should interview all the functionaldepartments and all the business units within the organization. We willrefer to members of functional department and business units simply asthe business. This tedious work will require numerous meetings with thebusiness. During the interviewing process, the business should be askedto rate the importance and throughput of the processes they are describing.It is helpful to create a database to capture processes from various unitsand organize them by major groupings such as order-to-cash, purchase-to-pay, product development, marketing, etc.After all the current business processes have been cataloged, the nexttask is to determine which of these processes are core to the organization.Core processes are those that are critical to competitive advantage or thatcreate the most value. Obviously, value is hard to quantify at this pointbecause no process performance analysis has been performed. However,with inputs from the business and senior management, core processescan be subjectively determined. Do core processes have to be currentprocesses? Core processes are most likely existing business processes.There might be strategic initiatives that will confer competitive advantageand require new processes to be designed and implemented. In suchBusiness Process Management Implementation Methodology 249situations, these new processes will be core once they are implemented.From a cost perspective, there are bene?ts to include these new, yet-to-be implemented, processes in the list of core processes and implementthem as part of the process management initiative. There are risks asso-ciated with this approach because the process management initiative isonly beginning at this stage. However, after several projects have beencompleted through the Analysis, Design, Implement, and Support (ADIS)cycles, these risks are mitigated.With existing business processes cataloged, they can be prioritized forimplementation. The ?rst process to be implemented should not be overlycomplex or critical. In conservative organizations, it might be prudent tostart with a process that is not a core process and not overly complex.The process management implementation methodology and BPMS technol-ogy infrastructure will mature over time. The choice of a noncore processwill not seriously impact business if there are implementation problems.Furthermore, it is important to the BPM initiative that the ?rst project besuccessfully implemented. After the organization has one or a few suc-cesses with BPM projects, the implementation priority list should be givento core processes. This process list is by no means static. As the businessenvironment changes, new processes can be added and the prioritizationcan change.Establish Process Management Technology InfrastructureThe next set of tasks is related to the technology aspect of BPM initiative.A BPMS product selection committee should be established to choose theright BPMS product for the organization. Ideally, any one department doesnot conduct the process of choosing a BPMS product. Everyone will beaffected by the BPM initiative and will use the BPMS product directly orindirectly. The product selection committee should be composed of rep-resentatives from the process management unit, IT, and the various func-tional departments. The selection committee can canvass existing literaturefor products that are likely ?ts for the organization. Once the pool oflikely products has been established, vendor candidates should be invitedto give demos. Most of these product presentations should be taken withgrains of salt. With constant news of technological advancements andscienti?c progress, we have been conditioned to believe in the illimitablecapabilities of technology. For those of us in the IT ?eld, undoubtedlycomments such as why can’t it do that, and it should be easy right, havebeen heard many times from business users annoyed when desiredfeatures were not available. IT is like the magic bullet we described250 previously. We have been conditioned to think of technology as capableof doing anything. Because this perception of technology is widespread,product vendors have to hype their wares to meet the market perception.After one vendor starts the hype, all vendors have to participate tocompete. It is a rare occasion when a product vendor willingly admits tothe shortcomings of its product. The purpose of vendor product presen-tations should serve to provide information of high-level product features.The more technical-savvy members of the product selection committeeshould be encouraged to ask tough technical questions to help draw theline between hype and reality.In a marketplace where product hype is common, how should orga-nizations make intelligent decisions on a product? A good method is tohold a competition for the various product vendors. The competition couldbe a process solution bake-off. The competing product vendors will begiven the same process and the same technology infrastructure to provethe capabilities of their products. The business process chosen for thecompetition should not be complex, but it should cover at least twoapplications that need to be integrated, and two human tasks that needto be performed. It’s a good idea to have employees embedded with eachteam if the product vendors allow for such practice. This will broadenthe organization’s understanding of BPMS products. The duration of thecompetition might take anywhere from three days to four weeks. Inevaluating the prototypes from the various competing teams, the imple-mentation time should be taken into consideration along with featuresand ful?llment of the business process. Implementation time gives a goodindication of how easy or how dif?cult it is to implement solutions usinga particular BPMS product. Depending on the potential size of a BPMScontract, it might be possible to ask the vendors to foot some or all ofthe costs for the product competition. It is still a good investment evenif the organization has to pay the costs for the product competition. It isfar cheaper to spend money for proper product selection than for theimplementation and rework costs due to an un?t product.With the selection of a BPMS product, there needs to be a technologygroup to support this product. This should fall under the responsibilityof the process management technology group. This technology groupshould be responsible for maintaining the servers, databases, and systemlandscape associated with the BPMS product. The logical department tomanage the process management technology group is the IT department.Most system administration tasks require the same skills regardless of theproduct. The IT organization already has the knowledge base to adapt tothe maintenance of a BPMS product. Because this organization will besupporting the process management initiative, it is prudent to align theprocess management technology group to support process managementBusiness Process Management Implementation Methodology 251projects. In the next phases, the process management technology groupwill need to provide dedicated systems administration support to theprocess management project teams.With the BPMS product selected and the BPM initiative well underway,the task can be started to build a process management framework. Theframework is a set of items and services that will be used in building aprocess management solution. These items include a meta-data model, anorganizational model, implementation methodology, and standards. Themeta-data model is particularly important because it includes the enterprisedata model. There needs to be a consistent data model used throughoutthe organization to describe such information as customer, vendor, salesorder, purchase order, business process performance, etc. Ultimately, datais the basis of information. If every business process is de?ned using itsown set of data, it will be dif?cult to compare the same data from differentprocesses. Thus, the establishment of an enterprisewide meta-data modelis important. At this stage, no processes have been implemented. It is notreasonable to expect a meta-data model that can cover all the futureprocesses to be implemented. The more comprehensive the meta-datamodel can be devised at this point, the easier it will be for processmanagement projects. The other model is the organizational model. Thismodel re?ects the reporting hierarchy of an organization. Numerouspeople in the organization use most business processes. The goal of theorganizational model is to expedite process management projects whenthe processes in these projects need to assign work to speci?c membersin the organization. An example is the approval of a purchase order. Theprocess design can use the organizational model to indicate the approvalwork item should be routed to the manager of the employee placing thepurchase order. Standards and implementation methodology are the othercomponents of a process management framework that should be devel-oped. Implementation methodology is not unlike what we are describingin this chapter, except it is much more detailed. The methodology shouldspecify the phases, participants, roles, and responsibilities, testing proce-dures and speci?c tasks of a process management project implementation.The contents of analyze, design, implement, and support phases describedin this chapter would be contained in a process management projectmethodology. The methodology would serve as a guide for processmanagement project implementations. In support of the project method-ology are standards. These standards could be naming conventions, forms(e.g., functional design form, technical design form, etc.), process metricde?nitions, and training templates. The standards will ensure that projectsare documented using the same mechanism and that the outputs fromdifferent projects are consistent.252 Prepare Organization for ChangeIn the previous section, we discussed the process management unit andthe process czar. The process implementation of?ce is akin to the projectmanagement of?ce we ?nd in project-based organizations. The subunitdetermines which processes to improve, implements process managementprojects, devises implementation methodology, and serves as the knowl-edge center for process management. One of the BPM practices is con-tinuous improvement. The process implementation of?ce is the arm thatexecutes process improvements. The bene?ts of the project of?ce havebeen widely discussed in the management press. Their functional rootsand relationships limit project teams within functional departments. Fur-thermore these functional project teams do not have the experience todeal with cross-functional integrations, and they lack a support organiza-tion that provides methodology and implementation knowledge. The roleof the process implementation of?ce is to provide a home for processmanagement implementation teams. This of?ce maintains the standardsfor implementation and the network for implementation team membersto learn from each other. The implementation of?ce decides which pro-cesses to improve based on the process performance gathered by theprocess support of?ce.Another important function of the process implementation of?ce is toprovide education on business process and business change. In recentdecades, the change management discipline has garnered attention in thebusiness management world. It is well established that effectively man-aging change and cultivating change leaders within the organizations areimportant for the business change initiative. Change leaders serve toin?uence others within the organization to adapt to the new businessenvironment. Some people naturally adapt to change more readily thanothers do. These people are the candidates to be the change leaders. Theideal change leader candidates should also be respected members withinthe organization who can exert in?uence on others. The role of the processimplementation of?ce is to provide training for these change leaders onthe value of the business change and how to create an organizationalculture that is friendly to change. These change leaders should be returnedto their functional departments to in?uence others to accept the processmanagement. They also serve as a pool of change agents who canparticipate in process management projects, which we will discuss theanalyze phase. After change leader training, the process implementationof?ce remains their link to learning about process management projects.This way the change leaders will stay connected to the process manage-ment and the cycles of change even when they are not involved in processmanagement tasks.Business Process Management Implementation Methodology 253Aside from providing change agent training, the project implementationof?ce should be responsible for providing training to the process imple-mentation team members. These individuals are responsible for managing,designing, and developing process management projects and solutions.The training should cover process management implementation method-ology, process design methodology, and BPMS product training. Becausemaintaining an internal training capability is expensive, some of thesetraining activities will probably be outsourced. It is a good idea to maintainan internal capability at least for the project implementation methodology.As an organization completes the process management projects, it gainsmore knowledge about how to best implement these projects. This knowl-edge is part of the organization’s intellectual property and should betransformed into enhancements to the project implementation methodol-ogy. Internal training is a good way to disseminate that knowledge.Phase 3: AnalyzeThe next four phases form the outline of a process management project.Each process management project contains a cycle of these four phases.Once a project has been completed, the process implementation of?cecan start a new project and a new cycle involving these four phases startsagain. Analyze is the project planning and process analysis phase. Theinputs to this phase are the process to be implemented chosen by theprocess implementation of?ce and an estimated project completion date.Once an objective has been set, the project team should be formed. Inthis phase, the project team should develop a project charter and analyzethe existing processes covered by the project scope. We will discuss theproject team setup, project charter, and process analysis in this section.Figure 10.4 shows the tasks that should be completed during the analysisphase.Assemble Project TeamA project team should at least have the following components: projectmanagement, business change, development, and technology support.Figure 10.5 shows the various teams in the project.Project management is responsible for the overall success of the project.The best command setup is to have one project manager so responsibilityis not diffused. The project manager’s responsibilities include creating theproject plan, coordinating the various teams within the project, elicitingproject stakeholder participation, and engaging the project steering254 committee. Stakeholders are any parties that are affected by the processmanagement implementation project. They could include managers fromdepartments affected by the process management project, the IT depart-ment because it has to support the systems, and users who have to learnnew ways and technology to conduct business. The stakeholder committeeis made of senior managers of business units that will be impacted withinthe BPM project scope.The business change team is the driver for the business process designand organizational alignment. This team should be composed of changeleaders, core team members, organizational design experts, and processdesign experts. The change leaders should provide leadership to thebusiness change team and they should serve to in?uence the affectedbusiness units into adapting changes being implemented by the processmanagement project. Core team members are representatives from thebusiness units who can provide knowledge on how the current processesFigure 10.4 Tasks for Phase 3 — Analyze.Assemble Project Team• Include change leaders and core team members from the business into project team• Create project steering committee• Engage project stake holdersDeliver Project Charter• De?ne process problem, project scope, implementation objectives, roles and responsibilities, high-level project plan and project assumptions• Obtain approval from steering committee and stake holders for project charterPhase 3 Analyze—Overview• Gather process data for existing processes within the project scope• Analyze data to determine performance of existing processes• Document current process challenges• BPM project team• Steering committee• Project stake holdersParticipantsPerform Process AnalysisBusiness Process Management Implementation Methodology 255are performed. These core team members should be highly regarded andtrusted within their organizational units so they can provide a positivecommunication link from the process management project to the businessunits. It is important for the core team members to believe in the processmanagement initiative. Skeptical core team members communicating neg-ative feedback to the business is detrimental to the change managementprocess. What is the difference between core team members and changeleaders? Core team members are usually people closer to the work. Theyhave a good understanding of the operational aspects of their section ofthe business. Change leaders are usually higher up in the organizationalhierarchy. Their role is to lead business change and to interact with middle-and upper-level managers.Figure 10.5 Example of Business Process Management Project Structure.SteeringCommitteeProjectManagerProjectStakeholderCommitteeBusinessChangeTeamDevelopmentTeamTechnologySupport Team• Change leaders• Core team members• Organizational design experts• Process design experts• Enterprise application architects• Web designers• Web developers• BPMS application developers• Legacy application developer• System administrators• Database administrators• Network administratorsBPM Project Structure256 The other resources in the business change team are subject matterexperts, including experts in organizational design and process design.Organizational design experts have the responsibility of analyzing theorganizational structure from a process performance optimization perspec-tive. Sometimes the organizational design analysis leads to organizationalstructure modi?cations to provide best process performance. Changes inorganizational structure usually entail changes in jobs and roles. De?ningroles and responsibilities of jobs affected by process management isanother task that organizational design experts have to tackle. In additionto these, organizational design team members help to de?ne processperformance goals and employee rewards for achieving process perfor-mance goals. Just as organizational design experts look to optimize per-formance from an organizational perspective, process design expertsanalyze the current business processes within the scope of the processmanagement project, and they redesign the business processes using BPMprinciples. Process management experts are trained in process designmethodologies, and they are trained in using the business process designand simulation tools of the BPMS product. The primary responsibility ofthe process management experts is to take the inputs from the other teammembers and utilize scienti?cally rigorous process design techniques todevise the best business processes within the scope of the project.Supporting the business change team are the development and tech-nology support teams. The development team constructs the programsrequired to support the process management design. BPMS vendors adver-tise their products as being capable of automatically generating code, withsome vendors going as far as advertising programming-free solutions. Thereality is development is still needed using any kind of BPMS product.The automatic code generation ability is generally limited to simple forms,interface proxies, simple interface transformations, and component stubs.Developers are still needed to implement complex business rules, userinterfaces, and component interfaces. The development team shouldinclude Web designers, Web developers, enterprise application architects,application developers who are trained in using the application develop-ment tool of the BPMS product, and developers with experience in theapplications that are part of the process management project scope. Thesedevelopment roles are needed in the development team. Individual devel-opers might be able to satisfy more than one role. Thus, the number ofdevelopment team members might be less than the number of roles. Thereis a distinction between Web designer and Web developer. The Web designerprepares the look and feel of a Web page, while the Web developerprograms the server-side logic that controls the Web page. The enterpriseapplication architect designs the component model of the process man-agement project scope. The architect is responsible for making sure theBusiness Process Management Implementation Methodology 257components within the process management framework are leveraged forreuse and that new components are designed with future reuse in con-sideration. Another responsibility of the enterprise application architect isto ensure all components follow enterprise process management standards.Most of the applications in a process management scenario might notprovide adequate interfaces to satisfy the requirements of the processmanagement solution. Application developers knowledgeable about theseexisting applications should be part of the development team to ensurethese applications can be properly integrated in the BPMS product.The last team in the process management project is the technologysupport team. This team performs system administration tasks and systemperformance optimizations. For large-scale projects, a dedicated technol-ogy support team is essential to the success of the project. In such projects,any delay in the project timeline can have a large ?nancial impact. A fullystaffed and dedicated technology support team can ensure that technologyrelated issues do not contribute to project delays. Regardless of projectsize and whether the dedicated technology support team is part of theproject, there needs to be a previously agreed on service response timebetween the technology support team and the other project teams. Thisservice level agreement should take the heightened support needs duringthe critical phases of the project into consideration.Project CharterWith the team assembled, the next set of tasks revolves around the creationof the project charter. The project charter is the basis for the existence ofthe BPM project. It contains the process problem, project scope, imple-mentation objectives, roles and responsibilities, high-level project plan,and assumptions. The concept of the process management project charteris similar to the project charter from the Six Sigma methodology. Theprocess problem states the current business process (or lack of businessprocess) and the business challenges are a result of the current state. Theproject scope is the scope provided by the process implementation of?ceto initiate the project. Various teams should collaborate to determine theimplementation objectives. These objectives include anticipated bene?tsas a result of the project. The bene?ts are high-level bene?ts that will bemore detailed as the project engages in the design phase. Any assumptionsmade to reach the anticipated bene?ts should be stated in the projectcharter. Finally, the charter includes the roles and responsibilities of allparties involved and a high-level project timeline. Roles and responsibilitiesextend from those of the project team to the project stakeholders, thebusiness users, and the steering committee. The project timeline includedin the charter is a high-level timeline that will be tweaked during the258 design phase. This timeline is an estimate based on experience withprevious projects of similar scope. The timeline might turn out to beunrealistic as the project team ?nishes the design phase. At that point,the detailed project plan should be submitted to the steering committeefor approval with any changes in dates.The main purpose of the project charter is to serve as a communicationto all parties affected by the project. The steering committee and projectstakeholders will sign this project charter. Once the project charter hasbeen authorized, it serves as the mandate the project team can use tojustify the project’s existence and actions. By involving the stakeholders,the business will signal its commitment to the project.Process AnalysisIn preparing for the project charter, the project team needs to performan analysis of the current processes in the project scope. High-levelinformation about the existing processes has already been gathered duringthe research phase. The process analysis expands on the informationpreviously collected. The primary goal of process analysis is to determinethe performance of existing processes. The data to perform processanalysis might not be easy to gather because there might not be consistentand readily available data for the current processes. If a process involvesapplications that contain transactional logs, these logs can be used todetermine the activity duration. Sometimes when transactional logs arenot available, the analysis would have to be done using indirect measure-ments such as dividing total transactions in a given period by the numberof full-time equivalents for that period. Other techniques for processmeasurement include direct observation and interviews. One of the jobsof the process implementation of?ce is to devise techniques and tools forenabling current process analysis. Other than process performance mea-sures, the project team should also determine current process challengeswhile performing process analysis. Using the performance measures andinformation on current challenges, realistic project goals can be drawn.The results from the analysis are used as inputs to the project charter.Phase 4: DesignThe design phase is when the project kicks into high gear. The primarygoals of this phase are to design the best process management solutionand to build a prototype that validates the feasibility of the design solution.Figure 10.6 shows the tasks for the Design phase.Business Process Management Implementation Methodology 259The business change team has the responsibility for designing thesolution. The approach for process design should include workshops withvarious business stakeholders to obtain their inputs. Once business inputshave been gathered, the business change team, led by the process designexperts, should come up with alternative high-level process designs. Thealternative design solutions are entered into the BPMS process designerand simulations are run to choose the best process alternative. The processalternative chosen is then the focus of further design activities. It has beenremarked that processes are like onions, with layer upon layer of detail.The chosen process alternative should undergo cycles of re?nement andsimulation so it contains all the decision points, branches, and exceptionsthat are likely to be encountered in real life. Readers interested in knowingmore about process design and analysis techniques might want to readbooks by Harmon and Burlton.3,4Figure 10.6 Tasks for Phase 4 — Design.• Conduct workshops to obtain business inputs• Draft design alternatives• Use simulation to pick the best alternative• Optimize the chosen design alternative through iterations of design simulation and re?nementBuild Process Prototype• Choose the primary process branch of the process management solution• Develop business logic, component interfaces and web pages for the solution prototypeParticipants• BPM project team• Project stakeholdersPhase 4 Design—OverviewComplete Detailed Solution Design• Update organizational design with revised roles and responsibilities in support of the process management solution• Design detailed process ?ows for all possible branches of the process management solution • Develop process solution technical model• Complete functional design documentsOptimize Business Process Design260 The same time the process design is being re?ned, the organizationaldesign experts should look at the current organization and determine whatneeds to be changed to take advantage of the process solution. Organi-zational changes might be as simple as updates to job descriptions orthey might be as radical as creation and deletion of organizational units.The organizational design outputs from the design phase include descrip-tions for jobs, roles, activities, and work processes. The roles involved inthe to-be business process and activities to be performed by each roleshould be ?nalized by the end of this phase.To validate the feasibility of the to-be process solution, a prototypeshould be built. The prototype should cover the main processing branchof the process solution. If any applications are involved in the processsolution, the prototype should include integration to at least one applica-tion. The prototype is a joint effort between the business change teamand the development team. This provides the development team with achance to see what the process solution looks like and what the level ofdevelopment efforts might be. Traditional waterfall methodologies do notprovide the development team the opportunity to be involved in thesolution until after the functional team has completed detailed design.The inclusion of the prototype in the design phase should hopefully bringabout a closer working relationship between the business change anddevelopment teams. The other bene?t of the prototype is it serves tomitigate implementation risks. By engaging the development team duringthe design effort, the technical feasibility of the process solution can bedetermined. Sometimes functional teams would design elegant and highlycomplex solutions only to have the technical teams determine the solutionis either impossible to build or cannot be implemented within the projecttimeframe. The prototyping effort makes sure the ?nal process solutionis technically feasible while still covering the main process requirements.In building the prototype, the enterprise application architect workson designing a high-level process solution technical model. This modelcontains a data model and a component model. Traditional object-orienteddesign methodology usually contains state transition and sequence dia-grams to capture changes in the object state and the ?ow of processactivities. In the BPMS design approach, state transitions and processsequences are modeled graphically as part of the process design usingthe BPMS process designer. This has the advantage of integration betweenmodeling and development, because the development is done by directlyembedding logic into the process design. This also means the enterpriseapplication architect can focus on designing the functions of each com-ponent without having to be bogged down by working on speci?cinteractions of the components using Uni?ed Modeling Language (UML)–likeBusiness Process Management Implementation Methodology 261diagrams. Process sequences, thus component interactions, are handledin the BPMS process designer as part of the overall process design craftedby the process design experts. The enterprise application architect drawson the standard enterprise data model when building the process solutiondata model. This ensures the solution data model will be consistent withthe enterprise data model. The other members of the technical team wouldalso be involved in building the prototype. If there is no enterprise Webdesign style guide, the Web designer could come up with several Web pagetemplates for the project team to choose. Web and application developerswould be working closely with the process design experts from thebusiness change team to make sure all the development items for theprototype are designed and developed.One of the handicaps of IT–enabled process change methodologieshas been a disconnect between functional design and the actual devel-opment output. In these methodologies, the functional design team gathersthe business requirements. These requirements are translated into func-tional design documents. The functional design documents are handed tothe technical analysts to convert to technical design speci?cations. Thesedesign speci?cations are given to programmers for development. Themultiple layers of communication and translation of requirements usuallyleads to differences between the original requirements and the imple-mented solution. Using a BPMS designer and a project methodology canhelp alleviate the requirement-development gap. The BPMS processdesigner comes with a high-level process ?ow layer and a low-levelbusiness logic–scripting layer. The low-level business logic-scripting layeradds detail to the process ?ow. It is the layer integrating components(such as other applications) and Web services (such as component inter-faces encapsulated as Web services). Process design experts who aretechnically savvy and are trained in the BPMS process designer shouldbe able to design detailed process ?ows using the high-level graphicalprocess ?ow layer of the BPMS process designer. The developers leverageon the process ?ow has already been completed for the process solutionin building the low-level business logic script. Using the same environmentfor process ?ow and low-level business logic development should helpreduce the chance for the functional–technical disconnect.Aside from a BPMS process designer, methodology-related measurescan be taken to foster the environment for close cross-team collaboration,thus reducing chances of functional–technical disconnect. The constructionof a prototype is a good opportunity for close cross-team collaboration.It requires the business change and development teams to work togetherin building the prototype. Process design experts from the business changeteam create the process ?ow, and the development team has to develop262 business logic scripts and integration to the applications or servicesincluded in the prototype. Work on the design document provides anotheropportunity for fostering close cross-team collaboration. While the busi-ness change team has the primary responsibility for delivering the func-tional design documents, the business change team members should workclosely with the development teams in completing these documents. It isa good idea to have a development team member shadow a processdesign expert during this phase. This approach enables the developmentteam member to fully understand the rationale behind the process solutiondesign. Even though most IT–enabled project methodologies stress theimportance of a close working relationship between functional and tech-nical project teams, the relationship, from this author’s experience, hasusually been uncomfortable. Functional team members are sometimesmiffed about the length of development time and shortcomings theyperceive of the developers’ meeting design speci?cations. Technical teammembers are sometimes frustrated with changes to design requirementsand what they perceive as unreasonable requests from functional teammembers. Not understanding each side’s challenges might be the causeof most of the discomfort. This tension between functional and technicalsides will probably never go away regardless of the methodology or tool.However, any opportunities to enhance understanding and bring collab-oration between the business change and development team will ulti-mately help in the delivery of the process solution.Phase 5: ImplementAt the end of the design phase, the solution prototype has been built andthe process solution has been deemed feasible to proceed with follow-on phases. The implement phase is when the rest of the solution devel-opment is performed. This phase leverages the solution prototype andfunctional design documents. Several activities happen during this phase:1. Complete the technical design document2. Develop the programs and the user interfaces needed for theprocess solution3. Conduct a unit test of the individual programs4. Conduct multiple iterations of integration tests involving all roles,components, and programs5. Design training documents6. Conduct user training7. Create online help documents8. Go liveBusiness Process Management Implementation Methodology 263Work on the technical design documents could actually start duringthe design phase. The technical design work has to be done to supportprototype building. Any remaining technical design for the process solutionthat was not part of the prototype should be ?nished at the beginning ofthis phase. The enterprise application architect should have de?ned thehigh-level technical model for the process solution during the designphase. Once the high-level technical model has been re?ned to containthe information on individual interfaces, the developers are responsiblefor completing the technical design speci?cations. In the course of com-pleting the technical design, the development team would have to engagein a series of team discussions and design walk-throughs to ensure thatall the pieces ?t together and form one coherent solution design. Whenthe technical design has been ?nalized, technical team members start onthe development items assigned to them. Unit testing follows completionof the development items. Unit test plans for each development itemshould be drafted and executed.Unit tests are the ?rst set of tests in the software testing cycle. Theother sets are the integration tests. There should be at least two iterationsof integration tests. Integration test is the end-to-end process managementsolution. Business scenarios make up each cycle of the integration test.Business processes is typically composed of multiple decision points andbranches that a process instance can undertake. A scenario is one end-to-end path of a business process instance. The integration test scenariocontains the activities performed by human and system participants for abusiness scenario. Each activity in the scenario has input test data and anexpected output from the activity. When executing the integration testplan, the output should be compared to the expected output to determinewhether there are any defects. There are several testing management toolsin the marketplace, such as TestDirector from Mercury Interactive, Silk-Central from Segue Software, eTest from Empirix, etc. It is advisable touse a test management tool. Test plans for each scenario can be loadedinto the test management tool and testers are assigned to each test plan.Defects encountered during test plan execution can be entered in the testmanagement tool and assigned to the appropriate party for resolution.Once the defects are in the test management tool, the integration testmanager can track them for resolution. A good integration test is one thatuncovers and resolves a high number of defects. Defects should not beclosed until all the test plan steps have been re-executed to ensure thedefects have been resolved. The ?rst cycle of integration testing shouldcover the main scenarios that account for 80 percent of business processinstances. The second cycle of integration testing should cover as manyother scenarios as possible. Typically, the scenarios in the second cycleare exception process paths, while the initial cycle covers the main process264 branches of the business processes in scope. During defect resolution, ifa defect uncovered in the integration test has implications to other sce-narios, all impacted scenarios should also be retested to make sure thechanges do not negatively impact these scenarios.The integration tests involve the process design experts from thebusiness change team and the development team members. The core teammembers and the organizational design experts are responsible for creatingthe training documents. Care should be taken to make sure the changesresulting from the integration test defect resolution are communicated tothe team members crafting the training documents. Effective trainingmaterial usually involves computer interaction for the trainees. When thetraining documents are done, they can serve as the basis for online helpdocumentation. To coordinate the training effort, there needs to be atraining manager who handles the scheduling and coordination of thetraining sessions. It is important that suf?cient resources and attention bedevoted to the training effort. The most common complaint from usersof IT–enabled business change projects is insuf?cient training. Properlytrained users will help reduce support needs and help raise acceptanceof the business process management solution.The implement phase is the phase requiring the highest amount ofinvolvement from the technology support team. Regardless of how wella project has been planned, the implement phase usually involves longworking hours from team members. It is not inconceivable that work willbe done 24 hours a day. It is critical to have timely support from thetechnology support team. In terms of project system landscape, the min-imum requirements are to have development, quality assurance, training,and production environments available. Figure 10.7 shows the migrationof the process management solution between the various environments.The development environment is where process design experts do thedevelopment work and where the development team constructs the pro-cess management solution. The process management solution is promotedto the quality assurance environment after all the components in the processmanagement have been unit tested. The integration tests are performed inthe quality assurance environment. No development work should be donein the quality assurance environment. In fact, no development work shouldbe done in any environment except the development environment. Alldefects are ?xed and unit tested in the development environment andpromoted to the quality assurance environment to retest the integrationtest scenarios. The training environment can be a copy of the qualityassurance environment. After the training environment has been created,any defects ?xed in the development environment should be promotedto both the quality assurance and the training environments. At theBusiness Process Management Implementation Methodology 265conclusion of the integration tests, the production environment should bebuilt by promoting all tested components of the process managementsolution from development environment.Other than the minimum required environments, it is very useful tohave a sandbox environment. The sandbox environment is used to buildthe prototype and for the process design experts and developers toexperiment with different alternatives before creating the desired alterna-tive in the development environment. Another helpful environment isstress testing. For process management solutions expected to experiencehigh throughput, stress testing is essential to make sure the solution, whenput into the production environment, can handle the throughput withreasonable response times. During stress testing, process instances arecreated using an automated testing tool with test data from the integrationtest plans. Because of the high volume of process instances required forFigure 10.7 Diagram of BPM System Landscape and Solution Migration Paths.Sandbox DevelopmentStress TestTrainingQualityAssuranceProduction12 2341. Design implemented in Development environment based on prototype in Sandbox2. Solution migrated from Development to Training and Quality Assurance after unit testing in Development3. Solution migrated from Development to Stress Testing environment after one iteration of integration test4. Solution migrated from Development to Production environment after successful integration test cyclesRequired environmentOptional environmentBPM Implementation System Landscape266 stress testing, it is not recommended to perform stress testing in the sameenvironment and at the same time integration testing is taking place.Go live is the last activity of the implement phase. Go live is whenthe users are allowed into the production environment to use the processmanagement solution. It is the most exciting time of the project. This isthe moment when the project team and the organization ?nd out whetherthe process management solution is working or not. As the saying goes, thisis when the rubber meets the road. Some project team members shouldbe assigned to support groups of users. Those team members not assignedto speci?c users serve as the issue resolution team. Inevitably, users willencounter problems. An issues tracking tool should be used to captureall issues reported by users. Once issues have been reported, they shouldbe assigned to issue resolution team members for resolution. Go-livesupport can last from two weeks to two months or longer. The end ofgo-live support marks the transition from project implementation to pro-duction support. This is when the support for the project managementsolution shifts from the project team to the process support of?ce.Phase 6: SupportThe last phase of the BPM implementation methodology is the supportphase. Where the previous three phases, analyze, design, and implementinvolve the process management project team, this phase involves theprocess support of?ce. The process management organization units reportto the process czar. The process implementation of?ce is the unit thatimplements process management projects. The process managementproject team participating in the analyze, design, and implement phasescomes under the auspices of the process implementation of?ce. Theprocess support of?ce is the organizational unit that takes over supportof process management solutions from the process management projects.The transition occurs during the go-live support period. Once project go-live support ends, some project team members (such as the change leadersand core team members) return to the business units and other projectteam members (such as the project manager, the organizational designexperts, and the process design experts) prepare for the next processmanagement project.The process support of?ce contains several support teams. Each of theprocess support teams is assigned business processes that it supports.Once the process management solution from the project team has beentransitioned to the process support team, the support team is tasked withmonitoring process performance, gathering process statistics, validatingBusiness Process Management Implementation Methodology 267the process management solution design, and managing the process.Monitoring process performance and gathering process statistics can bedone using the BPMS product. The process performance statistics can beused to determine whether the original design goals of the processmanagement solution have been attained. If the goals have not beenattained, the process data will help in diagnosing problems with the designand provide feedback to the process implementation of?ce for futureprojects. In a process-oriented organization, process performance servesas a benchmark for employee rewards. The performance statistics gatheredby the BPMS product serve as inputs for management and human relations(HR) to decide on employee rewards. Finally, the process support teamresolves issues encountered with any process instances. Working withprocess managers, the process support team implements enhancementsto the processes it is supporting. Enhancement opportunities that requirea longer time frame and substantial resource involvements are submittedto the process implementation of?ce. The project planning function ofthe process implementation of?ce prioritizes, plans, and schedules processimprovement opportunities for implementation.ConclusionIn this chapter, we discussed a generic BPM implementation methodology.What we described here might not be 100 percent applicable to allorganizations intent on pursuing BPM. It should serve as a high-levelreference for most organizations. Hopefully, a BPM–bound organizationwill ?nd this reference methodology useful in developing its own imple-mentation approach. In this book, we discussed a wide range of topicsregarding the BPM principles and technology. BPMS is a young andmaturing technology. New products and enhancements for existing prod-ucts are constantly being introduced. What we described in this book areideal features we believe a BPMS product should possess. While thecurrent offerings by product vendors still have room for improvement foreffecting a process management solution, the products that are availableby the time this book is published will undoubtedly be markedly improved.BPMS is a very exciting technology that promises bene?ts long desiredby process-oriented organizations. The excitement also generated hypeabout what this new technology can do. This book takes a realisticapproach in discussing what this technology can offer. Hopefully, readerswill ?nd the content of this book useful in your journey into BPM.