People get passionate about almost anything, including the best-of-breed versus single-source ERP argument.
One of the criticisms you frequently hear about best-of-breed ERP architecture runs something like this: “We want our solution to come from a single source because best of breed is an integration nightmare.” The point being that single-source ERP solutions are created by a single entity. Thus, they are tightly wired together to assure complete harmony and unity between the assorted functional parts of the ERP system.
On the other hand, best of breed is a disparate group of applications that’s designed to stand alone.
Further, the critics will run on about best of breed requiring separate databases, separate data entry and other services. End-users will have to learn a vast new collection of apps, tools and other things to get their jobs done.
Finally, the critic will deliver the triumphant final blow. Best of breed means vendors pointing at each other over every system problem, hiccup and support issue.
It paints a bleak scenario right? Who would want to jump into that briar patch?
Let’s take a deeper look at some of these points.
Myth: Unified applications are easier to implement.
This is almost laughable when you really think about it. ERP is not sausage; all of the ingredients are not chopped up and extruded into a tidy little tube. ERP is all about parts—separate parts and individual parts serving individual chunks of the enterprise. Each part is specialized and should be built to conform to the unique needs of the functional unit. If the goal is conformity, then the code is going to suffer and the functionality is going to be less robust.
How can a purchasing module possibly be written “in unity” with a shop-floor-control module? The tribal knowledge, regulatory requirements, skill sets and KPIs involved have almost nothing to do with one another.
Obviously, the two functions require two separate applications. Do they need to connect? Do they need to be “aware” of each other? Of course they do, we’ll talk about that a bit later.
Myth: Best of breed causes separate support and service requirements.
Again this is hooey. Any ERP system vendor you deal with should be providing first-line support for the entire suite of functionality covered on the license. As support cases are filed, vendors will direct them to whatever support specialty might be required to address the issue at hand.
I’ve spent a considerable amount of my career supporting a small piece of a larger solution. I know the frustration end-users feel when something isn’t working the way they feel it should. Their priority is getting to the right support source as quickly as possible.
This is how quality support organizations work. They get users communicating with the right support asset as quickly and as directly as possible. This has less to do with the employer of the support provider than it does the quality of the problem-resolution infrastructure maintained by the vendor.
In other words, do your due diligence during the ERP vendor selection process. Check out your vendor in terms of application support.
Reality: It’s about integration and user experience.
The key to effective ERP and successful ERP implementations is based on the functional integration of the system and the user experience associated with the system. These two factors are what make it go or fall over.
Integration is key. I don’t care if you are best of breed or single source, integration is still critical. No company installs ERP without connecting the vendor code to something.
Does your ERP sit by itself, isolated from all of your other systems? Of course not. You have third-party and perhaps homegrown applications installed all over the place. Your ERP system is almost certainly connecting to, feeding, extracting or otherwise pushing data in and out of multiple systems. This requires integration.
Think you’ve got a single-source ERP system installed? Don’t be so sure. Check out the history of your ERP vendor. Have they ever acquired other companies? Have they merged with another company or been acquired by another company? Who are their partners? Are they embedding third-party code?
Why do you suppose that would happen? The reason is, someone in one company sees functional expertise they need in their ERP application over in another ERP company. They can buy the functionality by buying that company, they can license and embed the functionality in their solution, or perhaps the other company buys them to achieve the same envisioned synergy accomplished through merging the two entities together. Regardless, you end up with an integrated solution.
That’s not a bad thing. You want a vendor that knows how to get integration done. You want a vendor that knows how to build something from multiple, disparate parts that achieve greater functionality than the two parts ever did separately.
The User Experience
This is where it’s at for your end-users. They really don’t care what’s under the hood; they want to know how the system makes their lives easier.
The tight integration among assorted functional units of the newly purchased ERP system and other in-house systems is a non-negotiable requirement. But, for the end-users, this is all assumed to be in place. How does the system affect end-users’ lives? The user experience should provide the precise, complete and timely array of information and execution tools end-users need to do their jobs while minimizing what they have to learn, accelerating training time and making them productive as quickly as possible.
The screens they use for their jobs, the information they access and the execution tools they are equipped with should be tailored to the role end-users have within the enterprise.
The message here is simple. Virtually all ERP systems require integration. Effective integration is the issue—not single-source versus multiple-source ERP. Success or failure will depend on how effective your integration is and how well your end-users like their experience with the software.