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?

Major application vendor headaches...

[Z00L00K]

My experience is that by using large vendor systems like Oracle and SAP is just a good way to waste money without getting any benefits. Those systems are in general not very well designed, and the money paid is used for marketing, not application development.

"Always" is a strong word

[tepples]

Always fucking expand the first instance of your acronym in your summary. Always.

True, I agree that HVAC, ERP, and SBU should have been expanded. But some terms, such as "Hypertext Markup Language", "Motion Picture Experts Group", "Universal Serial Bus", "chief executive officer", "Federal Bureau of Investigation", "Systeme, Anwendungen und Produkte", and even "application programming interface" are probably more recognizable to Slashdot's audience in the abbreviated form.

move consideration to Enterprise open Source ERP

[wanderson]

This is a perfecr example case for considering an enterprise, professional world class Open Source ERP solution like OpenERP, ERP5 or Compierre which will not only allow "user" modifications and configurations to application functionality/ source code/ to suit purchaser's needs and requirements, but will generally work with far better with all other data formats and APIs, and is especially beneficial for evading all the proprietary vendor lock-in and incessant hands-out for more payments as article writer noted. If the company has fairly competent personnel in their technology support department, it would not be climbing Mt. everest to have them acquire programming knowledge and expertise from the FOSS applications developers, at considerably less costs that custom modifications. That is unless the company technologists are extricably tied, by perks,limited training and/or personal incentives to Oracle, Microsoft or other large proprietary software vendors whi derive much of their great profits from just such scenario as described in the article.

Erotic Role-Play

[hort_wort]

This is what the acronym means for many people who play online games. I just wanted you guys to know so you'll understand the giggles coming from the back of the room at every meeting.

Bite the bullet / replace the apps

[dave562]

We are still going through this where I work. Previously IT was run on a bunch of Lotus Notes / Domino databases. Those have since been replaced by PeopleSoft and ServiceNow.

You have to see the opportunity for what it is. You can have real conversations with the departments about what their real needs are. It is going to take a while, but you will have to produce documents that detail the core application functionalities for all of the applications. Then you will have to map those functions into the ERP system. Once you have done that, you will have your gap analysis and be able to focus your developmental resources. You have to get buy in from across the organization and get people committed to and willing to do things differently. The ERP equivalents of the current applications will not be apples to apples. If you try to do that, you will never get through it and will end up failing. If you are just going to recreate the apps, you might as well not even bother. The key is to focus on the functionality. Focus on the business needs / business cases for the applications.

For something that big, you are going to need at least 3+ full time employees. A project manager to keep everything organized and fight back against scope creep, a senior developer / architect to make the technical decisions and provide guidance to the team of developer(s) who will do the actual work. In all honesty, what you are proposing is a significant investment for the organization and a shift in culture. Each one of those employees is easily a six figure salary, so figure over half a million dollar in salary (plus benefits, etc.) Good developers are hard to find and building a successful development team is a challenge. You will obviously need an executive sponsor who can help you figure out where to position this new group / department in the overall organizational hierarchy.

The long term benefit to your organization is that you free yourself from the vendor. The risk that you run is that you might end up with incompetent developers or management on the new team and find yourself worse off than before.

Have you considered bringing in another vendor? At the very least, you can use that as leverage to negotiate more favorable conditions with the current vendor.

You should have enough experience with the current vendor to determine how accurate their project quotes are. Use that knowledge when you ask them for quotes on replacing / reproducing the current application functionality. Then compare that to what it will cost your organization to do it in house. It should be clear very early on in the process if you are going to save enough money to justify such a drastic realignment of the management, operation and development of the systems.

Business in a Box

[Anonymous Coward]

My experience with them (having done at least 4 big Oracle and 2 big SAP implementations) is that if your business model fits the built in business processes in the ERP, it's pretty easy to do (aka Business in a Box). If you have some business processes that are not in line with their out of the box processes, it gets really expensive quickly and makes things very hard to get working. The most successful (2 on time on budget) implementations were both where the company would conform to the ERP business model for the modules it planned to implement.

Also keep in mind that there are strict approved ways to integrate with big ERP systems like this so that you don't break the upgrade chain later. It would be best to get someone in house, even if just on contract, who has done customizations to the ERP system and specifically the module you want to customize. Put that ERP expert, your business process expert, the core developer(s), and maybe a PM (if you need to) into a core team and let them run. Take small chunks at a time and write tests for data integrity so you know you aren't killing things when batch processing/etc runs.

Hope that helps.

Re:Hire More Devs

[ranton]

