Alignment Architecture Business Process Management

(1)

Alignment Architecture

Business Process Management

(2)

Versions

Version Date Modified By Modifications

1.0 01/02/2014 Peter De Kinder Initial Version

1.1 21/05/2014 Peter De Kinder Overhaul of chaptering + appendix elaboration 1.2 10/03/2015 Peter De Kinder Added process management diagram + OODA 1.3 29/12/2015 Peter De Kinder Elaborated Refinement Techniques

References

Document Date Description

OMG-BPMN Jan 2011 OMG Business Process Modeling Notation (BPMN) v2.0 OMG-BPMM June 2008 OMG Business Process Maturity Model (BPMM) v1.0 OMG-BMM Nov 2008 OMG Business Motivation Model (BMM) v1.1

O-BMM Sep 2010 Oracle Practitioner Guide – Creating a BPM Roadmap v3.0 O-BPE Dec 2010 Oracle Practitioner Guide – Business Process Engineering v3.0 O-GOV April 2011 Oracle Practitioner Guide – A Framework for BPM Governance v3.0 O-FND Sep 2010 Oracle Practitioner Guide – BPM Foundation v3.0

BS-BPMN Oct 2011 BPMN Method & Style 2nd_{Edition (Bruce Silver)}

PH-BPC July 2007 Business Process Change 2nd_{Edition (Paul Harmon)}

MMJS-ABFT Sep 2002 Agile Business for Fragile Times (Mary Pat McCarthy & Jeff Stein) WCKRM-BOS Aug 2005 Blue Ocean Strategy (W. Chan Kim & Renée Mauborgne) WFMC-PSB Sep 2014 Passports to Success in BPM (WFMC)

Prerequisites

Document Description

(3)

1 Introduction

1.1 BPM as a Project

Projects are driven by requirements, and thus so are the choices made surrounding architectures in those projects. To categorize architectures we devise three different groups as shown in the illustration.

Illustration 1.1.1 – Architectural Categories

We position BPM Architectures in the Alignment Architecture Category, where we place those architectures that are not only driven by a strong technological current, but by a business current as well. In this case the solution will not only be strongly constrained in requirements by its technological components (more specifically the BPMS), but also by the business processes defined.

1.2 BPM as a Discipline

Where up till World War II, when we speak of Business Process Management, it was all about work simplification, we nowadays usually divide this effort into three streams of thinking. The Business Management stream where we concern ourselves with the strategy of the enterprise and the structure of the industry it is situated in. Quality Control is the school of thought where we focus on improving business processes, and finally information technology where we try to automate these processes. Naturally BPMS components have the most allegiance with the third stream.

(5)

The book “Business Process Management – The Third Wave” by Howard Smith and Peter Fingar characterizes this evolution as the following three waves:

 The first wave (early part of the 20th_{century) focused on gaining higher efficiency in the day-to-day}

operations of businesses with the introduction of Taylorism (or the scientific management theory), where processes were present in spirit through work practices.

 The second wave focused on the adoption of packaged enterprise applications (ERP, SCM, CRM…) and the utilization of business processes embedded in these applications. Processes are manually engineered, and through one-time development activity practically cast in stone.

 The third wave focused on current efforts to recognize BPM as a holistic endeavor that a business engages in to gain efficiency and agility in its operations while creating sustainable competitive advantage. The ability to change processes becomes predominant over the ability to create them in the first place. The reason for the emergence of this third wave and the most current incarnation of business processing, comes from the limitations of the previous wave to adapt to the particularities of the enterprise in which it was rolled out, as some of these systems are so complex that modifying them costs a large amount of expertise, time and money. This adaptation is usually done by writing scripts or one-off coded extensions to these packages, of which studies would indicate they take up as much as 20% of the initial investment, and in some cases prevent timely upgrades, preventing the users from the benefits of progressive releases of these packages. They also lacked the element of collaboration within the firm itself, as well as with other firms.

They also suffer from a lack of visibility over the entire process, which is mostly scattered over these systems. Not only is there no mapping on which parts of the process are addressed by which tools, but there is also no support for determining the gaps in the automation (and thus the monitoring) of the process. Once this overall coherence is visible, the integration of said solutions also becomes a lot less difficult.

The success of rolling out a BPM approach within an organization depends in large part on how well the organization can make process improvement part of the DNA of the organization, and their willingness to engage fully in an iterative approach for BPM. A transition to a process-managed enterprise is complete when it exhibits the following attributes:

 Process improvement is embedded in the business strategy  Competitive advantage is supported throughout the value chain  IT practices process-driven budgeting and resource allocation

 Key processes flow seamlessly through the value chain or key processes

1.3 BPM in an Organization

1.3.1 BPM and Business Strategy

Brett Champlin, president1_{of the Association of BPM Professionals states that BPM is only one component of}

business modeling, and that there are other areas of which extensive knowledge is needed to properly describe, analyze, transform, and optimize a company’s business processes. The following information is of equal importance and is not included in an enterprise BPM program:

 Enterprise or Line of Business Information

o High-level business context, describing the business’s relationship to Competitors, Regulators, Suppliers, Business Partners, Customers, Community, …

o Strategic Objectives and Performance Metrics o Controls and Constraints

o Markets and Consumers o Products (goods and services) o Locations

 Operational, Cross-Process Information o Value Chains and Process Portfolios o Operational Goals and Objectives o Policies

o Performance Metrics and KPIs o Organizational Structure and Roles  Process-specific Information

(6)

o Activity Resource Requirements

o Revenue and costs, both activity-based and resource-based o Job Aids (instructions for human performers)

 Technical Information o IT Systems o Services o Data

Typically, all these information fields have describing models of their own, which in some way or another relate to the Business Process Models (usually described by an Enterprise Architecture), or in the Business Strategy (as described by the “Business Strategy - Analysis” document). Those that have been stricken through, are the topics the writer of this document and Brett Champlin disagree on.

