Back To Basics
Business Process Management (BPM) has been around ever since the first rules on how to do something were created. Whether that started on a cave wall or a papyrus scroll, it’s not real clear but we do know that Business Process Management Software (BPMS) is still relatively new. Maybe it’s no longer in its infancy but certainly it has not reached full maturity yet. Let’s say BPMS is in its “tween” years right now.
My Story
I worked in a claims department at a health insurance company when I was first brought into the world of BPMS or, as it was known to us back then, image processing. Our office was lined with bookcases filled with paper files and we had full time employees devoted solely to moving those files from shelf to shelf and desk to desk. The notion that those files could be scanned into a system and pulled up on computers at our desks sounded like a paradise especially for an examiner like myself who spent at least 25-30% of my day dealing with the physical movement of paper and files.
Enter BPMS
Our company purchased BPM software, established workflows, created simple forms to use with the images, and set out scanning not only our new claims but also doing a back-file conversion of all the files. This was not an easy task but once it was done, our world was significantly better. Instantly we knew how much work was out there. We didn’t need to keep a daily tally sheet of our backlog and work completed (although there were still a few supervisors who didn’t trust the technology and wanted them done anyway). Needed an old file in order to process a new claim? No problem. It was right at our fingertips.
Pandora’s Box Opened
The technology opened our eyes to the possibilities but perhaps opened them up too much because instead of keeping the workflow simple, we started adding on to it and then began to complain about the system that had provided a great boon to the department.
Our forms needed to be more intelligent even though prior to the imaging system we only had a paper routing sheet with checkboxes.
Instead of having work queues that held first in/first out, they had to be divided into states, then alphabetically, then by product and then by dollar amount.
Specific users had to have work assigned to them by a supervisor instead of letting employees pull from a pool of work (even a pool paired down by the filters in the previous bullet).
It became unacceptable for an image to take 5 seconds to open when before we sometimes had to wait days to receive a file we needed to process a claim.
Business users were at odds with IT and vice versa due to the ever increasing length of time it took to make changes primarily because the number of changes made the system more complex and difficult to change.
A lot of these challenges were hold overs from the paper days but also because the user community knew the technology had the ability to do the things they wanted. Soon, complicated interfaces were developed to allow assignments based on the skill level of users, how much time had passed since their last investigation, who had certain approval amounts, etc. Again, all of this obtainable within the capabilities of the software but moving further away from the basic workflow that, on its own, brought great efficiencies. The add-ons made the system much more complicated to maintain and update and because the changes had to be implemented fast, thorough testing wasn’t done and caused production problems once the change was deployed.
The Industry Was Watching
What we were doing seemed to be representative of what other companies were doing with BPMS and the software vendors were paying attention. Fast forward a few years and now we have case management, smart forms, built-in integration points, dashboard reporting, dynamic work allocation, open source, cloud based solutions, low-code, even social media integration. Are these features useless? Absolutely not but it clouds what BPM is at its core: a way to make a job easier.
I remember when I moved from the business side to the software side and worked at my first BPM vendor. There was an internal contest to come up with an “elevator pitch” for describing our software. I won that contest by coming up with “Getting Your Work to You So You Can Get Your Work Done” (or something to that effect…it’s been several years!). The message was a simple one but that’s what BPM and BPMS was supposed to be…simple. Can we say the same for the industry today?
I will say that the Low-Code advances make the most sense for BPMS as it can put the development of workflows and forms into the hands of the users. I believe this will move the BPM systems back to a simpler state because if the users have to do it themselves, you can bet that list of features will end up being much smaller than it was when they were going to hand the development over to IT.
Basic Business Process Management
Maybe we need a new acronym: BBPM. Basic Business Process Management and start extolling the true meaning behind it. For all the great technologies and features that are available in just about all of the BPMS products, there are still thousands of companies who are handling physical files, manually keeping track of backlog and work completed, and dealing with obstacles that limit productivity and affect the bottom line. I would say these are the companies who need to know the basic benefits of a BPM system and not the fact that it can integrate with Facebook or Twitter. Let’s get them into the car first so they can see how it drives before pointing out the number of cup holders or Bluetooth pairing capabilities of that car.
Again, there is nothing wrong with these advanced capabilities and many companies can use them but ALL companies need what a simple implementation of BPMS can provide: efficient workflows with visibility into all aspects of their business processes while mostly removing the physical aspect of dealing with paper. I’ll be exploring some of these ideas in future blogs.
Getting back to basics. It’s what BPM needs.
