Process Management

Introduction

Business Process Management (BPM) through Process Mapping is a management technique which looks at business activities as a series of processes handling items of work. In understanding business activities as a series of processes it becomes possible to start to understand which activities have the most business impact and which are using the most resources and to effectively allocate resources to the most productive activities and importantly to make process optimizations where they will bring the greatest business improvement.

Business Process Management can be used to improve operational efficiency (Operational Excellence), to improve agility, to increase capacity, to reduce costs and to calculate the Return on Investment (ROI) of a proposed change such as outsourcing a function or investment in a new system introduction.

Process Management techniques are used extensively within service businesses as well as manufacturing and in activities as varied as hospital treatment and the operation of air craft carriers. As a tool the techniques give the manager alternative perspectives of their business which allow fresh insights and significantly improved management focus.

Goals

BPM starts with defining the goals of the business in order to bring understanding to which activities within the business are important and what about them is likely to be important. Any business contains a large number of processes but only a proportion of processes are critical to the effectiveness of the organization.

In any business activity problems arise and after time the problems can become the unavoidable pre-occupation of management to the extent that it becomes difficult to have an objective assessment of how well a group of people or business function is performing and it becomes difficult to illustrate the role and overall success of the business function. This becomes a greater problem as a business grows and for executives within the organization it becomes difficult to visualize the relative importance of the needs of different functions or to assess the impact of potential changes within the overall organization.

An important step in defining processes, and understanding what metrics are appropriate to measure them, is to understand the business function in question. The needs of the stakeholders who use the services or product of the business function ultimately provide the purpose for which the function exists. The management of the business function will generally have a strong historical perspective on this, a view of potential strategies, and an understanding of the reactions of key stakeholders to prior strategy proposals.

The goals and objectives of the business function can be discussed in parallel, but preferably prior to, the definition of the processes begins. The goals and objectives provide a single summarized view of the purpose of the business function.

Understanding the needs of the management and stakeholders allows a prioritisation of goals to be proposed and for a productive debate to occur with stakeholders while reviewing and agreeing priorities. As much as possible this should result in a consistent understanding amongst the stakeholders of a working set of goals and objectives of the business function. This in itself can have significant benefit in clearing blocked communication between the stakeholders by resolving misconceptions and in triggering reflection upon the business goals.

Sources of goals:

• Customer Requirements
• Enterprise Goals
• Industry Benchmarks
• Regulatory Requirements

Once goals have been identified the process of prioritising them in conjunction with stakeholder interviews is key to involving stakeholders and in getting guidance as to which processes are important and how their metrics should be constructed.

Process

A process is an activity with multiple steps. They are not a creation of the manager but a sequence of activities that would happen in some form if they were managed or not because they are necessary in order to get the needs of the organization met. For example to purchase equipment somebody may request it from a manager, a manger may seek further approval from a budget owner, a technologist may need then to specify the exact bill of materials (The details of the component items), the purchasing department then issue a purchase order, the supplier is contacted, the supplier contacts somebody at the facility to arrange installation, the systems is commissioned, the acceptance of the received goods is communicated to purchasing, the vendor sends an invoice, accounts payable release the payment, controllers adjust budgets. If the steps of this process are managed or not many of the steps are likely to be required and the needs to track the status of the order, available budget and payment disbursement may be difficult to support. At the level of an organization, the marketing and sales process exists if we describe it as such or not but through describing it we can discuss the weaknesses of different steps and the overall rate and reliability of the process.

Until the major processes are identified it isn't practical to identify the processes which are critical to customers and what aspects of the process are within acceptable limits or causing tension or costs for customers.

Definition

At any level of assessment discussion of the existing allocation of human resources can reveal both current deployment choices and the groupings being described will reveal much about how management are thinking of the functions. In general management will be thinking of functions and head counts within functions and not of processes so the discussion should initially be at the level of functions. This is partly a result of established financial and head count budgets which are allocated by function to allow more tangable control. After major functions have been identified the next questions both to senior management regarding the breakdown of work load within a function and with operational management should be about what time in heads or person days are spent with different tasks or processes. The differences in perspective between senior management and operational management should be noted as they can reveal disconnects.

A useful tool can be to map out the staff across a floor to understand which desks are described as performing what functions. This is useful in verifying the headcount information that management have provided and quite large disparities are often found with additional groups within the headcount being at other locations or performing related but different functions. The resulting basic map can also be used within the assessment team to coordinate more detailed interviews.

In order to identify significant business benefits processes must have significant resource allocations or have a high impact on the quality of the groups work product. As a result at each stage of the process of identifying functions, high level processes and sub processes it is necessary to focus efforts on the processes which are most significant in business terms. The effort required to assess every process is prohibitive in any real world environment.

