But the comments made by top brass from Hannaford (hit by a 4.2-million-card data breach) and Levi's (a troublesome ERP rollout suspended lots of shipments) have raised the question of where the responsibility line should be drawn. At what point is the software company responsible for doing what it has billed itself to do? And at what point is the CIO supposed to deliver, no matter what?
This is a question that isn't going away, especially as more companies move increasingly toward an overwhelmingly outsourced enterprise environment, with an ever-shrinking percentage of apps that are homegrown. Sometimes, security assessors strongly encourage retailers to avoid homegrown applications.
In the Levi's case, the problem was a massive ERP rollout, courtesy of SAP. During the implementation of SAP, Levi's encountered issues and subsequently "chose to temporarily suspend shipments to our customers in the United States, causing us to miss the customer-requested delivery dates that fell within this period," according to an April 8 company SEC filing.
"This disruption lead to delays in filling customer orders and customer order cancelations that accounted for a substantial portion of our Q2 net revenue decline in the region," said Robert Hanson, president of the Americas region for Levi's, in a conference call with reporters after the filing.
For Hannaford, the CIO at the time of this year's data breach detailed some of the reasons for the breach and pointed at PCI shortcomings and security holes in Microsoft software.
"We used a lot of Linux," said Bill Homa, who stepped down as Hannaford CIO earlier this month. "None of the breach was anything related to Linux. All of it was Microsoft."
Added Homa: "Microsoft is so full of holes. That's why it's still a target. If you limit your exposure to Microsoft, you're going to be in a more secure environment."
But in today's complex IT environments, where does—and should—that line of responsibility fall? On the "it must stay with the CIO" argument comes the reality that a software glitch today is just as likely to involve a conflict with a competing app or an OS hiccup as some internal problem to that application. On the "it may stay with the ISV" argument is the fact that as large ISVs such as Oracle—in addition to Microsoft and SAP—continue to expand their product lines and promise end-to-end robustness, they must stand behind their work.
Paula Rosenblum, managing partner for Retail Systems Management and a former CIO herself, takes a decidedly pro-ISV perspective.
"The days are long since gone when a company can get up with a straight face and say, 'I tried to do a major ERP implementation and it drove my business to its knees,'" Rosenblum said. "It just doesn't work that way. The industry has to have matured to a point where that excuse is no longer valid. There was a period in the 90s when it was really popular."
Rosenblum said it's expected that there will be bugs during a new ERP rollout, but she said "the art of managing a project and the art of implementing new systems isn't about getting it 100 percent right. It's about contingency planning. It's about planning for all the stuff that can go wrong."
The comments by Hannaford's Homa drew a larger than typical number of reader comments on the story, most of them also taking a decidedly pro-ISV (pro-Microsoft, in this case) position. Asked one anonymous reader: "He seems to be blaming (Microsoft) directly for the breach. I wonder if he ever signed a PO for an MS product during his tenure."
The missing factor here is what is reasonable to trust someone with and what isn't? Last year, quite a few major retailers got caught up in some Fair and Accurate Credit Transactions Act (FACTA) lawsuits because they were illegally issuing consumers credit card receipts complete with full credit card numbers and expiration dates.
Many of those retailers argued that it was reasonable to have expected POS software vendors to deliver products that were consistent with federal law. I'd agree. Are we really expecting CIOs of $20 billion chains to test and verify the credit card printing apparatus? In hindsight, that's reasonable, but at what point is it considered fiduciaryly (if it's not a word, it should be) responsible to trust an application from a major software house?
That said, when we take this up quite a few notches and are talking about enterprise-wide ERP deployments or a top-level E-Commerce platform or payroll software, that equation is quite different.
Some have argued that the responsibility of the CIO doesn't end with selecting the right vendors and having their products extensively tested. It also includes making the assumptions that most things will indeed fail—Murphy's IT law: the more strategically important the rollout, the better the chance it will fail—and to prepare backup plans.
That's a fair point. But there is a huge difference between reckless indifference and making a reasonable decision and implementing reasonable backups that happened to prove inadequate.
The question boards must ask: "Given what the CIO knew at the time, was the action (or inaction) reasonable, especially considering the finite budget we have granted that CIO?" Better yet, let's pose that question in the reverse: "If the CIO had spent $XX million dollars on an additional redundant (a Monday Morning Quarterback might say "unnecessary") system and the deployment went fine, would we have been justly angry with that CIO? Honestly?"
After a major IT disaster, it's easy to point the finger at a major ISV or industry guidelines, especially when there's good cause to do so. Is anyone going to argue that Microsoft's OS is truly secure? Or that PCI could stand a lot of improvement? Or that SAP ERP deployments aren't always trouble free?
But it's just as easy to point the finger at the CIO—after the fact—and say, "You should have anticipated this and avoided this problem."
But if both sides tried less blaming and more reasonable balance, it couldn't hurt.