1.3.2 BPM and Enterprise Architecture

In enterprises, it is not uncommon for several architectures to coexist at any given time. Some of those address very specific needs, while others are more general in nature. Enterprise Architecture (EA), or more specific TOGAF, tackles this by using Architecture Partitioning. TOGAF stipulates the needs for this with following point:

 Addressing all problems within a single architecture is too complex  Different architectures might conflict with one another

 Different (human) resources need to be leveraged for different elements of architecture at the same time, and partitions allow for specific groups of architects to own and develop specific segments

 Effective architecture reuse requires modular architecture segments that can be taken and incorporated into a broader solution

Illustration 1.2.1 – Architecture Content Aggregation (TOGAF)

A point of concern is that this partitioning strategy incurs the risk of producing a fragmented and disjointed collection of architectures that cannot be integrated to form a coherent picture. For this to be mitigated, TOGAF proposes a content framework (see illustration 1.2.1). Architectures are segmented, based on debt of detail, organizational scope and architecture domains. The positioning of a BPM architecture in this segmentation is spanned over all architectural domains. Its depth of detail is however situated on the lower two segments. The organizational scope of the architecture is of course dependent on the adoption level of the architecture, and can range from enterprise-wide to processes within an individual business unit.

(7)

EA and BPM are very synergistic and highly complementary. Where EA will deliver value to the BPM effort by identifying those processes in the value chain which offer the highest benefit to the business goals, BPM will deliver value to the EA effort by operationalizing the future-state vision established by EA. And through this operationalization, BPM creates detailed current- and future-state business models that enrich the EA models, supporting other EA efforts such as information architecture and application portfolio rationalization.

Illustration 1.2.2 – BPM in a Project Cycle

In summary, the different branches of BPM will come into action during the cycle of implementation and governance of a project where it is the preferred architectural choice (dependent on the requirements), and the BPM analysis techniques can be viewed in such a cycle as shown on the illustration 1.2.2.

(8)

2 Purpose

2.1 Requirements

For an organization to be successful, it needs to realize a simple truth, paraphrased from the well-known adage by Heraclitus of Ephesus: It is in a constant state of change. And this state has a dual nature. The changes take place, driven by internal as well as external influences.

As the internal workings of organizations evolve, so must the technologies that support them. Several factors are now occurring simultaneously that inhibit the ability of prior technological solutions to support this constant environment of change:

 Increasing Business Complexity: Organizational layers, products, and services grow and change in scope

and complexity.

 Increasing Number of Regulations and Compliance Requirements: New compliance issues emerge in

response to internal and external business standards and regulations.

 Increasing IT Complexity: Layers of disparate (and often siloed) information technology (IT) systems inhibit

broad-spectrum performance visibility and overall productivity.

 Increasing Data Complexity: Changing data and workflow inputs and the use of mobile devices and other

social technologies in the workplace increase the strain on IT departments’ ability to support organizations.  Increasing Talent Pool Dynamics: The employees of a company are more than ever in flux with competition

and an aging workforce

Not only will organizations change from the reasons listed above, they also have to react to the reality of the market they are operating in. We calls these external influences. Typically, in economically bad times, a company will seek to make their processes more efficient and focus on reduced costs, where in economically good times, they will improve their processes to offer better products and services in order to expand their customer base. According to Treacy and Wiersema, the three value propositions are:

 Product Leadership: These companies focus on innovation and performance leadership. They strive to turn

new technologies into breakthrough products and focus on product lifecycle management.

 Customer Intimacy: These companies focus on specialized, personal service. They strive to become partners with their customers. They focus on customer relationship management.

 Operational Excellence: These companies focus on having efficient operations in order to deliver the lowest-priced product or service to their customers. They focus on their supply chain and distribution systems in order to reduce the costs of their products or services.

Illustration 2.1.1 – Company Positioning Strategies

(9)

BPM will attempt to alleviate these concerns by enabling an organization to possess the capabilities attributed to business agility, as described by McCarthy and Stein2_.

 Maintaining a continual focus on profitability and revenue growth

 Understanding central priorities and the importance of assessing and reporting on value  A sustained commitment to communications that starts at the top

 Acquiring and filtering pertinent information from and to key constituents, rapidly  Testing assumptions and frequently measuring results

 Having a performance culture  Enabling shared decision making  Adapting rapidly to change

As this is no trivial amount of work, the entire organization needs to shoulder this task. The BPM philosophy relies heavily on and therefore will promote Business-ICT-Alignment. The important word here is "alignment". It is not just about IT! It is not just about business! It is about working together - one of the major challenges of any BPM project. Make no mistake, the introduction of a BPM architecture will change the way an organization functions. It will also require a cultural changes as following needs will arise as well:

 Business user will need to be trained and incentivized to participate in modeling (becoming knowledge workers)

 Business management needs to be committed to their team’s participation  IT needs to accept the knowledge workers as modelers

 The organization will need to accept Process-Driven Agile development projects

This will result in a host of benefits, needed for an organization to remain competitive in its chosen market segment, or as McCarthy and Stein dubbed it “a survivability edge that allows organizations to observe, react and factor market changes into an embedded discipline of continual cost and growth refinement”:

 Increased efficiency (productivity improvements)  Higher transparency and distributed workload

 Better quality and reduced opportunities for error rekeying  Reduced costs

 Reduced turnaround times  Enabling new business models

 Increase business involvement and responsibility

 Emergency preparedness and disaster recovery responsiveness  Reduced time-to-market by decreasing development/deployment times  Removal of dependency on key individuals

 Increased responsiveness to changing regulatory requirements

 Social Media Collaboration (or Social BPM). Rebranded by Gartner to “Design By Doing”

2.2 Hurdles

As with the introduction of any new concept within an enterprise, there will typically be a number of hurdles to overcome when introducing an architecture that will impact the enterprise as a whole (enterprise-wide adoption level). These hurdles can be divided into the following categories:

 Management hurdles: we need a positive management buy-in and a clear mandate for the intended changes. We also need management to identify which processes align best with the business strategy.  Organization Adoption hurdles: Some of the biggest challenges are to align staff to the new/changed

