Once the first Business Process Management (BPM) project is completed, opportunities begin to emerge from all corners of the organization. Executives and Line of Business (LOB) Managers soon appreciate the potential for BPM technology to help them radically improve business performance as they drive the organization to achieve its Key Business Objectives (KBOs). Moreover, the cost equation is attractive - development and maintenance of a typical BPM enabled application is between one and two thirds of a custom development.. With continuous process improvement (CPI) as the core discipline of BPM, the models that drive work through the firm evolve constantly. Indeed, recent studies suggest that firms fine-tune their BPM-based applications at least once a quarter (and sometimes as often as 8 times per year). The point is that there is no such thing as a "finished" process; it takes multiple iterations to produce highly effective solutions - even if business conditions do not change. Every working BPM-based process is just a starting point for the future..
This Document is based on a thematic extraction of the content of the source document. It is meant to be consumed by search engines … please go to http://www.bpmfocus.org/membership/document.aspx to download the source document
Entire document is © BPM Focus, 2007. All Rights Reserved.
Why is this important? CPI matters because it creates superior performance. But it also presents a scale problem for most organizations. Right now, most major firms are still experimenting with BPM by focusing on a few, tightly scoped process engagements The core BPM team,is growing its capabilities and confidence, in preparation for more demanding and complex business problems. But with multiple processes that could benefit from BPM-style automated support, the issue becomes how to support dozens or even hundreds of engagements per year. Current application development practices hit the wall under such circumstances - they simply cannot cope.. Without an efficient, iterative BPM delivery capability, firms will fail to achieve the performance enhancements they seek. With LOB Managers queuing up for the attention of key resources in the BPM team, the introduction of BPM into the wider business will falter as a result. While widespread adoption is still possible, it will happen more slowly than originally intended. Of course, many firms are currently in this situation! Instead of an application backlog, they are building up a BPM project backlog.. Furthermore, without comprehensive support for the process lifecycle, iterations will be slower; allowing more agile competitors to evolve their offerings more rapidly. In the end, maintaining competitive advantage relies on the ability to adapt more quickly than a challenger.. This paper focuses on how to create an effective methodology and organizational capability to meet this challenge. It presents a wide variety of best practice tips and pitfalls to avoid, highlighting the experiences of several major enterprises pursuing business transformation via BPM.. Business Drivers for BPM..

In a recent review of BPM case studies, we found that project objectives covered several of the headings show in Figure 1. Depending on the circumstances of the firm, some of these objectives were more important than others. Enhancing Business performance was the most common goal (lower cost and faster cycle time). Becoming "Easy To Do Business With" (ETDBW) and more responsive to customer demands was also seen as critical. When looking at the customer experience, firms also wanted to integrate their disparate customer channels....

Figure 1: Firms are looking for a wide range of benefits from BPM Others really wanted to focus on integrating their distinct systems and legacy applications, re-using their existing IT assets and the embedded fragments of process within them. Some wanted to outsource parts of the process or to choreograph the distribution of responsibilities amongst suppliers and partners (or even to the customer). Most were looking forward to the enhanced agility and lower operational risk. For some, better support for regulatory compliance was also critical.. Regardless of the firm's objectives, the BPM system had to work with existing systems and approaches. In the case of Hasbro, that meant interoperating with the firm's SAP system (see case study below). Like most others, Hasbro set out to support the wider business process that surrounded their transactional system.. Hasbro Case Study..

