Protocols include sets of rules or procedures for events in a process. Many processes have protocols or rules that must be followed and include areas where when one thing happens, there are things that absolutely must happen after that event, and often times in a given time range. The Protocol analysis tool uncovers areas where protocols are being broken or not followed.
A protocol is a predefined sequence of activities typically in a prescriptive form, i.e. the protocols are supposed to be followed. One could think of a protocol as an instruction or a cookbook. The examples of protocols: Resuscitating a patient with a cardiac arrest; Onboarding a customer with 401K rollover; Selling a product to a new customer, Defending PhD thesis, and so on.
A protocol doesn’t have to be a single linear sequence. There could be multiple protocols depending on the nature of the object (one for cardiac patient another for gunshot). There could be multiple branches within the same protocol: do something, check the result, if A – go one way, if B – go another way. There could be the protocols which happen within another protocol, for example, in the middle of patient admission process she developed the acute cardiac arrest. Moreover, the “inner” or “child” protocol could be triggered by some step in the “parent” protocol (a protocol to create new employee’s email account is triggered as one step in the overall employee onboarding process) or start completely independently by some external event, as in the case of the medical emergency during the admission process.
When dealing with protocols, a number of important questions arise:
How do we follow the protocols? What kind of violations do we have and how often?
Do protocol violations change the outcome? How much and for what type of violations?
If we have multiple protocols, what’s the difference in outcomes between them?
This list didn’t include the protocol discovery process as I want to treat it separately.
As already mentioned above, a protocol could be much more complex than the liner set of activities.
It may include:
User sets up the protocol including whether or not an event/step is optional, has a time constraint after a certain event/step, should happen concurrent with another step/event, should be repeating between events/steps, or floating between events/steps.
After clicking Show Violations the user is displayed all of the violations in a list with the option to hide or filter by a specific violation. The user can then dynamically arrange violations by the Protocol Item, Violation Type, Count, or Timeline percent just by clicking on that respective column header item.
If a user decides to hide certain violations they will be compiled in a list and reachable by clicking on Hidden violations in the top right corner of the Protocol Violations list. Users can then decide to unhide all or just a specific violation.
Here’s the example of a fairly complex protocol for a customer onboarding.
1) Obtain signed application
2) Get authorization
3) Create new account
4) If current 401K holder exists:
5) Call customer and review his options
6) Activate account
The outcomes may not be parts of the protocol itself. In this example the outcomes could be
Process aborted – the customer drops from the process in the middle of it.
Temporary success – the customer activates the account but leaves in the first 6 months
Success – the customer stays active for 6 months following the account activation
Then the analysis would show the typical protocol violations: