During my time at Epicor Perspectives I have run into plenty of engineers wrestling with implementing Epicor 9. Last year, Epicor was very careful to set expectations for those thinking of migrating from a different product or running the upgrade. The message was loud and clear: plan, involve us, it's not easy. I liked that as a warning message but I'm not sure many heard it. Net net, customers I bumped into this year consistently said that while they are leery about talking ROI, on the one hand it has been a tough road, on the other they think there will be as yet undefined benefit.
This is not unusual. All project managers want to believe their projects will be a success but in their heart of hearts they know that upgrades, and especially technical upgrades in bespoke environments, will be painful. It was therefore refreshing to spend time with Al Sussman, CIO Apogee. His Epicor 9.0.5 project has just gone live with progressive roll out to five operating units within that group. He counts the project a success. I wanted to address two broad themes: selection and implementation.
Background: Apogee is a publicly traded $1 billion group in good years. This year it will hit $650 million, largely as it is impacted by recession in the construction industry where it has its greatest exposure. Al has been on all sides of the buy/sell side table having spent time with Accenture and with a variety of mid-sized companies, implementing anything from Baan and PeopleSoft to bespoke and vertical market specific solutions. At the time Apogee made the decision to buy Epicor, it was operating a mish-mash of old solutions. There was a need to standardise. Epicor won against Oracle. He cites four reasons:
Al said that by the time he arrived, the group had made the decision to buy Epicor but even so he still gets emails from the board asking whether the company made the right decision.
What keeps Epicor attractive?
What does the project team look like?
Apogee has a culture of learning. This is actively fostered by the CEO, an ex-Vietnam fighter pilot instructor. Of itself you might think this is only a colorful aside but there is a reason why I mention this. A startup in which I had an investment is led by an ex-jet jock. It turns out that to be successful in that role you have to be unflappable yet wholly self aware. That in turn allows you to create a culture where voices have greater chance of being viewed equally and where failure is allowed, provided you are honest about what happened and are not a persistent offender.
Most of the Apogee project team have been with the company many years. "Some of the team have been with us for 10 years and more. You don't get that unless there is a commitment to success."
From the get go, Apogee insisted on a named sponsor from inside Epicor. "Shared responsibility has to involve the vendor, otherwise you get tangled up in all sorts of disputes about where issues lay. The best way is to have a representative from the vendor who is with you all the way."
Did the project make it in on time and to budget?
A frequent measure of success is whether a project meets the two criteria of cost and timeliness. At this point Al smiled. "Have the people who use this measure ever implemented a project? Projects of this size and greater are inherently complex. It doesn't matter how much you plan you cannot possibly understand the whole scope of the project going in. Therefore, while you may have a good idea what will happen based on many experiential factors, it is almost impossible to to eliminate or predict unknowns. Now, you can mitigate the risks but in any budget planning you've got to have a contingency." That didn't quite answer the question but provided a pragmatic insight into why projects need to be flexible in scope and budget.
To the direct point, Al says that Apogee got what it wanted but in part that was because it made a point of ensuring that Epicor understood its technical requirements. "There was a shared learning where we explained the what and why of how we wanted to architect the physical and virtual components inside the data center."
He also says that as the project proceeded, the company followed a rigorous policy of reviewing learnings. "Learnings are documented and become input to the next implementation," he said.
Is Apogee's experience unique? No. But the elements that stick out are: experience, learning and shared responsibility. The fact Apogee was able to assemble a team that shared each of those attributes contributed significantly to the success. It lends credence to the idea that subject to the software being a disastrous mismatch, it is not the technology that really matters. It is the culture, expertise of similar scale projects and a willingness to learn that make the difference between success and failure.
Apogee's example points to the characteristics that you will find in a mid-sized company that can afford to use internal resources while being able to introduce vendor assistance. Al says these styles of project cannot readily support external consultants but even then, he would want to be very sure about what they have to offer in terms of project experience. Having consultants dropped in once a month to perform adult supervisory tasks is not usually warranted.
The impression I got was that when Epicor released 9.0, they did not anticipate the kind of shared service hub that Apogee envisaged. This is a highly cost effective way of maintaining the balance between common components and unique requirements. It means for example that in reporting, operating units can use a common chart of accounts so that account name parsing is eliminated and consolidations are relatively easy. Those are big wins at the business end. Apogee's ability to engage Epicor to make changes clearly contributed to a project that would otherwise have been implemented in a sub optimal manner.
We debated whether the Oracle's and SAP's of this world are able to offer this level of service for mid-range customer. My view is that they should be able to do so. I know for example that in some projects, SAP will parachute engineers into a failing situation because they have the deepest solution knowledge. That in itself lends weight to the argument that vendor representation is useful across multiple dimensions.
The most important learning though is that despite many years of implementing the same software, each project will have unique elements that may, or may not, be planned. Therefore, while you can mitigate risk through the identification of common elements, there is always the need to learn.
In this case, the vendor was also able to take on some learnings. It means that Epicor should now be in a position to start thinking seriously about moving up the food chain. Whether it will take that bold step is another matter. On Apogee's criteria, it can win and on my assessment of capability and vision, it is an attractive alternative to better known names. As Al pointed out, Epicor has been in a certain slice of the mid-range for many years and adjusting your sales and engineering teams to think differently about the larger deployment is both a practical and marketing budget challenge.
On this second point, Epicor needs to do more because in a market where the usual suspects will always play, having a name that is not only highly referencable but recognised is critical to getting on shortlists.