Have you been tasked with:
- Capturing as-is process flows (eg swim-lane charts or BPMN [Business Process Model and Notation] diagrams)
- Starting a new project where understanding the current state is important
- Finding ways to optimise day-to-day activities performed by your team
- Creating a baseline process to identify automation opportunities
- Comparing your current processes with recommendations such as eTOM or ITIL
- Identifying which tasks are leading to SLA / OLA breaches
As you may’ve experienced during project kick-off phases, as-is processes are usually not well defined, captured or adequately quantified (eg transaction volumes, duration times, fall-outs, etc) by many customers.
If process diagrams have been captured, they’re often theoretical workflow maps developed by Business Analysts and Subject Matter Experts to the best of their knowledge. As such, they don’t always reflect real and/or complete flows. They may have no awareness of the rare flows / tasks / situations that can often trip our OSS/BSS tools and operators up. The rarer the sub-flows, the less likely they are to be documented.
Even if the flows have been fully documented, real metrics / benchmarks are rarely recorded. Metrics such as end-to-end completion times and times taken between each activity within the flow can be really challenging to capture and visualise, especially when you have large numbers of flows underway at any point in time.
Do you struggle to know where the real bottlenecks are in your process flows? Which tasks cause fall-outs? Which team members need advanced training? Which process steps have the largest differences in max / min / average durations? Which steps are justified to build automations for? As the old saying goes, if you can’t measure it, you can’t manage it.
You need quantitative, not qualitative understanding of your workflows
As a result, we’ve developed a technique to reverse-engineer log data to map and quantify processes. Logs that our OSS/BSS routinely collect and automatically time-stamp. By using time-stamped logs, we can trace every step, every flow variant, every sequence in the chain and every duration between them. This technique can be used on fulfilment, assurance and other flows. The sample below shows transaction volumes / sequences, but can also show durations within the flows:
Note that this and subsequent diagrams have been intentionally left in low-res format here on this page.
Better than just volumes, we can compare the max / mean / min processing times to identify the duration of activities and show bottlenecks (thicker red lines in the diagram below) as well as identifying hold-ups and inconsistencies in processing times:
By combining insights from flow volumes and timings, we can also recommend the processes and/or steps that optimisation / automations are most justified for.
We can also use monitoring of the flows to identify failure situations that have occurred with a given process, such as the examples highlighted in red below.
We can also use various visualisation techniques to identify changes / trends in processing over time. These techniques can even assist in identifying whether interventions (eg process improvements or automations) are having the intended impacts.
The following chart (which is clickable) can be used to identify which tasks are consistently leading to SLA (Service Level Agreement) breaches.
The yellow dots indicate the maximum elapsed time (from the start of a given workflow) that has not resulted in the SLA breach. In other words, if this activity has ever been finished later than the yellow dot, then the E2E workflow it was part of has breached its SLA. These numbers can be used during a workflow to predict likelihood that it will breach SLA. It can also be used for setting jeopardy values to notify operators of workflow slippages.
There are a few other points of interest in this chart:
- Orange dots indicate the longest elapsed time for this activity seen within all flows in the log data
- Grey dots indicate the shortest elapsed time from the beginning of a workflow
- Blue dots indicate the average elapsed time
- Yellow dots are the Jeopardy indicator, meaning that if the elapsed time of this activity has ever exceeded this value then it has gone on to breach SLA
- The red line is SLA threshold for this particular workflow type
- Shaded box shows tasks that have never been in an E2E flow that has met SLA
- You’ll notice that many average values (blue dots) are above jeopardy, which indicates this activity is regularly appearing in flows that go on to breach SLA levels
- Almost all max values are above jeopardy (most are so high that they’re off the top of the scale) so most activities have been part of an E2E flow that has breached SLA
- The shaded blue box shows tasks that have never been in an E2E flow that has met SLA!!
- Needless to say, there were some interventions required with this example!
Operational Process Summary
As described above, using log data that you probably already have ready access to in your OSS/BSS, we can assist you to develop quantifiable process flow information. Having quantifiable data in turn can lead to greater confidence in initiating process interventions, whether they are people (eg advanced training), process (eg business process re-engineering) or technology (eg automations).
This technique works equally well for:
- Understanding the current situation before commencing an OSS/BSS transformation project
- Benchmarking and refining processes on an OSS/BSS stack that is running in business-as-usual mode
- Highlighting the impact a process intervention has had (ie comparing before and after)
Would you like to book a free consultation to discuss the challenges you face with your (or a customer’s) as-is process situation? Please leave your details and list of challenges in the contact form below.