Hasbro is a $3 billion manufacturer of widely recognized brand name toys. The firm now outsources nearly all of its production to a growing list of third party manufacturers most of which are in the Far East. An SAP based ERP system captures orders and RFPs from customers in the US, many of which have conditions attached (deliver by dates, etc). In the past, orders were broken down and relayed to the appropriate suppliers for quotations and responses using faxes, e-mail and phone calls. Replies were chased, collected and collated before a response was provided to the customer. Managing this process was time-consuming, involving the manual coordination of a broad array of vendors, manufacturers and logistics firms. Around 200 people were involved in the Hong Kong office alone and the typical cycle time was in excess of 2 weeks to respond to a customer-driven RFP.. To alleviate this problem, Hasbro built a BPM enabled portal (branded e-Connect) to interact with its partners. SAP provided the transaction engine, but Hasbro needed BPM to manage the business process that surrounded the transaction.. Since the introduction of e-Connect, the productivity of those 200 people in Hong Kong has gone up by 3 times (it doubled in the first year). So has the business they are doing with Wal-Mart, a major customer (also up by 3 times). Just as importantly, e-Connect has given managers at Hasbro complete visibility and traceability on work in the system. Average cycle time is now down to less than 24 hours.. But the benefits did not stop there. With the introduction of the USA PATRIOT Act came changes to the level of reporting that was required on all shipments bound for the USA - imports had to be tracked and reported at the box level (rather than at the container level as it was previously). For a firm like Hasbro, that could have been a real problem. Driven by the regulatory change, Hasbro could quickly modify the BPM system to update the Purchase Order, Shipping and Logistics process models. They then focused on educating their third party suppliers to work with the new customs labeling.. For Hasbro, this unanticipated benefit gave them real competitive advantage. They were able to institute the new processes well before the regulatory change became mandatory. So while competitors had their goods tied up on the docks (because they had failed to meet the new standards imposed), Hasbro was able to clear customs quickly and efficiently, while meeting increased levels of customer demand. Along the way, Hasbro has been through five major releases of the e-Connect system in the first year of deployment. After four years, the application has been through many, many revisions.. The Fallacy of Requirements Definition..

While the business itself was firmly behind BPM at Hasbro, most organizations regard BPM programs as application development initiatives. And as such, they often suffer from a misunderstanding of how different BPM-based process development is from traditional IT projects.. A couple of underlying assumptions underpin the traditional application development lifecycle …that business people really do know what they want; and that their requirements will not change during development. On the other hand, most business people neither understand, nor care, about the technology itself. They are only interested in the capabilities it enables. Yet, in the traditional model, accurately defining the need for a business system requires users to have a deep appreciation for what is possible, and to articulate that vision in painstaking detail.. After an extensive set of interviews with business analysts, those in the business are supposed to sign-off on a document that specifies their precise requirements. The design of the overall application architecture happens (somehow). Systems analysts write detailed technical specifications for interpretation by programmers. Programmers write code that hopefully meets the needs of the user. Over time, the original set of user expectations morphs into a set of computer programs that, hopefully, still meet the current business need.. Of course, such application development projects can take a very long time. And because of the time, business people try to pack in all functionality and "nice to have" features into the first release. With traditional development approaches, they know that years could pass before they get a chance of an upgrade.. Inevitably, information leakage and miscommunication occurs at every step, leading to compromise. Indeed, by the time the development process completes, it is a miracle that developers ever deliver effective applications. The application rolled out to the business almost fits the originally defined need, but it is often full of workarounds and concessions.. From the perspective of the business users, they usually "see" little until very close to the delivery date (that is, apart from documents and specifications). But requirements that look good on paper seldom translate perfectly into a finished application. It is only during User Acceptance Testing that many "changes" to the, as yet un-deployed, application are identified.. Once the application has been in use for even a short period, the user expectation starts evolving. User requests for new features and enhancements start to appear, many of which have fundamental repercussions on the original design. The primary reason that technology people want a tightly specified requirements document is to discourage change as, from a systems perspective; it is difficult to hit a moving target.. The point is that business requirements always evolve continuously. Whether driven externally (by regulation or through competitive pressure), or through a better appreciation of what is possible, in the eyes of the business user the system is always out of date.. Over the years, technologists have developed a number of strategies and approaches to deal with these issues. Detailed specifications, prototyping, agile programming, extreme programming - the problem is that none of these approaches can handle the sort of scale problem described earlier. They take too long and rely on a waterfall style implementation (where everything arrives all at once at the end of a long incubation period). This approach to systems development never did work that well. It inevitably failed to deliver what the customer eventually wanted, and often led to a damaged user-developer relationship.. The New BPM Methodology..

