Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
Businesses Databases Oracle IT

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

Posted by timothy 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?
This discussion has been archived. No new comments can be posted.

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

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

Comments Filter:

  • Hire More Devs (Score:5, Insightful)

    by jerpyro ( 926071 ) on Thursday July 31, 2014 @04:14PM (#47576873)

    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.

    • Re:Hire More Devs (Score:5, Informative)

      by ranton ( 36917 ) on Thursday July 31, 2014 @04:54PM (#47577287)

      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.

      • Re:Hire More Devs (Score:4, Informative)

        by Cytotoxic ( 245301 ) on Thursday July 31, 2014 @11:16PM (#47579137)

        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.

    • Exactly, either way your going to continue to hemorrhage cash on this, however having in house devs document and create the modules you need will help in the long run as a point of contact to upgrade, patch, and improve upon. Having contractors will get you what you need in the short term but your going to pay extra just for changing the icon to cornflower blue.
    • Agree. I think you are describing Service-oriented architecture (SOA) [wikipedia.org] and it's the way to go here. My company is currently going through an ERP replacement. In my case, the tools that were originally implemented using a SOA approach have been easier to adapt to the new ERP. Why? The interfaces between the tools and ERP are preserved. An interface could be any API. The ERP team is required to re-implement the interfaces as they go through the upgrades. The partner applications are largely unaware of
    • I used to work for an Aerospace Manufacturing plant, and their ERP system M1 wasn't cutting it. I developed a complete web-based portal system that interfaced directly with the SQL server to bring the data to life. I now sell my software I made to other businesses that use the M1 ERP system and customize it to their needs. I highly recommend that route. You won't be disappointed when you see your data come to life in an orderly fashion.

    • Re:Hire More Devs (Score:5, Insightful)

      by pkinetics ( 549289 ) on Thursday July 31, 2014 @07:23PM (#47578243)

      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

    • Re: (Score:3)

      by bungo ( 50628 )

      I agree. Hiring devs and interfacing is the better solution.

      Now, the dev team doesn't have to be in house, it could also be an external team. As long as they develop against and API, then that's all that matters. If it's easier to hire an external team to develop than making the longer term commitment for new employees, then do that.

      What I haven't seen anyone mention is the cost of upgrading. This is the biggest factor by far. It can cost you more in upgrading what you've customised than the original cost

  • No matter how common you think it is... (Score:4, Insightful)

    by i kan reed ( 749298 ) on Thursday July 31, 2014 @04:15PM (#47576885) Homepage Journal

    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.

    • Even ERP is a misnomer. I have used several different products that does that and each has it's own up and downs.

      The biggest hurdle is generally changing internal processes to make use of the new software. The problem is 50% of people memorize absolute position rather than relative process. Ie every who complains about Msft ribbon memorizes the absolute position of procedures versus the process.

      • MS Ribbon encourages that kind of mindless position-process because you can't even talk about it without words attached. All you can do is grunt and point at the cave paintings.

    • Re: (Score:2, Insightful)

      by geekoid ( 135745 )

      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)

      by sexconker ( 1179573 ) on Thursday July 31, 2014 @04:28PM (#47577013)

      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.

    • 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.

    • Re: (Score:2, Flamebait)

      by dave562 ( 969951 )

      If you are working in IT and do not know what an ERP system is, you are playing in the minor leagues. Go back to coding your iOS and web apps and leave the rest of us to solve our business problems.

    • Thank you, but I'm (selfishly) asking for advice from those who have experience in this area from a technical point of view who would know these terms. However, you have done a fantastic job defining those acronyms for me so others can find the other comments provided by other /.s that answer the questions and provide insight for similar problems they've faced and solved.

    • Let's ret report him to the AAAAA. (The American Association for the Abolishment of Acronym Abuse)

    • Re: (Score:2)

      by pla ( 258480 )
      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.

      I agree with you in general, but in this case, if you don't know those acronyms intimately, I can safely say you have zero ability to provide a useful answer to the underlying question.


      As for the question at hand - They s

      • Re: (Score:2)

        by Ocker3 ( 1232550 )
        Exactly, when I saw Access and Excel I thought I had mistyped the URL and was reading The Daily WTF again!

  • Major application vendor headaches... (Score:5, Informative)

    by Z00L00K ( 682162 ) on Thursday July 31, 2014 @04:15PM (#47576895) Homepage Journal

    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.

    • Re:Major application vendor headaches... (Score:4, Interesting)

      by Zeek40 ( 1017978 ) on Thursday July 31, 2014 @08:54PM (#47578669)
      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.

    • That was always my opinion. Unless you happen to run a business that has been completely solved in the enterprise software world - something like a mortgage broker or a restaurant - I would rather roll my own. I met a group who started a mortgage company and their entire business plan centered around using things off the shelf as they were intended to be used - designing their business processes around the available tools rather than trying to customize them to an existing business plan. Their IT shop wa

  • That's the thing with ERP systems. Most companies only focus on the initial cost of the system, but these large ERP setups like oracle and SAP are really just basic frameworks. The most important aspect is customizing to your business structure/procedures. If you take the time and resources to set it up properly then you can pretty much use them without having to manage a thousand spreadsheets and tribal knowledge that most companies use. The tools are always there... they just need to be configured.

  • Vendor vs In House (Score:5, Insightful)

    by James-NSC ( 1414763 ) on Thursday July 31, 2014 @04:19PM (#47576925) Homepage
    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

    • Thank you for your feedback.

    • Re: (Score:2)

      by radtea ( 464814 )

      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.

      Even in those cases where you get a good service provider (which will depend on the specific people you've got working on your project much more than the company they work for, so anyone who says "Oracle = good" is missing the point) you still run into one of the most fundamental human problems: we suck at communication.

      When you outsource something the degree of clear, concise, validated communication required is many times what is required for in-house development (where communication can still be a major

      • Re: (Score:2)

        by Ocker3 ( 1232550 )
        Also, don't just Ask the end users, actually watch them work. Google, MS, Apple, etc., they actually setup labs and watch how people interact with their products. That way you can See if they're having problems with your software, you don't have to rely on the problem being big enough for them to remember and write it down. Some/many users don't want to seem stupid and ask silly questions.

  • ERP system from *Oracle* (Score:5, Insightful)

    by nurb432 ( 527695 ) on Thursday July 31, 2014 @04:20PM (#47576931) Homepage Journal

    there is your answer. ditch it. quick..

    • Re: (Score:2)

      by Gramie2 ( 411713 )
      Can you imagine how much face would be lost by people up in the executive suites if they admitted a mistake of this magnitude? They would run the company into the ground first.

      • Re: (Score:2)

        by Livius ( 318358 )

        I don't think you can hide the fact that it came from Oracle, so it's already too late.

  • move consideration to Enterprise open Source ERP (Score:3, Informative)

    by wanderson ( 1321837 ) on Thursday July 31, 2014 @04:35PM (#47577079)
    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.

  • It always takes longer and costs more than anyone ever thought possible.
    The results are not always what you had in mind
    It often ends up in court
    You definitely don't want to be around while its happening

    • Re: (Score:3)

      by ranton ( 36917 )

      It always takes longer and costs more than anyone ever thought possible.

      Although with a home remodeling project it will probably only go 50% over budget, not 500% over budget.

  • Erotic Role-Play (Score:3, Informative)

    by hort_wort ( 1401963 ) on Thursday July 31, 2014 @04:40PM (#47577145)

    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.

  • You don't want dozens of applications that interface with the ERP system. If you do that, when the ERP interface API changes you now have to change dozens of applications. The ultimate result of that is that the ERP system upgrade cost now goes through the roof. 10 years laster, someone is going "You are using version *WHAT* ?!?!?! It only works with Internet Explorer version *WHAT*?!?!?!" I've been there! You also now have to train people how to use each of those applications.

    • Thank. This is the kind of answer I'm looking for from a pro or con perspective. As for the training, it would make more sense to attempt to stick closely to what they've developed w/ their own processes but that's not always the best idea or option. Appreciate the feedback.

    • Re: (Score:3)

      by ranton ( 36917 )

      I always recommend that our clients not rely on their ERP system to take primary control over integrations. A middle layer written in house provides far more control over the process, and helps avoid vendor lock. But vendor lock usually isn't the real problem (since it will still be very hard to switch), it is dealing with upgrades to the ERP.

  • Bite the bullet / replace the apps (Score:5, Informative)

    by dave562 ( 969951 ) on Thursday July 31, 2014 @04:46PM (#47577207) Journal

    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.

    • Thank you for your valuable feedback and I've added your suggestions to my (growing) list of pros and cons.

      • Re: (Score:2)

        by Dastardly ( 4204 )

        An additional concept that might also help is the concept of application strangulation. http://paulhammant.com/2013/07/14/legacy-application-strangulation-case-studies/

        In addition to the current functions, try to find out what these groups wish they could do, watch what they do. Because as the grand-parent said,

        If you are just going to recreate the apps, you might as well not even bother.

        If you just recreate the apps, what will motivate the user to use the ERP or the new app built on top of the ERP? You want to put in something beyond their existing tool to motivate them to stop us

      • whatever you do do not let the techies run the project. This isn't a technical solution but a business solution. The techies may think a fit gap tells them what they need to know to build a system but the reality is unless someone one really understands Hal the system is used and what the LOB need you will wind up with a mess. The IT folks will focus on the IT aspects and forget there is a whole organizational component that can derail them even if the system works.

        I've seen to many projects where the focu

  • Business in a Box (Score:2, Informative)

    by 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 mode

  • Blend It (Score:4, Interesting)

    by TheNinjaroach ( 878876 ) on Thursday July 31, 2014 @04:49PM (#47577239)
    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.

  • Easy Answer... (Score:5, Insightful)

    by Kookus ( 653170 ) on Thursday July 31, 2014 @04:54PM (#47577285) Journal

    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.

  • Even the smallest amount of research about the cost and time to implement an ERP would indicate that it will cost a lot more than you think and customizing it to fit your specific business will take both time and a lot of money.

    ERP systems are huge, extremely complex and when implemented incredibly essential to the running of the company.
    If an ERP system goes down, the business stops. That is why you spend the time, money and consulting fees to have it
    configured as a very high availability system. Esp whe

    • Going to /. will give me a wide range of answers from experienced IT professionals and code monkeys just starting their career. When you're looking to brainstorm, it's good to get like minded people together that cross generations. I can get new ideas from the youth and hand swatting from the old that can tell the youth their idea will fail because they attempted it x number of years ago with the result of Y. That actual synergy you get will be lost once a ton of baby boomers retire and the youth start re-i

    • Re: (Score:2)

      by sphealey ( 2855 )

      There exist ERP systems for small, mid-sized, and enterprise-sized companies with corresponding scope, size, and complexity. The OP's business sounds as if it is large enough (plus multinational) to justify an enterprise-grade system, but e.g. an implementation of Visual Manufacturing(tm) for a small-medium engineer-to-order or make-to-stock company is well within the ability of a 1-3 person staff to understand and manage.

      sPh

  • I may have missed what you were asking - if you have spent millions implementing an ERP, you are attempting to use an ERP strategy over a "best of breed" strategy. This may be the motivation behind your CIO comments. If this is the case, your departmental applications should be dumped entirely and the business processes involved should be modified to fit the "best practice" processes built into the ERP. Where a department really has requirements for a separate system (this is a much rarer situation than mos

    • ERP overall strategy. For most of our business, the ERP strategy has worked and processes were changed to match those best practices; however, some processes can't be changed due to customer/partner reluctance, prior contract support, or simply the ERP not fitting (workbenches come to mind here).

      Thanks for the feedback.

  • I'm available (Score:5, Funny)

    by fredrated ( 639554 ) on Thursday July 31, 2014 @04:58PM (#47577323) Journal

    15 years solid Access experience!

  • Keep ERP system customization to a minimum (Score:4, Insightful)

    by div_2n ( 525075 ) on Thursday July 31, 2014 @05:01PM (#47577341)

    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.

    • Re:Keep ERP system customization to a minimum (Score:5, Interesting)

      by King_TJ ( 85913 ) on Thursday July 31, 2014 @05:08PM (#47577401) Journal

      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 (Score:4, Interesting)

    by dominux ( 731134 ) on Thursday July 31, 2014 @05:11PM (#47577435) Homepage

    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.

    • Unfortunately, we're not considering going to an ERP, we're already there; designed it, deployed it, now final tweaking it.

  • Hold up - solve the right problem (Score:3, Informative)

    by Janhaus ( 3771469 ) on Thursday July 31, 2014 @05:15PM (#47577459)
    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.
    • Agreed. Look into what the business needs are first before considering expanding ERP, especially away from configuration into customization. Once you go down that road, it's hard to come back and you're screwed at every upgrade. Look into ways to integrate your ERP with other systems either COTS or home-grown and use each system for their specific purposes. Integrate them via a Web service so that the updates to each system don't significantly impact your other systems versus an interface. Most open system

      • We already have a data warehouse and BI tools that I'm slowly training people to use and is where I'm finding these home-grown applications.

    • You've hit the nail on the head. These spreadsheets are being used to manage the data that ultimately ends up back in the ERP. It's like human ETLs once you think about it. Thanks for your suggestions.

  • We purchased a large ERP to 'centralize' and 'homogenize' our data. Instead if disparate systems trying to interface, we wanted all our divisions to use the same system. We had IT research the different options with occasional feedback, and they picked one, and we started implement it.

    It turns out that we had disparate systems for a reason, and the new ERP system didn't fit into any of them. We adjusted models to fit the best practices of the ERP as best we could, but that only got us so far. At t

  • What? (Score:3, Funny)

    by wonkey_monkey ( 2592601 ) on Thursday July 31, 2014 @05:38PM (#47577607) Homepage

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

    Modify the what?

    I work for one of the largest HVAC manufacturers

    A what manufacturer?

    We've currently spent millions of dollars investing in an ERP system

    A what system?

    but it's been a great ordeal getting the thing to work for us across SBUs

    Across what?

    (via API of choice)?

    Ooh, I know that one!

    Our CIO

    Chief... something... officer...

  • The more you mod the ERP the more likely you will have to pay again to incorporate you mods in the next major ERP release. While developing your own solutions isn't cheap at least once they are working you will just (a big just) have to ensure your data feeds and APIs are still functioning properly.

  • Depends! (Score:4, Insightful)

    by ageoffri ( 723674 ) on Thursday July 31, 2014 @05:50PM (#47577679)
    This is almost a philosophy question. While I haven't been directly involved with the implementation of an ERP, I have been at clients that were implementing large scale ERP systems. There are two main ways to deal with this. The first is to take the ERP system and make minimal changes to it and instead perform business process transformation to align the business with the ERP system. The second is to take the ERP system and use existing business processes with minimal modifications and instead modify the ERP and/or put in place interfaces/API's to make the ERP work with the business processes. The answer is not always easy. Many places can benefit from business process transformation because processes have been used for a long time and don't take into account the current environment, they haven't been changed because "this is the way we've always done it". Sometimes the business processes are optimized and your better off changing the ERP and/or putting in the interfaces.

  • Not a technical problem (Score:3)

    by Dishwasha ( 125561 ) on Thursday July 31, 2014 @05:52PM (#47577705)

    What your CIO should be doing is bringing together two (or more) separate proposals to the executives who then mandate that all department heads provide cost estimation and risk analysis for each of the two scenarios. Once all those are compiled together, cost and risk can then be used to help the CIO and other executives make a choice. Then they can once again mandate a conformance of all departments to the chosen solution and give the department heads X amount of time to convert N percentage of their business processes to the chosen solution. Iterate until all legacy systems and processes are sunset.

    Choosing one technical solution over another or choosing to pay a cost here versus there makes absolutely no sense until you completely understand the needs, resources, timelines, and risks.

  • The title and the first couple lines with all the acronyms and Im pretty sure we just saw the output of a Turing test...

  • Use DRM (Score:5, Informative)

    by rabtech ( 223758 ) on Thursday July 31, 2014 @07:01PM (#47578123) Homepage

    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.

  • sooo, let's see if I got this right:
    - you "spent millions of dollars investing in an ERP system"*,
    - then you "discovered" that the system only does input/output
    - so for managing the data you use "systems of spreadsheets and access databases wrought with macros to turn them into functional applications"***
    - on top of that you have empty data centers you can't really find any good use for****
    - and you just learned some new buzz words related to cloud technologies but heard someone say cloud is counter product

    • The current ERP system works for 90% of our operations, so it's an investment that's paying off. The management of the data isn't the meat and potatoes of the data that fit the ERP. This includes metadata not necessary associated with orders/invoice/shipping/AP, process queues, and workflow management. Actually, the cloud tools I was referring to would allow us to re-use our empty data centers with a private/public cloud hybrid. These aren't buzzwords that I've learned but tools I've actually implemented an

  • "Business Intelligence"

    Reading between the lines, and with over 20 years experience of working with Oracle E-Business Suite, when you say 'managing' data, what you really mean is 'analysing' data. I agree Oracle E-Business Suite is primarily a 'repository' for the data, and typically the analysis is done with Business Intelligence tools built on either the EBS database directly, or on a dedicated data warehouse. The canonical product you would use is Oracle BI, but there are free tools probably just as goo

    • We already have OBIEE that we're training people to use. By managing data, I'm referring to work queues, metadata, and workflow functions.

  • Quit (Score:2, Insightful)

    by vinn ( 4370 )

    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

    • 1) This isn't about getting my way, this is about evaluating and presenting the best solutions.
      2) Working in HVAC is no different than any other company. An income statement is the same at every company.
      3) Which is why I'm evaluating all of the alternatives.
      4) No, speaking about the data center room helps answer the question before it's asked: "Do you have the capacity to support these apps (servers, redundant power, load balancing, etc.)." It also keeps the conversations on-topic (see the acronym complaint

Slashdot Top Deals

"Open Channel D..." -- Napoleon Solo, The Man From U.N.C.L.E.

Close