processes and customer requirements by ensuring there is sufficient internal education and communication. Especially when the staff is part of different departments, it is imperative that they begin to see that they are working in a company-wide process, and not competing against each other.

 Technology hurdles: The technology should support a large number of (if not all) requirements put forth by the different stakeholders. In the case of BPM, this means sustaining a portfolio of business processes, and making them work together seamlessly. This also includes the integration of existing systems into these processes in a seamless manner.

(10)

Except for the typical hurdles associated with such endeavors, there is also a human component to this approach, which translates into the following pain points adopters will raise:

 It is something extra to do

 You have to take time out to really understand where everyone fits in  You have to measure things you don’t normally measure

 You have to talk to and work with people that sit in the team beside you  You identify weaknesses in your current methods

 You may have no idea who the customer is or what they think  Managers are scared of the unknown

 It threatens power bases and hierarchical structures

 It drives changes… which many people feel uncomfortable with

We can summarize these pain points into the following topics: resistance to change and unsurmountable effort anxiety. Each of these should be addressed with a proper change management strategy.

2.3 Constraints

One of the possible technical constraints is the level to which the chosen BPMS implements the BPMN2 standard. It should be obvious that symbols not supported in the automation tool should be avoided in describing business processes that are going to be automated. There is however a certain duality in this. One could also argue that the choice of the BPMS is dependent on which symbols have been used in the business process description of the business architecture.

(11)

3 Philosophy

3.1 Business Concepts

3.1.1 Definition

Although no universal definition of the business process exists, and a wide range of these are postulated from Adam Smith (The Invisible Hand) to Michael Porter (Five Forces Analysis) to Henry J. Johansson (Business Process Reengineering), a set of characteristics can be distilled from this amalgam of statements:

1. Definability: It must have clearly defined boundaries, input and output.

2. Large and Complex: involving the end-to-end flow of materials, information and business commitments. 3. Cross-functionality: A process regularly can, but not necessarily must, span several functions.

4. Order: It must consist of activities that are ordered according to their position in time and space. 5. Dynamic: Constantly changing in response to customer demands and changing market conditions. 6. Customer-Oriented: There must be a recipient of the process' outcome, a customer.

7. Value-adding: The transformation taking place within the process must add value to the recipient, either upstream or downstream.

8. Embeddedness: A process cannot exist in itself, it must be embedded in an organizational structure. 9. Dual natured: processes are both business and technical in nature.

The compromise to the definition of the Business Process Management Discipline has been attempted in 2015, and specialists around the globe coined the following definition:

Business process management is a discipline involving any combination of modeling, automation, execution, control, measurement and optimization of business activity flows, in support of enterprise goals, spanning systems, employees, customers and partners within and beyond the enterprise boundaries.

To me, this definition feels a bit too much as a compromise of sorts. This definition tries cramming every bit of insight about the discipline into a single unified theory, and ends up being too broad and generic for my tastes. If I want to use this theory to verify whether any activity in a transformational project (for example an IT development project) is part of this discipline, I feel the answer would always be “yes”. The scope of the discipline has become almost all encompassing with this definition.

3.1.2 BPM Levels

According to Bruce Silver3_{, BPM in the real world can be classified into 3 levels, based on how the model is used:}

1. Descriptive modeling, the kind most BPM consultants typically talk about -- high-level, occasionally ignoring BPMN's diagram validation rules, but easy to communicate across the organization, linked with a methodology for how to do it. Level 1 modeling requires understanding of fundamental concepts such as pools and lanes, tasks and sub-processes, and sequence flow, but not the complexities of BPMN's various flow control and event patterns. Its goal is to simply document the process flows in an enterprise.

2. Analytical modeling, more detailed, showing all the steps, including the exception paths, required either to analyze process performance using simulation or to create detailed requirements for an IT implementation. Although Level 2 modeling requires disciplined thinking and attention to detail as well as an understanding of BPMN's various decision and merge patterns, events, and exception handling patterns, it reflects a business-oriented perspective and must thus be understandable by business users, and not just IT. Level 2 diagrams must be both valid according to the rules in the BPMN spec, and organized effectively as hierarchical representations of the end to end business process.

3.

Executable modeling, where BPMN is part of the executable process implementation. While this capability of

BPMN is a major reason for its widespread adoption, modeling at this level is somewhat vendor tool-dependent, as most BPM Suites do not support all of the gateway and event types defined in the BPMN spec, and may offer their own proprietary extensions as well. Moreover, most tools ignore the BPMN spec's implementation attributes, and instead provide equivalent implementation detail in tool-specific attributes of the model's activities, gateways, and events. Its purpose is to enrich the Level 2 model with technical

(12)

specifications. Level 3 diagrams thus typically impose additional validation constraints beyond those of the BPMN spec.

3.1.3 Process Lifecycle

Any process from the moment it is selected as a viable candidate for a BPM project, undergoes a number of states positioned on the process Lifecycle (as seen on the illustration). These states are:

 Identified - The process has been selected for modeling and automated process management.

 Defined/Refined - The business aspects of the model have been captured, modeled, and refined to a sufficient level to support this iteration of process optimization. On the first iteration through this cycle the identified process selected for automation undergo process discovery and definition; on subsequent iterations the process, having been already defined, is merely refined. (descriptive modeling)

 Outsourced – The process has been deemed opportune to be outsourced to a third party. This is followed by a periodic assessment of whether or not to continue with the outsourcing or to consider the process for refinement again.

 Designed - The technical aspects of the process model have been addressed including integrations, message handling, interface specification, exception handling, security, transactions, etc. (analytical modeling)

 Composed - All external integrations, message wiring, and security roles have been configured. (executable modeling)

 Tested - Any software engineering needed to support the process has completed and has been tested along with the process.

 Deployed - The executable process model, and all external dependencies, have been deployed into a production environment.

 Approved - Final QA approval. All testing and user acceptance has completed. The model has been commissioned and BPM system manages execution of the business process.

 Monitored - Process metrics being are collected and provide actionable business intelligence.  Disposed – The process no longer has a purpose and all allocated assets are repurposed.

