Business process improvement using state diagrams

Over the last 10 years I became increasingly more interested in visualization of behavior and 'way of working'. I was focusing on process efficiency and quality, and I noticed that quite some organizations don't actually know how good or bad their processes run. They have a flow chart, a tool and are used to how the process works, including its workarounds and caveats.

The typical business process flowchart is focusing on descriptive text and RACIVS tables (Responsible, Accountable, Consulted, Informed, Verified, Sign off). Digging somewhat deeper in the process and checking the interaction of the users with the process flow, I noticed that moreover there was a lack of visibility of the process flow. Typically and largely a result of project focus on delivery, not on support/documentation. Users had to work with either the high level BPM diagrams or the application UML data diagrams.

One day we had to link our content management system to the customer relationship management system in order to pipe incentive and marketing data/feedback to the correct systems. It seemed an easy task and on the technical level it was, but still the CRM managers were not satisfied with the speed at which updates were delivered. None of the existing systems had been changed and all individual processes worked as usual so what went wrong?

Essentially, the connection between the systems and the visibility we got from the new department heads re-surfaced some existing issues we hadn't really fixed in the past. Some systems needed manual follow-up during batch processing of tasks so we timed those processes to run during working hours, having the IT staff readily available to monitor progress. Over time the systems were tweaked, performance and stability improved significantly but as usual, running projects had main focus so no one considered retiming the data pipeline for efficiency.

This is where I come in :-) In an effort to properly document the systems under my control and better understand the systems that we were feeding to, I started working on a data state diagram. None of the process management methods I knew covered what I needed to analyze so I used a Petri Net Diagram approach as a basis. My trigger came from my brother who is a Biochemical Engineer and overall smart ass. He once explained the state diagram approach to me and I tweaked it to fit my needs.

Basically a state diagram has 2 components:

• State visualized by a circle
• Action visualized by a rectangle

Here is a simple example showing the step of validating data, which needs to have the data available for validation and which will result in validated data.

 

Remember that I don't care about who owns the data or system, I just want to increase efficiency of the throughput to satisfy my customer.  So I need to add the test scenario to the diagram as this could be a potential bottleneck in my throughput:

 

Nothing too spectacular here and although it provides me more insight in the system's complexity and dependencies, it will not really help me solve my problem.  The single most important thing that helped me identify the true bottlenecks and focus the developer's efforts was the step where I added timing.  The timing dependencies turned out to be crucial for optimal efficiency and we were able to derive the timing data from the obvious sources like existing Business Process Diagrams, overall Working Hours and Cron batch scripts.

Timing can exist of many features but for my purposes I required to know:

• process absolute start (e.g. working hours, batch process kick off...)
• process nature: automated vs manual
• process run time

Having this information enabled me to run different scenarios to validate time related bottlenecks and overall it made the throughput time clear to al parties involved, reducing help desk tickets and inquiries tremendously.

 

This is merely a small example to convey the concept to you.  Although there are some very powerful business process tools available that could do the trick including the automated scenarios, most of them would require a lot of information to be entered into the process entities before a flow can be generated.  I used Visio to visualize this complete data flow spanning multiple pages (we plotted the diagram on an A1 paper so show the full image).

Even though I have used this simple technique multiple times, the teams involved are every time again surprised about some of the unexpected dependencies that turn out to be the true culprit.  Some seem relatively obvious like working hours, customer feedback process, synchronization timing being daily instead of hourly.  At times I stumbled upon indirect timing dependencies like daily scheduled IT maintenance by other teams killing the network bandwidth...