Announcing: Slashdot Deals - Explore geek apps, games, gadgets and more. (what is this?)

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

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

timothy posted about 6 months ago | from the which-point-in-the-chain dept.

Businesses 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?

Sorry! There are no comments related to the filter you selected.

Hire More Devs (4, Insightful)

jerpyro (926071) | about 6 months ago | (#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.

who not whom. (0, Offtopic)

Anonymous Coward | about 6 months ago | (#47576947)

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.

who not whom.

Re:who not whom. (-1)

Anonymous Coward | about 6 months ago | (#47577025)

Nobody cares.

Re:who not whom. (-1)

Anonymous Coward | about 6 months ago | (#47577195)

Submitter should use smaller words. He's trying to swim in the deep end ("whom", "wrought") when he's barely ready for the kiddy pool.

Re:who not whom. (0)

Anonymous Coward | about 6 months ago | (#47577419)


Re:Hire More Devs (5, Informative)

ranton (36917) | about 6 months ago | (#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 (1)

who_stole_my_kidneys (1956012) | about 6 months ago | (#47577409)

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.

Re:Hire More Devs (1)

flanders123 (871781) | about 6 months ago | (#47577423)

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 this and do not need to change.

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

i kan reed (749298) | about 6 months ago | (#47576885)

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.

Re:No matter how common you think it is... (1)

Anonymous Coward | about 6 months ago | (#47576981)

But somehow you assume everyone knows Heating, Ventilation and Air Conditioning [wikipedia.org] ?

Re:No matter how common you think it is... (3)

i kan reed (749298) | about 6 months ago | (#47577231)

No, I can just use context to realize it's mostly irrelevant to the actual question.

Re:No matter how common you think it is... (1)

peragrin (659227) | about 6 months ago | (#47576987)

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.

Re:No matter how common you think it is... (1)

dcollins (135727) | about 6 months ago | (#47577339)

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:No matter how common you think it is... (0)

Anonymous Coward | about 6 months ago | (#47577579)

I object.

I object to your comment as untrue (everyone who complains about MS ribbon....) because I complain about it for another reason.

I object to the ribbon because it makes me re-learn something needlessly. In fact, it makes some things difficult to access unless I customize it, which was not something I had to do previously.

This isn't process versus absolute position, this is taking something that works without customization and inserting a more laborious way to access that function requiring customization. And I have yet to see a benefit for its existence that personally applies to my use.

MS commonly broke where things were with differing windows releases (management operations). You had to go and relocate where the function you wanted was and what it might have been renamed as or buried under.

I *hate* it when interface designers or UI programmers decide how I want to interface with something whether I like it or not. Especially in products which are successors to successful ones with well known interfaces!

Re:No matter how common you think it is... (2, Insightful)

geekoid (135745) | about 6 months ago | (#47576997)

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... (5, Insightful)

Concerned Onlooker (473481) | about 6 months ago | (#47577121)

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... (5, Insightful)

i kan reed (749298) | about 6 months ago | (#47577283)

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.

Re:No matter how common you think it is... (4, Funny)

msauve (701917) | about 6 months ago | (#47577297)

It's a simple matter of getting all hands on deck and thinking outside of the box, so they can add value to a 6 sigma paradigm, architecting it to meet mission critical business needs while driving a best of breed reprocessing, in order to improve the EBITDA and get the boss a big bonus. If we can globally revolutionize synergistic e-commerce while doing so, win-win!

Re:No matter how common you think it is... (1)

desdinova 216 (2000908) | about 6 months ago | (#47577421)


Re:No matter how common you think it is... (0)

Anonymous Coward | about 6 months ago | (#47577445)

Are you leveraging?

Re:No matter how common you think it is... (3, Insightful)

sexconker (1179573) | about 6 months ago | (#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.

Re:No matter how common you think it is... (1)

Anonymous Coward | about 6 months ago | (#47577153)

What's a PHB? Expand plz.

Re:No matter how common you think it is... (1)

ArcadeMan (2766669) | about 6 months ago | (#47577229)

PowerShares High Yield Corporate Bond Portfolio

Re:No matter how common you think it is... (1)

jonbryce (703250) | about 6 months ago | (#47577405)

Pointy Haired Boss - http://www.dilbert.com/ [dilbert.com]

Re:No matter how common you think it is... (1)

Enfixed (2423494) | about 6 months ago | (#47577017)

I wish I had mod points today... although I don't know if I would have give you a +1 funny or informative. ;)

"Always" is a strong word (2, Informative)

tepples (727027) | about 6 months ago | (#47577019)

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:"Always" is a strong word (0)

Anonymous Coward | about 6 months ago | (#47577415)

Chill dude.

Some of us have heard of SAP but wouldn't ever guess that it stands for Systeme, Anwendungen und Produkte.

I'd be more worried about people trying to expand GNU (GNU's Not Unix) (GNU's Not Unix Not Unix) (GNU's Not Unix Not Unix Not Unix) ...

Re:"Always" is a strong word (1)

i kan reed (749298) | about 6 months ago | (#47577467)

Point ceded.

Re:No matter how common you think it is... (1)

Anonymous Coward | about 6 months ago | (#47577031)

In this case, if you don't know the jargon, the submitter wasn't asking for your input.

Re:No matter how common you think it is... (0)

Anonymous Coward | about 6 months ago | (#47577213)

Exactly. This is as much a business question as a technical one. I side with the CIO in that replacing all systems with one isn't a single point of failure it is a single point of support. That means less expensive in the long term, and capable of greater functionality.

Re:No matter how common you think it is... (1, Flamebait)

dave562 (969951) | about 6 months ago | (#47577039)

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.

Re:No matter how common you think it is... (0)

Anonymous Coward | about 6 months ago | (#47577477)

I work on a communication service with millions of customers around the planet, for a company with about 100K employees, and neither I nor my contact on our operations team knew what ERP stood for. So stuff it.

Re:No matter how common you think it is... (0)

Anonymous Coward | about 6 months ago | (#47577049)

Then you should be on this thread moron.

Re:No matter how common you think it is... (1)

Anonymous Coward | about 6 months ago | (#47577133)

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.

You mean the submission had nothing to do with Erotic Role Play?

Re:No matter how common you think it is... (1)

yeshuawatso (1774190) | about 6 months ago | (#47577273)

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.

Re: No matter how common you think it is... (1)

jd2112 (1535857) | about 6 months ago | (#47577317)

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

Re:No matter how common you think it is... (1)

pla (258480) | about 6 months ago | (#47577343)

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 seriously use Access and Excel as the interface? Fire them now. Access and Excel have their place, and enterprise level data access ain't it. Buy a working ERP package that meets your needs, and spend your in-house development time on integrating with something that meets 95% of your needs rather than trying to bolt functionality on to a piss-poor 50% solution.

Although you might at first prefer to work with the Devil you know, the biggest problem with extending what you have now will rear its head when you try to upgrade it to the latest version, and find that virtually all your customizations have broken. Even if you pay your vendor to make those customizations, you may have somewhere to point a finger, but you can still expect months of pain telling them which parts of their own damned software they broke and need to repair.

Re:No matter how common you think it is... (0)

Anonymous Coward | about 6 months ago | (#47577501)

mod up
u r so right

Re:No matter how common you think it is... (0)

Anonymous Coward | about 6 months ago | (#47577553)

Always fucking expand the first instance of your acronym in your summary. Always.
I agree ERP and SBU should be expanded, but I don't agree with the "always" part.

So TCP/IP should be expanded to Transmission ControlProtocol/Internet Protocol?
SMTP should be expanded to Simple Mail Transport Protocol?
SQL should be expanded to Strutured Query Language?
ATM should be exanded to Automatic Teller Machine? (even when it's obvious by context you don't mean Asychronous Transmit Mode)
RADAR should be expanded to.... radio detection and ranging?

Some acronyms are so ubiquitous they don't need expansion. Others like Radar or Laser graduate to actual words.

Protip (1)

Mycroft-X (11435) | about 6 months ago | (#47576893)

When asking a detailed question about your employer, try not to include enough information that you can actually identify the company with a pretty good degree of confidence. If they find out who you are you might get a good rheeming out.

Re:Protip (1)

Noah Haders (3621429) | about 6 months ago | (#47576963)

whom do you think it is?

Re:Protip (1)

yeshuawatso (1774190) | about 6 months ago | (#47577103)

This was a typo where I was referring to the third party as an object of the sentence but changed it for clarity w/o changing one letter. Chrome has no grammar check.

Re:Protip (1)

geekoid (135745) | about 6 months ago | (#47577009)

Maybe he is Daikin you for a ride?

Re:Protip (0)

Anonymous Coward | about 6 months ago | (#47577209)

Nah, he is probably just taking us all on a trane ride (or other carrier) to tell us about his big johnson.

Re:Protip (1)

yeshuawatso (1774190) | about 6 months ago | (#47577085)

LOL, I'm bouncing ideas around and the information shared is already knowledge that's outside of our company walls (customers, wiki's, our own website). Plus, my user handle is enough to identify who I am and who I work for if someone just Googles me. I'm also interested in dialog so anonymous submission wouldn't help.

Re:Protip (1)

mr_mischief (456295) | about 6 months ago | (#47577379)

Clearly you work for Trane since your freelancer.com profile says Fort Smith. There, that's out of the way now.

Re:Protip (0)

Anonymous Coward | about 6 months ago | (#47577105)

Chances are that many of the OP's coworkers also know how fucked up the system is, and they're giddy to see other people's complaints about it drawing attention.

As long as you don't actually name the company or the PHB's that chose the product/integrator, I think you're safe enough.

Re:Protip (0)

Anonymous Coward | about 6 months ago | (#47577183)

The problem with your theory is that the OP said he worked for a *manufacturer*. Rheem is just a branding company that buys Chinese and Mexican OEM systems and slaps their name on them - like *every* *other* *name* *brand* *HVAC* *company*.

Case in point, R8HE is "the first ever condensing gas pack" that is sold by no fewer than TEN different companies, ALL of whom claim to have made "the first ever condensing gas pack." Like Rheem, they are all just importing it from China and slapping their name on it.

Major application vendor headaches... (4, Informative)

Z00L00K (682162) | about 6 months ago | (#47576895)

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.

Not an answer... but hindsight! (2)

blueshift_1 (3692407) | about 6 months ago | (#47576897)

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.

Re:Not an answer... but hindsight! (1)

Anonymous Coward | about 6 months ago | (#47576991)

Yes, it will take a couple years to get the ERP up to snuff for day to day. You will be better off with competent internal staff that can modify the ERP. Single point of failure is not a problem, you currently have 20 single points of failure instead of one, if one of your "department spreadsheets" breaks they are down and each department has its own.

The more you modify your ERP the more expensive and difficult the upgrade for it will be. Try and fit the business into the standard ERP where you can, make modification that are as separate to the base when you need to.

As for hiring internal ERP staff, good luck finding someone who is willing to work for less than as contractor doing the same thing, who will also care enough to understand your business to do a good job. Its almost as if ERPs are designed to be failures from the start because of this.

Re:Not an answer... but hindsight! (1)

Anonymous Coward | about 6 months ago | (#47577389)


Most ERP projects end up late and over budget.
There is actually a place for them in large enterprise business, but you MUST tailor your business processes to fit the model imposed by the ERP system.

Customizing the ERP system to fit home grown processes (spread sheets? Yikes!) is not only a recipe for failure; but actually creates a space time discontinuity. This money and sanity sucking black hole can only be closed by the sacrifice of many innocent IT workers, and the ritual knife and truncheon used must be wielded by the ass hats who bought the ERP system and refused to modify their pet processes.

Re:Not an answer... but hindsight! (1)

megalomaniacs4u (199468) | about 6 months ago | (#47577403)

They aren't designed to be failures as such, just inadequate enough that people will upgrade for new features (no matter how irrelevant) and to keep the supplier receiving support payments, and training fees.

You know like most big software out there...

You're getting the SPOF concept wrong (1)

pcias1 (1749214) | about 6 months ago | (#47576913)

If you use a chain of apps interfacing to the ERP and all of them are critical for the business process to run, you are creating a chain of multiple SPOFs. Surely ERPs are made for limiting the technology diversity, so companies whose business is not IT can use IT limiting its exposure to technology expenditure and risks

Hey, I used to work there! (1)

qmetaball (1645933) | about 6 months ago | (#47576921)

Interestingly enough, I know which company you work for and I used to work for them at what used to be the residential headquarters. In truth, you're going to find that, at least from my past experience, they've already made up their minds and anything you bring to the table isn't going to have any attention paid to it until long after something catastrophic fails and leaves you without a backup. What I had wanted to do, and what local staff had always wanted to do, was bring everything back in house on the local data centers so that production never stopped when the outside links went down; we were ignored. I do wish you the best of luck in this endeavor though, i mainly only commented because I know what you're going through first hand.

Vendor vs In House (5, Insightful)

James-NSC (1414763) | about 6 months ago | (#47576925)

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

Re:Vendor vs In House (1)

yeshuawatso (1774190) | about 6 months ago | (#47577291)

Thank you for your feedback.

Re:Vendor vs In House (1)

radtea (464814) | about 6 months ago | (#47577529)

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 problem). Capturing user needs and implementing them in a useful and user-efficient manner is hard enough with a high-bandwidth internal-communications channel. With outsourcing it is almost impossible for the people designing and building the system to get the information they need from the end-users.

So one question I would ask the OP is: how often do your provider's developers talk to your end users? (not your end user's managers, who don't have a clue what the system requirements actually are). If the answer is "never or hardly ever" then in-house is definitely the way to go, because your in-house team will have at least some chance of building a system that will serve end-user needs.

ERP system from *Oracle* (5, Insightful)

nurb432 (527695) | about 6 months ago | (#47576931)

there is your answer. ditch it. quick..

Re:ERP system from *Oracle* (1)

Gramie2 (411713) | about 6 months ago | (#47576973)

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:ERP system from *Oracle* (1)

Livius (318358) | about 6 months ago | (#47577345)

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

Trust your CIO, he obviously knows best. (0)

Anonymous Coward | about 6 months ago | (#47576993)

I forget which large chain implemented ERP and found they couldn't ship a single product for months on end (3? 9? I forgot) because of troubles implementing this all-new all-singing-and-dancing magical silver bullet piece of software. This happened a few years back and so one'd think it should be well-known in CIO land.

Anyway, why are you asking random strangers for advice? As a CxO it's his job to have done his due diligence and all that. You have your marching orders.

Re:Trust your CIO, he obviously knows best. (2)

Pascoea (968200) | about 6 months ago | (#47577175)

Take your pick: http://www.cio.com/article/242... [cio.com]

On that list, Hershey (SAP), Nike (i2), HP (SAP), etc, etc, etc.

Backwards (0)

Anonymous Coward | about 6 months ago | (#47577007)

You are looking at this backwards. Start with the business need, not the technology that it's built in. For example, a business need would be to capture business expenses. Rate yourself on your maturity in this area from a process, training, and technology perspective. You might need some training to fill the gaps, because I'm guessing your Oracle system can easily do the expense tracking. Perhaps you need to standardize the process people use across the company. Finally perhaps you have a gap between your standard process and the systems you have put in place. Then, and only then, should you start asking the next questions about the data models, the technology platforms, and finally about the integration layers needed to bring that all together.

Re:Backwards (1)

magarity (164372) | about 6 months ago | (#47577427)

He isn't looking at it backwards and does indeed have three serious business concerns. The business is concerned about shelling out to the third party consultants for every little change, concerned about data silos in the form of the spreadsheets, and concerned about future scalability in light of concerns 1 and 2.

I say definitely move development in house for this large of an ongoing project.

Wut? (0)

Anonymous Coward | about 6 months ago | (#47577023)

Ummm, what's ERP?

Re:Wut? (1)

maroberts (15852) | about 6 months ago | (#47577151)

Ummm, what's ERP?

They're that family that had a Gunfight at the OK Corral. There was Wyatt ERP, Virgil ERP and Morgan ERP....

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

wanderson (1321837) | about 6 months ago | (#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.

ERP Implementations are like home remodeling (2)

lusid1 (759898) | about 6 months ago | (#47577087)

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:ERP Implementations are like home remodeling (2)

ranton (36917) | about 6 months ago | (#47577305)

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.

Thedailywtf (0)

Anonymous Coward | about 6 months ago | (#47577125)

This should be on thedailywtf.com instead of here, it has all the ingredients

- Huge IT project
- Complete Mismanagement
- Third party vendors
- Access and spreadsheets
- Duck tape and string

Erotic Role-Play (2, Informative)

hort_wort (1401963) | about 6 months ago | (#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.

Self hosted or hosted by Oracle? (0)

Anonymous Coward | about 6 months ago | (#47577159)

Either way you're screwed! Dealing with a deployment of Oracle on Demand, their hosted "cloud" based solution and it's been a mess from day one! Mostly it has been due to the vendors (Both Oracle and consultant) over promising and under performing on all issues. Things that should be simple - things like printing!!!! are over complicated and a mess. (What I need a seprate Internet route-able IP for each printer even though the printers will not be exposed out to the Internet???? WTF???) Can't interface with our current bill payer system? But we were told it could, see right here on page ... what ... oh it can if you now write middle ware for it at HOW MUCH???? And on it goes. Good thing I retire in 5 years, it might even be a working solution by then.

I agree with the CIO (1)

MobyDisk (75490) | about 6 months ago | (#47577181)

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.

Re:I agree with the CIO (1)

yeshuawatso (1774190) | about 6 months ago | (#47577225)

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:I agree with the CIO (2)

ranton (36917) | about 6 months ago | (#47577327)

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 (5, Informative)

dave562 (969951) | about 6 months ago | (#47577207)

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.

Re:Bite the bullet / replace the apps (1)

yeshuawatso (1774190) | about 6 months ago | (#47577333)

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

Re:Bite the bullet / replace the apps (0)

Anonymous Coward | about 6 months ago | (#47577491)

You replaced Notes with ... PeopleSoft? Are you a masochist? Or just a sadist?

Business in a Box (2, Informative)

Anonymous Coward | about 6 months ago | (#47577217)

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.

What are you trying to do? What are your apps? (1)

AnOnyxMouseCoward (3693517) | about 6 months ago | (#47577221)

What kind of "applications" are you building using data from your ERP system? The whole goal of having the system is to have this single, integrated software that does everything. Sure you can interface with it, but "best practices" would mandate you only do it when it's strictly necessary. Having a bunch of Excel spreadsheets running around kind of defeats the purpose of having your ERP in the first place.. I know the costs are always great, but if your ERP system can do what you want to achieve, then use it. You never know if the APIs are as great as you think they are, and I shudder to think of having to maintain 20 different applications using an ERP system whose data model might change ever so slightly over the years...

Also, plan your staffing. If you have the money to pay for Oracle, you have the money to hire one or two people in-house to manage and code on it. They can guide your consultants and keep them honest, without that expertise you can easily be wasting money. The best people are the ones that worked as developers at Oracle, don't count on people that studied to just get a certification.

Re:What are you trying to do? What are your apps? (1)

yeshuawatso (1774190) | about 6 months ago | (#47577375)

Most of the applications are for managing the data for day-to-day tasks like knowing what to work on next. The ERP is already running with few hiccups and most processes were changed to match the ERP and best practices, it's these one-off apps that were created to compliment what the ERP was missing for them to get their work done. Thanks for your feedback.

Blend It (3, Interesting)

TheNinjaroach (878876) | about 6 months ago | (#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... (4, Insightful)

Kookus (653170) | about 6 months ago | (#47577285)

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.

A Business Analyst's perspective (0)

Anonymous Coward | about 6 months ago | (#47577309)

Are you dealing with transactional data or historical data? If it's historical to perform any sort of reporting or projecting, I'd recommend a data warehouse or data mart.
You would have to spend some time determining your business processes and what you want to get out of your system.

ERP systems integrate with other systems all the time and most provide an open architecture to allow for this to easily take place via Web services or an API. One example is that an ERP is not a full-fledged asset management/work order system. It tries to be, but in most cases it isn't up to par with other EAM systems. Saying that, you still need to keep your HCM, FMS, FSCM data in your ERP. By integration with a Web service, you can create WSDLs to get data into other systems and they'll be updated via transaction or time.

The big question you want to ask is what is your system of record for each type of data. I.e. employee data would be in an ERP's HR or HCM system.

In the long run, you'll save lots of money by not interfacing but integrating and keeping your ERP as original as possible, no customizations but just configurations so you don't have to deal with problems every time you upgrade/patch the ERP or any system connecting to it.

No due diligence taking place? (2)

enigmatic (122657) | about 6 months ago | (#47577313)

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.

Re:No due diligence taking place? (1)

yeshuawatso (1774190) | about 6 months ago | (#47577571)

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-inventing wheels, something I fear for my generation.

Thanks for your feedback.

ERP strategy vs best of breed (2)

gmacd (181857) | about 6 months ago | (#47577315)

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.


Re:ERP strategy vs best of breed (1)

yeshuawatso (1774190) | about 6 months ago | (#47577589)

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 (4, Funny)

fredrated (639554) | about 6 months ago | (#47577323)

15 years solid Access experience!

Re:I'm available (0)

Anonymous Coward | about 6 months ago | (#47577515)

Step 1: replace cheap, home-built Access systems with multi-million SAP implementation
Step 2: replace multi-million SAP implementation with cheap, home-built Access systems
Step 3: repeat

ERP (0)

Anonymous Coward | about 6 months ago | (#47577335)

Many people are into erotic roleplay and the important first step in coming to terms with it is to understand that you are not a freak and that your sexual preferences are your own.

Keep ERP system customization to a minimum (3, Insightful)

div_2n (525075) | about 6 months ago | (#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 (4, Interesting)

King_TJ (85913) | about 6 months ago | (#47577401)

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 (3, Interesting)

dominux (731134) | about 6 months ago | (#47577435)

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.

Apps vs. enterprise (0)

Anonymous Coward | about 6 months ago | (#47577455)

ERP was always the one enterprise application to rule them all. Then came a Customer Relationship Managment CRM. Neither meets the goal. On the consumer side, small apps that work together meet the users needs via Application Programming Interfaces API's. And in enterprise, those Apps are replaced by spreadsheets, custom web views and other bespoke tools to help the user meet their goals. Dumping more money into the big ERP tool is just dumping more money. Give the people what they want and simplify your life with APIs and integrated apps.

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

Janhaus (3771469) | about 6 months ago | (#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.

Re:Hold up - solve the right problem (2)

bchmurray (3771471) | about 6 months ago | (#47577559)

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 systems have APIs that work sufficiently. If you have a closed system to integrate, you might have to use an interface, but make it as simple as possible. Also consider your data. Keep your financial and hr data in your ERP where it belongs and keep your other system with their 'owned' data so you don't replicate too much data back and forth. It sounds like you're looking more into a BI dashboard or some BI tools required which there are tons of vendors out there with COTS systems. Also, if you're looking to perform more analysis, you'll need to look into a data mart or data warehouse. This way, it takes all the things that are being done in spreadsheets and moves them to a server in which everyone can use and share. You'll also need to set parameters with some sort of business analyst to make sure you're doing it right. Nothing is better than getting a pivot table where the hypothesis is based upon the wrong theory. It takes lots of time and energy to determine what makes the best sense and it's not all IT/system specific. You still need to consider the people accessing your system and your processes - both present and future. Figure your business case first, then gather requirements because you'll probably find it's not the ERP which is meant to be transactional, but everyone is using the ERP to do things the ERP is not designed to do.

Software in question (1)

PincushionMan (1312913) | about 6 months ago | (#47577471)

I dunno why the poster was making a big deal of the secret; off the top of my head I can think of two Monolithic ERP systems that Oracle provides.
  1. 1) JDEdwards — has both the "cloud" version or a premise version. From experience, I can tell you the internal coding tools were not pretty.
  2. 2) Peoplesoft — probably same as above

In theory, it makes life easier for the corporation, in practice, not so much.

ERP is overpriced database (1)

Marc_Hawke (130338) | about 6 months ago | (#47577563)

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 the end of the day the ERP was nothing but a database (SQL Server) and all the day to day operations were done with custom built applications interface through API's and ODBC. Occasionally, (but rarely) there will be a business need that happens to be implemented natively by the ERP, but it's not something we count on.

One of the original suggestions was that we just 'roll our own' solution. In the end, we did, but we first saddled ourselves with a large pricetag and mostly useless support contract.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?