Best Practices for Delivering BPM Projects. Jörg Grote BPM Solution Architect. Copyright TIBCO Software Inc.

BPM A look back in time Departmental Workflow Solu2ons of the 90s Projects ini2ated, funded, and delivered by Business without IT Hybrid-teams of Business and Drag n Drop client-server developers Complete process-based applica2on building capabili2es within the product Development and Deployment RAD/JAD/Itera2ve Approach Rapid 2me to benefit Very Few Project Failures Possible Because Small Scope Human-centric Non-mission Cri2cal Non-Core Data Few Channels Minimal coupling

But When BPM Took On The Enterprise Infrastructure/PlaTorm is key considera2on of the BPM developer N-2er architecture, High-availability and scalability Technology (Java or.net?, Servlets, EJBs & Assemblies) Mul2-node, mul2-geography implementa2ons Integra2on is a key skill of the BPM developer EAI/SOA PlaTorms Java (PoJo & EJB) and.net HTTP, JMS, Web Services XML, SCHEMA, XPATH, XSLT LDAP, Single-Sign-On Data is a problem for the BPM developer What s does the process need to execute? (BPM duplicates) Where is it? (Loca2on) How do I get to it? (Integra2on) What does it look like? (Data Models) What s the single truth? (Reusability, Aggrega2on, Transforma2on)

BPM in an SOA world Back To The Future Provide a platorm for BPM Distributed applica2on server High-availability Service-engine distribu2on and inter-communica2on Service (process, web service, PoJo, etc.) deployment topology is an Architect s func2on Provide integra2on Service implementa2on is the SOA developer s func2on Support new services Virtual Data Data virtualiza2on is the SOA developer s func2on Process enacts upon business domain (Concept) model SOA provides virtualiza2on mechanism hide complexity from the future BPM developer

BPM in an SOA world - Back To The Future Change the nature of BPM, BPM will return to its roots but on an Enterprise Scale AMX & BPM will provide the SHARED SERVICE PLATFORM for mul2ple BPM ini2a2ves to use in parallel Control, Availability, Scalability, Connec2vity, etc, provided by the platorm Greatly simplify and change the role of the BPM developer Re-Focus BPM on the needs of Business User Higher-level Modelling Processes, Domain Models, Rules, Forms, Work, Goals, SLAs, KPIs, etc,.. User Experience Role-centric Process Paeerns Re-Focus BPM on Business Requirements People efficiency as well as process efficiency SLA management and Metrics Simula2on and Op2miza2on Re-Focus BPM on Rapid Applica2on Development Much, much less technical in nature Model driven applica2on development tooling Fulfilment SHARED SERVICE PLATFORM BPM MATRIX Customer Care Billing Project Management

BPM The Journey TIBCO BPM Execution Model Step 1 Step 2 Step 3 Step 4 Step 5 Step 6 Develop Vision & BPM Program Roadmap Define & Implement Organization & Governance Define & Implement Technical Infrastructure & Standards Analyze Process & Develop Project Roadmap Design, Build & Deploy Business Process Repeat for each project Operate the Business BPM Governance Continuous Improvement BPM Project Life Cycle Management and Control Measure Business, IT and Organizational KPIs & SLAs / Analyze ROI Executed on Service, Subprocess, and Main-Process Level - each

BPM The Journey Step 1 The Vision Map out a roadmap of projects Selec2on criteria for the first project/process/service Success criteria Simple simula2on to jus2fy ROI Map out the high level processes Level 1 and 2 (SCOR Model great example) Great way to manage scope creep yet understand the bigger picture Step 2 Organiza2onal Structure Iden2fy the business sponsor COE team; Business analyst, SME, COE leader (IT liaison) Map out the par2cipants for the first process

BPM The Journey. Step 3 Infrastructure Hardware and somware Templates; requirements, design Prince 2 methodology Standards and governance; Modeling approach, workshop checklists Reference Template processes Standard paeerns (i.e. Wil Van Der Aalst) Step 4 Mapping out the As-Is process Process understanding and workshops (i.e. using NIMBUS) Watch people work, don t just take someone's word for it Documenta2on Repor2ng and metrics for success criteria Map out the concepts required for the process