Contrast the waterfall style implementation of traditional application development initiatives with the spiral methodology employed in BPM programs. Best practice BPM implementation methodologies do not assume that business people know exactly what they want at the outset (before they have seen anything that works). Instead, they initially focus on the 20-40% of functionality that delivers the bulk of the value. Thereafter, the models that drive the application are iteratively developed and embellished to deliver the fine detail of the needed functionality. BPM-based applications are "built to change. Based on experience of the working application, the business users themselves are in a much better position to identify this additional functionality.. Indeed, business users tend to identify functionality that is more appropriate to their real needs once they understand the context. This enhanced functionality does not stop with the process model. Give the users a way of automatically deriving performance metrics from their system and they immediately want improved, subtly different metrics. It is no longer good enough to know the average cycle time. They now need to know the cycle time of all shipments to important Customer X, or the performance of Team Y in influencing those orders.. Similarly, the user interface will probably need to evolve. Or, the work distribution mechanisms may need to change to reflect a new organizational structure or a change in regulation. Indeed, the whole scope of the desired application can change quite quickly to reflect an evolving business climate as the firm focuses on a core competency while outsourcing other aspects.. Each one of these different types of changes would normally have major implications on a traditional IT application development. On the other hand, a modern BPM Suite that provides effective support for the full development lifecycle enables the rapid resolution of each issue as it arises.. Some of those new requirements emerge from better understanding, while others derive from even more pressing competitive dynamics, or changes in regulation as in the Hasbro case. In some businesses, it is only with process automation that opportunities for further performance improvement emerge. For example, Dell Computer used BPM to coordinate their process more effectively with its third party shipping agents. But it was only after the initial deployment that the company gained sufficient insight into delivery problems to allow it to determine options for improvement....

At Pulte Mortgage, they already understood their process relatively well. They set out to change the model of customer service by becoming more proactive and concluding tasks well before customers would reasonably expect completion. But without visibility into the metrics of the process, it was difficult to spot opportunities for improvement. Through the implementation of an automated case tracking application, managers could identify areas where service improvements were possible. Indeed, it was only possible to identify requirements once process metrics were gathered.. For example, as a result of the better visibility into the process, managers could monitor the number of hours it took to push a case through to the point of offer. As the number of cases rose in the queue awaiting approval, managers realized they could influence overall performance of the process by lowering the credit-scoring threshold (where the system automatically accepts mortgage applications). But as they reduced cycle time, the financial risk would rise. This does not mean that managers were interested in re-configuring business rules in real time. Rather, as part of the manager's dashboard user interface, the system should now expose slider control.mechanisms that enable this sort of control.. But this is a business judgment, trading off higher risk against more rapid response to customers and hence, more business. As they come to understand the dynamics of these decisions, they could then start to embed that enhanced understanding into a more dynamic set of business rules that supported the decision (even down to suggesting the level of automatic credit scoring approval).. Vendor Support for Iterative BPM Development In regards to supporting that iterative development approach, most BPM vendors describe their support as "round-tripping. They are referring to the spiral implementation approach of BPM - from analysis, through development, into deployment and then monitoring and optimization. The idea is to engage in short cycles of iteration, improving the behavior of the application over time.. While telling the story of iterative development, the majority of vendors only pay lip service to supporting this important aspect of BPM development. Out-of-the-box support is usually rudimentary at best, leaving it to the team to develop and support a homegrown lifecycle management approach. System administrators and business analysts must ensure that the requested functionality is tracked and implemented later....

Figure 3: A simplistic view of the iterative BPM lifecycle Features offered are normally limited to support for "version control" of the currently running model (ensuring the audit link between process instance data and the relevant process model used to drive the work). Others point to their inclusion of a bundled simulation environment and robust set of analytics capabilities - as though the mere provision of these tools will directly support the lifecycle. Some products provide for the parallel running of different versions, allowing the business to pilot a new version in a specific area and then compare its performance against the current standard. Occasionally there is even support for the configuration management of deployed solutions.. Of course, the BPM lifecycle is itself a collaborative process, involving many participants. Best of breed vendors support the entire team as they interact with each other. The BPM project manager, the business analyst, process modelers, associated IT developers, the deployment team, business managers, subject matter experts, end users - all will usually require different tools, but to collaborate effectively, they should at least share the same set of underlying models stored in a shared repository. Mechanisms for capturing exceptions,and supporting their management are also important here. Moreover, with a few exceptions, products rarely provide direct support for the engagement of business users in a workshop situation.. Probably, the Lombardi Software product set provides the most effective support for this aspect of BPM projects. It explicitly focuses on enabling the effective communication between all participants in the BPM development project. It does this by ensuring that all parties share the same set of models even where different, role-specific user interfaces support the special needs of team members.. Best Practice BPM Development Methodology Just as BPM technology is markedly different from conventional approaches to application support, the methodology of BPM development is markedly different from traditional software implementation techniques. With the intervals of change getting shorter and shorter, firms need to develop an effective methodology to get around the business optimization cycle quickly enough....