(13)

3.1.4 Knowledge Workers

Illustration 3.1.4.1 – Overview of Employee Interactions

People are at the heart of any meaningful process, be they customers or employees. The employees are categorized by the level of involvement they have with the process, from simply performing the tasks within the process to redesigning existing or creating new processes. They are also indicative of the level of empowerment their job brings them (ranging from low to high on the illustration).

3.2 Best Practices

The idea to use a proven approach to BPM projects is to promote predictability, so that the results and costs of such an undertaking can be determined in advance with a high degree of certainty. The clue here is to stick with the recognized standards. Try to deviate from them as little as is needed for your project. It will also add to the traceability to have the same governance approach. This way the impact analysis of changes is reduced in complexity.

A BPM Architecture does not come from one set of stakeholders, but is rather a concert of many different roles. As indicated in previous chapters, it serves to divide the workload and accountability across both IT and business people. This comes from the need for a clear definition of duties. The importance of stakeholder analysis in these types of projects cannot be understated. The illustration below shows a number of different roles we can include in the analysis. Be sure to strive for an early participation of as much of the stakeholders as possible.

(14)

Several other best practices are listed here:

 Work out your exit plan. This should be a component/process failure prevention strategy

 Have a watchful eye on the funding mechanisms in place, which can be leveraged to guide the evolution of a BPM initiative

 Develop process manuals and trainings for internal use within the enterprise  It is very important to have an accurate view on user expectations

 Make the assessment of the current state and the process selection a tightly time-boxed operation to ensure timely completion of this phase

 Perform a timely evaluation of the IT assets available to the project, as it might impose limits and constraints on the process analysis.

 Retool your processes for a balance between operational efficiency and organizational effectiveness. A heavy concentration on lowering operational costs can hamper creativity and innovation. Alternatively, constant innovation can create instability and adversely affect business operations.

A good way of starting a BPM initiative is Nathanial Palmer’s 90 day plan to getting started with BPM in an organization. The first 30 days will be needed to define a starting point by defining the core goals, deliverables, and assets in collaboration with the stakeholders to determine the scope and boundaries of the plan. This will also give an indication of whether you will “go live” after 90 days, or will simply deliver some proofs of concept. The next 30 days will be spent devising the narrative of the processes, their look and feel, through a series of workshops. The final 30 days will come with the task of defining the measuring points of the newly formulated processes in order to secure buy in from senior management to extend the exercise to more processes.

3.3 Pitfalls

Sandy Kemsley4_{has defined four myths of BPM projects, which are true in most organizations:}

1. Business users WILL create executable process models

2. Business users/analysts CAN create executable process models 3. Business users/analysts WANT to create executable process models 4. IT WANTS business analysts to create executable process models

There will always be business guys and IT guys, and they have a different understanding of things. Business guys will never be able to model complex business processes. Therefore, Business-IT-Alignment is very important, and tooling cannot solve this problem. Business and IT have to work together to do BPM successfully.

The first statement we will call the Volition Myth. Vendors will try to create the “Field of Dreams” mentality of “If you build it, they will come.” Meaning that if you provide your business users with the capability of creating and maintaining their business processes, they will do so. The reality is that these people have more than enough work without having to worry about this as well. They simply lack the time to put in the effort.

The second statement (called the Capability Myth) is what is generally presented by BPM solution vendors as the “zero-coding” advantage, this is that business people will be able to change their applications without intervention of the IT team, therefore cutting expenses and reducing the time-to-market. While this might theoretically be possible if business processes are relatively simple and consist of only user tasks, the reality is that most BPM implementations are still complex, and thus development projects, with all the requirements and best practices a full-blown software development project entails. Not only do your business users need the analytical skills to determine pain points in the process model, they need the modeling skills to properly translate their solution into the model as well. Even in the case that this were true, they still don’t have an overview of the end-to-end process. Consider for example that a web service is called in the process. Even if the tool easily allows the wiring of this web service into the model, a business user still has no idea of the intricacies of the underlying infrastructure. They might not realize the cost of calling such a service (towards performance of the system or even actual monetary cost in the case of a subscription-based web service).

The third statement is known as the Desire Myth. In most companies, there is a long standing tradition of systems functioning correctly being the sole responsibility of the IT department. As we have mentioned earlier in this document, one of the goals of BPM architectures is that a joint accountability is created for the workings of such a system between business users and IT. Most business users are not that keen on taking on this increased level of responsibility.

The last statement is the Desire Redux Myth. The previous 3 myths address the qualms of the business users, but there are also qualms in the IT department camp. As mentioned in previous myths, business users need a lot of

(15)

knowledge to be able to work well with process modeling, and most IT departments regard business users as being unable to model even the logical view of a process. And in most cases, they are right. Mostly, process modelers are business users that have been promoted into the job without any formal training. Process modeling isn’t something you can grow into. You need the necessary knowledge. However, once you have mastered the modeling and analytical skills, there is no reason why business users cannot become valued members of the process modeling team.

The four myths are pitfalls that occur when trying to introduce BPM into an organization. However, once this decision has been made, several pitfalls will crystalize during the rollout of the new architecture:

 Calculated ROI is usually incorrect for the first implementation...

 The additional effort required to refine a defined process is typically underestimated.

 The fixed-scope project management model (as defined by the Project Management Institute), has repeatedly been shown to be too rigid to provide the flexibility demanded by a BPM project.

 Analysis Paralysis can occur when given too much time.

Where Sandy Kemsley focused on the misconceptions during the Business Process Modeling, Gartner on the other hand lists their five pitfalls, based on the reasons why one should roll out a Business Process Modeling effort throughout his enterprise.