BPM The Journey. Step 5 Designing to the To-Be Stay focused on success criteria Challenge the legacy process, what is the process goal? What is key? What must remain? What is non-value add? Can this be removed? What are the system restric2ons? Are they s2ll current? What is the customer concerned with? What is the focus of the process? Simula2on is only a guide the first 2me through Step 6 Execu2ng Monitor success as based on ini2al criteria Iden2fy room for improvement Introduce simula2on based on reality. Import real data.

The Five Maturity Levels Level 4 Predictable Level 5 Optimizing Capability management Change management Level 3 Standardized Business-Line management Level 2 Managed Work-Unit management Level 1 Initial Inconsistent management

Why Process Management Is Different Implemen2ng a Process Management system is a process, not a project. BPM is an enabling technology which can deliver benefit throughout an organiza2on, it does not (only) provide a discrete solu2on to a discrete problem. This characteris2c has significant implica2ons for the way a project is scoped and phased. Process Management is a new concept to many organiza2ons it becomes par2cularly important to promote understanding of the technology and gain user involvement in developing a solu2on. A Process Management system fundamentally affects the way people work a BPM project must be very sensi2ve to people issues, the need to promote awareness of objec2ves, to work in teams, to encourage feedback from users, and to manage change. The objec2ves for implemen2ng a Process Management solu2on are normally core to the opera2on of the business for example the objec2ves might be to bring new products to market more quickly, or to improve customer service levels and avoid performance penal2es. There are omen therefore big implica2ons for gesng it wrong (but also big implica2ons for gesng it right!). A Process Management project is normally a collabora2ve development between IT and business this requires a degree of co-opera2on and mutual understanding that is unusual in tradi2onal IT projects where the responsibility of the business is omen restricted to signing off a specifica2on of their requirements and then tes2ng the finished system to confirm that it meets their requirements. A Process Management solu2on normally incorporates a number of different technologies and tools with implica2ons on the technical resources required, and complica2ons in the configura2on of suitable development and test environments, as well as in the technical design of the solu2on. Given the above, there are some rules which will help guarantee success..

Rules for success Rule 1 - Keep It Simple Rule 2 - Deliver Quick Wins Rule 3 - Get It Wrong Quickly Rule 4 - Deﬁne The Scope Rule 5 - Deﬁne The Objec2ves Rule 6 - Deﬁne A Plan Rule 7 - Involve The Business - Appropriately Rule 8 - Measure The Results Rule 9 - Cul2vate A Business Sponsor Rule 10 - Use Known And Proven Components

Rule 1 - Keep It Simple This is the Golden Rule. Experience shows that the success of an IT project is inversely related to the complexity of the project. The greater the number of components in a project, the greater will be the amount of effort to complete the project and the greater will be the risk that the project will a. go over budget b. fail to meet requirements. This is par2cularly valid for Process Management projects, because in most cases the organiza2on deploying a Process Management system has no prior experience of Process Management technology (which directly contributes to risk).

Rule 2 - Deliver Quick Wins This rule is another way of expressing the Golden Rule. A BPM Process Management system is designed primarily to automate processes, not to manage documents or data. Unlike documents or data, an organiza2on s processes will change on a regular basis, according to the pace of change of the market in which the organiza2on operates. It is fruitless to spend many months analyzing, defining and implemen2ng the perfect process, because a dynamic organiza2on may have changed its processes (as a result of introducing new products or services) before its original (and now incorrect) processes have been automated. It is far beeer to define a narrow project scope and focus on key business problems in order to deliver short-term benefits.

Rule 3 - Get It Wrong Quickly Ready Fire Fire. Process Management is a unique technology in the way that it forces people to change the way they work. This change par2cularly affects those people who are responsible for managing work (iden2fying the types of work to be done, alloca2ng the work to an appropriate work group, making sure the work gets done, monitoring produc2vity) Because many of the management tasks will be performed automa2cally by the Process Management system. To try and define a perfect automated business process based on the requirements of the people who operate the current manual process, is like trying to draw a picture with a blindfold on. Only by implemen2ng and using a Process Management system will a business really understand how it wants to use a Process Management system.

Rule 4 - Define The Scope A well-defined scope is as important for a Process Management project as it is for any other IT project. The previous rules may seem to encourage a relaxed approach to scoping a Process Management project. Far from it., and the previous rules are intended to assist in making the scope realis2c and effec2ve.