Figure 4: The best practice of BPM involves a number of rapid iterations Figure 4 depicts a way of organizing activity and ensuring that the project stays on track. The methodology involves many smaller iterations focused on a particular topic; each with "playback" sessions where the BPM team, subject matter experts and business managers interactively validate newly developed functionality. This approach ensures that no surprises emerge along the way, while delivering the flexibility to change as needed. There are iterations in the requirements area (Discover and Understand), iterations during the Design phase, iteration at Build and Test, etc. Further, managers need to monitor the process and control the way in which it operates. Before repeating the cycle again, the Analysis and Optimization phase involves several additional iterations as business analysts and managers experiment with alternative scenarios.. Given four or five business optimization cycles per year for a business process, each overall cycle must complete within three months. To achieve this, it is necessary to time-box the different phases of activity. Otherwise, the temptation is always there to spend longer, which encourages scope creep and increases the risk of project failure.. Process Discovery and Understanding..

Every organization has a different start point and, as a result, different needs. Some already have a defined process, others are less well developed. Some want to emphasize automation of the process, while others need better tracking, visibility and performance measurement.. Either way, the first objective is to understand the process. Instead of developing a 400-page requirements document with every detail tightly specified, focus on tying down the core functionality that will deliver the large majority of value.. There is always a need to capture the "As-Is" process. The underlying requirement is to be able to "step outside" of the process and understand it fully. The key protagonists need models that enable them to communicate effectively with each other. Secondly, these models will form the underlying structure to underpin the capture of baseline metrics. It is important to gather reference metrics to ensure that the team can later prove the performance improvements.. To achieve a rich appreciation of the process it is necessary to model the process at a high level, from a number of different, complementary perspectives. Assessing the business situation using a complementary set of modeling techniques allows people to better comprehend the fundamentals of the process. The ideal techniques for this phase are: Flow diagrams to look at the order of activities (BPMN); Role Activity Diagrams to focus attention on role interactions and desired behavior of the various actors; Object State Transition Network models to focus on how the things moving through the process change state; and Capability models to look at the process as sets of re-usable business components. (A capability may be composed of other capabilities or implemented by a procedure - BPMN style model).. The emphasis here is on understanding the process - not building models for transformation into code or executable process definitions. This then enables both the business analyst and the business user to step outside of the business as usual view and see the process differently.. Given suitable access to subject matter experts, a good rule of thumb is that this phase of activity should complete within a week or two. While this might sound challenging, it is entirely feasible. The trick is to ensure that models are at a suitably high level. Always keep in mind the purpose of the modeling and the intended audience. Models should be detailed enough to drive understanding and discussion, but no more detailed than is necessary to support this aim.. Best Practice Observations..

Problems can occur in this phase of activity if people decide to set out and capture all potential paths through a process, all exceptions or all potential activities. This is the root cause of "analysis paralysis. IT-centric analysts wrongly assume that the path to success begins by populating a multi-dimensional modeling repository. In the short term, it can kill a BPM project as it distracts from the critical requirement of proving the efficacy of the BPM approach to the business.. Creating the "definitive" Requirements Specification is a waste of time. Documents by themselves are flat. Indeed, as stated earlier, the whole notion of a definitive requirements specification becomes irrelevant in a BPM project.. From Design to Deployment..

