Slashdot Mirror

← Back to Stories (view on slashdot.org)

Ask Slashdot: When Is It Better To Modify the ERP vs. Interfacing It?

Posted by timothy on from the which-point-in-the-chain dept.

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?

9 of 209 comments (clear)

  1. Hire More Devs by jerpyro · · Score: 4, 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.

    1. Re:Hire More Devs by pkinetics · · Score: 4, 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

  2. No matter how common you think it is... by i+kan+reed · · 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 in our day-to-day lives. A lot of us don't care about a strategic business unit. Most slashdotters are in the field of making software, not babbling almost-but-not-quite-meaningless business jargon about software.

    1. Re:No matter how common you think it is... by Concerned+Onlooker · · 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.

      --
      http://www.rootstrikers.org/
    2. Re:No matter how common you think it is... by i+kan+reed · · 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.

  3. Vendor vs In House by James-NSC · · Score: 5, Insightful
    One of the key problems I've run into, not only in regards to ERP, but in general, is that when you outsource all of your development your future is in the hands of someone who doesn't have your companies best interests as their primary concern. Their primary goal is to get paid and to keep their company in the green, the only way they can do that is to, as you noted, keep putting their hands out. It is not in their best interest to produce a system that is self sufficient, it is in their best interest to keep you on the line.

    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

  4. ERP system from *Oracle* by nurb432 · · Score: 5, Insightful

    there is your answer. ditch it. quick..

    --
    ---- Booth was a patriot ----
  5. Easy Answer... by Kookus · · Score: 4, 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.

  6. Re:who not whom. by lgw · · Score: 4, Insightful

    I care. Language cries when you abuse it like that. It makes me sad. Think of the small words!

    --
    Socialism: a lie told by totalitarians and believed by fools.