ERP case study: user adoption and implementation

There is no doubt that implementing an enterprise-scale ERP platform is a complex endeavor. However, while rolling out the technology itself can be problematic, ensuring that organizational managers provide proper levels of commitment and share appropriate project details with those in their command for user adoption, tends to present a few more difficult challenges.

Some years ago I was engaged by a mid-sized public company in order to design, develop and implement an enterprise-scale resources system to drive its global hospitality business. At the time (the late-90s) SAP was the only truly integrated ERP platform in the sector, however, budget constraints applied; so instead, I decided to leverage Oracle as a SQL-common datastore, then tap off-the-shelf ‘Oracle-integratable’ modules provided by third-parties, to flesh out the company’s purpose-built ERP needs.

The final requirements, demos, and selection evolutions were resolved accordingly, the company’s COO and CFO accepted my final recommendations, and we consequently started sending out checks.  In the meantime, I was busy selecting and engaging a proper third-party consulting team to handle necessary core and middleware code work; defining and establishing training programs; and developing specialized report indexes since the company operated in the EU and Asia-Pacific regions, as well as working domestically. 

The consulting team was also periodically aided by a small ‘go-team’ made up of internal resources within the company’s IT Department; although a central goal of the effort was to allow the internal IT folks to keep the lights on, while the consulting people framed out and mounted the new platform in parallel with the company’s daily needs. At the end of the day, this group of human resources formed our ERP committee, reporting to me, and up the chain the COO.

Check out our step-by-step implementation methodology for success on your next ERP project

At that point, on paper, and within the evolving operational infrastructure at least, we appeared to be in pretty good shape, and the hybridized ERP effort looked like this at a general module-by-module basis

• GAAP Accounting; housing GL, AR, AP, Payroll, Inventory.
• Multi-location Finance, Cost Accounting, and Consolidation
• Multi-location Sales
• Universal Reporting
• Universal Production Control and Scheduling
• Universal Test/QA
• Universal Training and Affiliated Educational Programming
• Universal HR
• Universal Support Tracking
• Tailored Scripting as necessary
• And all elements are embedded and integrated within a core Oracle RDBMS 

As we began to develop active data channels between each module/location, we’d do daily work-in-progress tests to ensure that we were going in the right direction, and the work was beginning to pay off in terms of speed, accuracy, and on-schedule production validation. However, there was an issue that I missed entirely, that ultimately created ripples that would come back to haunt the project down the road.

The company’s organizational chart was set up as a classic business pyramid with the CEO at the top of the triangle, the COO and CFO (no CIO yet) at the next level in the funnel, and at Tier 3 two Enterprise VPs were involved; with each of these VPs being responsible for a particular operational region. In the US, the COO handled the company on a daily basis, while VP1 was located in London, and VP2 was located in Hong Kong. Below these senior managers, subordinate directors, and line managers applied. 

When I did the final omnibus requirement, each offshore VP location was polled for their particular localized needs, then I kept them in an evolving loop as a matter of weekly status. However, what I didn’t do, was spend enough time with each VP ensuring that their subordinates were going to get the same level of information.

Also, about two months prior to the spin-up date, we did an enterprise-wide data load test and all the lights blinked, the buzzers buzzed accordingly, and the core datastore operated as expected. In my mind, then, we were nearly ready to go, other than the completion of various customizations, tying up obvious loose ends, and finishing some report trimming. Then, we began to hit the wall.

Two or three days after the load test I got an email from the Sales Director in Hong Kong asking a series of detailed questions about how the new system was going to deal with booked versus WIP transactions. Since the actual spin-up was going to occur in the middle of the company’s fiscal year, he was concerned about the potential of lost revenue due to data cutover inaccuracies. 

I responded to his concerns and we resolved the issue accordingly. However, later that day one of the bookkeepers in London sent a set of accounting questions, and shortly afterward another group of questions arrived from London HR requesting more detail on the new system; how it worked; and how employee data was going to be secured etc.

At that point, it occurred to me that Murphy’s Law Of Management had emerged since we were facing a serious lack of knowledge problem, not a technical one. After spending the next two days canvassing senior management, it ended up that the core issue represented a classic; someone didn’t get the memo downstream problem.

Clearly, I had tried to be particularly sensitive to needs and queries relating to the company’s senior management tiers when I set the requirements evolution up, but I forgot that systems and seniors don’t run things; line managers do. So, while spending a lot of time talking to folks at the top of the pyramid was a fine thing to do I had, in turn, assumed that the big offshore dogs would pass necessary questions down to the people who were actually ‘going to do the work’, and they hadn’t.

Obviously, this was a problem, particularly since the company’s entire workforce training constellation had to be revised, simply because I ‘assumed’ that line managers would already be updated properly. At the end of the day, the issue caused a schedule ripple that cost the project three months of slip time, and nearly $250,000 in consulting fees; for which I was brow-beaten accordingly.

So, from a project management perspective, the moral of the cautionary tale becomes simple; signing in every day is one thing, but signing on means you keep digging out details until a job is done; and not before.