Pitfall No. 1: Being Caught Unprepared to Demonstrate Value Delivered

With this pitfall, the BPM team may well have delivered some value to the organization, but if it did, it failed to keep a record of these achievements, or to routinely communicate them to those that matter. All BPM projects should start with an understanding of how success (outcomes) will be measured. It is vital to understand what the team is trying to improve (with a baseline measurement) and the corresponding improvement (metric). This metric must be communicated to the business, to clearly articulate the benefits delivered. The key is to learn the language of the organization and to use that language to communicate success.

Pitfall No. 2: Deploying a BPMS without Understanding BPM as a Discipline

Deploying a cutting-edge business process management suite (BPMS) will solve nothing unless the organization also applies BPM as a discipline. BPM is not about technology. Because it fundamentally changes how people work, BPM is about change. The problem with relying solely on input from one subject matter expert, or group of managers, is that the process documented will reflect only what the expert or managers "think it should be." This "offline" analysis misses one of the greatest opportunities for improvement: mapping the real process. Also, very few enterprises seem to build a business case around measurements before an implementation. The discipline of BPM is heavily based on the idea that you can’t improve what you can’t measure.

Pitfall No. 3: Launching a BPM Effort Based on Perceived Problems, Without Validating the Facts

BPM activities must be based on facts and data, rather than reactions to those who shout the loudest. When starting a BPM initiative, it is good practice to allot a period of time to set up and gather metrics before process improvement work occurs. This period should be agreed to upfront, with the BPM steering committee or project sponsors, to properly set expectations.

Pitfall No. 4: Developing BPM Capabilities without Delivering Business Value

A BPM team must build its capabilities, but this effort needs to be balanced with a degree of realism: the organization wants to see some return on its investment, often relatively quickly. Effort must be made to deliver benefits — even if they are relatively small at first — and to communicate them to the business so it can see some return on investment and feel positive about maintaining funding.

Pitfall No. 5: Focusing on Mapping Processes Instead of Improving Processes

BPM teams can get lost in mapping processes, acting under the assumption that this mapping activity amounts to "doing BPM." However, if these process maps are not used as a tool for bringing about real business improvements — or if such productive use cannot be demonstrated — they have no inherent value. BPM teams need to track and communicate the business value delivered.

Peter Schoof of BPM.com fame reiterates some of these pitfalls in his analysis of the main reasons why BPM initiatives fail, but adds a significant one: “Don’t treat BPM as a project”. In which he means that a BPM initiative should not be finite, as a project approach would suggest. For this, we should always envision continuity of the BPM effort after the project introducing or elaborating on the discipline has ended.

(16)

4 Tools and Techniques

4.1 Analysis Techniques

BPM approaches play on three spheres of influence within an organization: the enterprise scope, the program scope and the project scope. Each of these scopes requires different actions to be undertaken to make them successful.

Illustration 4.1.1 – BPM Adoption Scopes

4.1.1 Enterprise Scope

The main idea of a BPM effort is to make an organization self-sufficient in their process efforts, reducing reliance on outside consultants, and have a continuous improvement, as well as an operational organization in place to watch of the day to day happenings. At this scope, we have the three major flows: governance, project portfolio management and operational management. These flows will mainly make up the workings of the Centre of Excellence (CoE), an organization playing at all three scopes in different capacities. Change needs to be managed, so these workings are focused on guarding and guiding the transformations of the organization.

The necessity of feedback loops with relevant information for the involved parties introduced several of such flows: 1. The operational loop: Providing status information of a product and/or service and capacity information of the

resources handling the products or services (giving information like “is a certain resource overflowing or standing still”, “how is the flow of production of the product/service going as we speak”).

2. The tactical loop: Using the accumulated data of how your process is performing. This gives you information about how the process of a product or service is performing over time based on data provided by the product itself and/or the resources handling the product in various stages.

3. Strategic loop: In this loop the accumulated data is not so much used for process improvement purposes, but is used to analyze the product and services that are offered. Is there any demand, does the client want an alteration of the product or a no product at all.

Corporate Governance is about creating and maintaining an environment for success (effectiveness), ensuring consistency and establishing accountability. An extension of this is Process Governance, which at its core defines the mandates (or decision-making rights) associated with the selection and execution of enterprise process improvement initiatives.

(17)

Governance and Change Management in a BPM context are driven and monitored by a Centre of Excellence. This is a centralized group with executive mandate, which has to accomplish a wide variety of governance practices. The Oracle BPM approach divides these into categories, each with their own activities:

 BPM Vitality Governance: Strategies, standards, practices, infrastructure,… must be kept current with

business motivation and strategy, legal and corporate mandates ,and industry and technology progress  Portfolio Governance: The management of BPM projects, assets, and associated metadata across the

enterprise. It establishes a common language through categorization, supports process identification and selection, and ensures business alignment.

 Design-time Governance: Focus on business process change, spanning analysis ,definition and

management of the business processes

 Operational Governance: Day-to-day monitoring and correcting of process instances

 BPM Organization Governance: Management of organizational changes as a result of redesign and

improvement of business processes, as well as the cultural change

Illustration 4.4.2 – Process Governance (Oracle)

The first step in establishing a Centre of Excellence is determining what its mission statement will be. Trying to cover all fields of governance at once will be a herculean endeavor, at least initially. Identify the needs of your clients and focus on those first. Later, the other relevant fields can be annexed into a smooth running operation. This also comes with determining how the success of the Centre of Excellence will be measured. For a Centre of Excellence to work, it also needs a mandate stipulating its strategic focus and a funding model. It is imperative that it has upper management backing for it to succeed with any measure of success.

As with every initiative of this scale, there is a certain amount of resistance to change. It is critical that the Centre deals with changing the playing field, so that it has every chance to succeed. The following questions need to be addressed at its inception:

