Archive | June, 2012

Who is Watching the Watcher?

28 Jun

The last house I moved into was fully equipped with smoke detectors – the new kind – that are wired directly into the house’s electricity. So I was more than a little surprised after a year or so of living in this home that one of the detectors starting beeping – and for no clear reason.

And when I finally took the cover off of the detector I noticed an interesting thing – there was a battery inside. I couldn’t understand why an electric smoke detector would come with a battery – until, that is, my wife happened to stroll by, noticed the confused look on my face (easily recognized after 20 years of marriage), and said:

“It must be a backup for when the power goes out.”

Of course. If the smoke detector is watching out for a fire, the battery within it is watching out for a non-functional smoke detector. In other words, the battery is “watching the watcher”.

Which brings to mind my favorite story of a client using an alerts system:

The client is a hospital that sends out an ambulance with EMTs when an emergency arises. The EMTs load the patient on the ambulance and immediately proceed with triage and treatment to the best of their ability. The patient’s symptoms are logged into an on-board computer where they are electronically relayed to the hospital.

(Now here’s the really cool part.)

At the hospital, the alerts system monitors the incoming patient’s symptoms and – based on those symptoms – the appropriate doctor is notified (typically via their pager or mobile phone).

But there was a problem with this process; sometimes doctors changed their pager number, PIN, or even their cell phone number – and didn’t remember to inform the hospital of that change. So, when the alerts system tried to notify the appropriate doctor, sometimes the alert failed – and continued to fail as the alerts system repeatedly tried to use that invalid delivery address.

Enter “plan B”, which was: “if an alert to a doctor is not successfully delivered within 5 minutes, failover the alert to either an alternate doctor or to a nurse’s station.” Brilliant!

This functionality – referred to under such names as “redundancy checking”, “self-monitoring”, and “alert watchdog” – is essential for organizations that rely on an alerts system for the health and productivity of their HR staff and for the efficiency of their business as a whole. After all, an alert is only as good as its ability to reach its intended recipient; thus the need to identify and act on those alerts that do not reach their recipients is every bit as important as the rest of an alerts system.

Ideally, the self-monitoring aspect of an alerts system should provide the following:

  • Determination if an alert has been successfully delivered
  • Identification of “over-triggering” – i.e., an event whose conditions are met too frequently
  • Identification of “alert overload” – i.e., a single alert recipient who is getting sent too many alert messages (which will eventually cause them to ignore all alerts)
  • Capture of alerts with invalid delivery addresses, such as invalid email addresses, bad fax numbers, or incorrect mobile device numbers or PINs
  • The ability to identify alert events that have been added or customized (and by whom)
  • Trend analysis of triggered events (e.g., “are things getting better or worse?”)
  • Alert events that are configured incorrectly or are missing components

So – when you configure an alerts system for your organization, think positively and hope for the best – no missing data, no invalid contact information, and the like. And then plan for reality. If watching your HRMS data is as important to your organization as you think it is, don’t leave it to chance.

Watch the watcher.

 

When Nothing is Really Something

1 Jun

When Nothing Really is SomethingIt’s one thing to look at your HR data and see information that requires your attention. A purchase order request; a contract that’s about to expire, or an employee with a negative vacation balance.

But have you ever tried to identify an HR activity that should have happened – but didn’t? That’s not nearly so easy. Consider a monthly HR task which the vast majority of your employees complete. You don’t need to know about all the employees who completed that task; rather, you need to know about that small number of employees who failed to complete that task.

This is a case where the absence of activity is exactly what you need to know.

It’s unfortunate but true that often the most important information for an HR organization doesn’t concern what has happened, but rather what hasn’t happened. Employees who have not received their reviews, staff who have not taken their mandatory drug tests, or managers who have not taken required certification courses are all good examples of HR business activities where “inactivity” is key.

Some inactivity scenarios in HR are easier to address than others because they have specific dates associated to them. Activities such as an employee’s “next review date” or their “last drug test date” typically utilize individual, date-specific fields within your HR solution. In those cases, it’s not too difficult to run a report or query where your date-sensitive selection criteria retrieves only those records where the “next review date” is within ‘x’ days, or the “last drug test date” is more than ‘y’ months old.

The difficulty occurs when there is no such date field associated with an action that should have occurred. For example, an organization might offer training classes on employee safety. These courses might be on such subjects as CPR, hazardous waste handling, and fire prevention methods. Employees might be required to take one or more of these courses on a periodic basis, such as monthly, quarterly, or yearly.

And as important as it is to see who has taken these courses (and when), it is even more important to see who hasn’t taken them.

The problem is the absence of data to report on. And the best way to understand this is to imagine this information stored in a file cabinet. Imagine that you open a drawer and reach for all the papers filed under “Last Year’s Safety Course Attendees”. These papers might show that 60 (out of 100) employees took such courses. Unfortunately these papers don’t help us to see which employees didn’t take those courses.

So how do you go about reporting on data that just isn’t there?

The answer is “by cross-referencing”.

Cross-referencing is a two-step process, and is typically the only way that “absence of activity” can be reported on. In the above example, before you’d reach for the stack of “last year’s attendees”, you’d reach for a separate list of all employees.

Then – and only then – could you cross-reference that list of “all employees” with the list of “last year’s course attendees”. You would identify any employee that had zero course registrations for last year, as that would be a staffer who has not taken any safety courses – exactly what you’re looking for.

Most importantly, cross-referencing should be an automatic process within your HR solution. Just as you can configure your HR solution to automatically tell you when certain critical activities have happened, you can similarly automate the process whereby you are told about things that have not happened.

Because in the HR world, nothing can really turn into something.

 


Switch to our mobile site