This is page 2 of:
How An IT Glitch Turned CVS Into A Meth Dealer
When CVS was notified of the problem, the company reconfigured its software. Sales of pseudoephedrine in CVS drugstores in southern California dropped to a fraction of their previous levels. But from the DEA’s perspective, that was $77 million too late.
Could software have stopped that crooked manager from breaking the law? Probably not. The MethCheck software has a manager’s override, just like there is on every POS system. A bad manager can override the software for all the wrong reasons. But the manager who was arrested was the exception.
The real question is why all those other employees ignored customers who were obviously buying more pseudoephedrine than they were supposed to. The uncomfortable—but realistic—answer is that none of those employees’ incentives were for enforcing the law. Their incentives were for selling.
And that’s a problem. Drug laws, privacy laws and food safety laws all get in the way of moving merchandise. Violating those laws can bring a retailer lawsuits and fines, even when employees aren’t trying to do anything but their jobs. That’s a set of conflicts that all retailers face.
So what do they do? They turn to IT to install systems that enforce the rules. That puts IT in the role of enforcer and sets the department in direct opposition to employees. Care to guess who will win that particular conflict?
Wait, it gets worse. When there’s a problem that involves people using IT systems—especially systems that are supposed to enforce rules—IT is always the most likely scapegoat.
After all, it’s very hard to pin blame when employees bend rules so they can sell, say, an unauthorized drug product or outdated milk or meat. Is the employee breaking a rule? Is the manager allowing or even encouraging employees to break that rule? Is upper management looking the other way as long as sales are good? When the system fails at the people level, finding root causes can be next to impossible.
But it’s very easy to identify the problem when software that’s supposed to enforce rules fails to work. Whether it’s a bug, a bad configuration or a bit of sloppy design, it’s right in the software—undeniable and completely reproducible.
That’s despite the fact that employees can always work around software, one way or another.
It also explains why DEA investigators zeroed in on CVS’ software to look for evidence of negligence or wrongdoing and why prosecutors specifically called out the poorly configured software when they announced the record-breaking fine. IT systems are easy targets in an investigation.
Yes, CVS’ IT people should have configured the software correctly. They should have monitored it to verify that the output made sense. Doing that right would at least have provided a little more legal cover for the chain.
But in the end, at CVS it was IT versus employees. And that was one battle IT was bound to lose.
-Marc
October 21st, 2010 at 12:45 pm
That the CVS MethCheck software didn’t prevent all those illegal purchases is unfortunate and a bit of bad application design. That those at CVS responsible for replenishing those drugs at rates so significantly higher than the sell-thru’s at the remaining stores in their chain probably requires some comment. Application errors happen, unfortunately, but there was undoubtedly a variety of reports and other metrics available to the replenishment teams that were overlooked or, worse case, ignored. It’s difficult to believe that those associates did not know that they were replenishing a controlled substance.
October 21st, 2010 at 2:44 pm
Scapegoating IT folks is both wrong and misplaced. Also, the so-called software fix that CVS/MethCheck were forced into making was rendered useless in a matter of months by group smurfing and false ID smurfing of retail pseudoephedrine.
October 22nd, 2010 at 9:18 am
Rob,
Blaming IT is safe and easy. Nobody understands us anyway, and our face is that of a glass panel on a terminal.
October 22nd, 2010 at 9:25 am
Editor’s Note: There has been this undercurrent that the story was inappropriately blaming IT for this incident. As for blaming, the story did not say that it was some reckless act. It merely pointed out that the system was overly easy for rank-and-file employees to override. And given the fact that the incidents plummeted so quickly and so substantially when the software was tweaked certainly tends to substantiate the suggestion that the initial settings should have been different.
But that’s a far cry from saying that it was some reckless or evil act. It’s merely a heads up to some of the potential impact of how these settings are selected.
November 14th, 2010 at 7:55 pm
Re: Editor’s Note — Why is this regarded as an IT issue at all? The business unit / owner of whatever project implemented this requirement should be held accountable — they either didn’t supply the correct specifications or they did not test it properly before accepting it for production implementation.
Or are you expecting IT to catch all the blunders business units make in their specification or testing? Are you expecting IT to know the business requirements better than the business unit managers?