At the most detailed level sitting with operational staff and observing the process occur in real time can provide confirmation or reveal gaps between actuality and the descriptions of the activities obtained through standard interviews.

The identification of significant processes allows management to present a description of the related business functions and as a result be in a better position to obtain and allocate resources and provide appropriate support to the processes in a way which maximizes business impact.

Visualization

Top Level Process Graphics

As part of the process of gradually revealing detail in a controlled way it is important to review the high level processes with stakeholders. There are really many levels of process with graduated scales that can be employed and different diagram styles used but in general the top level can be considered the highest level of process that falls within the domain of your set of stakeholders and a similar diagram used regardless of the scale of the process (Enterprise, department, function etc.) In order to do this each high level process can be visualized, normally as a single presentation slide per process, using a symbol for the process surrounded by different aspects of the process.

The aspects of the process described normally include:

• The description of the process itself (One or two sentences)
• A number or tag to identify the process
• The input to the process
• Initiating events
• The output of the process
• The resources used by the process
• Integration points
• The benchmarks or SLAs currently defined for the process
• The tools or systems employed by the process
• The current flow rate of the process
• The capacity constraints of the process

Senior stakeholders will normally not want to review below the level of a single box for a process and will be averse to the time required to review networks of processes. This is appropriate and it should be assumed that the networks of process will be discussed primarily with operational managers.

Sub-Processes

The important top level processes can be further illustrated to show a number of sub-processes and how they interact. This may be by breaking them down into the sub-processes occurring within different functions or stages within the major processes. It can also be important to illustrate where numbers of resources are engaged in independent processes so that the resource usage can be better understood.

This style of diagram is vital to give context when interviewing operational managers and as a way of responding to questions from stakeholders. Within the assessment team the diagrams are necessary in order to understand the interactions of the individual process maps.

Process Maps

The stanrdized visual notation as BPMN (Business Process Modelling Notation). A BPMN detailed process map is very similar in appearance to a UML swim lane diagram. As a result the more widely understood (By analysts but not business managers) format of the UML diagram is an alternative layout to adopt. The diagrams are best presented vertically as the wording can be better laid out within components while wasting less space with arrows taking the flow from component to component. As a result the diagram looks similar to the lanes of a swimming pool with the lanes representing the groups or systems performing the functions and a flow chart like sequence of components flowing the events within the process from the top of the page to the bottom. Only one process should be illustrated per page in order to ease change management.

BPMN is an industry standardized methodology. BPMN provides standard visual components for representing the process:

• Events - A small circle representing an initiator or an end point of a process. A trigger for the sequence of steps.
• Activities - A step within the process. A task
• Gateways - A diamond similar to that seen in flowcharts

Solid headed arrows are used for the sequence flows in the same way as they are in a flow chart.

Sub-Goals

In order to understand the importance of different processes and to understand how metrics should be constructed around them it is necessary to break down the business goals into sub-goals and potentially to also add some more minor goals. Omitting this step is a key problem in many process management assessments and in an organizations SLAs as it results in confusion about their importance or lack of it. If the process being discussed is the successful on boarding of a client there are many sub-goals in that process which are part of judging the success of the on-boarding process. For example there may be wish to minimize the level of customization, there may be an attempt to create cross selling relationships. These sub-goals need to be called out and prioritized with appropriate managers in order to understand the true significance or not and the importance for related sub processes.

Metrics

For processes whose goals have business significance, or which currently absorb significant resources, metrics can be defined to allow the effectiveness to me measured and managed. It is important to define metrics for the most business critical processes not just because the assessment needs to be scoped but also because if important processes are omitted then management by the metrics could result in an important function being neglected. The successful grading of the importance of the sub-processes and building of metrics is central to the benefit of process mapping as the metrics will drive the views of executive management and as a result motivate operational management. The aim of the metrics is to drive management actions.

The definition of metrics should begin with the most significant processes and work down to the less significant processes. Initially only one to three metrics should be identified with further details being added as necessary depending on the balance of the different processes. The metrics need to be measurable and will need to be reviewed between different groups of business operations, service providers or IT analysts. As a result they should not be superfluous. They must be genuinely important to the business, quantifiable and calculable.

The metrics can also be prioritized and presented as key performance indicators using the process names as headings in communication with executive managers and line staff as this allows them to be presented with a focus on explaining processes. The operational managers need to understand both process and metrics in greater detail and will need to be familiar with the factors exposed in the process maps for the full benefit to be obtained.

The metrics can also be used in the creation of scorecards which generally exist informally even if they do not exist formally.

