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.
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.
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.