My take on business process management systems starts with a story about software that charted process flows that came up when I was leading a project to select a new ERP system a few years ago.
We were considering the usual suspects when the CFO asked me to look at one more option. The CFO's brother-in-law had a cousin who had a friend who worked at a startup technology company. This company had developed a product that generated business applications. At the request of the CFO, I included this company in our ERP selection process.
I started my exploration of this product by meeting with the founder and his vice president of sales. The two explained the amazing product their company had built. At the user interface, a person defined the business rules and process flow required by the business process. This company's technology would then build an application and database to support these rules and flows. The big selling point was that no one would ever have to endure vanilla or standard functionality again. Every department in an organization could build applications that supported its unique set of business rules and process flows. In other words, we could not just pave the cow paths, we could enshrine the cow paths!
Since one of our project goals was to base many of our transactional processes on industry best practices -- we probably did not need a unique and interesting set of business rules and process flows to handle our employee reimbursements -- we dropped this company and its technology from our selection panel.
I recall this experience each time I think about business process management (BPM) systems. BPM has come a long way over the past few years. It no longer has to be another massive, put-the-business-at-risk system to implement and support. And, for certain business processes, a BPM system makes a lot of sense.
However, recalling my reluctance to enshrine the cow paths, I always organize,...
To continue reading for free, register below or login
To read more you must become a member of SearchCIO-Midmarket.com
streamline and simplify my transactional processes as part of my BPM projects. I recently shocked one of my peer CIOs by telling him that I always manually map processes as part of any system requirements-gathering exercise.
Process mapping makes the process visual. With the process visual, we can objectively assess the usefulness and quality of the process steps and find ways to streamline and improve the process. After we implement the process changes, we then use BPM tools to help automate and manage the process.
For example, a few weeks ago, we decided to map our sales quoting process. Our company bids on numerous types of projects, and our salespeople -- as salespeople are wont to do -- each took a different approach to the process. We needed to improve our visibility into our sales pipeline so we could make more rational scheduling and resource prioritization decisions. I gathered a group of the process participants -- salespeople, accountants, production schedulers, etc. -- and we walked through the current process. I asked each person on the team to "staple themselves to the process" and describe to me what happens first, then second, then third and so on.
As we drew boxes for process steps and diamonds for decision points, the problems became obvious. Too often, the people at the tail end of the process -- the accountants who needed to price the quote and the production people who needed to define schedules and equipment availability -- were getting the information they needed too late. As a result, the quotes were sometimes late. This frustrated the salespeople and caused us to miss some opportunities.
Our process map showed an entire series of decision diamonds that asked, "Do we know enough to complete this process step?" If the answer was "No," the process flowed back to the step to gather the needed information.
With the process now visible, the salespeople immediately understood the issues and proposed that they all use a common template that listed what the downstream process steps needed to know. By the end of the meeting, they had drafted the template and agreed to start using it.
With this done, we could comfortably go to the next step and apply technology that gathered and reviewed the required information as part of the process workflow. Without analyzing the process as part of this BPM project, our workflow would have included the multiple points that looped back to get missing information.
By first clearing the process decks, we automated a process that deserved being automated.
Let us know what you think about the story; email: Niel Nickolaisen or editor@searchcio-midmarket.com.
