Best practice when implementing Continuous Monitoring

exMon can check for almost any discrepancy one might think of. However, this is not the scenario we want to see throughout our processess, systems and workflow. We want to choose every check carefully, and it is therefore handy to use a simple assessment process when deciding on which checks to implement. This is one chapter of four to explain best practice around implementing exMon Continuous Monitoring

How to prioritize and assess which checks to implement in exMon?

  1. Use a checklist to assess the urgency, value and overall importance of every potential check, that includes the following:
    • Name of check, ex. Check on handling fee X
    • Description of the check, ex. Find bills where handling fee has been omitted from bills with type XYZ
    • Goal of implementing the check, ex. That all bills include handling fee
    • Assess the value of the check, ex. €4 per wrongly omitted handling fee in lost revenue, or ave. €250 per case of misuse of blocked SIM card
    • Anticipated solution of uncovered discrepancy, ex. Better or more frequent education for agents, or improved registration workflow
    • Identify process owner
    • Assess urgency – high – medium – low
    • Identify data sources for the check, ex. System, system module/part, business contact, system contact, does the technical system contact have exMon access?
    • Frequency of checks, ex. „Working days at 08.00 and 14.00“ Assess carefully a time of check run that minimizes disturbance/latency in systems, but maximizes the informational benefit.
    • All type of information from databases that shall appear with exception alert, ex. Customer name, customer ID, bill number, amount, address, etc., with the goal of minimizing the need to look out of exMon when handling the exception case/alert.
    • Should the check result in e-mail? To whom?
    • Report all cases, or only new cases?
    • Should it be possible to comment on each case through e-mail?
  2. Then prioritize in a disciplined way; use the philosophy of need to have vs. nice to have – you don‘t want exMon to fill up with checks of little or no value.
  3. Keep the checks specific. A check that returns several thousand exceptions after first run is a bad check, it is very likely not specific enough. Be as concrete as possible and narrow the specification for each check for it to be possible to work on and fix the root cause of the problem.
  4. Keep exceptions that are only informational separated from actionable exceptions to minimize diversions. Example: Tracking of unsolicited log-in into system X in the middle of the night might be an example of an exception that is there foremost for information, something you want to know about and possibly see a development pattern over time, while an exception that uncovers a blank fill-in in an order can and should be fixed as soon as possible.
  5. Try to assess beforehand who will be responsible for solving the root couse of an exception returned from each check. It is important to assess whether the exception should be sent to a small group of employees instead of sending it to a potential „single point of failure“, i.e. one specific person.
  6. It is important to align the frequency of alarms and exception lists with the human resources available and the time required to analyze and fix the problems.
  7. The subsequent alarm and analysis cycle can easily turn in to unnecessary distraction instead of benefit if the initial assessment of the check is not thoroughly completed.
  8. Be ruthless in removing checks that are no longer relevant and keep the overall set-up of checks up to date at all times.