1. Who will oppose this and who must be won over? 2. What will keep you from succeeding?

3. What must you change to set the stage for success?

4. Propose a remediation plan to change what must be changed.

5. Offer a realistic roadmap to the foundation – but deliver benefit along the way.

Since business processes drive business operations, the day-to-day work of employees included, the adoption of this type of architecture necessitates a certain amount of change management to assist people to adapt to new or changed processes, and get them excited over the improvements (cultural awareness). In order to avoid the usual amount of resistance to change, the communication surrounding the benefits of this change and employee retraining become a major player in the success story of any BPM adoption.

(18)

For the communication to run smoothly, there are a few steps5_{worth following:}

1. Plan: Before you do anything, draft a communications plan. This should include the messages you want to communicate, the mediums you will use to communicate and the timeframes for the communications. But who are you communicating with…?

2. Identify your audience: Who will be the process owners? Who is involved? You need to ensure that these people feel loved from day 1. More communication is better than less. Explain to them what you are trying to do, what help you need from them and how you are going to perform the work.

3. Start off big: You may think that by identifying your key audience that you have covered all your bases, but be sure to expand your communications to as many people as you can (within reason). There are always people who are left out of the loop who feel that they should be involved. It’s important to make these people feel that their opinions are being heard or they can inflict negative PR on your process change. Remember, however, that the bigger the audience for communication the more general your communication should be. Think of this as part of a marketing campaign within the organization that you need to launch in order to sell the Centre of Excellence to its recipients.

4. Build Rapport: By this I mean that you should get to know your audience personally. The more you can break down barriers and understand personality types the more likely they will be to co-operate with you. Don’t be afraid to ask them about their lives outside of work. They may even start to think of you as a human being!

5. Make it regular, consistent: Whatever communications you are performing you need to make sure that it is regular. This is because it often takes time for a message to sink in. The world is so filled with communication “noise” that it may take a number of communications before people start to “get it”. This is why the communication needs to be consistent, in order to hammer home the message. It’s like beating a drum over and over – eventually people will hear it and start to walk in step.

Ideally, change management already starts in the process design/redesign phase where we actively involve the stakeholders. One should never dictate a customer what the process should be. Even if the process design is obvious to the BPM consultant, it is vital that the customer comes to this conclusion on his own with the help of the consultant. We need to guide him in the right direction, not push him.

This is likened by James Adonis to the hard power/soft power approach. When trying to get your employees to adhere to policies and procedures, you have hard power and soft power at your disposal. Hard power is negative motivation. This is when you intimidate employees into compliance. You issue warnings, reprimand them, and offer greater (or fewer) tangible rewards. Soft power is when you get them to follow a new process via the art of influence. He states seven ways of utilizing soft power:

1. Involve people: Get your employees’ buy-in before a new process is set up. 2. Explain yourself: Don’t just issue instructions. Explain the rationale behind them. 3. Verify understanding: Check that you and your team are on the same page. 4. Communicate openly: Once the new procedure is in place, ask staff for feedback. 5. Be credible: Display the desired behaviors you most want to see.

6. Be friendly: Employees are more prone to accept ideas from personable managers. 7. Repeat the process: Most of us need to hear stuff a few times before it sinks in.

Operational governance comes with its own set of best practices, but when regarding the change, one should not only take into account the versioning of the business processes, but also how a system should react in the case of a new version in relation to active instances of that process. Typically, two approaches can be determined. One is letting the instances continue in the previous version of the process, and only new instances would start with the new version. A second option is the migration (if possible) of all instances to the new version. Each of these options has consequences for the enterprise, which should be weighed, perhaps even on a per change basis.

Each of the governance categories described above follows their proper continuous improvement loop, which consists of the following phases:

 Assessment: The framework applies an incremental approach to defining and deploying a BPM

Governance model in which the assessment phase evaluates the BPM strategy to identify and prioritize the current BPM challenges and assembles them into an initial BPM Governance roadmap.

 Strategy and Planning: Existing governance practices are evaluated alongside the BPM Governance

Framework to determine immediate governance needs, size the effort to match the scale of the BPM program, and integrate with existing practices. The roadmap is further elaborated to expand the

(19)

governance capability in parallel with BPM rollout, while its effectiveness is evaluated with every subsequent cycle of the improvement loop.

 Execution: Existing governance practices are updated while new ones are implemented according to the

established roadmap. As governance practices are implemented they are carefully monitored to collect metrics concerned with the effectiveness of the BPM program and the impact of BPM governance.

Illustration 4.1.3 – Continuous Improvement Loop (Oracle)

For illustrating the management of individual processes, we have the Process Management Diagram, which was initially developed by Geary Rummler and Alan Brache in their book “Improving Performance”. The main idea of this diagram is to describe the tasks that a process manager should take to heart in order to ensure the proper workings of the business processes. The diagram helps in the initial analysis of process problems, as well as the operational follow-up of processes. In essence, it illustrates how a process manager will perform the change management of said process.

(20)

4.1.2 Program Scope

4.1.2.1 BPM Roadmap

The program scope effort starts with an extensive assessment and process selection activity leading to a roadmap planning. This is supported by numerous techniques and frameworks coming together as part of the working of the before mentioned Centre of Excellence. The project scope effort will be the all-important implementation of the business process automation, of which the most important techniques are highlighted in this chapter.

In order to draft up a roadmap, the architect has to establish what goals are valued, how they relate in a hierarchy (applying the MoSCoW rating) , and which level of adoption (enterprise, business unit, project, ..) is needed, before a gap analysis can be made between the current state and where this project needs to take the solution (future vision definition). As with every current state, we assess it by employing a Maturity Model (see appendix). This will in turn decide and hierarchically structure the capabilities needed, which is reflected in the Logical View of the architecture.

The goals have been listed in detail in the requirements chapter, but not all of these apply to every level of maturity of the BPM adoption. The goals to attain are sorted in the following hierarchy, with the score reflecting the different maturity levels (Ad hoc scoring 1 and Managed scoring 5).

