You studied the reviews, then selected the “best” all-in-one ERP system.
What possibly went wrong now that you realize that this is not working for you?
The explanation comes easy. You spent years developing a set of “best practices” that gave your organization a competitive advantage but you lost most of that by adopting someone else’s workflows, and forms.
What were the options?
None, actually, until recently, because the only other practical option would have been to go for a “best-of-breed” solution where your IT or an outside consultant would have had to integrate the modules and hope for the best.
Your third option would have been to build an ERP software system of your own which is somewhat like trying to build the next generation Ferrari in your garage. Bill Gates did it, Steve Jobs did it, why not you?
There now is a 4th option.
It’s still called “best-of-breed” with one small change called a Generic Data Exchanger that allows individual modules to talk to each other bi-directionally. The idea is you pick your modules, some of which you may already have and the only “customization” required is formatting of data going out of these and parsing of data coming into these.
A generic data exchanger allows each module participating in a “best-of-breed” configuration to export its data and import data using native data element naming conventions with the data in whatever format each module is able to work with.
What this means is that with one module acting as a publisher pushing out a data object we will call “abc”, a 2nd module acting as a subscriber can call this data object “def”, and a third can call it “ghi”.
If the subscriber who receives “abc” as “def” needs, for some reason, to enrich this data object and take on the role of publisher of “def”, the other two will be able to read it as “abc” and “ghi”.
The data exchanger does three things
1) It accommodates the mapping, once, then
2) It allows selective broadcast of data – if the publisher of “abc” does not want the 1st subscriber in our example to receive this data object, we simply show “ “ in lieu of “def” and “abc” goes only to the subscriber who likes to receive “abc” as “ghi”. Finally,
3) It allows each subscriber to published data to pick up the data according to a preferred frequency (i.e. every minute, every hour, twice a day, etc).
The issue of formatters, parsers and data transport needs to be addressed.
The traditional approach has been to acquire a specification and then proceed to write code to format or parse. Do this and in many cases the data you need to ship/receive ends up using 10% of what is in the specification.
Today, with code that is capable of writing code, you can build a “sniffer” that builds a formatter or parser by “reading” a data file. In many cases, this greatly reduces the effort relative to coding from specifications.
So, you have, today, some pretty interesting options to all-in-one ERP systems.
If you are not happy with your current ERP, you should take another look at “best of breed” solutions. Don’t worry about data conversion. If your ERP is able to export its data in some reasonable format, it’s not a big deal to format that data and fan it out to different modules in a “best of breed” set of modules.
Think about how nice it would be to regain your competitive advantage.
The bottom line here is get your software working for you.
The option where you work for someone else’s software simply reinforces the notion that “one size fits none”.
If you want more information on the relative merits of “best of breed” versus “all in one” call me, Karl Walter Keirstead, at 1 450 458 5601.