Some years ago, I witnessed a terribly botched software selection and implementation process that couldn't have affected me more directly. The whole affair taught me a lesson about the dire necessity of making informed, thoroughly researched purchasing decisions when it comes to enterprise software. Since I had to use that software every day to do my job in our orders and customer service department, I suffered due to someone else's lack of due diligence.
I was working for a now-defunct textbook sales company at the time. The company needed to select a new vendor to provide software to update its textbook ordering system. The old system was very old indeed-think AS/400 green-screen and you get my drift in terms of its antiquation.
Real Questions for BI Vendors
Click through to see the questions Ann discovered that can make a tangible difference in your diligence.
To make a long, maddening story much shorter, the company picked the wrong software. Rather than opting for a system that, say, was already suited for handling book-related information and product inventory, the powers-that-were chose a system designed for managing supermarket inventories.
As you can probably guess, this system didn't work as we needed it to from the moment the switch was flipped and the old system was put out to pasture (it was ugly and "dumb," but it worked, we'd lament later). It had far more features than we needed and was both confusing and unwieldy. Stripping out functionality meant that modules broke, and taking customer orders frequently ground to a halt as the vendor's support team patched software that seemed to have more bugs than a Times Square movie theater.
Eventually, the out-of-state vendor placed a team of programmers on-site. If I recall, those triage coders spent at least 3 months providing on-call service. I can only imagine how expensive that was. By the time they left, we had something that worked, but not very well. It looked better than our previous system, but I doubt it performed much better. Productivity suffered, as did employee morale.
How did such a crucial decision, one at the very core of the business, be made so poorly? No one asked me for my opinion, before or after the debacle, but I'd say that the software evaluation process was deeply flawed. I have no insight into how it transpired, but, given the business culture at the time, I always wondered if someone in the company said it looked flashier and more modern than the old system, another proposed some lunch and rounds of golf, hands were shaken and a grand failure was born.
Since my job taking customer orders was so negatively impacted by the selection, I wish I could go back in time and surreptitiously slip one of the decision makers a copy of the Software Evaluation Policy available in IT Downloads. Created by the San Francisco Committee on Information Technology, this sample policy can guide the process of crafting an evaluation policy to better meet organizational needs, while encouraging consideration of open source options and emphasizing the importance of understanding the TCO for a particular software solution.
Sadly, while I can't undo the occupational trauma inflicted by someone else's bad choice years ago, I hope that steering others to this resource can help prevent others from going through what we did.