Chapter 10Bus…


Chapter 10
Business Process
In Chapter 2, we brie?y discussed the process management lifecycle. In
this chapter, we will expand on the concepts in Chapter 2 and focus on
the essential elements needed to successfully implement a business process
management (BPM). We will discuss the steps an organization seeking to
implement BPM can perform. BPM is simply not a technology proposition.
We will take a holistic view and look into organizational, functional, and
technical aspects of implementing BPM.
Lessons from Business Process Reengineering (BPR)
BPM management practices owe their origins to previous management
practices. Two in?uential management practices are Total Quality Man-
agement (TQM) and BPR. The latter is more relevant because of BPM’s
reliance on technology as a key enabler. While BPR had a large following
among large organizations, it achieved mixed results as discussed in
Chapter 1. Several factors contributed to BPR implementation failures.
Several of the factors are related to the BPR enabling technologies. To
help formulate a BPM implementation methodology, it is helpful to learn
from the BPR lessons.
In their formulation of BPR management concepts, Hammer, Champy,
and Davenport discussed the implementation of BPR at a high level. The
marketplace relied on project methodologies designed by various consult-
ing ?rms and ERP companies. These methodologies are based on the
traditional systems of engineering methodologies. There are typically four
phases. The ?rst phase usually involves an analysis of the current state.
This includes understanding the current business processes, mapping these
processes to the applications that support them, and documenting any
unique requirements that need to be addressed. Areas of opportunity are
also identi?ed. The next phase is designing an Information Technology
(IT)–centric solution for the future state. The reason it is IT–centric is the
current business processes are compared to the business processes of
the Enterprise Resource Planning (ERP) system that is to be implemented.
The ERP system essentially provides the best practice business processes
the organization should adopt. In cases where there are gaps, workarounds
or custom solutions are designed. At the end of the design phase, the
project should have written design speci?cations for how the system
should be con?gured and what customized solutions should be built. After
the design phase comes the development phase. During this phase,
systems are con?gured to the design speci?cations, customizations are
developed, and organizational changes are enforced. The last phase is the
deployment of the solution. The deployment phase involves testing the
systems and processes and training the users. The phases are dependent
and sequenced. Each phase usually takes one month to six months. At
some point in the design phase, business requirements are frozen, because
future business changes are dif?cult to include in project scope. This
methodology is typically called waterfall, presumably for its relative in?ex-
ibility to revisit completed phases and start work on a subsequent phase
prior to completion of the current phase. As most ERP projects are complex
and time consuming, they force the businesses to freeze their business
processes until the projects have been implemented. The freeze could
take from three months to one year, depending on the length of the
project. This is obviously hard for businesses to stomach because most
industries face changes much more frequently than the imposed freeze
periods. This is one of the major drawbacks of the ERP waterfall imple-
mentation methodology.
Another common problem of ERP and other IT–enabled business
change methodologies is the lack of emphasis on change management.
Lynne Markus and Robert Benjamin published an excellent article, “The
Magic Bullet Theory in IT–Enabled Transformation,” on this topic in 1997.1
Business Process Management Implementation Methodology  239
In their article, the authors describe the common belief that the IT solution
is the magic bullet that always ?nds its target. Because the bullet always
?nds its target, IT specialists do not feel the responsibility for ensuring
that users are adopting the technology solution. Senior managers also take
comfort in knowing the bullet is always on target, and they turn the
projects over to the IT specialists, who also serve as the convenient
scapegoat if the projects fail. The point the authors want to make with
the magic bullet theory is most projects do not follow change management
practices. In most IT–enabled business process change projects, the users
are assumed to be docile, submissive beings who always succumb to the
magic bullet. In fact, the authors say users are anything but. They know
how to dodge the bullet by ?nding faults with the IT solution. They may
use the solution but still fail to reach management’s intended results, and
they 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 IT
change facilitator model. While everyone should share the responsibility
for change, this model calls for change facilitators to be part of the change
effort. The change facilitators should be neutral to any proposed solution
and serve to empower the business users and IT to arrive at a solution.
The second alternative that Markus and Benjamin propose is the IT change
advocate model. In this model, the change advocates are people within
the organization who have visions for the future and can in?uence people
to these visions. Change advocates are usually charismatic people who
know how to affect people to change. Markus and Benjamin conclude
their article by recommending that IT specialists and line managers adopt
and embrace change management practices. After all, it is usually the
people, not the technology, that decide whether business change projects
will succeed or fail. They follow with the second recommendation that
all organizational members involved in business change projects should
learn and practice change management skills.
Readers who have experienced IT–enabled business change projects
would probably agree with Markus and Benjamin’s comments on the
importance of change management and the lack of it in most projects.
This is relevant to BPR and other IT–enabled business process projects. This
is validated by a study of BPR projects, discussed in Chapter 1, that found
process transformation and social design as two of the top three stages
for achieving project success based on a survey of BPR participants.
Change management should be the number one priority of any IT–enabled
business change implementations. The change management team must
have a direct relationship to the executive champion of the project, and
its members must be in?uential senior managers who are respected within
the business. Ideally, change management team members should engage
in all process designs. In the design phase, they actively engage the
business to understand their concerns about proposed process changes,
and they collaborate with process team members to design processes that
will be easier for the employees and the corporate culture to adopt. If
there are disagreements, they are the facilitators to resolve any con?icts
and issues. In addition to process work, change management specialists
should be engaged in designing organizational changes that facilitate the
changes accompanying the business change implementations. The role of
change management is to make sure the changes are tolerated, if not well
received, and accepted by the organization as a whole. This goes a long
way to ensuring the success of the project. It has often been said that
IT–enabled business change, especially ERP projects, are all about people
and much less about technology and systems. Technological issues are a
lot easier to overcome than people issues. While broken systems can be
replaced, it is a lot harder to replace an organization that is resisting the
change. Unfortunately, the role of change management has been reduced
to user training and project communication in most business change
implementations. This project methodology de?ciency is probably due to
the systems engineering origin of most IT–enabled business change meth-
odologies. The end product of systems engineering does not involve
humans after all.
The third most common complaint about IT–enabled business change
projects is the lack of executive ownership. IT project managers who do
not represent the business usually manage ERP projects. Projects managed
by IT managers could give the perception that the projects are IT–driven.
This perception automatically raises resentment from the business. Even
on ERP projects that are managed by senior managers from the business,
there is usually a considerable gap between project management and
executive management. This slows down the issue escalation process
when tough cross-functional issues, such as transfer price and product
costing, have to be addressed. The ideal setup is to have either the Chief
Executive Of?cer (CEO), President, or another senior executive of the
corporation be the project champion. Project management should have a
direct relationship to the project champion. Issues are resolved with the
full participation of the steering committee, which includes the project
champion and the various business stakeholders.
Business Process Management (BPM)
Implementation Methodology
The complaints discussed above are not only relevant to BPR and ERP
implementations. These are common complaints that are relevant to any
Business Process Management Implementation Methodology  241
technology-enabled change projects. Undoubtedly, most lessons from BPR
or any other technology-enabled change practices will be relevant to
implementation of BPM. In the following sections, we will discuss a generic
BPM implementation methodology that contains commit, research, ana-
lyze, design, implement, and support phases.
Figure 10.1 illustrates the various phases of BPM methodology. During
the commit phase, the organization commits to process management
through organizational alignments and strategic direction. The research
phase is for the organization to determine existing business processes,
research, and select a process management product (e.g., Business Process
Management System (BPMS)), and prepare for business change. The next
Figure 10.1 BPM Implementation Methodology.
1 Commit
2 Research
3 Analyze
6 Support 4 Design
5 Implement
Business Process Management
four phases form an iterative cycle for implementing a process manage-
ment project, focusing on one or a small set of processes identi?ed in
the research phase. The analyze phase starts the cycle with the project
team, project charter, and the current process performance metrics. In the
design phase, the to-be process is optimized and architected. Any neces-
sary organizational adjustment and employee reward metrics are made
during this phase. The process solution is built and tested, and users are
trained during the implement phase. The end of implement phase marks
the go live of the process solution. The last phase of the cycle, the support
phase, is to measure the new process for comparison to performance
goals and perform the project closeout with lessons learned. From the
process perspective, the support phase does not stop. The new process
will be continually monitored and controlled using BPMS. However, the
process management implementation team can focus on new tasks or
projects after project go live and a period of go live support. Because this
is not a book on project management, we will discuss the BPM method-
ology on a high level. In formulating this generic methodology, we
incorporate generally accepted project management practices, change
management practices, lessons from ERP implementations, and practices
from TQM and Six Sigma methodologies. The blending of these practices is
made to take advantage of BPMS features. Hopefully, readers looking to
implement BPM and BPMS will ?nd this methodology useful as a starting
point for their implementation plan.
Phase 1: Commit
Once an organization has decided to adopt BPM practices, the organization
has to be committed to this decision. Too often business improvement
initiatives are pet projects initiated by executive management that never
receive the proper executive attention and organizational support they
need to be successful. What usually happens is a project team will be
formed to implement the business improvement initiative. The executive
sponsors take a hands-off approach, and their only involvement is in
occasional project status brie?ngs. It is up to the project team to engender
culture change, suggest organizational adjustments, design the business
improvements, and implement the business improvements. This approach
might work in an organization that has a change-friendly culture and has
the organizational framework already in place so major reorganization is
not necessary. In a change-friendly organization, the scope of the business
improvement project is usually small and most issues do not require
executive decisions.
Business Process Management Implementation Methodology  243
Business change projects in organizations not accustomed to change
are risky undertakings. Some projects fail because of the overwhelming
resistance from the organizations to adopt the business changes the project
teams want to implement. There will always be resistance in organizations.
Most people are happy with status quo; this is general human nature. We
adopt ideas quickly, and we loath to adjust the ideas we have adopted.
That is probably why children learn faster than adults do. As human
beings, once we are set in our ways, we do not want to disrupt those
ways and have to rearrange our lives. Thus, it takes effort, sometimes
external motivation, and time to prepare humans for change. This extends
to all organizations made of humans. Implementing a project in an
organization that has not been properly prepared for change carries the
additional burden of having to introduce the concept of change to the
organization. This undoubtedly will create tremendous organizational
upheaval, which means additional risk to the project.
Major organizational alignment is best done outside the scope of a
business improvement project. By organizational alignment, we are refer-
ring to changes in organizational model, such as from a functionally
oriented to a process-oriented model. This kind of organizational change
is a complex endeavor that deserves dedicated attention from executive
management. Even if all the executives agree on the alignment, there will
often be strong resistance from senior managers reporting directly to
executives. These senior managers will ?ght with teeth and nails to protect
their turf and positions. It takes conviction and planning to convince the
senior managers and business unit heads to the necessity for organizational
Therefore, in our BPM methodology, we introduce the commit phase
to address the larger strategic, cultural, and organizational aspects of the
major 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 and
effect organizational alignment. Figure 10.2 illustrates the tasks that need
to be accomplished during this phase.
Set Strategic Direction
There is usually a champion for every business change initiative. The
champion is the person who pushes for the business change initiative. In
the case of BPM, that champion should be the CEO. BPM, implemented
throughout the organization affects so many departments, that only the
person overseeing the various departments, typically the CEO, has the
in?uence to generate support in the executive ranks. Before they can
convince others, the executives must ?rst be convinced themselves. This
paraphrase of a quote from Thomas Carlyle is appropriate for any situations
that 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 stature
or in?uence, in?uence most of us. Employees on the lower portion of
organizational hierarchy look to their executives for guidance. Unity at
the top of the organization illustrates determination for the BPM initiative
from the executive ranks. The show of determination and unity can help
persuade employees to support the new initiative.
After the executive ranks agree and support BPM initiative, the next task
is to cultivate an environment that is conducive for BPM. This can be initiated
by 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 practice
Figure 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 BPM
E?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 performance
• Executive Management
• Process Czar
Phase 1 Commit—Overview
Business Process Management Implementation Methodology  245
for achieving strategic goals. This will likely generate attention and develop
support from the senior management and mid-level management levels.
Another method to engender organizational support for a BPM initiative
is to tie the initiative to strategic goals. Strategic goals are important to
steering the organization toward a clear destination. When they are pas-
sionately communicated throughout the organization, they can galvanize
the employees with a sense of purpose and soften resistance to changes
associated with the business initiative. It serves the BPM initiative well to
set strategic goals that use the business process as the key enabler. A
strategic goal might be to achieve 10 percent productivity improvement
per year by continuously improving the business process. At the very
least, this sort of pronouncement should prepare the organization for the
BPM initiative. Any business change initiative requires enormous amounts
of communication. Most people do not register the information given to
them the ?rst time. As humans, the more mature we become, the more
times information needs to be reinforced for our minds to accept the
information. It is important for the organization to hear from the executives
on the process management strategic direction and the goals that BPM
will enable the organization to achieve. This information needs to be
reinforced multiple times, either by executive management or by other
management levels.
As we mentioned previously, there are often challenges in converting
senior managers to embrace any initiative that changes the organizational
structure. It is never good to mandate certain behaviors. People can be
in?uenced and mindsets can change when a case for change is successfully
built and precisely communicated. There are books written on how to
in?uence and change organizational mindsets.2 These books present
approaches that could help any organization deal with business change.
It might also help to present a sense of urgency for change. Business
changes swiftly. There are mergers, acquisitions, and changes in business
environments. Given these dynamics and the centrality of processes in
dealing with these dynamics, executive management has to present a clear
case for change to deal with the urgent business challenges.
Effect Organizational Alignment
Aside from strategic direction, the organization should commit to BPM
through 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 painful
for 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 organizational
model might react quicker to changes in business processes, it also creates
duplicate functions within different process units. Thus, there is produc-
tivity loss from this redundancy. Not to mention the business risks and
organizational turmoil a functional organization faces while it is undergoing
transformation to a pure process-based organizational model. A popular
alternative is a matrix, or network, organization that retains functional
departments, but it also contains process units that interact with the
functional departments. Employees in a matrix organization have direct
or indirect reporting relationships to functional departments and process
units. Although a matrix organization requires more managerial attention
and communication, it is probably the preferred organizational model for
organizations not familiar with process-focused management practices.
Just as departments have department heads and business units have
business unit leaders, processes should have process leaders. A senior
executive should be in charge of the business processes. This leader
should serve as a process management czar who oversees process man-
agement activities. To help establish credibility, this process czar should
report to the CEO. Processes do not know departmental or business unit
boundaries. Having a senior executive as the process czar ensures there
is enough political clout to manage the business processes effectively.
Serving under the process czar are a process implementation of?ce, a
process support of?ce, and process managers. We will discuss more about
these subunits in our discussion of the research phase. At a high level,
the process implementation of?ce is responsible for implementation of
process management projects and maintaining knowledge relating to the
implementation of these projects. The process support of?ce is responsible
for monitoring, controlling, and reporting on processes. Process managers
are the process owners who are responsible for the performance of
business processes. In this phase, the process implementation of?ce should
be created and ready for operation at the beginning of the research phase.
In the next phase, the process implementation of?ce will participate in
product selection and cataloging of current business processes. After
process management projects have been implemented, the process support
of?ce should be ready to control and measure these processes.
People behave the way they are measured and compensated. Employee
compensation strategy is an important factor for making process manage-
ment work. During the commit phase, an employee compensation strategy
that 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 formulation
and broadcast of process-based performance evaluation serves to attract
attention to the BPM initiative from employees. The more attention
employees pay to the BPM initiative, the easier it is to communicate the
Business Process Management Implementation Methodology  247
bene?ts of the BPM initiative. Communication is the key to winning
Phase 2: Research
The 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 management
organizational unit and senior managers. While executive management
planted the seeds for BPM, much work remains to be done. In this phase,
we divide the tasks into three major groups: prepare organization for
change, 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 implementations
Establish Process Management Technology Infrastructure
• Organize product selection committee
• Conduct product selection competition
• Establish process management technology group
• Start to build process management framework
• Process Implementation O?ce
• Change leaders
• Subject matter experts from the business units
Phase 2 Research—Overview
Prepare Organization for Change
• Establish training program for change leaders
• Establish training program for process design techniques and BPMS design tools
Determine Current Business Processes
Once the organization is committed to BPM, one of the ?rst process
management tasks is to determine the current business processes. This
can be done by the process implementation of?ce. Even organizations
that are not process-focused have business processes. Maybe that is not
the phrase people are used to. Processes are steps that workers follow
to conduct business. In nonprocess focused organizations, the processes
might end at the departmental boundary. Once the task has been handed
to another department, the previous department is no longer concerned
with the outcome. Understanding of current business processes is critical
to 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 might
be left out. Second, organizations accumulate knowledge as they evolve.
In the growth of an organization, processes might become needlessly
complicated because old methods of doing things were never challenged.
Some processes might have evolved to be exemplary, ef?cient, and confer
competitive advantage. Again, without canvassing current processes, these
exemplary processes might have been neglected. Third, one of the bene?ts
of process management is to measure process performance and improve-
ments. Improvements cannot be measured unless current processes are
identi?ed and their performance measured. To catalog current processes,
process implementation team members should interview all the functional
departments and all the business units within the organization. We will
refer to members of functional department and business units simply as
the business. This tedious work will require numerous meetings with the
business. During the interviewing process, the business should be asked
to rate the importance and throughput of the processes they are describing.
It is helpful to create a database to capture processes from various units
and 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 next
task is to determine which of these processes are core to the organization.
Core processes are those that are critical to competitive advantage or that
create the most value. Obviously, value is hard to quantify at this point
because no process performance analysis has been performed. However,
with inputs from the business and senior management, core processes
can be subjectively determined. Do core processes have to be current
processes? Core processes are most likely existing business processes.
There might be strategic initiatives that will confer competitive advantage
and require new processes to be designed and implemented. In such
Business Process Management Implementation Methodology  249
situations, 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 implement
them as part of the process management initiative. There are risks asso-
ciated with this approach because the process management initiative is
only beginning at this stage. However, after several projects have been
completed through the Analysis, Design, Implement, and Support (ADIS)
cycles, these risks are mitigated.
With existing business processes cataloged, they can be prioritized for
implementation. The ?rst process to be implemented should not be overly
complex or critical. In conservative organizations, it might be prudent to
start 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 process
will not seriously impact business if there are implementation problems.
Furthermore, it is important to the BPM initiative that the ?rst project be
successfully implemented. After the organization has one or a few suc-
cesses with BPM projects, the implementation priority list should be given
to core processes. This process list is by no means static. As the business
environment changes, new processes can be added and the prioritization
can change.
Establish Process Management Technology Infrastructure
The next set of tasks is related to the technology aspect of BPM initiative.
A BPMS product selection committee should be established to choose the
right BPMS product for the organization. Ideally, any one department does
not conduct the process of choosing a BPMS product. Everyone will be
affected by the BPM initiative and will use the BPMS product directly or
indirectly. 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 literature
for products that are likely ?ts for the organization. Once the pool of
likely products has been established, vendor candidates should be invited
to give demos. Most of these product presentations should be taken with
grains of salt. With constant news of technological advancements and
scienti?c progress, we have been conditioned to believe in the illimitable
capabilities of technology. For those of us in the IT ?eld, undoubtedly
comments such as why can’t it do that, and it should be easy right, have
been heard many times from business users annoyed when desired
features were not available. IT is like the magic bullet we described
previously. We have been conditioned to think of technology as capable
of 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 to
compete. It is a rare occasion when a product vendor willingly admits to
the 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 committee
should be encouraged to ask tough technical questions to help draw the
line 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 to
hold a competition for the various product vendors. The competition could
be a process solution bake-off. The competing product vendors will be
given the same process and the same technology infrastructure to prove
the capabilities of their products. The business process chosen for the
competition should not be complex, but it should cover at least two
applications that need to be integrated, and two human tasks that need
to be performed. It’s a good idea to have employees embedded with each
team if the product vendors allow for such practice. This will broaden
the organization’s understanding of BPMS products. The duration of the
competition might take anywhere from three days to four weeks. In
evaluating the prototypes from the various competing teams, the imple-
mentation time should be taken into consideration along with features
and ful?llment of the business process. Implementation time gives a good
indication of how easy or how dif?cult it is to implement solutions using
a particular BPMS product. Depending on the potential size of a BPMS
contract, it might be possible to ask the vendors to foot some or all of
the costs for the product competition. It is still a good investment even
if the organization has to pay the costs for the product competition. It is
far cheaper to spend money for proper product selection than for the
implementation and rework costs due to an un?t product.
With the selection of a BPMS product, there needs to be a technology
group to support this product. This should fall under the responsibility
of the process management technology group. This technology group
should be responsible for maintaining the servers, databases, and system
landscape associated with the BPMS product. The logical department to
manage the process management technology group is the IT department.
Most system administration tasks require the same skills regardless of the
product. The IT organization already has the knowledge base to adapt to
the maintenance of a BPMS product. Because this organization will be
supporting the process management initiative, it is prudent to align the
process management technology group to support process management
Business Process Management Implementation Methodology  251
projects. In the next phases, the process management technology group
will need to provide dedicated systems administration support to the
process 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. The
framework is a set of items and services that will be used in building a
process management solution. These items include a meta-data model, an
organizational model, implementation methodology, and standards. The
meta-data model is particularly important because it includes the enterprise
data model. There needs to be a consistent data model used throughout
the organization to describe such information as customer, vendor, sales
order, purchase order, business process performance, etc. Ultimately, data
is the basis of information. If every business process is de?ned using its
own set of data, it will be dif?cult to compare the same data from different
processes. Thus, the establishment of an enterprisewide meta-data model
is important. At this stage, no processes have been implemented. It is not
reasonable to expect a meta-data model that can cover all the future
processes to be implemented. The more comprehensive the meta-data
model can be devised at this point, the easier it will be for process
management projects. The other model is the organizational model. This
model re?ects the reporting hierarchy of an organization. Numerous
people in the organization use most business processes. The goal of the
organizational model is to expedite process management projects when
the processes in these projects need to assign work to speci?c members
in the organization. An example is the approval of a purchase order. The
process design can use the organizational model to indicate the approval
work item should be routed to the manager of the employee placing the
purchase order. Standards and implementation methodology are the other
components of a process management framework that should be devel-
oped. Implementation methodology is not unlike what we are describing
in this chapter, except it is much more detailed. The methodology should
specify 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 described
in this chapter would be contained in a process management project
methodology. The methodology would serve as a guide for process
management 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 metric
de?nitions, and training templates. The standards will ensure that projects
are documented using the same mechanism and that the outputs from
different projects are consistent.
Prepare Organization for Change
In the previous section, we discussed the process management unit and
the process czar. The process implementation of?ce is akin to the project
management of?ce we ?nd in project-based organizations. The subunit
determines which processes to improve, implements process management
projects, 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 that
executes process improvements. The bene?ts of the project of?ce have
been widely discussed in the management press. Their functional roots
and relationships limit project teams within functional departments. Fur-
thermore these functional project teams do not have the experience to
deal with cross-functional integrations, and they lack a support organiza-
tion that provides methodology and implementation knowledge. The role
of the process implementation of?ce is to provide a home for process
management implementation teams. This of?ce maintains the standards
for implementation and the network for implementation team members
to learn from each other. The implementation of?ce decides which pro-
cesses to improve based on the process performance gathered by the
process support of?ce.
Another important function of the process implementation of?ce is to
provide education on business process and business change. In recent
decades, the change management discipline has garnered attention in the
business management world. It is well established that effectively man-
aging change and cultivating change leaders within the organizations are
important for the business change initiative. Change leaders serve to
in?uence others within the organization to adapt to the new business
environment. Some people naturally adapt to change more readily than
others do. These people are the candidates to be the change leaders. The
ideal change leader candidates should also be respected members within
the organization who can exert in?uence on others. The role of the process
implementation of?ce is to provide training for these change leaders on
the value of the business change and how to create an organizational
culture that is friendly to change. These change leaders should be returned
to their functional departments to in?uence others to accept the process
management. They also serve as a pool of change agents who can
participate in process management projects, which we will discuss the
analyze phase. After change leader training, the process implementation
of?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 process
management tasks.
Business Process Management Implementation Methodology  253
Aside from providing change agent training, the project implementation
of?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. Because
maintaining an internal training capability is expensive, some of these
training activities will probably be outsourced. It is a good idea to maintain
an internal capability at least for the project implementation methodology.
As an organization completes the process management projects, it gains
more knowledge about how to best implement these projects. This knowl-
edge is part of the organization’s intellectual property and should be
transformed into enhancements to the project implementation methodol-
ogy. Internal training is a good way to disseminate that knowledge.
Phase 3: Analyze
The 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?ce
can start a new project and a new cycle involving these four phases starts
again. Analyze is the project planning and process analysis phase. The
inputs to this phase are the process to be implemented chosen by the
process implementation of?ce and an estimated project completion date.
Once an objective has been set, the project team should be formed. In
this phase, the project team should develop a project charter and analyze
the existing processes covered by the project scope. We will discuss the
project team setup, project charter, and process analysis in this section.
Figure 10.4 shows the tasks that should be completed during the analysis
Assemble Project Team
A project team should at least have the following components: project
management, 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 responsibility
is not diffused. The project manager’s responsibilities include creating the
project plan, coordinating the various teams within the project, eliciting
project stakeholder participation, and engaging the project steering
committee. Stakeholders are any parties that are affected by the process
management implementation project. They could include managers from
departments affected by the process management project, the IT depart-
ment because it has to support the systems, and users who have to learn
new ways and technology to conduct business. The stakeholder committee
is made of senior managers of business units that will be impacted within
the BPM project scope.
The business change team is the driver for the business process design
and organizational alignment. This team should be composed of change
leaders, core team members, organizational design experts, and process
design experts. The change leaders should provide leadership to the
business change team and they should serve to in?uence the affected
business units into adapting changes being implemented by the process
management project. Core team members are representatives from the
business units who can provide knowledge on how the current processes
Figure 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 holders
Deliver 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 charter
Phase 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 holders
Perform Process Analysis
Business Process Management Implementation Methodology  255
are performed. These core team members should be highly regarded and
trusted within their organizational units so they can provide a positive
communication link from the process management project to the business
units. It is important for the core team members to believe in the process
management initiative. Skeptical core team members communicating neg-
ative feedback to the business is detrimental to the change management
process. What is the difference between core team members and change
leaders? Core team members are usually people closer to the work. They
have a good understanding of the operational aspects of their section of
the business. Change leaders are usually higher up in the organizational
hierarchy. 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.
• Change leaders
• Core team members
• Organizational design experts
• Process design experts
• Enterprise application
• Web designers
• Web developers
• BPMS application developers
• Legacy application developer
• System administrators
• Database administrators
• Network administrators
BPM Project Structure
The other resources in the business change team are subject matter
experts, including experts in organizational design and process design.
Organizational design experts have the responsibility of analyzing the
organizational structure from a process performance optimization perspec-
tive. Sometimes the organizational design analysis leads to organizational
structure modi?cations to provide best process performance. Changes in
organizational structure usually entail changes in jobs and roles. De?ning
roles and responsibilities of jobs affected by process management is
another task that organizational design experts have to tackle. In addition
to these, organizational design team members help to de?ne process
performance 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 experts
analyze the current business processes within the scope of the process
management project, and they redesign the business processes using BPM
principles. Process management experts are trained in process design
methodologies, and they are trained in using the business process design
and simulation tools of the BPMS product. The primary responsibility of
the process management experts is to take the inputs from the other team
members and utilize scienti?cally rigorous process design techniques to
devise 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 programs
required to support the process management design. BPMS vendors adver-
tise their products as being capable of automatically generating code, with
some vendors going as far as advertising programming-free solutions. The
reality 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, user
interfaces, and component interfaces. The development team should
include 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 the
applications that are part of the process management project scope. These
development roles are needed in the development team. Individual devel-
opers might be able to satisfy more than one role. Thus, the number of
development team members might be less than the number of roles. There
is a distinction between Web designer and Web developer. The Web designer
prepares the look and feel of a Web page, while the Web developer
programs the server-side logic that controls the Web page. The enterprise
application architect designs the component model of the process man-
agement project scope. The architect is responsible for making sure the
Business Process Management Implementation Methodology  257
components within the process management framework are leveraged for
reuse and that new components are designed with future reuse in con-
sideration. Another responsibility of the enterprise application architect is
to ensure all components follow enterprise process management standards.
Most of the applications in a process management scenario might not
provide adequate interfaces to satisfy the requirements of the process
management solution. Application developers knowledgeable about these
existing applications should be part of the development team to ensure
these applications can be properly integrated in the BPMS product.
The last team in the process management project is the technology
support team. This team performs system administration tasks and system
performance 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 fully
staffed and dedicated technology support team can ensure that technology
related issues do not contribute to project delays. Regardless of project
size and whether the dedicated technology support team is part of the
project, there needs to be a previously agreed on service response time
between the technology support team and the other project teams. This
service level agreement should take the heightened support needs during
the critical phases of the project into consideration.
Project Charter
With the team assembled, the next set of tasks revolves around the creation
of the project charter. The project charter is the basis for the existence of
the 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 charter
is similar to the project charter from the Six Sigma methodology. The
process problem states the current business process (or lack of business
process) and the business challenges are a result of the current state. The
project scope is the scope provided by the process implementation of?ce
to initiate the project. Various teams should collaborate to determine the
implementation objectives. These objectives include anticipated bene?ts
as a result of the project. The bene?ts are high-level bene?ts that will be
more detailed as the project engages in the design phase. Any assumptions
made to reach the anticipated bene?ts should be stated in the project
charter. Finally, the charter includes the roles and responsibilities of all
parties involved and a high-level project timeline. Roles and responsibilities
extend from those of the project team to the project stakeholders, the
business users, and the steering committee. The project timeline included
in the charter is a high-level timeline that will be tweaked during the
design phase. This timeline is an estimate based on experience with
previous projects of similar scope. The timeline might turn out to be
unrealistic as the project team ?nishes the design phase. At that point,
the detailed project plan should be submitted to the steering committee
for approval with any changes in dates.
The main purpose of the project charter is to serve as a communication
to all parties affected by the project. The steering committee and project
stakeholders will sign this project charter. Once the project charter has
been authorized, it serves as the mandate the project team can use to
justify the project’s existence and actions. By involving the stakeholders,
the business will signal its commitment to the project.
Process Analysis
In preparing for the project charter, the project team needs to perform
an analysis of the current processes in the project scope. High-level
information about the existing processes has already been gathered during
the research phase. The process analysis expands on the information
previously collected. The primary goal of process analysis is to determine
the performance of existing processes. The data to perform process
analysis might not be easy to gather because there might not be consistent
and readily available data for the current processes. If a process involves
applications that contain transactional logs, these logs can be used to
determine the activity duration. Sometimes when transactional logs are
not available, the analysis would have to be done using indirect measure-
ments such as dividing total transactions in a given period by the number
of full-time equivalents for that period. Other techniques for process
measurement include direct observation and interviews. One of the jobs
of the process implementation of?ce is to devise techniques and tools for
enabling current process analysis. Other than process performance mea-
sures, the project team should also determine current process challenges
while performing process analysis. Using the performance measures and
information on current challenges, realistic project goals can be drawn.
The results from the analysis are used as inputs to the project charter.
Phase 4: Design
The design phase is when the project kicks into high gear. The primary
goals of this phase are to design the best process management solution
and 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  259
The business change team has the responsibility for designing the
solution. The approach for process design should include workshops with
various business stakeholders to obtain their inputs. Once business inputs
have been gathered, the business change team, led by the process design
experts, should come up with alternative high-level process designs. The
alternative design solutions are entered into the BPMS process designer
and simulations are run to choose the best process alternative. The process
alternative chosen is then the focus of further design activities. It has been
remarked that processes are like onions, with layer upon layer of detail.
The chosen process alternative should undergo cycles of re?nement and
simulation so it contains all the decision points, branches, and exceptions
that are likely to be encountered in real life. Readers interested in knowing
more about process design and analysis techniques might want to read
books by Harmon and Burlton.3,4
Figure 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?nement
Build Process Prototype
• Choose the primary process branch of the process management solution
• Develop business logic, component interfaces and web pages for the solution prototype
• BPM project team
• Project stakeholders
Phase 4 Design—Overview
Complete 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 documents
Optimize Business Process Design
The same time the process design is being re?ned, the organizational
design experts should look at the current organization and determine what
needs to be changed to take advantage of the process solution. Organi-
zational changes might be as simple as updates to job descriptions or
they 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 in
the to-be business process and activities to be performed by each role
should be ?nalized by the end of this phase.
To validate the feasibility of the to-be process solution, a prototype
should be built. The prototype should cover the main processing branch
of the process solution. If any applications are involved in the process
solution, the prototype should include integration to at least one applica-
tion. The prototype is a joint effort between the business change team
and the development team. This provides the development team with a
chance to see what the process solution looks like and what the level of
development efforts might be. Traditional waterfall methodologies do not
provide the development team the opportunity to be involved in the
solution until after the functional team has completed detailed design.
The inclusion of the prototype in the design phase should hopefully bring
about a closer working relationship between the business change and
development teams. The other bene?t of the prototype is it serves to
mitigate implementation risks. By engaging the development team during
the design effort, the technical feasibility of the process solution can be
determined. Sometimes functional teams would design elegant and highly
complex solutions only to have the technical teams determine the solution
is either impossible to build or cannot be implemented within the project
timeframe. The prototyping effort makes sure the ?nal process solution
is technically feasible while still covering the main process requirements.
In building the prototype, the enterprise application architect works
on designing a high-level process solution technical model. This model
contains a data model and a component model. Traditional object-oriented
design methodology usually contains state transition and sequence dia-
grams to capture changes in the object state and the ?ow of process
activities. In the BPMS design approach, state transitions and process
sequences are modeled graphically as part of the process design using
the BPMS process designer. This has the advantage of integration between
modeling and development, because the development is done by directly
embedding logic into the process design. This also means the enterprise
application architect can focus on designing the functions of each com-
ponent without having to be bogged down by working on speci?c
interactions of the components using Uni?ed Modeling Language (UML)–like
Business Process Management Implementation Methodology  261
diagrams. Process sequences, thus component interactions, are handled
in the BPMS process designer as part of the overall process design crafted
by the process design experts. The enterprise application architect draws
on the standard enterprise data model when building the process solution
data model. This ensures the solution data model will be consistent with
the enterprise data model. The other members of the technical team would
also be involved in building the prototype. If there is no enterprise Web
design style guide, the Web designer could come up with several Web page
templates for the project team to choose. Web and application developers
would be working closely with the process design experts from the
business change team to make sure all the development items for the
prototype are designed and developed.
One of the handicaps of IT–enabled process change methodologies
has been a disconnect between functional design and the actual devel-
opment output. In these methodologies, the functional design team gathers
the business requirements. These requirements are translated into func-
tional design documents. The functional design documents are handed to
the technical analysts to convert to technical design speci?cations. These
design speci?cations are given to programmers for development. The
multiple layers of communication and translation of requirements usually
leads to differences between the original requirements and the imple-
mented solution. Using a BPMS designer and a project methodology can
help alleviate the requirement-development gap. The BPMS process
designer comes with a high-level process ?ow layer and a low-level
business logic–scripting layer. The low-level business logic-scripting layer
adds 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 are
technically savvy and are trained in the BPMS process designer should
be able to design detailed process ?ows using the high-level graphical
process ?ow layer of the BPMS process designer. The developers leverage
on the process ?ow has already been completed for the process solution
in building the low-level business logic script. Using the same environment
for process ?ow and low-level business logic development should help
reduce the chance for the functional–technical disconnect.
Aside from a BPMS process designer, methodology-related measures
can be taken to foster the environment for close cross-team collaboration,
thus reducing chances of functional–technical disconnect. The construction
of a prototype is a good opportunity for close cross-team collaboration.
It requires the business change and development teams to work together
in building the prototype. Process design experts from the business change
team create the process ?ow, and the development team has to develop
business logic scripts and integration to the applications or services
included in the prototype. Work on the design document provides another
opportunity 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 work
closely with the development teams in completing these documents. It is
a good idea to have a development team member shadow a process
design expert during this phase. This approach enables the development
team member to fully understand the rationale behind the process solution
design. Even though most IT–enabled project methodologies stress the
importance of a close working relationship between functional and tech-
nical project teams, the relationship, from this author’s experience, has
usually been uncomfortable. Functional team members are sometimes
miffed about the length of development time and shortcomings they
perceive of the developers’ meeting design speci?cations. Technical team
members are sometimes frustrated with changes to design requirements
and what they perceive as unreasonable requests from functional team
members. Not understanding each side’s challenges might be the cause
of most of the discomfort. This tension between functional and technical
sides 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: Implement
At the end of the design phase, the solution prototype has been built and
the 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 and
functional design documents. Several activities happen during this phase:
1. Complete the technical design document
2. Develop the programs and the user interfaces needed for the
process solution
3. Conduct a unit test of the individual programs
4. Conduct multiple iterations of integration tests involving all roles,
components, and programs
5. Design training documents
6. Conduct user training
7. Create online help documents
8. Go live
Business Process Management Implementation Methodology  263
Work on the technical design documents could actually start during
the design phase. The technical design work has to be done to support
prototype building. Any remaining technical design for the process solution
that was not part of the prototype should be ?nished at the beginning of
this phase. The enterprise application architect should have de?ned the
high-level technical model for the process solution during the design
phase. Once the high-level technical model has been re?ned to contain
the information on individual interfaces, the developers are responsible
for completing the technical design speci?cations. In the course of com-
pleting the technical design, the development team would have to engage
in a series of team discussions and design walk-throughs to ensure that
all the pieces ?t together and form one coherent solution design. When
the technical design has been ?nalized, technical team members start on
the development items assigned to them. Unit testing follows completion
of the development items. Unit test plans for each development item
should be drafted and executed.
Unit tests are the ?rst set of tests in the software testing cycle. The
other sets are the integration tests. There should be at least two iterations
of integration tests. Integration test is the end-to-end process management
solution. Business scenarios make up each cycle of the integration test.
Business processes is typically composed of multiple decision points and
branches that a process instance can undertake. A scenario is one end-
to-end path of a business process instance. The integration test scenario
contains the activities performed by human and system participants for a
business scenario. Each activity in the scenario has input test data and an
expected output from the activity. When executing the integration test
plan, the output should be compared to the expected output to determine
whether there are any defects. There are several testing management tools
in the marketplace, such as TestDirector from Mercury Interactive, Silk-
Central from Segue Software, eTest from Empirix, etc. It is advisable to
use a test management tool. Test plans for each scenario can be loaded
into the test management tool and testers are assigned to each test plan.
Defects encountered during test plan execution can be entered in the test
management tool and assigned to the appropriate party for resolution.
Once the defects are in the test management tool, the integration test
manager can track them for resolution. A good integration test is one that
uncovers and resolves a high number of defects. Defects should not be
closed until all the test plan steps have been re-executed to ensure the
defects have been resolved. The ?rst cycle of integration testing should
cover the main scenarios that account for 80 percent of business process
instances. The second cycle of integration testing should cover as many
other scenarios as possible. Typically, the scenarios in the second cycle
are exception process paths, while the initial cycle covers the main process
branches of the business processes in scope. During defect resolution, if
a defect uncovered in the integration test has implications to other sce-
narios, all impacted scenarios should also be retested to make sure the
changes do not negatively impact these scenarios.
The integration tests involve the process design experts from the
business change team and the development team members. The core team
members and the organizational design experts are responsible for creating
the training documents. Care should be taken to make sure the changes
resulting from the integration test defect resolution are communicated to
the team members crafting the training documents. Effective training
material usually involves computer interaction for the trainees. When the
training documents are done, they can serve as the basis for online help
documentation. To coordinate the training effort, there needs to be a
training manager who handles the scheduling and coordination of the
training sessions. It is important that suf?cient resources and attention be
devoted to the training effort. The most common complaint from users
of IT–enabled business change projects is insuf?cient training. Properly
trained users will help reduce support needs and help raise acceptance
of the business process management solution.
The implement phase is the phase requiring the highest amount of
involvement from the technology support team. Regardless of how well
a project has been planned, the implement phase usually involves long
working hours from team members. It is not inconceivable that work will
be done 24 hours a day. It is critical to have timely support from the
technology 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 migration
of the process management solution between the various environments.
The development environment is where process design experts do the
development work and where the development team constructs the pro-
cess management solution. The process management solution is promoted
to the quality assurance environment after all the components in the process
management have been unit tested. The integration tests are performed in
the quality assurance environment. No development work should be done
in the quality assurance environment. In fact, no development work should
be done in any environment except the development environment. All
defects are ?xed and unit tested in the development environment and
promoted to the quality assurance environment to retest the integration
test scenarios. The training environment can be a copy of the quality
assurance environment. After the training environment has been created,
any defects ?xed in the development environment should be promoted
to both the quality assurance and the training environments. At the
Business Process Management Implementation Methodology  265
conclusion of the integration tests, the production environment should be
built by promoting all tested components of the process management
solution from development environment.
Other than the minimum required environments, it is very useful to
have a sandbox environment. The sandbox environment is used to build
the prototype and for the process design experts and developers to
experiment with different alternatives before creating the desired alterna-
tive in the development environment. Another helpful environment is
stress testing. For process management solutions expected to experience
high throughput, stress testing is essential to make sure the solution, when
put into the production environment, can handle the throughput with
reasonable response times. During stress testing, process instances are
created using an automated testing tool with test data from the integration
test plans. Because of the high volume of process instances required for
Figure 10.7 Diagram of BPM System Landscape and Solution Migration Paths.
Sandbox Development
Stress Test
2 2
1. Design implemented in Development environment based on
prototype in Sandbox
2. Solution migrated from Development to Training and Quality
Assurance after unit testing in Development
3. Solution migrated from Development to Stress Testing
environment after one iteration of integration test
4. Solution migrated from Development to Production
environment after successful integration test cycles
Required environment
Optional environment
BPM Implementation System Landscape
stress testing, it is not recommended to perform stress testing in the same
environment and at the same time integration testing is taking place.
Go live is the last activity of the implement phase. Go live is when
the users are allowed into the production environment to use the process
management solution. It is the most exciting time of the project. This is
the moment when the project team and the organization ?nd out whether
the process management solution is working or not. As the saying goes, this
is when the rubber meets the road. Some project team members should
be assigned to support groups of users. Those team members not assigned
to speci?c users serve as the issue resolution team. Inevitably, users will
encounter problems. An issues tracking tool should be used to capture
all issues reported by users. Once issues have been reported, they should
be assigned to issue resolution team members for resolution. Go-live
support can last from two weeks to two months or longer. The end of
go-live support marks the transition from project implementation to pro-
duction support. This is when the support for the project management
solution shifts from the project team to the process support of?ce.
Phase 6: Support
The last phase of the BPM implementation methodology is the support
phase. Where the previous three phases, analyze, design, and implement
involve the process management project team, this phase involves the
process support of?ce. The process management organization units report
to the process czar. The process implementation of?ce is the unit that
implements process management projects. The process management
project team participating in the analyze, design, and implement phases
comes under the auspices of the process implementation of?ce. The
process support of?ce is the organizational unit that takes over support
of 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 leaders
and core team members) return to the business units and other project
team members (such as the project manager, the organizational design
experts, and the process design experts) prepare for the next process
management project.
The process support of?ce contains several support teams. Each of the
process support teams is assigned business processes that it supports.
Once the process management solution from the project team has been
transitioned to the process support team, the support team is tasked with
monitoring process performance, gathering process statistics, validating
Business Process Management Implementation Methodology  267
the process management solution design, and managing the process.
Monitoring process performance and gathering process statistics can be
done using the BPMS product. The process performance statistics can be
used to determine whether the original design goals of the process
management solution have been attained. If the goals have not been
attained, the process data will help in diagnosing problems with the design
and provide feedback to the process implementation of?ce for future
projects. In a process-oriented organization, process performance serves
as a benchmark for employee rewards. The performance statistics gathered
by the BPMS product serve as inputs for management and human relations
(HR) to decide on employee rewards. Finally, the process support team
resolves issues encountered with any process instances. Working with
process managers, the process support team implements enhancements
to the processes it is supporting. Enhancement opportunities that require
a longer time frame and substantial resource involvements are submitted
to the process implementation of?ce. The project planning function of
the process implementation of?ce prioritizes, plans, and schedules process
improvement opportunities for implementation.
In this chapter, we discussed a generic BPM implementation methodology.
What we described here might not be 100 percent applicable to all
organizations intent on pursuing BPM. It should serve as a high-level
reference for most organizations. Hopefully, a BPM–bound organization
will ?nd this reference methodology useful in developing its own imple-
mentation approach. In this book, we discussed a wide range of topics
regarding the BPM principles and technology. BPMS is a young and
maturing technology. New products and enhancements for existing prod-
ucts are constantly being introduced. What we described in this book are
ideal features we believe a BPMS product should possess. While the
current offerings by product vendors still have room for improvement for
effecting a process management solution, the products that are available
by the time this book is published will undoubtedly be markedly improved.
BPMS is a very exciting technology that promises bene?ts long desired
by process-oriented organizations. The excitement also generated hype
about what this new technology can do. This book takes a realistic
approach in discussing what this technology can offer. Hopefully, readers
will ?nd the content of this book useful in your journey into BPM.

Acerca de Raúl Suescún

Padre, esposo y programador web el resto del tiempo. Ver todas las entradas de Raúl Suescún


Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de

Estás comentando usando tu cuenta de Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: