The WSJ ran a story yesterday about Arizona State University’s Oracle ERP implementation and the unique approach they’ve taken.
From the WSJ:
In order to avoid the cost overruns that are typical with projects like this, the university stuck to rigid deadlines, counting on the staff to adapt to the new software while the information-technology department worked out any technical glitches.
I’ve heard that the implementation was fast-tracked by necessity, but even so, Sannier has some serious mojo to attempt this. He compares ERP implementations to having your wisdom teeth removed. I would have said root canal, but either way, think of it as a really bad dental visit.
According to the WSJ, the ASU project schedule was a set-in-stone 18 months, whereas typically, implementations of comparable size take four years. Sannier cut out most of the testing time, saving the school millions. His budget was $70 million. He spent just over half that figure.
Oh yeah, and the project finished on time. Michael Krigsman, whose blog is titled “Rearranging the Deck Chairs: IT Project Failures”, knows a thing or two about disastrous ERP implementations. He calls the approach “bizarre”.
Sure the approach was bizarre, but next time, lead with “on time” and “under budget” instead, and you’ll get another adjective. Successful.
The focus of the coverage has been on the horror stories. I know people got paid the wrong amount, or not at all and had to take out loans. There were “glitches” because ERP implementations are complex.
Having been on many ERP implementations in my days in Oracle Consulting, I can tell you with 100% certainty that these glitches happen in every project. This is nothing out of the ordinary. It’s really difficult to tell how a complex system like ERP will run in production, even if you have an exact duplicate for testing. This isn’t just an Oracle problem either. SAP has it, PeopleSoft had it.
But, consider how much more egg is on your face if you’re over budget and late (in years, not months). The disgruntled users and check-writers will rightfully want to know why the system isn’t working right after pouring years and millions into it.
Krigsman is right. This is bizarre, but it’s mad scientist genius. Sannier was faced with a problem, and he attacked it with a risky solution. He engaged his users in a beta project, letting them know in advance not to expect a finished, glitch-free product. This is Web 2.0 all the way: the perpetual beta, engaging users, crowdsourcing. I love this approach.
Sannier would be a hero, if he hadn’t messed with people’s money, never a good idea. However, ASU went live in July, and already the payroll error rate is a third lower than it was with the old homegrown ERP system. So, ROI is on its way. And did I mention he saved the university millions?
I don’t know if Sannier is involved with everything at ASU, but they seem to get it, or at least Google has convinced them. They are a Google Apps customer, I think one of the first. They also use Google Search Appliance to power the university enterprise search. They are rumored to be working with Google on a virutal world based around Google Earth. Apparently, they get along well with Google.
From this vantage point, it looks like a great case study for how a big enterprise (61,000 students, 8,000 employees) handles change brought on by New Web.
Props to Sannier for getting how New Web principles can work in the enterprise and for his crazy mojo for taking the leap.