Goal Statement Score

Enable rapid response to changing business conditions (e.g. competition, market forces, acquisition, etc.) 5

Develop a cycle of continuous improvement of business processes. 5

Monitor business process efficiency and effectiveness of change based on KPIs 4 Improve business process transparency and visibility for improved control and consistency 3

Enable knowledge management through documented processes. 2

Facilitate streamlining of human tasks through automation. 2

Apply BPM to a limited set of projects to demonstrate the benefits of BPM and build credibility with the business owners.

1 Improve business/IT alignment through common business process language and shared repositories 1 Once the capabilities are decided upon, and the proper business processes are selected (see chapter “Process Selection”), the project will stipulate a planning for the implementation of these capabilities, and form a schedule. Typically, the most effective horizon in terms of planning a BPM project is 2 to 3 years in throughput. It is of vital importance that during the scope definition of the roadmap, all involved parties agree upon the adoption level, ranging from enterprise adoption to project adoption.

(21)

4.1.2.2 Capability Development

Not all companies start with a full-blown BPM project. However, the sooner a company starts the process of migration towards a process-driven enterprise, the more benefits can be reaped. Craig Ryan (aka the Process Ninja) compares BPM to a garden, which demands a lot of attention and a significant cost to maintain. So he willfully ignores this until the weeds grow to such a proportion that it takes half a day to clear them all. Half a day that can be avoided by scheduling 10 minutes of work every two weeks. As with a BPM project, the time (and budget) must be spent to put in place so that the process changes are never big enough to warrant a project of themselves.

Illustration 4.1.6 – CMMI Levels applied to BPM Maturity

Paul Harmon of BPTrends divides company maturity using CMMI (see illustration), a simile also detailed in the Business Process Maturity Model of OMG. He stipulates that most companies are in the level 1 to 2 bracket and are just not quite ready for automation and optimization. The processes are ad hoc or just monitored for cost, schedule and functionality, where success either depends on individual effort or an attempt to repeat earlier victories. When companies reach maturity level 3, most processes have been documented and standardized, but the goals these processes aspire to, have not yet been crystalized. Companies at level 4 are exceedingly rare, and have managed to link their processes back to the company strategy and goals, where level 5 companies have a companywide effort to continuously improve upon said processes and goals. This is a view very similar to BPM Maturity as defined by the Object Management Group.

Transitioning a culture of heroes into an organization with the capacity for of repeatable success, requires it to chart the majority of its processes and classify them into process maps. This will ensure visibility of the business processes as well as reduce the effort needed for an ISO 9001:2008 certification. This certification is based on three principals, which can all be supported by a proper BPM architecture:

 Tell me what you do (describe the business process)

 Show me where it says that (reference the procedure manuals)

 Prove that this is what happened (exhibit evidence in documented records)

A secondary benefit is the support in knowledge management this visibility achieves. In an economic climate ruled by relatively high employee turnover rate and an aging workforce, knowledge that is possessed by employees is constantly in danger of getting lost, and the effort to train new employees is higher than it needs to be. It also introduces realistic commitments for work, based on previous work efforts and work requirements.

Once the majority of the processes has been captured, the alignment with the business strategy and its goals needs to be made in order to determine the proper KPI’s to measure in the processes. This information will in turn feed the business analytics effort with relevant data. As a result of this exercise, the processes can also be automated, reducing defects and achieving process flexibility. Once automated, the KPI’s can be monitored by the IT systems. Once we has a near complete picture of the process landscape within the organization, individual processes can

(22)

also be redesigned more easily on an enterprise scope. The organization has reached a maturity level of Standardized Processes.

After the business strategy alignment, we need to consider how to approach the question of process change. The processes are evolving to a Predictable Level. There is a need to quantitatively understand, reduce, and control variation in how work is performed. Process change ranges from analyzing and redesigning very specific business processes to projects that seek to completely reconceptualize a major line of business. This step of process refinement is elaborated in its proper chapter. With the capability to handle change, the possibility for it becoming an innovation driver materializes. New ideas (such as for example Social BPM, or initiates derived from the business analytics effort) can be rapidly expanded upon, and as a result be capitalized on. Processes can even undergo corrective actions towards performance and quality goals while being executed.

To achieve a level where the organization has a system in place for continuously improving its processes, we need to expand the mission of the Centre of Excellence to encompass all levels of governance surrounding the BPM effort, as well as determine an approach for the business process reengineering. Not all methods (such as Lean or Six Sigma) are beneficial to all organizations, and choices must be weighed and made to adopt the proper way forward. Only this way does the organization strive for a continuous competitive advantage. The main categories for improvement at this level of maturity are:

 Defect and problem prevention improvements  Planned innovative improvements

 Continuous capability improvements

4.1.2.3 Process Refinement Strategies

Michael Hammer identifies three types of business that benefit from business process re-engineering (BPR). The first is companies that are in big trouble, that are being beaten by competitors, that are losing money, that are just in terrible shape. These companies turn to re-engineering as a last resort. The second group is composed of companies facing major change. Everything is pretty good now, but they see on the horizon a very different set of circumstances. An example of this is a business that is subject to changing regulations. This is the largest group of companies that are re-engineering because almost every industry is in the throes of unbelievable change. And the third group is filled with companies that are doing just fine, that don't see major change on the horizon, but they re-engineer in order to get so much better than the competition that nobody will ever catch them. In short, his opinion was that all businesses need BPR in one form or another to keep their competitive advantage.

Depending on the market situation, which is considered either a red ocean or blue ocean6_{market, we employ}

different approaches to improve processes. We either apply innovation principles such as business value management and business value engineering, or we apply optimization principles such as Six Sigma or Lean. Adding business value to a process can be done through different approaches, but it boils down to addressing the following five avenues, as defined by Gartner:

 Automating business processes: This approach has the goal of reducing the cost of doing business by