Reporting

Once metrics have been defined the next step is to introduce reporting on the metrics. Typically not all metrics are freely available in any one system or possibly can be ascertained but are not in any system. Processes often flow across different organizations or at least different divisions of an organization and it is unrealistic to expect instant integration of the data flows to a reporting system. A common solution to this is to introduce a data store in which the data is collated, initially manually but where possible without human intervention. This can be in many different forms:

• A slide presentation
• An Excel sheet
• A BPM tool
• An MIS database
• A data warehouse
• A dashboard application

There are significant advantages to operational managers being able to take ownership of the quality and of the mining of the data though as much as possible the collation should be delegated and where possible pushed to the IT department. For this reason simple approaches in Excel or with slide presentations may be preferable. An existing or an additional BPM system or MIS database offer a better medium and long term solution as they allow a method of automating the collation and separate the collation of the data from the creation of the reports. Where the collation effort is considerable it may be appropriate to make use of data warehouse Extraction, Transformation, Loading (ETL) tools. Dashboard and governance applications are marketed but some experience should exist within the organization before the sophistication of these tools will reap sufficient benefits. Out of the box the dashboard applications can only provide higher quality presentation tools and initially it is the capturing and understanding and use of the data which needs to the focus more than learning about more complex presentation tools.

Where the relationship is contractual there will be pressure to limit the number of metrics monitored and to define a simpler report but it is necessary to retain visibility of sufficient metrics to get a realistic representation of the service or product provided. This often involves a distinction in the reporting between contractual SLA metrics and informational metrics. It is important to retain the informational metrics in the reporting to senior management if they are, as they should be, significant business value drivers.

Techniques

An assessment most commonly involves recommending process improvements, but may simply be driven by the need for metrics to allow the organization to organically change, or may involve the full modelling of a transition with mapping of the current (As-Is) state of processes and their future (To-Be) state. In general when metrics are introduced it is inevitable that obvious conclusions will be drawn so some recommendations should be made to the extent that the stakeholders will accept this. Mapping significant proportions of both the As-Is and To-Be future state can however be repetitive and should only occur where it is not redundant effort. Depending on the project objectives it is better to more fully map either the As-Is or To-Be state and reduce the level of detail presented where there is not a business reason to illustrate the detail.

Interviewing stakeholders and manager is a skill built on experience. There are types of questions which will work, and others which will not, which can be taught but interviewing staff whose time is valuable needs to be handled in an understanding and time effective manner which requires experienced interview staff. In general questions should be open and allow the stakeholder to express their views concisely. Listening to the views and the emphasis provided allows an understanding of management focus which needs to be echoed back to the stakeholder and reviewed to remove accidental implications. In general the interview team should be two to three people and the interviewer should appoint one of the other team members to make summary minutes. The summary minutes are primarily to communicate to other team members but also as an aid memoir particularly on the names of groups, people, reporting lines and functions of systems. Formally circulating the minutes with stakeholders, particularly by e-mail, is not cost effective and can lead to the need to spend time managing anxious e-mail exchanges. It is important to ask stakeholders for knowledgeable subject matter experts so that effective choices of further interviews are selected. Having the stakeholder send an e-mail to potential interview candidates within their area as an important step in setting up the interviews. Using a senior stakeholders administative assisstant to schedule the appointments can also be important in some environments. There is no obligation to interview everybody mentioned, instead every interview should be for a defined real reason. The revealing of information as usual has to be done in a planned manner.

When talking with System Analysts it is important to understand that the terms Workflow may be understand as being manual processes across groups and the term Process may be thought of as a more detailed series of steps implementing the function within a system. Within Zachman based frameworks workflows are often described as telling you who, where as processes are described as telling you how. Despite this both workflows and processes contain both processes and implementations of functions but you need to be sensitive to different people's terminology. The important thing is not to cause duplicate effort by separately and potentially differently defining workflows and processes and to realise that they are different terms sometimes used for stages or by different people in the definition of detail of the same thing. Service Oriented Architectures (SOA) refers to the separate implementations of units of work and of processes. As such the steps of the process make use of generic or custom services in order to implement there function. This decoupling has obvious advantages, at least where they are generic, so where common elements of steps in a process can be called out it is worth doing so, but as a later stage when processes are mapped to future state systems. It is necessary to allow the system analysts to choose the method of implementation which is appropriate.