I agree. If you are spending millions of dollars on your ERP, you should probably have in house developers capable of customizing your system (unless you just mean a couple million over a decade or so). You will probably always need some help from consultants, but a good deal of the work could be done by your own staff. This would likely save quite a bit of money. I work as a consultant on various ERP and CRM systems, and all of our long term clients eventually start to bring the work in house because of costs. Our load goes down as they hire more people, but we usually stay available with support contracts for years.

And the first thing your in house devs should control is the integrations between your ERP and home ground applications. Companies that rely on consultants to handle their integrations become very dependent on those consultants.

There is nothing wrong with having a large number of integrations. If you have a large system, the belief that you can get all business processes into one ERP system is probably just a dream. But getting a firm handle on all of your integrations is an attainable goal. Then you can make more informed decisions on when and how to move functionality into your ERP software. And you can be more comfortable that you are re-implementing that functionality properly.

Disclaimer: My day job is re-engineering the integrations for ERP/CRM systems, so take the importance I give to the integrations with a grain of salt.

Hold up - solve the right problem

[Janhaus]

I have been on several projects similar to the one described and I would caution that before diving into the build-vs-buy decision, I think you should re-evaluate and see if you're solving the right problem. At this point, having spent millions of dollars investing in your ERP it's not feasible to swap it out but it seems that most of the pain lies in the applications that MANAGE the data, the Excel spreadsheets, Access db's, etc. I would suggest looking into a front-end PaaS cloud solution with good dev and integration API's upon which to quickly re-build these apps, streamlining and standardizing processes and workflows - the situation you've described is a common case for cloud migration. You may want to look at a platform which will vastly improve time to app (Gartner and IDC have studies ballparking how much quicker you may realize time to app with a good cloud platform), lower your TCO and the OPEX vs CAPEX model may be more palatable to your accountants when evaluating costs of rebuilding. Also, like another poster mentioned earlier, you should try and avoid going down the path of heavily customizing your ERP because it will be a pain to upgrade, like it isn't painful enough already. I'd suggest having a platform layer upon which to build your apps, interfacing with your ERP via an integration layer. Without knowing additional details, I would recommend looking into the Force.com platform (disclaimer: No, I don't work for the company but I've designed solutions on this platform to solve situations like what the OP describes, migrating macro-ridden excel sheets, databases, legacy apps like lotus notes, etc. etc. onto the platform while integrating with an Oracle/SAP back-end so I'm comfortable recommending it). It's a good platform to build upon, literally hands-free upgrades, with numerous dev integration API's that guarantee backwards-compatibility, better up-time than Google and various integration middleware solutions as well so you don't need to rewrite connectivity interfaces for all your apps if you ever decided to swap out Oracle ERP for say, SAP. And the language is fairly simple to develop in, simpler than say, Java so you could get your third-party SI to lay the groundwork and then maintain/build upon it internally or, depending on your internal IT team's capabilities, take the bulk of the work on yourselves. Just my 2c, seriously - consider a cloud-based solution to solve some of your most pressing needs.

Use DRM

[rabtech]

No, not that DRM, I mean Data Relationship Management. It's designed for taking that manual excel spreadsheet crap and turning it into an actual process. I should know, I integrated the JS engine into it. You can version the data, blend (merge) it, and so on and create workflows.

I don't feel bad mentioning it since I'm leaving Oracle shortly to join a startup, but that's my full disclosure.

Re:Hire More Devs

[Cytotoxic]

This is good advice. In-house expertise is always preferable when possible.

I would not call the ERP a single point of failure though. It means having one version of the truth. If you have one place where the data is kept (and only one place), then the data will be correct - or as correct as the people using it need it to be. If you have it in multiple places, then none of them will be correct. Especially if spreadsheets are among the places where the data is kept and manipulated.

I would recommend using the ERP database as the master repository for every business application, even if you are using other custom apps to curate the data. That way you can maintain the business rules at the Oracle DB level and ensure data integrity.

The macro-laden Access databases and spreadsheets are fine for laymen to prototype their business models - but you have to hand it over to real developers to build enterprise class applications using the Oracle DB when it is time to go to production.

You can sell all of that to the accountants by including a push toward automation of the GL by using the ERP as a subledger. You can save tons of money on accountants and auditors by having every action in the company reliably captured in a database and automatically rolled into the accounting systems. Also, the board reports suddenly become reliable and easy to produce if you have a single version of reality. Bringing all of these little apps up to spec is a no-brainer. Sure, some of the managers who like having local control over their macros will complain about being hamstrung by IT, but it has to be done.