Ask Slashdot: When Is It Better To Modify the ERP vs. Interfacing It? 209
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?
Hire More Devs (Score:5, Insightful)
I would hire devs to interface with the ERP. Because when you go to upgrade to the next version [of the ERP], you have a modular thing that you can change pieces of rather than having to pay someone to rewrite the entire thing. If you continue to customize the ERP you're using, you'll be locked in to that specific version and all of its security/stability/functionality problems.
No matter how common you think it is... (Score:4, Insightful)
Always fucking expand the first instance of your acronym in your summary. Always.
Many of have absolutely nothing to do with Enterprise resource planning [wikipedia.org] in our day-to-day lives. A lot of us don't care about a strategic business unit [wikipedia.org]. Most slashdotters are in the field of making software, not babbling almost-but-not-quite-meaningless business jargon about software.
Vendor vs In House (Score:5, Insightful)
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
ERP system from *Oracle* (Score:5, Insightful)
there is your answer. ditch it. quick..
Re:No matter how common you think it is... (Score:2, Insightful)
If you don't know what ERP is, how could you possible answer the question with any insight?
The context was quite clear. Just move along.
Re:No matter how common you think it is... (Score:4, Insightful)
Always fucking expand the first instance of your acronym in your summary. Always.
Many of have absolutely nothing to do with Enterprise resource planning [wikipedia.org] in our day-to-day lives. A lot of us don't care about a strategic business unit [wikipedia.org]. Most slashdotters are in the field of making software, not babbling almost-but-not-quite-meaningless business jargon about software.
Thank you. I was confused because I didn't know what ERP and SBU meant, but thanks to your post I now know that they're just 2 more completely useless terms bandied about by PHBs.
Re:No matter how common you think it is... (Score:5, Insightful)
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.
Re:No matter how common you think it is... (Score:5, Insightful)
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.
Easy Answer... (Score:5, Insightful)
You didn't start your question with the sentence:
"I am the CIO for one of the largest HVAC manufacturers in the world."
So the answer is: I hope you either have a family tie to the company, or some other mechanism of having your voice heard.
Since you already have shown that the path is chosen and the consultants are already on the ground running with the conversion, then it's already too late.
See, really your problem is that you hired in people that don't know how to do the job, and that's the problem with the majority of consultants these days. If you have good people (consultants or internal) then good things are possible no matter what choice is made. If you have bad people, it doesn't matter either.. the outcome was based purely on whether you have the knowledgeable people in a decision making role and in positions to actually do the work.
It's pretty much hit or miss on successful or failure ERP implementations, the common thread is the people and management. Unless that's fixed, get ready for a rough ride.
There's one thing that I try to keep in mind, though, when traveling down the rough road:
Change the things that you're able to change and position yourself for the change that you can't. So that way, even though things don't go your way, hopefully you have a backup plan that is still possible in the event of failure.
Keep ERP system customization to a minimum (Score:4, Insightful)
I've seen companies spend ludicrous sums on TYRING to fit square ERP pegs into their odd ball shaped hole of business processes. Keep customization to a minimum. If you can't find an ERP system out of the box to do what you need it to almost completely, then building external apps to do what you want is not a bad way to go provided you have in-house talent to manage it.
Also make sure the vendor approves of what you're doing in those external apps. You might find them blaming you for system problems and not provide support when you need it most. You can bet the odds of this go up if you outsource the dev work. It's nothing for them to blame a third party they don't have a business relationship with.
Just remember -- external tools are basically external modules that are only dependent on the underlying data. As long as the database schema doesn't change, system upgrades shouldn't have any impact on your external tools.
Depends! (Score:4, Insightful)
Re:who not whom. (Score:5, Insightful)
I care. Language cries when you abuse it like that. It makes me sad. Think of the small words!
Re:Hire More Devs (Score:5, Insightful)
EXACTLY THIS!
For the love of all that is sane, make external interfaces.
This has the added benefit of providing an easy to find definition of your non ERP standardized business practices.
If the data belongs in the ERP, it should be managed in the ERP. If it is not, that means your ERP configuration is missing important business workflows and practices. The more the ERP breaks, the less people trust it, and the more they try to do outside of it. Your ERP should not have several feeders of business rules data.
It is one thing for the external interfaces to have good data, and send good data. It is another to bury all the source data in separate apps. I'm just imaging 100 little spreadsheets and Access databases propagating bad information across each other. This value means this is Billy Bob's spreadsheet but in Peggy Sue it should be this value.
AHHHHHHH
Quit (Score:2, Insightful)
Just quit.
1. You don't seem to be the one in control of this project. So, you are stuck on this path. Or, do you have the political capital and will to fight to get your way? You're seriously going to piss in someone's Wheaties and when you're standing in the shower in the morning, you better have a smile on your face knowing it's worth it.
2. You work for a major HVAC manufacturer. That's the most exciting thing you can do with your life? It would make me want to slit my wrists every day with a spoon.
3. You have to re-do these applications and make the data integrity robust. That means seriously looking at things like where you can get the most benefit for least amount of cost and/or where the data integrity is shit. "Oh, Jim manages our entire Northwest supply chain and inventory using that Excel spreadsheet he keeps on his desktop." I don't care if you use and Oracle product to get there or a cloud-based, super-redundant shade of the color blue. The only thing your boss's boss cares about is whether you a) prevent the company from losing money or b) make the company more money.
4. Speaking about data center room makes you sound like a systems or support person. This is an application and developer thing.
5. I'm not sure I understand where your pain points are. Customer relationship management? Supply chain? Inventory? Quality control? Payroll/HR? Quantify.
6. Do they pay you enough to worry about this? That might seem flippant, but it's very valid.