A comprehensive BPM Suite is necessary to underpin the target process-enabled application. The BPM Suite provides a configurable platform that executes procedural models, delivering work to the relevant employee or partner (or even customer). It ensures traceability of individual cases of work and guarantees compliance. Modern BPM Suites include integrated process modeling and business rules environments, integration facilities, sophisticated user interface capabilities and powerful analytics.. When developing the actual BPM-enabled application itself, the BPM team will find it much easier to gain clarity with a deep understanding of the process provided by the previous phase. Rather than attempting to define 80-90% of the final functionality, start with automating a more modest target of around 20-40% that delivers the vast majority of the value.. However, the process is just one area where work is required in the development and implementation phase. Focused effort is essential to ensure effective integration with third party applications. Similarly, the user interface will need special attention, as will the metrics gathered and the mechanisms provided to managers to control the functionality.. Rather than trying to address all issues together, focus on just one aspect of the development before moving on to the next. Create a separate sub-phase of work for each different facet: Process Flow - In the initial iteration, the aim is to agree the core 20-40% of functionality that will deliver the bulk of the value. Although a fair amount of modeling was undertaken when looking at the "As Is," this effort is all about creating the "To Be" process. Although organizational change may be considered a deployment issue, the way in which activities are assigned to the groups and roles will also be important.. Integration - This sub-phase focuses directly on information extraction and update from/to external applications. Associated with this sub-phase is design of the data for the process. Again, ensuring that the data model is developed separately from the "As Is" model ensures that team members design and support what is necessary, rather than taking for granted what is there already. The deliverable should concentrate on proving to the user community that the necessary data can be placed on a default user interface (i.e. do not attempt to customize the user interface).. User Interface - Ensure that the screens deliver the information required by the various roles involved in the process.. Metrics - Explore the management information deemed necessary, how this data is gathered, who should have access to it, and how it is presented. Often referred to as Key Performance Indicators (KPIs), the BPM Suite should capture all the necessary information. It is worth noting that the metrics used to track process efficiency and effectiveness may differ significantly from the data used to maintain the state of the process.. Controls - Business managers will want a way of throttling performance of the process, allowing them to control process execution. They need mechanisms that help them cater with peaks and troughs in demand, or influence the way in which business rules apply.. It is important to separate these portions of the development as it will allow specialist resources in the team to focus their efforts. Depending on the situation, the order of these sub-phases may change. For example, if extracting data from third party applications will present the greatest difficulty, then this sub-phase should probably run first. Of course, in many projects, individual sub-phases may reiterate based on feedback from those subject matter experts and managers.. Moreover, each of these sub-phases allows the team to present results back to the subject matter experts and management of the business area within a workshop situation. Supported by a shared model approach, these interactive playback sessions ensure that users can see the implemented functionality requested. Moreover, because the outputs are graphical, participants can quickly step through the changes made since the last iteration.. When looking at the capabilities of the BPM Suite make sure that project team participants have direct access to all related events, rules, user interfaces, process flows, code and analysis from the same tool set, in the same context. The product should not force application developers and analysts to switch tools or contexts to see what is going on in the process.. Best Practice Observations..

Ensure that comprehensive facilities are in place for continuous and ongoing collaboration between the business leadership and the BPM team.. Make sure that the end users realize that this is not a "once and done" system delivery. Ensure that they understand that the team is coming back for future iterations on the development so that they do not try to cram every detail into the initial release. It may be necessary to produce a functionality roadmap with future phases of activity linked to areas of functionality not yet implemented. This will help the BPM Team and the end users focus on the delivery from this phase of development.. Rather than attempting to "transform" the "As Is" model developed in the initial phase (Process Discovery and Understanding), build a new set of models inside the BPM Suite. This helps to focus on the desired functionality for this phase. It removes the temptation to bend the rules in the Discovery and Understanding phase (by attempting to put too much detail into models). It will also help ensure that the application leverages the features and facilities of the BPM Suite.. Locking down the "To Be" process definition in the first iteration can be challenging. Even when users know that further iterations are planned they will still push for functionality that is less important. Zeroing in on what the business really cares about is often difficult. Separate the identification of the happy path of the process from the handling of exceptions. In the initial iteration of the process flow loop, it may be good enough to capture and support the happy path. Subsequent iterations could then capture the major exceptions, leaving the more complex exceptions to another release of the application.. Catalog and weight exceptions to help identify those that are most important. Look at each one in terms of its impact (to the business when it occurs), its frequency, and whether it is detectable today. A severe exception may only occur twice a year. Or conversely, an exception that happens frequently may have little or no impact to the business.. Separate the management of the flow of instances (all cases in the system) from the management of a single case.. It is a good idea to ensure that the team carries out a fundamental re-assessment of metrics as part of the BPM implementation. Explore how to integrate the business relevant data (such as customer, or product information) with information on cycle-time, resource utilization, etc. When assessing KPIs, make sure that they support the underlying business objectives (the firms KBOs). Further, take care to ensure that the measures will reinforce the behavior that the initiative is trying to encourage.. When presenting finished functionality for any particular facet, ensure that the workshop includes a wider group rather than just the managers and subject matter experts already involved. This helps to remove errors, identify additional functionality for the next iteration, and encourages broad acceptance of the application when released into production.. Consider data and documents implementation details of the process. They are normally the mechanisms invented to keep the process coordinated, rather than the essence of the process. Look for ways of achieving the real goals of the process without that mechanism of coordination. Removing them will probably drive a massive jump in productivity and/or cost reduction.. When integrating third party applications, take the time to wrap them first in Web Services to insulate the process model from any changes in back-end systems (and vice versa).. Remember that both the use and understanding of data also evolves iteratively, which can have fundamental implications on the design of the process and integration mechanisms.. Ensure that a subject matter expert is available from each major role affected by the system, which is particularly important in the process flow and user interface area. Share specialist resources across projects.. When selecting a BPM Suite, identify a holistic environment that provides semantic consistency across different views as participants share the same set of models and configuration data. This minimizes any opportunity for miscommunication and lowers the cost of development.. Pitfalls..

