Slashdot Mirror
Ask Slashdot: When Is It Better To Modify the ERP vs. Interfacing It?
New submitter yeshuawatso writes I work for one of the largest HVAC manufacturers in the world. We've currently spent millions of dollars investing in an ERP system from Oracle (via a third-party implementor and distributor) that handles most of our global operations, but it's been a great ordeal getting the thing to work for us across SBUs and even departments without having to constantly go back to the third-party, whom have their hands out asking for more money. What we've also discovered is that the ERP system is being used for inputting and retrieving data but not for managing the data. Managing the data is being handled by systems of spreadsheets and access databases wrought with macros to turn them into functional applications. I'm asking you wise and experienced readers on your take if it's a better idea to continue to hire our third-party to convert these applications into the ERP system or hire internal developers to convert these applications to more scalable and practical applications that interface with the ERP (via API of choice)? We have a ton of spare capacity in data centers that formerly housed mainframes and local servers that now mostly run local Exchange and domain servers. We've consolidated these data centers into our co-location in Atlanta but the old data centers are still running, just empty. We definitely have the space to run commodity servers for an OpenStack, Eucalyptus, or some other private/hybrid cloud solution, but would this be counter productive to the goal of standardizing processes. Our CIO wants to dump everything into the ERP (creating a single point of failure to me) but our accountants are having a tough time chewing the additional costs of re-doing every departmental application. What are your experiences with such implementations?
That said, it's not always practical to in-house everything, so a balance needs to be struck - keep the design and some worker bees in-house and then leverage vendors/contractors to spin up extra bodies for build cycles.
Regarding your single point of failure concern - while valid, a properly designed ERP system with redundancies and load balancing should alleviate the core of that problem. Again, balance needs to be struck, while you want a single place to do all of your ERP functions, it doesn't always make sense to have them in one application that has to be customized to within an inch of it's life in order to do everything it needs to do. This needs to be addressed in the design phase to create logical business units that can sit on separate applications that, ex, communicate with the proverbial mothership via an API
there is your answer. ditch it. quick..
---- Booth was a patriot ----
Because articles aren't just for those who can answer them. The rest of us are curious and want to learn new things, but when one keeps the subject shrouded in esoteric jargon (to this crowd mostly) that makes it hard to do.
http://www.rootstrikers.org/
Because, and this is important, jargon familiarity isn't always equivalent to available insight. It's what popular culture uses as fictional markers for insight, but the reality is that not only is expertise a continuum, but it often involves ideas from multiple realms of knowledge.