The VP catches up to you and says, “The Strategic Planning Meeting was today and it was agreed we need new ERP Software – so you guys in IT get right on that – and can you have it done by Q2?”
Wow! That’s quite the project. Quite the responsibility. And can quickly become quite the nightmare. (We’ll address why you aren’t in the Strategic Planning Meetings in the first place in another column.)
As a Software Selection Consulting group, getting involved with an ERP selection project run solely by IT is a huge red flag for us. The only thing worse is the ERP project headed up solely by the accounting department - or a newly minted PMP certified Project Manager.
ERP – Enterprise Resource Planning really involves the entire enterprise. Trying to get user adoption when you’ve selected and installed ERP to meet requirements of the marketing team works fine until you get to the warehouse and realize their workload triples under the new system design.
In reality, industry averages show an 80% failure rate for ERP when measured by cost overrun, feature expectation or time to go-live. And many of those failures can directly trace back to differing goals, incentives and expectations of the various users.
So, how do you, the IT Manager, actually manage such a bear of a project?
Here’s a few Tips from ProfitFromERP, a group with experience in over 400 ERP projects ranging from small to regional companies, and even the occasional global and international projects.
ERP can have big payoffs but to be really successful it has to be a team effort.
There’s two teams of people you’ll be dealing with, volunteers and draftees. Your volunteers are excited about the project, those draftees need to be enlisted regardless if they’re wanting to play along – and more often than not, you’re trying to draft a CEO or CFO. The thought of ‘let the people who will be using the software pick the software’ is actually half right. Because ERP is two simultaneous projects, there’s a software project, there’s also a business consulting project.
Without the C-Suite providing executive input, that business consulting project is simply floating along, left to it’s own devices – and how many things in business ‘just work themselves out’? ERP isn’t one of them.
While the users in any department are the ‘experts’ at how things are currently done within their own department, there’s Williamson's First Law*, Everything looks simple if you don’t know the first thing about it – but he generally use a different f-word.
We were working with one Pharmaceutical manufacturer several years ago and had a morning meeting with the Supply Chain Manager, the Finance team was in the afternoon. We actually heard the Supply Chain Manager berate the Finance department for trying to save 8 cents a unit by foreign sourcing of a packaging vial without understanding customs costs or fees associated with importing. And in the afternoon, Finance criticized the Supply Chain manager for not knowing accounting terminology and ‘how she can run that department without knowing what FGI is, is beyond me’. In hundreds of accounting software projects, I’d never come across the term FGI either, so I suppose I’ll stay out of running Supply Chain departments just to be safe.
The point is, when you’re involving everyone in Enterprise software, you need to involve everyone from the beginning – and what one department thinks they know about another department can be very shortsighted.
But back to involving everyone. If they’re not on board from the beginning, find out what peaks their interest.
Yes, the higher ups are busy – but they’re also very focused on their areas of responsibility. The CFO may be too busy to look at journal entry screens, but she’s all ears when you tell her you’ve finalized the Requirements for the new AR workflow and she’ll make time to meet with you to cover those areas. The objective is to draft her involvement in future system design meetings and clarify/quantify project goals.
In a mid-sized company, you’ll end up with 75 – 150 Requirements – and working with your C-level leadership team, you should be able to make decisions like, Requirement 28 for centralized purchasing will cut costs by X while Requirement 63 auto batch reversal is nice to have a couple of times a year. Prioritizing your Requirements allows you to focus on evaluating which ERP solves your major issues best – and relegates those ‘nice to have’ issues to the right level of attention.
Fortunately for IT Departments – your daily work involves every department so use that access for full effect. CC higher ups with emails detailing proposed system architecture and when the final review meeting is to be held. You’ll be surprised who shows up.
Classically, you’ll want an Executive Steering Committee as your highest level of involvement – mostly in overall decisions. Your ERP Committee should have representatives from every department that will use a module in the new system – they may not all be in every meeting – but they’ll all be represented. Your User Group Committee should represent the staff doing the day to day entry into the new system.
And remember, you don’t own the actual project, you own the facilitator role. The new software doesn’t do anything – but your users can use the new software tool to accomplish much. Make sure they’re on the same page.
For more tips and methodologies used by the leading ERP implementation teams, www.ProfitFromERP.com offers podcasts, success stories, guidelines and white papers on how to select ERP and make it pay.
*This is generally referred to as Williamson’s First Law, from an article
by Kevin D. Williamson on National Review – regardless of your political stand, you have to admit it makes a great deal of sense.
