The question is actually surprisingly difficult, as perhaps becomes clear from this article. And of course, there’s also an easy and quick answer: contact us at Webbros, and we’ll help you move forward
Jumping on board with a single vendor and product certainly feels risky. The more typical approach is to first write down your requirements as a list, use that as a basis for filtering options, and then send out requests for proposals, just like the textbooks advice. After that, you simply select the ERP and vendor that best and most cost-effectively meets your needs. Simple!
There’s merit in this method—but also many pitfalls, which I’ll try to describe below.
From Ideation to Implementation
Sometimes needs are mapped out through a series of workshops or meetings, where either on your own—or with the help of a facilitating consultant—needs and ideas about future ways of working are listed. The system is then chosen to support that new way of working.
Read this article to find out what kinds of problems this approach may encounter and why the end result is often far from perfect. The outcome of ideation usually ends up being a requirements list full of unnecessary, conflicting, or biased needs, while still missing essential elements.
The Process-Driven Model
Another common approach is to use business processes—or rather, processes, plural—as the starting point. Instead of inventing needs from scratch, the company’s processes are mapped out in diagrams, and needs are derived from the requirements of those processes
There’s a lot of good in this method! Unnecessary requirements get weeded out, requirement specifications become consistent, and missing pieces are easier to spot since the process view ties things together nicely.
But there’s one catch! Processes are, in practice, product-specific: different ERP products have each developed their own unique ways of managing a given function.
Problems with Process Variations
The first problem arises in interpreting offers: they may use different terminology and refer to different processes than those described in the request for proposal. This can happen even if the vendor has understood the need correctly and has simply translated the requirements into the vocabulary of their own product. Of course, it could also be due to misunderstanding—or, in the absence of a match, the vendor might intentionally redirect attention elsewhere. It’s hard to tell!
The second problem is unnecessary (or incorrect) negative interpretations: a vendor may honestly state that the requested requirement cannot be fulfilled. However, the product might actually be capable of handling the desired function through a different method. If the requirement was rigidly locked down during the specification phase—just to have a clean and complete definition—some options may have been unnecessarily ruled out.
The third problem is the specification work with the selected vendor. The previous documentation created with the specification team likely won’t be usable for the implementation vendor because the processes and terminology won’t match the product. This means the process definition work must be started over from scratch. In addition to the cost, the time spent duplicating modeling work can be frustrating.
The Path of a Preliminary Product Selection
It’s also possible to choose a product in a more rough, preliminary way. Then, process documentation is done using that preliminary product as a reference, aligning the work with its processes. If the result of this study shows that the requirements can be fulfilled, the coordinating vendor proves to be cooperative and skilled, and a viable implementation offer is provided, then you have at least one very attractive and straightforward option.
If any of the above doesn’t work out, you’re still no worse off than with a generic specification—and may have even eliminated one unsuitable option from the list.
The Future Aspect
Regardless of how the needs are listed, they are typically limited by their static nature. At best, they are like a snapshot of the company’s current needs. If everything goes well, the ERP project helps the company grow and thrive. Which, of course, brings new challenges - this article outlines some examples.
If the ERP was selected strictly to match only the original requirements, with "no room for growth", it may no longer support the company’s new needs. That brings you back to square one—or, in the worst case, the company scrambles to acquire separate systems for each new need in the middle of a growth spurt. These systems often work great on their own, but integration problems arise: the company ends up entering the same products, customers, jobs, and other data into each system separately. Or, it must carry out complex and costly programming to make the systems talk to each other—an issue of its own. Or perhaps the data just isn’t fully in sync!
Looking back, one might wonder: should we have chosen an ERP from the beginning that included options for growth?
Webbros’ Approach
At Webbros, we favor a practical and straightforward approach. We can provide a fairly quick assessment of how much work an ERP project would be for your company. You can book a time for this kind of discussion below.
Book free appointment from my calendar
We do acknowledge that it is not always possible to achieve the goals with standard system. And we have ways to deal with that, as well. Read in this article what kind, and why Odoo is still the best choice!
