Posted by Connie Moore on September 8, 2009
By Connie Moore
I was going through a bunch of old slide decks last week and came across this one particular slide that struck me. I think it gave me pause because I don't normally use the slide, and I hadn't seen it in a long time. I think the material is workwhile for anyone thinking about using a business process management (BPM) suite, so here goes.
Consider a BPM suite when you need to:
- Change processes frequently. This is probably the most important reason to look at using a BPMS, but a few years ago you wouldn't have seen this on the list, much less anywhere near the top. Back then, everyone preached the mantra that you should find a repeatable process and use BPM to automate it. Maybe this came from a Six Sigma view of the world in which practitioners were trying to drive out variation in order to reduce defects and increase quality. Anyway, the old thinking has been turned on its head now: use BPM for processes that constantly change (in addition to the highly repeatable ones) because processes that constantly change are 1) hard to automate and 2) probably some of your highest value processes because they are usually people and knowledge intensive. A BPMS coupled with a continous improvement mindset (this latter point is the really important part) can really make a difference when it comes to processes that change. And let's admit it right now--business processes change a WHOLE lot more than we think they do.
- Automate and monitor processes across the value chain. We are kidding ourselves if we think that processes start and stop within the walls of the organization. To really understand a business process, you have to look at it from the customer perspective, and analyze all the steps involved in the business process, including steps that happen outside the oranization--say at the suppliers, the business partners, the dealers, the franchisees, and the customer. It's challenging to automate processes across a value chain and a BPMS can help. But the software is definitely not the hard part; getting everyone to agree on the process is the hard part. That's where industry frameworks can make a big difference.
- Support cross-functional processes. We still get inquiries from clients who want to start their BPM intiatives within a single department. They think this way because they want to lower their risk and learn from the first departmental implementation. But at its heart BPM is about tackling end to end business processes, and that means you should look across functional departments, including the white space between functional groups where work gets lost. An example of a lower risk cross functional process would be employee on-boarding, which goes outside the HR department. You can still address the risk factor without having to limit your BPMS implementation to a functional group. Anyway, if you need to automate a cross-functional process, a BPMS is a good way to go about doing it.
- Allow business users or customers to monitor the status of requests or work in progress. Fed Ex and Amazon have forever changed expectations about monitoring the status of a request or order. It's no longer good enough to expect customers to stay in the dark or be happy with e-mail updates. Customers and others making requests want to peer into the process to figure out what is going on. You can turn this into a huge customer benefit if you do it right. And BPM suites are specifically designed to monitor the status of work--whether inside the organization or outside it.
- Extend the life of legacy apps. This is a great advantage of a BPMS. If you have an older application, or a group of older applications that need refreshing but there's no budget to rewrite them/replace them, then a BPMS product can be implemented on top of the application(s) to become the layer that integrates apps or delivers additional value to the workers using the apps. Many companies that have implemented BPM suites have found that it cuts substantially into their maintenance backlog and reduces maintenance costs as well.
- Collect work metrics or meet SLAs. As BPM suites matured, they began to offer strong process monitoring capabilities for business managers. It's now possible to monitor work in real time, or look at analyses of work that has already been processed. By setting key performance indicators, BPM suites can become powerful management tools for managers and executives--not just for monitoring work in process but also for redirecting work when and if conditions require.
- Improve inaccurate, inconsistent or laborious manual work. This one is a real beauty for companies that have fallen way behind on refreshing their IT systems. I've personally seen companies realize as much as $5 million in savings the first year after implementing a BPMS because they had 1) fallen behind and relied upon laborious and duplicate data entry processes that generated data inaccuracies and customer satisfaction issues, 2) had massive, even heroic, manual activities associated with getting work completed and 3) relied extensively on paper documents and forms that were constantly misplaced. By implementing a BPMS to automate an archaic process quagmire, the savings can be huge.
- Capture process knowledge. Many companies in regulated industries (like manufacturing, pharmaceuticals, utilities, etc.) and government agencies are facing a steep climb in replacing retiring baby boomers. A US government study just came out last week that says more than 270,000 workers will be needed for "mission critical" jobs over the next three years. When organizations face that level of employee turnover, they often start documenting their business processes and nailing down all types of tacit and implicit knowledge. Definitely, modeling your business processes helps the organization gain more process knowledge, but there is a big caveat that comes with this approach. Many organizations fall prey to the ideat hat they can document their business processes in their favorite tool (Powerpoint, Visio, a process modeling too) and it will provide great value over time. In reality, unless the process model is tied to an execution engine, it will be outdated very quickly. That's because processes change much more frequently than we realize (see bullet 1 where I started . . . ). A BPMS product is one way to model the process for process knowledge and also link it to an execution engine that makes it much easier to update the process version as it changes over time.
I hope this list is valuable to you. It caught my eye and I thought I would share it.