replacing human assets with computer assets, improving the overall quality of the process.

 Augmenting business processes: Not all processes (or partial processes) can be automated. This is mostly

the case for routine work. However, the non-routine work of human assets can still be augmented by handing them the tools to efficiently do their work (such as for example search engines or knowledge repositories)

 E-commerce execution: This approach exploits the Internet in order to make the different services and

products of an organization available to a larger audience.

 Externalizing the organization: This approach leverages the social media to gather information on the

needs of the customer in order to tune the value streams towards this insight. This is also call Social BPM and is elaborated in a later chapter.

 Acting on novel signal patterns: This approach scans the ecosystem of the organization for subtle signs of

change in order to proactively play in to these changes. We employ Business Analytics to analyze and comprehend this vast behemoth of information.

A comprehensive overview of process refinement and its applicable methodologies can be seen in the illustration below. As stated, these techniques range from addressing optimization principles like performance improvement and quality management to innovation principles such as customer bonding. We delve into these methodologies in more detail with the appendix surrounding Business Process Refinement Techniques.

(23)

Illustration 4.1.7 – Process Refinement Techniques

4.1.3 Project Scope

4.1.3.1 Process Discovery

Process discovery (or identification) is not a trifle matter. Industry research has indicated that this step consumes around 40% of the time and effort to roll out a BPM approach. This because discovery of existing processes is largely a manual, time-intensive exercise conducted through meetings and human interactions. The information to extract can be seen on the illustration below. One effective way for process discovery is however “walking the process”. Instead of doing the workshops and interviews and documentation reviews, one can simply go to the workflow and follow a process by literally walking along the different workers performing it. It allows for a visual picture to form in the head of the consultant. This will not grant an exhaustive knowledge of the process, but it’s an ideal first step.

(24)

Another way to discover the processes, is by analyzing the data that is available in an organization and attempting to structure this in processes through the use of different algorithms (such as conformance checking, predictive analytics, data analysis,…). This practice is called ‘Process Mining’. There are tools that facilitate this, but they usually dictate stringent requirements for this discovery. For these tools to work, we need data in transactional activity logs, which can be correlated. This information should be structured according to the eXtensible Event Stream standard (XES). In short, we need to make sure that an activity log will always contain the following information for each activity:

 The Business Process Context: A unique identifier with which we can correlate all activities part of the

same process instance

 The Process Step: A unique identifier for indicating which activity in the process has been logged.

 The Activity Timestamp: A time indication of when (and preferably how long) this activity took place.

A host of additional information, such as the performer identification and/or role, adds to the options we have for analyzing the efficacy of the process. This information can also be used to run analytics on the process in order to determine bottlenecks and other points of refinement.

However, unless the as-is state of a process is felt to be for the large part close to being optimized, spending time documenting it in detail is a bit excessive. A simple workshop with the stakeholders to define and agree upon the process is sufficient before reworking it completely. A simple drawing or photo beats the pages of detail we normally produce for a process.

4.1.3.2 Process Selection

BPM projects are instantiated by the need to automate a business process. Typically, the processes in such a project already exist (creation of an entirely new process is an unusual occurrence), so the activities (both human and system) in such a process already exist in some form. The challenge for a BPM project is how to integrate these activities. The secondary main goal is for continuous improvement. For this to be achievable we have a strong requirement for being able to measure the day-to-day operations of these automated business processes.

Selecting which processes are valid or preferred candidates for a BPM project, can be done in two different ways. The first way is the Strategic Approach, where we select the processes that are most in alignment with the business goals and objectives. We view these processes as assets with a direct link to business value.

The Strategic Approach leans heavily on OMG’s Business Motivation Model (which is described in the appendix), where we will match the processes against the business strategy and business values of the enterprise to determine which processes are to be implemented first.

When a Strategic Approach is not possible due to the absence of business inputs (top-level models and business motivation), we can still assess the processes win a second way, namely the Tactical Approach. Here we identify process candidates without the assessment of Value Alignment, but rather we attempt to raise visibility and try to gain senior management commitment for future BPM projects. If the scope of these processes is not yet clear (we map this using the Business Capability Model). In this approach, we will be looking at core processes, as well as “low-hanging fruit” for process improvement.

(25)

Both approaches let us draw up a priority, based on process certification ratings, as well as a justification for the selection, which we both record into the process selection list. These two approaches are visualized in the illustration below.

Illustration 4.1.10 – Process Selection Method

Typically we gather the necessary information about the enterprise’s policies and procedures in six areas:  Policy & Procedure Manuals

 People  Legacy Code

 Enterprise Architecture Modeling Artifacts  Databases (Operational & Data Warehouses)  Automation

The process is added to the enterprise process collection, which is preferably divided into logical categories to improve the retrieval ease of a relevant process. Several classifications exist, from the more generic ones like the Supply Chain Operations Reference (SCOR) model or the Value Reference Model (VRM) to more industry-specific models like the Medicaid Information Technology Architecture (MITA), which is focused on the healthcare reimbursement industry.

The standard classification we use will be the Process Classification Framework (PCF) of APQC, which is an expansion upon the Porter Value Chain, and divides all business processes within an enterprise into 11 classifications, as shown in the illustration. For each of these classifications, the APQC also has an elaboration per industry.

In these industry-specific elaborations, we expand the classifications with process groups relevant to that industry, and fill those groups up with processes, made up of activities taking place in those processes. For

example, if we take their PCF for the Education industry, we notice that classification 2.0 is renamed “Develop, Deliver and Assess Curriculum, Assessment and Instruction”. One of the process group under this classification would be “Develop Curriculum”, which contains the process “Align with Federal/State/Local Governments” with a possible activity of “Align with Content Standards”.

Should a proper enterprise collection not exist (or not yet exist), we employ a BPM Tracker checklist to ensure no process gets left behind. This is a basic Excel template that can be utilized much to the same effect an enterprise

Alignment Architecture Business Process Management