Protocol
Main Use
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.
To use this analysis module, select Protocol in the drop-down list under the project's name.
Overview
What is protocol?
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 a gunshot wound). 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.
Analysis
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.
Protocol Complexity
As already mentioned above, a protocol could be much more complex than the liner set of activities.
It may include:
- Some activities could be performed in any order. The effect is similar to Concurrent activities however user may think about them differently.
- Concurrent activities – performed in parallel.
- Fork – the logical split between several possible paths. The fork could have many additional options, it may depend on the outcome of the previous activity or some attribute of the process or be completely outside of our control or be truly random.
- Repetitions – some activity could be performed a number of times equal, less, or greater than some value.
- Merge – the process can’t move farther until several or all branches merge together. This usually happens after concurrent activities
Using the Protocol Tool
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 you are 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.
Types of Violations
- Wrong position – an even exists however it happened in the wrong order.
For example, a protocol calls for ABCDE, but the reality was ABECD. In this case E – wrong position. - Missing step – required event is absent, like ABDE (C is missing).
- Wrong count – even should happened more or less times then protocol defines. Remember, in protocol definition you could specify the range of count for any event. By default it’s 1-1. So if in reality you’ve got ABCCCDE, that is count violation.
- Time violation – the specified time limit has been exceeded.
Example
Here’s the example of a fairly complex protocol for a customer onboarding.
- Obtain signed application
- Get authorization
- Create new account
- If current 401K holder exists:
- Request funds transfer from current 401K holder
- If no response in 2 weeks, request again
- If no response after 3 tries, escalate to Protocol "Nonresponsive holder"
- Deposit funds
- Call customer and review his options
- 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:
- Missed step 5) "Customer call". Happens in 28% of cases. Results in 2% increase in "Process Aborted", 9% increase in "Temporary Success", and 11% drop in "Success".
- Missed step 4.2). "Request funds again". Results in 14% increase in "Process Aborted", 3% increase in "Temporary Success", and 17% drop in "Success".
- And so on…
22.02.2024 17:28:05