You are on page 1of 11


> A 5-STEP GuIdE


Introduction define and Model Implement Measure and Report Optimize and Refine Repeat Change Management 1 2 3 6 7 7 8

One of the promises of business process management (BPM) is to improve the responsiveness of IT to business needs This is predicated upon the necessity for business and IT to work hand in hand throughout the BPM lifecycleand is the cornerstone of the implementation approach taken by Progress This overall approach consists of the following steps, which also roughly make up a BPM maturity model: 1 Define and model 2 Implement (iteratively) 3 Measure and report 4 Simulate and improve 5 Repeat The following model is a modified version of the Demming Cycle It is not necessary for every organization to complete every step There is incredible value in just completing the first step of process modeling and definition This step is roughly akin to CMMI level 2 and 3


Business Case Metrics and Goals Project Charter Estimates

Maps Business Reqs. Rules KPIs, SLAs Reports Org Model





Environmental Install LDAP Integration End User Training Deployment Planning


Deployment Checklist Production Tuning

Figure 1: BPM Project Timeline

dEfInE And MOdEl

Typically, a BPM project will start with a written charter and business case description by the process owner This establishes the project charter Next, the BPM delivery team will conduct a Process Discovery Workshop with the process owner and all concerned stakeholders The purpose of this workshop is to effectively and completely capture and model the business process, gather the business requirements, and ensure a solid understanding of the business process by all participants A majority of the documentation is done directly in the model itself, the thought being The model is the documentation The model itself is self-describing and contains: > > > > > > > Activity types and descriptions Functional requirements Activity inputs and outputs Participants Costs Durations Any other items of report

However, a supplemental business requirements document may also be completed to provide additional information During this analysis you also focus on business metrics Specifically, what are the key performance indicators (KPIs) and service-level agreements (SLAs) for the process as a whole and each activity within the process? It is critical to capture these metrics as they will form the basis of the reporting structure completed later It is this mechanism that allows you to measure and report on your process to determine efficiency, bottlenecks and whether you have met the overall success metrics and aligned with strategic objectives This is the heart and true power of BPM Once all stakeholders have agreed to the process model and the established business requirements, you can continue to the implementation phase Implementation involves an agile approach using multiple iterations

To be successful, implementation mandates that process owners and all concerned stakeholders be intimately involved in the process

Implementation begins with the Progress senior consultant and the delivery team meeting to decide on their delivery approach and to discuss implementation details and questions There are several approaches that may be considered These are listed below with a discussion of each to follow > > Serial Parallel > > > Inside-out Outside-in Hybrid

A serial approach takes each major activity in the defined process in turn, completely implementing that activity in the current iteration A parallel approach implements all activities concurrently, but each iteration focuses on one of the sub approaches listed Like building a house the inside-out approach starts with the foundation; in this case the foundation is the data structures or clearly defining the business data that will be going through the process This is followed by the plumbing of the house or, in our case, the business logic, business rules, and flows that connect each activity in the process Last, you want to make the house look nice For your effort this means developing the user interfaces or human interaction points for your process Conversely, the outside-in approach is the complete opposite; you focus first on the user interfaces, then the flows, and, last, your data structures The hybrid approach is a mix of the two, but focuses concurrently on the UIs and the data structures and, last, on the flows and logic Which approach is used is decided by the implementation team However, experience has shown that focusing on the user interfaces upfront has the highest impact with the business process owners as they can touch and feel a UI, but not a data structure

In addition to the three facets of process implementation discussed above (UIs, flows, data), you must also consider reports and analytics for each iteration These are integral to the success of any BPM project because without metrics and a usable format to display those metrics, you have no way to determine process efficiency or where to focus your improvement efforts This, of course, is the key tenet of BPM in the first place, and without it you are just doing workflow automation Reports are generally done concurrently with UIs as they are a value-add touchpoint of your process The result of this activity is completion of an iteration plan outlining how many iterations to expect and what each iteration will focus on Generally, each iteration is around six weeks in duration From there, each iteration will begin with a design workshop comprised of the delivery team and any process subject matter experts (SMEs) vested in the piece of the process that is the focus of the current iteration The goal of this workshop is to clearly define from a functional standpoint the design details of the current iteration This workshop is also used to uncover and deal with any unknown design or technical considerations Tiger teams may be assigned at this time to proof these x-factors Once the functional requirements of this iteration have been captured, concurrent estimates are determined for the time, complexity and level of effort by the design team, and the company prioritizes the work in accordance with the business requirements Typically, this is done using the MoSCoW method in which requirements are classified as must haves, should haves, could haves, and wants Starting at the top of the prioritized requirements list, you continue down the list until you have filled the allotted development time for this iteration A line is drawn on the list at that point Everything below that line falls out to the next iteration The result of this will be an accurately defined contract between what the business owners are expecting and what the implementation team can deliver in this iteration Development can now begin At the end of each week of development you conduct a playback session with the process owners These sessions are a critical for a successful project and delivery The goal of the playback is to demonstrate to the business owners both the progress and the direction of the implementation and to mitigate the risk of not meeting delivery expectations by providing a direct and timely feedback loop between the business owners and the implementation team This results

in an improved confidence level for the business owners, who are accustomed to waiting months before they actually see something tangible Throughout this process the concept of embracing change is at the forefront The playbacks provide a mechanism for business owners to request changes in the short term that will minimally impact the development effort The result is a responsiveness and agility between the business owners and the implementation team normally not seen with traditional development methods There are normally three-to-five playbacks during each iteration The final playback can also be viewed as part of user acceptance When the implementation effort for this iteration is done, true user acceptance testing will begin At this point there should be a beta quality product so this testing phase is more like a shakeout or beta testing effort In essence, you want customers to try to find the flaws and bugs Experience has show that this is a far superior method than traditional quality assurance (QA) with formalized testing scripts because users are certain to find flaws and problems your script writers never thought of This testing phase typically lasts anywhere from one-to-two weeks Concurrent with this testing effort is the start of the next iteration implementation effort At this time it is worth discussing some of the parallel tracks that have been going on during the implementation effort Aside from just developing and implementing the process, you also need to consider the following: > > > > Infrastructure installation Promotion and deployment End-user training Operational support

Infrastructure installation deals with installing and configuring your environments and, typically, consists of: > > > > Development Testing Staging Production

For each environment, considerations include product installation and configuration, LDAP integration for authentication and authorization, clustering, email, database integration for the business data system of records, other integrations, and any other server, network or environmental considerations The promotion and deployment track focuses on how you will promote and deploy the process or processes and all associated artifacts from environment to environment There are two primary methods for this: linear or radial Whichever approach is taken, the mechanism is the Apache Ant platform, an industry-standard method for building and deploying software Your deployment package and scripts must be written for automated deployments, or you may also deploy manually, in which case a deployment checklist is written End-user training is completed as the process implementation progresses and is somewhat based on the delivery schedule However, work on training material may progress in parallel with this effort This is a joint effort between the process owners, the customer training department, if applicable, and the delivery team The approach and type of training deliverables created depend on the customers environment, training maturity, culture, and desired scope The deliverables can range from simple documentation to training videos, classes, or a wiki Operational support takes care of end-user issues What happens when the process application breaks or is down? Whom do end users call for assistance, and whom, in turn, do the first-line support techs turn to for additional technical support or bugs, product issues, patches, etc ? The operational support plan is almost entirely dependent on and a function of the customers existing support structures, policies, and procedures However, the delivery team will guide this effort with respect to the process project and the supported platform and BPM best practices


Once your process is in production, you can begin to capture information about both the process and the business data going through it Focus on the following different types of reports for each process: > > > Process instance reports Process performance reports Operational reports

Process instance reports display information pertaining to a specific instance of your process This can either be instance performance data such as how long an instance is taking and where in the process this instance currently is, as well as the business data this instance is running through your process Process performance reports display aggregated information about all or a subset of process instances Examples include the average amount of time each instance is taking and what percentage of instances go through the happy path versus the exception path of the process model The next question to address is Why? These types of reports are very useful to process owners and are the basis of process improvement and optimization Operational reports are the custom reports process owners and stakeholders may request and typically reflect an aggregation of historical business data and process performance data These reports are usually used for operational base-lining and forecasting Reports are defined upfront and are delivered with each iteration At this point you begin to achieve some visibility into your business This would be roughly akin to CMMI level 4


This is the true value-add of BPM Once you have visibility into your processes and business, you can begin to address the difficult questions and ensure linkage to your strategic objectives and goals You will have answers to questions such as How can I improve my process to reduce costs by 10%? or If I improve my process responsiveness by 10%, how much will that add to my top line revenue?

BPM is continuous Just because you have completed one entire cycle does not mean you are finished In fact, you have just started To become a truly process-driven organization, you must continually work to measure and improve your process Failure to do this means you have just created shelfware Unfortunately, this is the norm rather than the exception

Embracing change is one of the tenets of BPM It is not a function of technology or software development It is an organizational issue, one that has a direct correlation to the success you will have with BPM in general Traditional heavyweight methods of dealing with change requests do not typically work with the iterative approach defined here However, as previously discussed, there are several elements built into the process to mitigate the risk of changes Foremost among these are the playback sessions Second is the method used for requirements gathering and project scoping As seen in practice, taken together these two methods eliminate a majority of change requests arising from miscommunication, mismanaged expectations, or lack of adequate user input However, there will be times when a change request is necessary during the implementation cycle In this case, it is first necessary to understand the scope and the impact of the change to the existing project timeline, and budget Second, alternative solutions should also be explored, such as whether the change requested can be pushed to a later iteration or what can be moved out of the current iteration to make room for the change request The process architect in conjunction with the business owner is responsible for developing this estimate Once the business owner fully understands the scope and impact of the change in terms of time and money, he or she must decide if the change is necessary at this time or, can be executed at a later time, or is unnecessary


Progress Software Corporation (NASDAQ: PRGS) is a global software company that enables enterprises to be operationally responsive to changing conditions and customer interactions as they occur Our goal is to enable our customers to capitalize on new opportunities, drive greater efficiencies, and reduce risk Progress offers a comprehensive portfolio of best-in-class infrastructure software spanning event-driven visibility and real-time response, open integration, data access and integration, and application development and managementall supporting on-premises and SaaS/cloud deployments Progress maximizes the benefits of operational responsiveness while minimizing IT complexity and total cost of ownership

Progress Software Corporation, 14 Oak Park, Bedford, MA 01730 USA Tel: +1 781 280-4000 Fax: +1 781 280-4095 On the Web at: Find us on facebook com/progresssw twitter com/progresssw youtube com/progresssw

For regional international office locations and contact information, please refer to the Web page below:
Progress and Business Making Progress are trademarks or registered trademarks of Progress Software Corporation or one of its affiliates or subsidiaries in the U S and other countries Any other marks contained herein may be trademarks of their respective owners Specifications subject to change without notice 2010-2011 Progress Software Corporation and/or its subsidiaries or affiliates All rights reserved Rev 07/11 | 6525-130709