The capabilities of the system, to support effective business monitoring and control, derive from an effective design and deployment phase. This section discusses the types of capabilities delivered. There are several perspectives that are important including dashboards, alert and escalation mechanisms, control loops and personnel management.. Dashboard-style user interfaces deliver appropriate metrics to managers and supervisors. The assumption is that managers will intervene where necessary to expedite items of work as long as they have suitable visibility on work in the system. Of course, the system itself can help facilitate this through the provision of mechanisms that enable the manager to inspect the item of work, reassign that piece of work or interact directly with the worker responsible. Moreover, the system can prompt individual users directly, bringing to their attention items of work that are in danger of exceeding any milestone or service level agreement (SLA) established.. Monitoring and control mechanisms should also enable suitably authorized managers to direct the overall operation of the process. When most vendors talk about BPM and continuous process improvement, most of them are discussing the larger, overall business optimization loop They have failed to grasp the importance of the secondary optimization loop where suitably qualified business managers control the running process directly. Generally, this is a design issue. The application should have built-in capabilities that provide managers with the controls they need to throttle business performance. (See Pulte Mortgage Example on page 10) Best Practice Observations..

Analysis and optimization is usually the responsibility of the business analyst or process owner. In an ad hoc fashion, these people are looking to identify the problems and suggest changes for the next release of the application. They are looking at the overall business process, its historical performance and related business data with the aim of identifying ways to improve performance.. Of course, the objectives of the business (the KBOs) should drive performance optimization. For most firms, adding more people (resources) to a process to improve performance is just not an option. The best BPM products provide mechanisms to test alternatives (other than simply adding additional resources at bottlenecks).. Simulation..

In response to this need, most vendors have focused on the provision of simulation tools that support the comparison of different what-if scenarios. At its core, simulation is a statistical technique that uses probabilities to predict average activity durations, queue lengths, resource utilization, etc.. But usage of simulation should come with a few health warnings. Simulation is most effective when used as a way of testing assumptions. For example, if interest rates fell, leading to an increase in mortgage applications. what would be the impact on the ability of the firm to provide the same level of customer service? At what point would additional resources be required? But simulation models are notoriously difficult to construct with each linkage in the model requiring careful statistical checking. In the above example, that might mean checking the sensitivity between interest rates and the numbers of mortgage applications. To solve this problem entails gathering historical data to support this testing. The best BPM simulation tools available today extract this data from the running process model to provide the base line information, which dramatically changes the cost benefit ratio associated with simulation.. Optimization..

