Oracle ERP software implementation tips and trends
A comprehensive collection of articles, videos and more, hand-picked by our editors
The most important step in planning an ERP project is deciding what users want from the system, according to Panorama...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Consulting Solutions experts who shared tips on ERP requirements planning and vendor selection at a user conference put on recently by the Colorado-based consultancy.
"If you define requirements well, and you can have a solid set, everything else flows easily from that," said January Paulk, Panorama's senior manager for business process and organizational change management. "Your vendor searches flow from that [and] when you get into implementation, your future state flows from that, your test scripts flow from that," she said. "It's really the foundation of everything."
But before establishing ERP requirements, it's important to lay some groundwork. One step Panorama helps clients with is an organizational readiness assessment conducted through surveys and focus groups.
"It really gives you an idea of where some of the pockets of resistance are in your organization," Paulk said. Functional areas that are more resistant than others can provide clues on how to tailor the requirements session.
Panorama likes to send out workshop guides so people know what to expect from the ERP requirements sessions, which Paulk said should last three to four hours and focus on priority areas. She suggested bringing in subject-matter experts to express their ERP pain points so that requirements can be written accordingly.
Geoff McPherson, Panorama's manager of client services, advised documenting every business issue that comes up in the sessions, even seemingly small ones such as dollar limits that trigger manager sign-offs. Doing so at this early stage can avoid problems later. McPherson said that he often sees companies spending 40% of their implementation time resolving conflicts between departments.
Besides keeping careful documentation, Paulk recommended setting up an iterative process for gathering ERP requirements that includes review sessions with everybody involved.
Categorize the requirements into three groups: mandatory, value-add and nice to have. Paulk said this categorization can help phase the implementation so that, for example, all the mandatory requirements are done first so the company can continue operating like it does, with the second phase introducing value-add items for optimizing processes.
"If you try and do everything too fast -- if you try and put all the optimization in, people are still learning the system [and] they're not even going to get there," Paulk said. "And then you don't ever realize those benefits."
When it handles this work for clients, Paulk said, Panorama goes step by step taking into account tasks that are executed both inside and outside of the ERP system, along with who does each one and what percent of their time is devoted to them. Pain points, such as poor visibility into key data, are often uncovered at this stage and go right on the ERP requirements list.
Once the requirements have been gathered and prioritized, the project team is ready to send out a request for information (RFI). Paulk recommended sending the RFI to six to eight vendors and focusing on the top 10% of requirements that are unique to the company -- for example, global tax support at a multinational company -- and not those related to the ability to automate workflows or provide visibility into certain data sources, which tend to be widely available across brands.
ERP vendor selection
After the RFIs come back from the vendors, it's time to boil them down to a shortlist of two or three vendors, send them requests for proposals (RFPs) with a four-week deadline, and bring in the ones who respond for demos. Paulk advised first looking at the financial viability of each vendor, especially the likelihood of their being acquired and how much research and development they devote to the must-have and value-add requirements on the list.
Then make "discovery" calls to each one, giving them a chance to ask questions about what's expected in the demos and perhaps inviting them to a site tour.
McPherson said this is the stage where gamesmanship can creep in. Some vendors will push back against the four-week deadline, perhaps with creative excuses, and everyone will jockey for the last time slot.
The demos themselves have an art and science all their own. Paulk said to invite the subject-matter experts who came to the requirements sessions so they can see how their work was translated and feel they still have a voice in the selection. Be willing to devote an entire day, sometimes two, for each vendor's demo, though only the core project team needs to be there the whole time. Others can just come for the parts that involve their department.
She advised providing demo training beforehand so employees have clear expectations and instructions not to give any clues about how they feel about the software.
"The vendors are there and they're going to pick up on it, and it just limits your ability to negotiate with them later on," Paulk said.
More on ERP project planning
Develop an ERP project plan
Secure senior management buy-in
Prepare an ERP project budget
The demos should involve business processes from the requirements list, based on scripts provided to the vendors -- and be light on bells and whistles. Working from scripts also makes it possible to check the honesty of a vendor's earlier claims.
Demos can also reveal if there's a cultural fit, according to McPherson. To him, setting up a good demo means asking vendors to do it on the company's actual data and providing them with real scenarios.
"When you have these demo scripts exactly how you want it, and [the vendors] turn up and do the bells and whistles, you know they're not listening to you on Day 1. There are some times when they've done this that we've had to send the vendor home."
Panorama also advises clients to have a method for participants to anonymously score the demos, typically on a 0 to 5 scale, then analyze the results. Another tip: Share the scores with the vendors.
By this stage, it's time to check customer references of the remaining contenders, focusing on companies in the same industry or the local area. Go on-site if possible, Paulk said, and ask what hiccups the users experienced.
This is also the time when some companies make the mistake of choosing the vendor and then going silent for several months before the implementation. Panorama suggests using that time to plan the project further and get end users involved, sharing some data and processes with them and working to break down departmental silos.
But the selection process doesn't stop there, McPherson said.
"Once you have the software selected, you want to make sure that whoever you choose to implement the software is a cultural fit with you. We recommend going through a similar process -- sending out an RFP to specific integrators, interviewing them, having them come in and talk about their methodology approach."