Slashdot Mirror
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?
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.
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.
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.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
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.
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
there is your answer. ditch it. quick..
---- Booth was a patriot ----
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.
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
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.
On that list, Hershey (SAP), Nike (i2), HP (SAP), etc, etc, etc.
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.
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.
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.
I went to eat some animal crackers and the box said, "Do not eat if seal is broken." I opened the box and sure enough..
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 when we are talking about a company of the presumed size you indicate.
The fact that you have apps running in Excel and Access is horrible, common, but very bad for a lot of reasons.
This problem might have been discovered while implementing the ERP.
Since you are already investing heavily into the ERP, making it part of that system makes the most sense to me.
The benefits of integrating these data and functionality reaps benefits across the ERP system.
Now going to Slashdot, where a whole lot of people you have non idea who is, nor what their real life experience with ERP systems
are borders upon irresponsible. Would you take the information offered by a pimply teenager on how to solve your problems? Or maybe
its an ERP expert, how do you know.
Since you work at a company that has a lot of resources, the prudent thing to do, is to find a consulting company with a proven track record
in the ERP you are working with (different from the people you already have) and pay them to come in and do a discovery of existing excel
and Access applications, map out their functionality and do an estimate for each one, how much it will cost (ballpark) to implement them in the ERP system
and give recommendations for each application as to its suitability for migration. There is likely no one answer for all of them.
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 most people think - especially in SBU's) a supportable interface to the ERP should be deployed. You are now supporting a hybrid ERP/BoB (which to some degree is often the case at most places claiming to be an ERP shop).
We deployed PeopleSoft here in 2006 with help of a third party partner - through diligent procedural development wehave become self sufficient even through major upgrades. A constant threat to our success has been the reluctance of process owners in the SBU's to even consider changing their business processes to match the vanilla processes delivered. More than once we have had to wait until a major decision maker retired to change processes only to find out the the new processes, after an initial painful adjustment period, are superior - better suited to our needs, easier to integrate, adapt better to changing requirements from users and governments, scale well and are easier to monitor and report on.
G
15 years solid Access experience!
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.
-- All that is necessary for the triumph of evil is that good men do nothing. -- Edmund Burke
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.
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) 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.
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.
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...
systemd is Roko's Basilisk.
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.
-- Slashdot, making the Left look conservative since 1997.
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.
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.
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.
Natural != (nontoxic || beneficial)
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 productive+
- now your "CIO wants to dump everything" (as in throw the garbage) into the ERP but the accountants don't want to pay up
- so you're asking for our advice +++
If I were you I'd tell the CIO I'm "on it" then go play golf or make myself seem busy. From time to time report that there was progress but you need more time and maybe an assistant. Prepare a nice looking excel for days when he actually wants to see what you've been up to. If he wants you to explain this to management, prepare a nice PowerPoint with colorful graphs and a few acronyms and buzzwords (use the cloud words you learned).
Since I'm not you, I offer you my services as a contractor for a modest fee. I'm sure I can come up with a figure that your accountants will be willing to cough up and will enable me to retire comfortably. I have enough experience to make your boss believe he's getting his money's worth and can make nice presentations to upper management.
* you mean wasted millions, not spent or invested**
** "spent" or "invested" would be words used by Larry Ellison or your incompetent third-party implementer
*** gasp. someone please help! This is like taping a cardboard on your overpriced Bentley to block out the sun and then using a piece of string to tie a shopping cart to it when you go to Walmart's.
**** how about selling them or putting the place up for rent...
+ what (wtf) does cloud have to do with your ERP woes? Besides, why talk about cloud if your DC is idle? The whole irony here is that ERP is counter productive. ++
++ I had too many stars to signify footnotes so I decided on using pluses instead.
+++ I know you asked for our experience, but you're really looking for a way of making everyone happy.
sigo ergo sum
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 above).
5) I know where our pain points are, I'm speaking about concepts and technological approaches.
6) I'm being paid to evaluate these options, so...yes.