When interviewing you will encounter fear of job loss, fear of loss of control and scepticism about ROI of wider initiatives. The aim of process and analysis, as it relates to operational staff, is to diminish unproductive work and to focus on work which is useful for clients. It helps to be realistic but to communicate that the steps that tend to be eliminated are the repetitive or unskilled ones. For example if tracking the state of a work item requires logging into three systems and making two phone calls, this monitoring could, after the completion of system changes, be a significantly faster task allowing time for more productive work. Ownership and control of a process is a vital concern which can only be resolved by executive action to resolve any role assignments needed within the organization. Within the process operational managers may have justified fear of loss of control steps. Depending on the function of the control it may need to be captured as decision steps (Also known as gateways). They need to be understood so that the importance of them is communicated for the implementation. Control steps can be preventing a variety of undesirable situations and many controls also have a regulatory function. Scepticism about the overall initiative needs to be handled by making sure that all interviewers understand the purpose of the initiative and are able to articulate it. Within the assessment the key to the ROI of the assessment is controlling how much information is discussed and focussing on the areas which have significant impact on the business or on resource requirements.

Tools

There are several hundred BPM tools on the market with consolidation starting to become apparent. While the range of feature sets provided is still developing the tools, to one extent or another, allow:

• the visual manipulation of process steps as a map,
• data entry as a step in a process,
• the addition of business rules,
• the execution or simulation of the workflow,
• notification such as e-mail to an external party with support for a response,
• visual representation of work item status and
• the ability to invoke services within a step

Notable tools include:

• Appian Enterprise BPM
• ORACLE's BPEL support
• BEA AquaLogic BPM
• TIBCO's Business Studio
• PegaSystem's SmartBPM
• Wipro's Flow-brix
• ERP Systems such as SAP
• JBOSS jBPM and jBPM BPEL

Standardization of visual representation and interchange formats provides greater tool independence but there is still a heavy learning investment in the choice of format.

BPM tools provide the potential for the model to flow through the full lifecycle from design through to execution and for change control to be implemented as a circular process so that the model that the business managers and architects see is the one actually used for the execution.

In some cases the design environment is available without charge in the hope that after adopting their design tool you will move to adopting their execution environment. Where different design and execution tools are being used the level of support of the format standards is critical to successfully integrating.

Standards

Standards Bodies

