Workarounds provide a way to bypass or overcome a particular issue or Incident, whether it is an end-user or back office issue. A example might be editing or adding a portion of a customer’s health care record/data through a script instead of through the application front-end due to coding or database issues.
Executing the script provides a workaround that resolves the Incident (albeit inefficient), but not the permanent fix. The following should be performed:
- A Problem Record should be opened and related to the Incident
- The Incident Record should be closed because normal operations has been restored and a workaround is in place
- Ideally, a Known-Error should be logged within a Known Error Database (KEDB) and would hold information about the workaround
- The Workaround must be tracked
A question recently arose about where to track the workaround since a formal KEDB did not exist. Since Workarounds are typically not permanent, managing its life cycle is important. Image your users continuing to execute the above scripted workaround after a permanent fix had been applied. This may cause data integrity issues or worse.
In our situation, the answer was to manage the workaround within the Problem Record itself. Why?
Quite simply because the Problem is now the active record for tracking root cause and permanent resolution of that original Incident. If Change Management and Problem are properly integrated, the Change process should help manage successful implementation and transition planning. Prior to closing the Change and Problem Record, proper communications and/or training would occur to remove any manual or automated workarounds. Finally, once no longer relevant, the Known-Error itself should be archived or disposed.