BPMS Implementation Methodology
The following diagram is the follow on process to the Process Improvement Diagram from the “Steps to implementing a BPM Process Improvement initiative" section of the site. These two processes can be used together for effective BPMS project implementations.
BPMS Implementation Process - Followed For Each Process
Assuming the to-be process, use cases, goals and metrics have been defined during the process improvement phase, the process can be prototyped. We highly recommend using an agile method to implement a BPMS system. Start with the modeling of the roles/groups to whom work will be assigned, develop rough prototypes, wireframes or mock-ups of the user experience/forms, data, flow and rules. Mock-up forms and walk them through the process before investing in full development. Often users can’t visualize how the application will work and all the data required to make routing decisions may not be evident, so use walk-thrus to help elicit and refine requirements. Use prototypes of reports the system should generate (mock-up reports in Excel if needed) as this too will uncover data elements or data relationships that may not be apparent.
Develop integration points and data persistence if data will be stored in a separate database. If the tool allows, test forms and processes separately to simplify troubleshooting. From this point you can follow a traditional SDLC (Software Development LifeCycle) approach.
While BPM methods can be used to analyze and streamline processes without the implementation of process automation or BPMS tools, often BPMS systems are used as a means by which to achieve more efficient business processes and help to institute BPM practices.
The key to a successful BPMS initiative is to define the methods you will use. When implementing a BPMS solution, there are two dimensions to methodology.
Top Ten Tips for Implementing BPMS
(Business Process Management Software)
1. Pick the right first project. Don’t pick something too complex or ambitious. This could be both technically and politically problematic. Get quick wins by implementing a portion of the process or select a project with less impact but one you can complete within 90 days or less.
2. Write or discuss all use cases. Even simple processes end up having many variations. Discuss and document all the various use cases. As much as people loathe documenting, it will help you uncover requirements early on instead of once users start testing (and grumbling). An ounce of prevention here is worth pounds of cure.
3. Determine measurements/metrics needed up-front. Who is the customer and what are the requirements critical to success. (Considering using a SIPOC Map). Don’t forget about metrics you will need to measure success. Knowing up front what the metrics are that will be needed to track, monitor and measure the process can affect your data modeling and data capture plans.
4. Prototype. Mock-up forms, worklists, etc. To “Walk” Forms/User Interface screens through the process without all the logic first. It will help the users visualize the process and ‘experience it” and uncover more requirements.
5. Iterate, Iterate, Iterate
Plan for iterations and meet weekly for continuous feedback and course corrections.
Plan for iterations and meet weekly for continuous feedback and course corrections. .
Plan for iterations and meet weekly for continuous feedback and course corrections.
Repeat the above...
... etc..
Exit only when your sure you have something users will be happy with.
6. Test the Forms, Integrations and Flow separately first. Isolating each component and making sure it works first can be helpful in speeding implementation. Use sample data (variables or similar) to test the behavior of the form and process through the various use cases. Test each one independently (does the form hide or show sections as it should? does the process execute properly end to end?) before linking them all together. It makes trouble shooting easier. And if multiple people are on the project, it's by far the best way to break down development tasks.
7. Invest in training and support. Don’t short change the knowledge part of your investment. Training and support from the vendor you choose will be money well spent.
8. Usability, look and feel matter. Often the focus is on process logic and integration. Even a great, technically sound process that meets all of your objectives can be rejected by users when the user experience is the last consideration. Users focus on look and feel and usability (as they should). Brand your BPMS tool (Login, header, etc. – most tools support this as a feature of the tool). Include breadcrumb trail types of markers so a user knows where they are in the process. Consider breaking forms into multiple screens instead of tab style layouts so users know how to progress through screens. Follow style guides. Focusing on design and usability can make the difference between users loving an application for all the help it provides, or ... feeling hatred for it and all the people that dared to foist it upon them.
9. Include all stakeholders in the process. Include representatives from every group impacted in kick-off meetings, prototype reviews, etc or at a minimum, at least get their feedback at critical points in the process (once to-be requirements are complete). If the process is very large and complex, consider breaking into sub sections to keep groups more manageable.
10. Consider future change. Don’t just design for today. Consider what types of changes have occurred in the past and what might be likely in the future. What device changes might there be (moves to MACs or Mobile devices)? Do policies frequently change? (perhaps rules should be exposed in a screen for users to easily change).
Earlier we covered the roles involved in a typical BPM Initiative (in the Scope of BPM Initiatives section). So now, exactly who does what and with whom do they collaborate when a BPMS system is employed?
First and foremost, ownership needs to be clear. You will need some type of program manager or committee to own the overall BPM initiative. They are responsible for standards, project prioritization, education tools, communications and 'buffering' to upper management. Based on your company and size, this may be an individual like a Process Director or a PMO office/committee.
Then for each BPMS project, you will need the following roles (a role not necessarily being an individual):
- A project manager to handle meeting coordination and scheduling, task and issue tracking, and overall risk and change management.
- A Business Analyst/Process Designer to facilitate workshops to capture as-is and to-be process information and prototype forms and processes. Each team will require process owner(s) and or those that have subject matter expertise and end users of the intended process - they will need to be closely involved in the project.
-Process Developer(s) to handle integration points and more complex aspects of your process implementation and access to the BPM system administrator.
Whether it's departmental or enterprise, 1 person or a team of 50, what matters is that the basic roles outlined in the chart below are covered.
Let's qualify that however, by pointing out a crucial differentiator in project success: the quality of the work done is dependant upon the training, skills and at least a modicum of general competence of team members. After all, without capable people in these roles you're likely to endure some classic problems. You or your team don't really want to be the subject of dark, water cooler discussions. Like:
- 'The end users won't adopt that new process (now that it's done).'
- 'Nobody asked for our input on that project.'
- 'Why is that project taking soooo long?'
- 'Why did they pick such a complex project first?'
- 'What is the value of that project anyway?'
- 'I can't believe they even funded that one.'
The bottom line here is- get the best team together that you can assemble and supplement needed skills with solid training.
While less common than other technology implementations, BPMS initiatives can and do fail. Yes competent, capable teams are key, but beyond that, some of the most common lessons learned by many BPM practitioners include:
- At the program/business level
Selecting the right project to start with (good value/moderate complexity/lower risk to achieve a quick win).Making sure you have an owner for the overall initiative.Having executive management buy-in and commitment.Educating the organization on how they will be affected and why this change is will have value to them (apply change management principles).Making sure you have the right skills and training on both the product(s) you are using and the methodology you employ.-Don’t underestimate the effort. BPMS tools, while certainly far easier to use to automate processes than outright coding, take knowledge, skill and time to implement effectively. If the scope of you project justifies it, get multiple estimates from different sources (vendors, participating internal departments, independent consultants) and ask them to supply a fine level of granularity for all the line items in the estimate. Challenge numbers that are widely divergent. As you contrast and compare these estimates, start building your own based on numbers that you have the greatest level of confidence in.
At the project level
Establish metrics upfront to measure results Business Stakeholders and Subject Matter Expert Involvement is critical to successAnticipate taking plenty of time for developing buy-in. It can take time and be challenging to get stakeholders to agree on the process.-Communicate often and throughout the project with all stakeholders
-Implementing a BPMS requires a SDLC (Software Development LifeCycle) type of methodology and needs to include:
Project ManagementBusiness AnalysisProcess Developers and Integration SpecialistsPrototyping and Iterative Development ApproachesMaking sure the types of changes your application may need over time is easily supported by the tools you select or is incorporated into the design. Change management and change propagation can be much more difficult or time consuming than might expect!Selecting a BPM Software (BPMS) Vendor
Who are they all? We counted 27 major BPMS software vendors that are building BPMS platforms and vertical applications. Given the number and variety, we thought we'd do everyone a favor if we collected important attributes and place it in a BPMS Vendor Comparison Chart. We think it can save endless hours of research. It lists 27 vendors across 30 attributes that can help with first pass vendor selection including any published price range information, number of employees, platforms supported, if they have an open source offering, provide a cloud offering, the major components of their platforms, their location and more. Below are some additional tips and guidance on building a BPM business case and ROI.
BPM Software Vendor Evaluation Process
Fig 7.
The ten basic steps to evaluating a BPMS vendor include:
- Determine your key “first pass criteria” (consider budget, vendor location, vendor focus, markets served, technology platform for example as potential “key”criteria to help filter down the list of candidates)
- Using your key criteria as a first pass – match this to vendors based on market and or analyst research data in order to narrow down the list from the well over 30+ vendors in the market to 6 – 8 that are suitable to your requirements and budget.
- Through vendor demonstrations, RFI/RFP data collection and analysis, narrow the vendors to 2 –3 (your short list).
- Have short listed vendors do custom demos, a proof of concept and/or trial based on a specific conceptual process you create that will exercise/prove out your requirements.
- Score vendors based on functional abilities.
- Conduct deep dive technical reviews.
- Score Vendors on technical abilities.
- Conduct Vendor reference calls.
- Score vendors on customer support and satisfaction.
10. Final analysis/selection and negotiations and contract award.
1. Don’t rely solely on the analysts for your short list. Just because a vendor is not listed in a Analyst report don’t automatically rule them out. It is impossible even for large analyst firms to include all the vendors in their in-depth analysis. Based on your budget, industry and geography, there may be totally viable candidates that do not make the analyst's cut. And remember, some on the list now were once newcomers in this ever evolving market and didn't previously make the grade. Also, keep in mind that smaller vendors can be more agile, more attentive and more flexible.
2. Ignore feature hype. Often there is hype around capabilities that not every organization or industry needs or should implement. Rules engines and critical event processing in a BPMS tool, for example, are typically needed in high transactional environments like financial services or systems where your are trying to perform automated decisioning. But they add what may be unnecessary complexity for many other use cases. Simulation can be very beneficial in modeling tools to performing “what-if analysis” – but few companies have the need or the needed skills to use some of the more sophisticated simulation tools.
3. Consider your real-world needs when defining criteria. When you think about business user functionality- be realistic about what business users really will do. Will process owners really model processes or will it end up being done by Business Analysts or IT? Will users really design and manage their own reports? Will the business really take ownership of certain aspects of administration?
Think about not only getting the process automated initially, but consider what features are needed to make ongoing changes to it. The ability to make 'in-flight' changes once your process is deployed is often overlooked and can be critical to obtaining the ongoing improvement and agility gains you are striving to achieve.
4. Start with an RFI and or RFP template. Find a BPM vendor selection RFP template and modify it to suite your own needs. Save yourself and everyone else time by keeping you request as compact and short as possible by cutting out the sections that you are certain will not apply to your environment.
5. Use data visualization methods to help analyze and compare BPMS vendors. Heat maps and spider charts are easily done in Excel and can help you analyze the information but more easily communicate it to decision makers and other stakeholders.
6. Talk to vendor references: Discuss support and on-line communities. Ask about training. Ask how long projects took with how many resources (vendor and theirs) and what types of resources (skills) were involved. Talk to individuals at different levels within the organization to get a complete perspective.
7. Do a Proof of Concept (POC)/Custom Demo. While nobody should ever confuse a demo with a fleshed out, manageable, production ready application, POCs can help validate critical functions like integration to certain systems or other basic elements that are essential to your success. Most vendors are willing to demonstrate a portion of your process in their tool, so map out a small number of steps and a form or portion of one and provide it to them. It can give you insight not only the functionality of the tool your are evaluating, but how a vendor will work with you and support you in your real-world implementation. It can also help you communicate internally as to how this technology can be applied and it’s benefits.
8. Understand skills needed and where you will get them. Every tool requires some general skills as well as tool specific knowledge and expertise. Make sure you can develop the needed skills through training or the vendor has enough trained individuals or partners to support your initiative.
9. Maybe one tool won’t do. Dentists, carpenters, doctors, plumbers and other professionals don’t have a single tool in the toolbox. Sometimes you need different tools to solve different problems. Maybe you like the capabilities of a given BPMS tool but their analysis capabilities are weak. Consider a stand-alone modeling and simulation tool (it will likely be used by only a handful of users anyway). Or maybe one project needs a tool that is better at SOA/Integration and another requires more tuned to Human interactions. Some large scale projects can easily justify an investment in two tools or consider open source for one. Applying a more complex tool to a simpler project may end up being more work than it is worth.
10. Meet the family. Meet more than the sales team. You are 'marrying' the whole company. Before you walk down the isle, meet sales, service and product executives if possible. Meet the person who would be training your team, the actual consultants that would be working on your project and the specific individual(s) providing you with support.
Depending upon the scope of your BPM initiative, making the business case for investing in BPMS technology may center around the benefits to be gained in a single process area or across an entire organization. Ideally your BPMS investment can leveraged across many business areas,but the size of your organization, internal politics and many other factors may make this type of broad business case difficult if not impossible.
BPM Business Case and ROI
Depending upon the scope of your BPM initiative, making the business case for investing in BPMS technology may center around the benefits to be gained in a single process area or across an entire organization. Ideally your BPMS investment can leveraged across many business areas,but the size of your organization, internal politics and many other factors may make this type of broad business case difficult if not impossible.
Some humble suggestions:
1) Align the benefits of your BPM initiative to specific business goals. Initiatives that help the top line are often valued over those that impact the bottom line. Will your initiative improve your top line through improved customer service response times, time to market for new products and/or services, etc? or is it aimed at bottom line improvements through workforce optimization, faster/less costly application development/system updates/modifications.
2) Include benefits that have been achieved by other organizations. Checkout our Case Study Sumany Report (requires simple registration only) or some ideas and BPM metrics as well as some of the other BPM market reports below. Also check out the Case Studies page where we aggregate BPMS vendor case study pages (all we can find- so you don't have to repeat our groping around).
3) Include a cost and benefit analysis – See some of the BPM Return on Investment tools below. Be sure to include all costs for software, hardware, internal resources, vendor support, training and show both expected quantitative measures as well as qualitative.
4) Include your plan for roll-out and risk management including planned periodic checkpoints and progress updates. Consider a POC and Pilot Project as part of your approach to illustrate how spending will be balanced with proven gains.
Here are some articles, tools and papers you may find useful.
Custom demo, trial, proof of concept or pilot
We all know it is a good idea to verify a software product is going to meet real world requirements before making a substantial investment. The following are all options you can consider using to do just that as part of a more comprehensive BPM software vendor evaluation process. We also have a detailed guide which includes how to develop “process requirements” and more in our Process Requirements For Validating BPM Vendor Capabilities. (Simple registation required).
To what extend each vendor will be willing provide these options for free as part of their sales cycle will vary dependent upon the complexity of your requirements, the vendor, the complexity of the software being evaluated and the cost of the technology.
Custom Demo: Ask the vendor to develop a custom demonstration (if it is within reason, almost all will gladly do so as a part of their sales process).
Need further validation?
Conduct a Hands-On Trial:
Ask for or sign up for a trial (many of the small to mid-tier vendors have trials readily available). Larger vendors may not be as eager as their products are typically more complex. Realize ALL require some degree of know-how to use them and if you have not used BPM products before, you will need some guidance.
OR
Do a Proof-of-Concept:
A trial can be a significant amount of work to truly and fairly evaluate capabilities, especially if you are planning to review several vendors. An easier path to consider is a proof of concept. The vendor – as in the custom demo scenario - will develop the process for you. However in this case, you will ask them to spend time showing you in-depth exactly how the process was built and ideally, be given access to the process to allow business users to interact with it.
Need even more validation?
Do a Pilot:
Pilot projects have the goal of delivering a very modest but representative application all the way through to deployment. They can help you better understand the overall effort required for a BPM initiative, assist with the business case for making initial or further investments in technology and/or resources, help you in vendor selection, drive interest and buy-in throughout the organization, help establish repeatable methods for future projects as well as achieving some quick wins to help gain momentum for BPM within the organization. You may also consider doing a small initial pilot with your selected BPM vendor of choice prior to making an enterprise wide investment in that specific tool.
When looking for how to select a pilot project, consider complexity, risks and benefits. You don’t want to pick a project that is extremely complex but at the same time, you don’t want to pick something that has no real business impact. So it's good idea to determine the scope of your pilot, tally up costs in advance based on tightly defined pilot requirements and be sure they are aligned with the pilot goals. Be conservative in your cost estimates. Unanticipated costs in a pilot can eat up project dollars faster than you can blurt out 'scope-creep!' (your fault) or 'What do you mean 'that's the way it works'?' (their fault). Be sure to avoid being caught in a circumstance where you have lost your negotiation position with your vendor because the investment in the pilot and your remaining budget now leave you with no choice but to use the vendor's platform or programming services even if you have big misgivings.
A useful pilot selection tool can be created in a spreadsheet (like the one found in the BPM Initiative Toolkit) that will allow you to enter various factors and plot them using a bubble chart. This is a good way to visually see value vrs.costs vrs.risk. Some of the factors that you can use for weighting the effort involved are the number of integration points, complexity of integration, the number of form fields, the number of steps in the process. For risks consider and give a weighting factor to items like the number of users or departments involved, volumes being processed, customer/revenue impacts, time to deliver the solution. For benefits/value factors you might elements such as cost reduction, cycle-time reduction, rework reduction, compliance adherence, improved quality of service, or improved competitive position
