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?

Blend It

[TheNinjaroach]

We use an Oracle-owned (bought) ERP as well. We had pretty fantastic success during ERP upgrades with the external systems that used the API - which remains remarkably consistent across versions. I find it to be cheaper, quicker and more robust to build and maintain tools around the ERP than within it.

In any case, that business data absolutely belongs in the ERP, all I'm talking about here is the manner in which the data gets there.

Re:Keep ERP system customization to a minimum

[King_TJ]

I'm inclined to agree!

I worked for one place that tried to roll out a big ERP system and even though it was done in multiple stages, just the "stage 1" portion was an incredibly costly undertaking that enlightened the in-house I.T. staff as to just what a bloated kludge the software really was.

I remember we encountered certain system errors trying to run reports which stumped the support people for the software.... What finally got it fixed was my boss devoting an afternoon to looking at it himself. He was pretty savvy with Oracle databases and rewrote some buggy queries in the code, correcting it.

All of the money charged for maintenance and support and licensing for these systems is NOT necessarily equivalent to receiving a superior level of actual assistance with the software. So IMO, just spend your money more wisely on in-house developers.

consider an open source ERP

[dominux]

You can throw good money after bad, and you probably will.
If you want to have an alternative, you could do worse than look at Oodo (formerly OpenERP) it is a python based, AGPL licensed ERP package that is modular with a sensible API that is growing an even more sensible API. It is not without it's problems, I wouldn't sugar coat it, but if it is broken, you own all the pieces (http://odoo.com source at https://github.com/odoo/odoo [github.com]) and that is priceless.
Depending on your specific requirements it might work great, or might be a bigger pain in the ass than your proprietary mess. Like I say, you will almost certainly take the path of throwing good money after bad, but for anyone else at the front end of a decision, the business value of Free Software is huge.

Re:Major application vendor headaches...

[Zeek40]

I couldn't agree more. I've been working on an Oracle based JMS-SOA system for the past year. I've opened over 30 SR's in that time that have lead to over 20 bugs being filed. The development team has told us that they won't be able to fix some of the show-stopper bugs we've discovered until next December (as a year and a half from now). I have weekly meetings with Oracle product managers where they give me the same song and dance about how hard they are working to fix our issues despite never getting any closer to providing us with a functional product. We've spent millions of dollars on licensing fees and hundreds of thousands on consultants. Four out of five of the Oracle consultants we've hired have been completely useless. I'm talking useless to the point where they were just sitting next to me and searching Google for answers to the problem we brought them in to solve. Never hire Oracle consultants for anything more complicated than installing a database. We have ~15 very competent engineers on this team and we've finally gotten upper management's approval to begin a working on a proposal to move away from oracle products to open source or in-house solutions after six months of completely useless support and schedule slips caused by Oracle software not working as advertised.