The Organization for the Advancement of Structured Information Standards (OASIS is an organization which publishes and promotes a number of global data standards related to business communication. They provide a wide range of standards focussed on business integration such as UBL, ebXML and WC-BPEL.

The Object Management Group (OMG) is a non profit industry consortium which is responsible for a range of technical specifications many of which have focussed on analysis techniques and technology implementations. UML and CORBA are both OMG standards.

The Workflow Management Coalition (WfMC.org) is a three hundred member industry body focussed purely on process. It both publishes its own standard (Wf-XML and XPDL) and also contributes to the standards created by other bodies.

There is overlap and co-operation between OMG and WfMC and other organizations.

BPM Design Standards

BPM design standards cover business process definition. They are used to store or exchange process definitions between tools such as design tools, simulators or implementation tools.

Business Process Modelling Notation (BPMN) by the OMG is the standard symbology for the visual elements of the business process. In other words the look of the diagrams and their interpretation.

XML Process Definition Language (XPDL) by The Workflow Management Coalition allows the interchange of business process definitions. It holds the graphics and locations of steps within the process but not the details required to execute it. XPDL provides a way of defining a BPMN diagram.

BPDM (Business Process Definition Meta-model) is a proposed standard of the OMG for the definition of meta-data related to executable processes. It may at some point be integrated with BPMN or partly overlap with and replace to an extent XPDL.

Semantics of Business Vocabulary and Business Rules (SBVR) standardizes semantics and terminology for defining business logic and includes an XMI schema for exchanging business logic.

WPDL was the FfMC's first process modelling protocol. It is Pre-XML and is now obsolete.

BPM Implementation Standards

BPM Implementation Standards allow the execution of the process. They allow system components to interact in order to achieve the purpose of the business process steps. Standardization allows different tools potentially from different vendors to interact successfully. The standardization also provides opportunities to more easily integrating process flows at the system level both within different parts of an organization and between organizations.

BPEL (Business Process Execution Language) from OASIS is a language for describing the execution of the business process rather than the graphical representation of the process. Not all features of BPMN diagrams are supported in BPEL. While it is intended as an execution language most systems use it as a standard to import the executable design. BPEL has little support for user interaction in the process.

Asynchronous Service Access Protocol (ASAP) is a technical standard defining the method of starting, monitoring and closing a process or service. This allows process execution infrastructures to successfully operate the environment.

Wf-XML 2.0 from the Workflow Management Coalition is an extension of OASIS ASAP. It standardizes the methods of starting and monitoring a program.

ebXML from OASIS and the UN/CEFACT is a range of standards to support global electronic business integration. Some of the standards are also adopted by ISO and have ISO standard numbers. ebXML BP defines the Business Process Specification Schema (BPSS) with which business may configure systems to support business process execution.

Improvement

Business process improvement (Also referred to as re-engineering or operational excellence) involves assessing the goals of the organization and current state and projecting possible changes to the business processes and potentially assessing the Return on Investment (ROI) which is likely to result.

The following is a list of possible changes that can be made to a business process. After the current business process has been understand the list can be iterated over to collect plausible actions. Prioritizing the actions in excel using scores based the prioritized goals obtained in discussion with the stakeholders yields a first cut list of actions to evaluate. The actions then need to be refined and prioritized with stakeholders in order to result in actions which can ultimately be sized and roadmapped.

The list of changes that could be made to a business process includes the following actions:

• Automation of manual steps
• Integrate data between systems
• Removing or combining duplicated activities
• Combining related activities
• Assess process routing and triggers
• Eliminating inspection, review or approval steps
• Simplify processes
• Reduce or increasing batch sizes
• Provide process monitoring and control
• Performing processes in parallel to reduce latency
• Triggering events based on need (JIT of work items)
• Outsourcing inefficient activities
• Reducing transfer or movement of work items
• Organizing multifunctional or dedicated teams
• Design cellular workplaces / villages
• Automate process statistics gathering and analysis
• Disintermediation: Customer self-service in initiating the process
• Centralize / Decentralize process management
• Providing process visibility to the customer
• Design for location independence: Share processes between business units
• Design for location independence: Find steps that can be completed in isolation
• Design for location independence: Automate escalation and handoffs
• Separate heads-down from interactive and collaborative functions
• Separate interactive event or incident based tasks from collaborative functions
• Batch data upload / download
• Improve methods of rendezvous for asynchronous tasks Reviewing the current state processes against the list of possible changes will result in a set of options which need to evaluated within the assessment teams, quantified to the extent practical and socialized with stakeholders.

Evolution

It is not productive to make demands on manager's time for something with which they have not yet seen the benefits of. As a result adding any methodology to the organizations mindset takes time and occurs through a series of levels of familiarity, comfort and buy-in.

Phases of introduction of process management are likely to follow a pattern similar to:

Initial Introduction

Identification and awareness of processes

Manual collation of data on processes

Initial dashboard implementation in existing tools (Excel, PowerPoint)

Initial process and organizational change

Process Management

Use of initial metrics to assess the likely ROI of proposals and set appropriate budgets

Feedback on efficiency gains from initial changes

Use of process design tools

Automation of collation of available internal data

Focus on data quality

Prepare for disintermediation of some data input tasks

Improved metrics

Discussion of processes with other groups

Process Integration

Initial process and data integration with other groups

Disintermediation of some data input tasks to external groups

Organizational structure to accomodate clear process ownership 

Preparing for use of process execution tools

Some external client integration for major clients

Process governance

Full lifecycle integration of process design and execution tools

Integrated dashboard creation

Real time process metrics

Closing of system integration gaps

External visibility of process metrics

Close gaps on external client integration

It is necessary to be aware of the current state of the organizations understanding of process management when assessing which recommendations are currently going to be receptive and to act appropriately.

Conclusion

The benefits of process management are great because we identify the processes about which the end customer valued. As a result metrics around the process focus management decisions on what the customer cared about. The ability to spot early trends in the processes the customer values allows the organization to better manage itself in order to avoid becoming aware of factors after they have had impact to the cutomers of the process. This reduces the unproductive disconnects comon in any complex organization and increases organizational understanding of the client needs within the processes of the organization. The metrics put in place draw amangement focus out to the clients need for the process of for internal decisions to be more frequently be made in accordance with client needs.

Heavily resource constrained or turbulent organizations will not be able to invest the resources in proceeding far through the stages of process support maturity described above. They should not realistically expect to, however in almost all situations the introduction of process management will be a sufficient management priority to be successfully accomplished.

Whenever major transitions or system investments are planned it is worthwhile to invest in process management as part of the effort. This is often necessary in order to project the ROI and obtain budget approval for wider initiatives. In cases of transitions such as integration of acquisitions it will be a key component of supporting the business through the transitions of groups and systems as well as in obtaining the expect return from the acquisition.

See Also

References

Biography

Process Mapping - How to Reengineer Your Business Process - V. Daniel Hunt -John Wiley & Sons. Inc.

Process Innovation - Thomas H Davenport, Ernst & Young - Harvard Business School Press

External Links

Comments

OwenBrunette - 05 Mar 2008