Rule 5 - Define The Objectives If the goals are not defined, they are unlikely to be achieved. There is a tendency when implemen2ng a Process Management system to make the automa2on of an exis2ng process a goal in its own right. This may be acceptable where the primary goal is to improve the efficiency of an exis2ng process, and where efficiency gains are expected by virtue of replacing manual tasks (such as the alloca2on of work) with automa2c processes. A business may however have many other reasons for implemen2ng a Process Management System, for example to make processes easier to change, to de-skill processes so that resource costs are reduced, to reduce elapsed 2mes from start to end of a process in order to improve customer service.

Rule 6 - Define A Plan If you fail to plan, you plan to fail. Once you know the scope of a Process Management project (rule 4) and you have defined the goal of the system to be implemented (rule 5), the task of defining a project plan is greatly simplified, but the importance of defining a project plan is by no means reduced. Because BPM encourages an itera2ve, prototyping approach to development of automated business processes, and because many projects are set up as pilots, before aeemp2ng the real thing, there is danger that project planning will be considered unnecessary. This is of course not the case!

Rule 7 - Involve The Business - Appropriately Mrs. Smith knows more than you do! This is another rule that is common to all IT projects, but which has par2cular relevance to Process Management projects because of the profound impact that Process Management will have on the way people work. If the people involved in current processes do not par2cipate in the design of automated business processes, those processes are unlikely to support the day-to-day processing requirements, and when the system is implemented exis2ng users may ac2vely seek ways to make it fail. However if the goal of a Process Management system is to radically change exis2ng ways of working, which may also imply the need for fewer people with less skills, over-reliance on assistance from current users may be considered to be not only inappropriate but also unethical.

Rule 8 - Measure The Results Repor2ng is what it is all about. Even when rule 5 is remembered, and the goal of a Process Management system is the pre-eminent factor in the design of the system, rule 8 is omen forgoeen. If the goal is to increase produc2vity by 50%, but the produc2vity before and amer implementa2on of the system is not measured, the success of the system cannot be quan2fied. Consequently it is difficult to learn lessons which provide feedback and influence the implementa2on of the next automated business process.

Rule 9 - Cultivate A Business Sponsor Without an influen2al, commieed business champion who keeps focused on the goals of the Process Management System, the chance of failure is high. A business sponsor, or perhaps a beeer name is a business champion, is essen2al to see through the implementa2on of a Process Management system. During the course of an implementa2on job roles will be challenged, power bases will be threatened, substan2al change will be introduced; In short many poten2ally fatal challenges will arise.

Rule 10 - Use Known And Proven Components Don t redesign the wheel. It is wise to avoid building any reliance in a Process Management system on a component which has never been used before, or never been used in the same way before. This applies as much to any product set from any vendor. In order to minimize the risk of unproven components, they should if possible be evaluated in a technical proving project before they become a cri2cal component of a produc2on system.

Plan for Success! Once you know the scope of a Process Management project (rule 4) and you have defined the goal of the system to be implemented (rule 5), the task of defining a project plan is greatly simplified, but the importance of defining a project plan is by no means reduced. If you fail to plan, you plan to fail

What, Why, Where, When & How Anaylse your process based on this Key Ques2ons

What are Standards? Standardiza2on: an agreement to support a common interface or representa2on (with coopera2on of the vendors) Why? Preserve investment: re-use rules across tools Interchange: allows coopera2ve development/deployment Re-use: avoids reinven2ng wheels Commodi2za2on: negates vendor lock-in Training: skill sets transferable Indica2on of market maturity Build up Naming Conven2ons very early, create Referencable Examples and Paeerns

Life-Cycle Try to adapt Life-Cycle Management early in every project SOA Services & long running BPM Procedures needing different Life-Cycles Deploy a Service or a Sub-process to the Integra2on and Produc2on Environment, when it is implemented. Start with the first Steps/Parts of your Process or Solu2on Why? Clear Strategy Tes2ng can be started very early Everyone will understand Impacts on changes early Training on later Produc2on Handling Avoid unwanted side Effects Avoid a Big Bang Strategy, as this is not SOA and BPM

Rules for BPM?