“Everything should be made as simple as possible, but not simpler.” – A quote often attributed to Nobel winning Physicist Albert Einstein.
Incident Management process is often quite simple. The process provides a lot of information beyond incidents themselves and are essential inputs for overall clinical risk management as well. In many cases, the knowledge that the incident management process is a first step to overall risk management is sufficient to drive us into analysis paralysis mode. Risk management is a very complex topic and has far too many factors in its implementation. We, at QUASR, have insights into clinical risk management and we will eventually integrate QUASR to provide this option for our clients. In this post, we want to address some of the common complications in implementing an incident management system and our solutions.
QUASR follows an industry-standard workflow for incident management. We implement a simple workflow and we are pretty proud of that fact. We believe we have achieved the simplest possible standard workflow that also captures the essence of incident management itself. However, during enterprise implementations, clients usually need quite a bit of convincing as to why this simple workflow is usually a good place for their needs. From our experience, this happens in two cases: when the clients have a legacy system that they have used for a while and are looking to keep the same process. Or they are looking to map their existing manual flow as-is into the new system. Both these approaches, frankly, are inefficient. Let us explain.
Legacy System Hangover
Systems that were built at least a decade back qualify as legacy systems. Any reasonably newer system might not have the issues that we are going to discuss here. For newer systems, the IT team was likely asked to implement their manual process as is! In software circles, there is an inside joke – “some unexplained bugs are actually features.”.
On a more serious note, systems that were implemented a long time back don’t fully take advantage of all the technological developments of recent times. Some of their design decisions could have been technology driven rather than user driven simply because it would be prohibitively difficult to implement differently.
A newer system built on more recent technologies doesn’t suffer from the same limitations. And hence it is possible to achieve more elegant solutions or workflows than wasn’t possible in a legacy system. That said, if we carried forward the legacy system as is, we might not fully utilize all the enhancements that technology offers us.
Mapping Manual Process to Digital Process
Since many of our customers are implementing their first digital system for incident management, this is the typical set of issues we face while onboarding and customizations. Many things we do manually, do not scale well to digital systems as such. And we all have seen examples of this: have you ever tried to collect all people interested in paying for a gift to a colleague? We send out an excel sheet and each person returns a sheet of their own and we merge them manually?
That’s exactly what we’d do before emails. We’d just go person to person, find out if they’d contribute and write it down in a piece of paper. But we all do know how inefficient that is, right? If we have to do the same thing today, we should probably set up a google form that each of the participant fills out and you get an excel sheet at the end of it. Same data is collected but far less work needs to be done by the person trying to collect it. The second option is a more digital native way of solving that problem. Incident management, incidentally, is full of such problems.
A typical example we often get as a customization request is to include additional workflow steps: include HoD as part of the workflow. Yes, we understand why you’d want to do that. But in many cases and as many of our customers agree too, this step is an FYI for the person involved. In a manual system, the HoD had no way of knowing what was happening unless you intentionally ran things by them. But digital systems aren’t really like that. Online systems are even lesser so. You’d just need to notify them in these cases.
In QUASR, we solve this problem by automatically having HoDs in the loop for all incidents in their department. You don’t need to do this additionally. However, we do not notify them every single time. EMail based notifications have become so common that we mindlessly mark things to read or archive them even without reading them. And we do not want to add to the inbox clutter either. So the HoDs just have to login periodically and they’d be updated on all the active incidents in their department. But unless we explain this, most of the users don’t see the solution. They are wondering how to implement an additional step in the workflow because that’s what they do in the manual flow.
Another example is typically around data collection fields. Many clients request adding quite a few descriptive fields whereas these aren’t very useful for systematic analysis. Descriptive data necessitates quality managers or investigators to spend time reading and understanding much information. But there is another downside: lack of sufficient information. Some people can describe an incident in vivid detail while others tend to write very little. Situations like these can be avoided by collecting quantifiable, standardized data instead. This, too, is an artifact of using paper based forms.
In paper based forms, it is impractical to collect incident type specific information for every incident type we want to track. So we end up with a few generic descriptive boxes for the users to fill up. However, adopting the same to a digital system does not allow you to utilize the full power of a digitalized solution.
Adopt Digitally Native Solutions
We just saw a few reasons why users typically have difficult-to-use, complex workflows in a digital system. But it’s not entirely their fault. As service providers, our first mantra is “Customer is always right!”. Blindly following the mantra, however, does very little to help the customer. While the customers know what they want, it is our duty to explain and clarify how best to provide what they want. Users tend to get carried away at the flexibility and try to plan for a future well ahead. It is worth remembering that technology evolves faster than our processes. So it is not very useful to plan far ahead into the future but plan for medium to short term only.
Enhancing software solutions are often quite simple and needn’t be as expensive either. Hence it is better to implement enhancements when the need arises rather than implement them all at once. Besides, having a digital native solution allows us to adapt to a digitalized workflow better – especially moving from a legacy or a paper-based system. Once we have acclimatized to a digitalized solution, we are better suited to decide how we need to enhance our systems in the future.