Best in class BPM Suites provide optimization mechanisms that provide automated support to help determine the best means of process improvement. This takes simulation a step further, addressing some of its inherent difficulties. Rather than leaving it to the analyst to determine options for improvement, the system should help to identify areas to consider. Moreover, it is often difficult to compare different simulated scenarios in ways that are meaningful to the business, for example: Business managers are usually most interested in assessing the effectiveness of a particular product or service. It is not good enough to know the average cycle time of all loans; they want to know the cycle time of the Jumbo loan (since they know that has the best margin). Or, they want to assess a particular line or service by sales channel.. Alternatively, they may look to analyze performance over time, comparing some slice of the past with current results, or looking into the future. For example, rather than looking at the average over the last six months, a manager might want compare the Holiday sales season with the Summer sales season. Or, look at the amount of business in production today and compare that with the business situation three months ago, or the same period last year.. Best Practice Observations..

Simulation is not an end in itself. It is one of many diagnostic tools. Do not rely on any one piece of information or one tool as being 100% accurate in its conclusion. Processes are multi-dimensional and so is the "truth. Use a variety of analysis techniques to isolate the most critical factors that affect the ability of the process in support of its Key Process Indicators (KPIs) and, as a result underpin the Key Business Objectives (KBOs) of the firm.. Avoid simulation models that are deterministic in nature; designed to prove to management a positive return on some proposed change. Such models often reflect the agenda of the modeler rather than the reality. They usually bury assumptions rather than surface them.. Growing the Team's BPM Capabilities..

So how does an organization go about improving its ongoing BPM delivery capabilities? Clearly, experience will grow over time. But responding to the situation outlined in the introduction - where the organization needs to support dozens of BPM engagements per year, has its challenges. Firms should develop a proactive strategy to manage and grow the knowledge of the BPM team, capturing insights and developing effective engagement methods.. The most common response to this challenge is to develop a BPM Center of Excellence (CoE) or Process management.Office. The idea is that a group of committed individuals will focus on the processes of the firm as they drive bottom-line profitability and performance. The team can support a number of BPM projects across the business, keeping momentum going across a broad front. They are usually responsible for developing common principles, language, frameworks and methodologies for process development and process architecture management.. However, in the early stages, the CoE can present an unnecessary overhead as it typically has a much wider scope than is necessary for a pilot project. The CoE concept comes into its own as the BPM program starts to address the needs of the wider organization. With more and more projects, the need increases for a coordinated and integrated approach. The CoE provides a central repository for knowledge and best practices development around BPM projects.. Best Practice Observations..

Benchmarking?As a first step, it is a good idea to conduct benchmarking exercises with other organizations. Rather than learning only from those of a similar size and culture, the group should also compare approaches with firms that have a fundamentally different view of how to organize BPM initiatives.. Grow the process acumen of the team by assessing different approaches - Take time to weigh different approaches (especially for process and business modeling). Rather than looking for a single approach for all situations, assess which techniques best support different types of scenarios. By necessity, this type of activity involves bringing in outside experts to educate and facilitate discussions Adopt an iterative development methodology, supported by appropriate technology. The old linear application development methodologies just will not scale to handle the number of engagements. Neither will they provide the agility needed for survival in a rapidly evolving business environment.. At first, do not bite off more than you can chew. Given the fundamentally different approach to development and implementation, it is vitally important to prove the effectiveness and validity of the approach. So look for a short, tightly scoped project that allows the team to build skills and experience. The project should have relatively low complexity and a clear business benefit.. Share the high-level vision with the business users along the way. Help them to understand the iterative approach, with multiple releases in quick succession. Otherwise, they will assume that the time between releases is infinity and will push for too much functionality in the first release, making it unnecessarily complex. Share the iterative builds with business users to make them more comfortable with the overall approach.. The relationship between Process Owners, Business Owners, the Center of Excellence and an individual BPM project team requires careful consideration. Address governance issues comprehensively and early. Identify process owners to sustain/support applications once in production. Agree on change procedures, expectations on resource availability, etc.. "Before Action Review" and "After Action Review" - This is the most important mechanism to grow the BPM capabilities of the firm over time. For each project, focus on short cycles of plan, prepare, execute, and review. For each project, phase and sub-phase. plan the engagement with the user community. Set objectives for each deliverable and brief the team to ensure that they fully understand the rationale. Conduct formal BARs and AARs for the entire project, for each phase and sub-phase. By necessity, the BAR-AAR cycle for sub-phases will be relatively brief affairs. Encourage all team members to take notes and participate in these meetings..