The wisest way to do ERP?

October 30, 2006 9:12 AM

What is the wise way for a medium or large businesses to implement ERP software?

By 'wise' I mean most likely to boost business performance and avoid pitfalls. What organisations have done this really well?

I ask this as somebody who has recently ventured a little way into the world of Oracle and SAP development having previously worked on less exalted (and often open-source) web technologies. At first site the ERP solutions seem to be a good way of dealing with the complexity and need for reliability. On closer inspection, however, they seem awfully prescriptive, inflexible, brittle and costly. Also some of the common management processes surrounding implementation (such as throwing many consultants onto a project to try to deliver it to a given deadline) seem a little dubious. This may well just be my inexperience - is it better to have a monolithic solution or something more customised and flexible?

posted by rongorongo to computers & internet (4 comments total)

This is an age-old question that can be argued ad nauseum without any consensus. Here's my personal opinion on the breakdown:

Turnkey solution: Cheaper, more stable going forward- your upgrade track is the vendor's upgrade track. You must be willing, however, to change your business processes to suit the software's workflow.

Customized: More expensive, less stable going forward- your vendors upgrades must continuously be reconciled against your customizations. Upgrades become much less frequent (if ever) and much more expensive. The upside is that you don't need to change the way you do business.

In my experience, on both the vendor and customer side of the equation at variously-sized companies, everyone wants the latter and it's a smart vendor who can steer you to the former. Mega-corporations, however, won't hear any of this and have deep pockets to spend to make your software fit their process.

The key, IMO, is in how "justifiably" unique your business process is. Everyone thinks they have some secret formula for success, and that they're a special little snowflake. The truth is that generally these processes have been built around specific people/clients, and don't scale well when you need to abstract out the resources needed to perform them. At some very large corporations, they may have, in fact, developed a unique process within their industry that is, essentially, their key asset, but these are few and far between.

Software vendors and their partners, seeing dollar signs, will often sell their software based on its theoretical customizability, offering a solution tailored to the client's process without considering the value of the process. Clients who buy into this, upon successful implementation, find their process hobbled by the software because it can't change from its highly customized state; the smart ones recognize this and move toward a more turnkey solution. The rich ones just keep paying.
posted by mkultra at 10:13 AM on October 30, 2006

The age-old answer: Don't.

No, seriously. If you look at ERP implementations, you'll see that just about every one of them has failed in some way -- and in big business, that can be millions if not billions in damage to the bottom line, customer service, and reputation. Any time you suddenly turn one system off and turn another on, and can't go back (which is the case with most), you're going to have people asking for your job, your head, and various other appendeges. The safe solution is to always keep doing things the way you have, and slowly start putting pieces in place that will help improve individual processes ... with a roadmap that will allow you to eventually integrate these pieces into one more cohesive application.

Ok, so a *few* of the common-wisdom, generalized pitfalls...
* Implementing too fast. If it's not ready, don't push the button, no matter how long you've worked on it or how much your boss is breathing down your neck. (Corollary: Sometime, the only way to know where a bug is ... is to go live with it.)
* Making too many promises, and not asking enough questions.
* Too much resistance from the line-level staff, who are afraid that they're going to be replaced.
* Bad UI. Bad UI will cost people time, especially the line level staff who at this point can generally do their jobs in the back of their heads while the rest of their brain does sudoku. Costing people time outside of the normal education process will obviously cost the company money. (i.e. by adding steps to a process that was already lengthy.)
* Bad Experience. If you deliver a frustrating experience, the software will generally cost you more in employee time, lost business, and dissatisfied customers than it will save you over the five-year amortized life of the project.
* Overcustomization. If you choose to go with a vendor who's selling you a platform, a package, and customization consulting, and you push the envelope on the package to overcome the bad UI, you'll cause future-compatability problems with upgrades to the base package... and since the vendor already has your money, they aren't going to be too quick about fixing it.

So, how do you solve those?
My personally preferred method is to roll out software slowly across different functions that all ties back into a central place.
Start on lower, less vital functions. I still remember when a comapny I worked for (10b-as-in-billion per year company...) implemented a new, in-house coded software for their estimators first. Estimators were the most vital function in the company, and they rolled it out to them first ... and shut down the entire freaking company for two weeks, to the point where they had some presses idle and jobs all bolloxed up for a few months aftewards. Don't do that. Roll it out to some task that's less vital until you're sure it's stable, then build stable parts on top of it.

I also prefer that companies develop their software in-house or from scratch with a close partner. This assumes that you can afford to pay a full-time programmer or programming team for years at a time, of course. You'll often find that in-house development or close partners have an investment in making your business more successful, and they also have to live with the consequences of their implementation mistakes ... so they're less likely to make a mistake than a consultant will.
(Hint: If you can't, you're probably not going to solve any problems with an ERP package. It'd be nice and make everyone's lives easier, but the bottom-line improvements are all incremental. When you have 10 employees, saving an hour a day per employee doesn't really honestly add you anything to the bottom line that a shared drive and an excel spreadsheet or access db won't. 100 employees is another story.)

If you go full-custom, your programmers / staff will know how things work and know what to expect. Problems get fixed faster because programmers can find the problem without using a 20-volume manual. Users are happier because "I'll fix it" sounds better than "Hmn... better call the vendor/consultant/my nephew". Using a cross-platform framework in a mature programming language (i.e. doing web applications in Rails or Symfony or some other web framework) will allow you to bring new staff members in who know that framework. Choosing something that's free and has been around for a while reduces your barrier of entry to time-only for your staff.

Contrary to popular (management-level) belief, it's easier and cheaper to find another Rails or Struts or Symfony/PHP developer than it is to dump an ERP vendor when their stuff doesn't perform. Programming languages are *generally* backwards- and forwards-compatible, whereas single-vendor solutions are generally not ... so you avoid the overcustomization lump. And generally one developer can use another one's work, whereas each ERP vendor works hard to tie you into their product line.

But most of all -- ask questions, find unanswered questions, and use the *software* to answer the questions. ERP and process revolution are all about the QUESTIONS. Every screen should ask or answer questions... even if it's as simple as "What do I need to do today?" And shut your trap until you've developed the software. I've seen more projects flop because the project manager or programmer or their bosses couldn't keep their damned traps shut and promised thread-of-gold ... and users get damned dissapointed when all they get in version 1.0 is straw.
posted by SpecialK at 3:51 PM on October 30, 2006 [1 favorite]

Thanks for these great answers. You both sound like you speak from bitter experience.
posted by rongorongo at 3:31 AM on October 31, 2006

I've commented about ERP systems on AskMe before.

I've worked as a business owner, MIS director, project manager, developer, programmer, manager, tester or user on a variety of ERP systems in manufacturing, materials management and distribution operations in a business career of over 25 years. In that time, ERP systems have truly grown up, and many of the issues that previous posters have discussed, have been overcome through business process engineering, or through improvements to ERP engines and databases. It is still true that business people who do not know their businesses can buy poor software and implement it badly, but it is harder to do with the major vendors such as SAP or Oracle, who simply don't want the headaches, and will generally steer away from such projects by structuring them to be massively expensive to do badly. So, with 2000+ ERP system vendors in the world, customers who want to do custom software development can still go to 2nd and 3rd tier vendors who may try to tackle their issues on a work-for-hire basis, but I pretty much feel that they deserve what they get and pay for.

People interested in getting on with their business do it the SAP or Oracle (or similar mature mid-sized vendors) way, and Things Work ® . These people don't have Sarbanes-Oxley issues. They don't miss accounting closes for systems problems. They don't get surprised by performance issues. They don't know what business system reliability problems are. They don't have nasty surprises in doing normal acquistions, mergers, or business unit re-alignment. They don't have unexpected issues changing accounting basis when business definitions change. They can actually manage subsidiary business structures and perform reporting consolidations on time, and with drill down functionality. They drive value added management and business intelligence applications, and they manage hella smarter. They are nimble and tough and they are ferocious competitors that develop significant economies of scale, and achieve and protect business process efficiencies as a routine part of their business. They become the "go to" guys for their industry or business sector.

The one thing I never see work (and have made something of a career cleaning up) is guys that hire programmers to implement ERP with custom functionality, unless the business is trivially simple, and they are working with a package that is as simple as core General Ledger functionality. A modern ERP package is no longer something that any single programmer, or even a small group of programmers, will completely understand. SAP R/3 Enterprise for an international multi-unit manufacturing business, with normal operations and planning functionality (Basis, FI, CO, HR, PM, MM, QM, PP, SD and WM modules only), installed for multiple languages, currencies, and national processing options, is a code base of something like 60 million lines of code, running on top of fairly sophisticated RDBMS systems, which implement a lot of business logic and package functionality themselves, beyond this. If a competent programmer attends all the SAP training he'll need to use the built-in development tools, and integrate his work properly so that his revisions and change operations can be rolled forward and validated against upgrades in a normal manner, he's going to spend about 9 months in SAP training, assuming he doesn't attend anything but the barest levels of functional training and implementation methods planning on SAP software, for familiarities sake. That'll set him, or his company back, about $200,000, and at the end of it, he'll be a loose cannon, with a dangerous ability to thoroughly screw up a good system, if his SAP training isn't matched with significant programming and design experience, and additional training in business, accounting, and management. The very last thing any one wants these days are code monkeys loose in the versions repository, reading source to try to understand what they are about to modify.

Basically, nobody but SAP sees value in training ABAP programmers any more, and it's really not such a useful skillset by itself, for the reasons I've cited above. There are other reasons for this, too, as interface packages mature, and more of what once were customization needs become defined as external interfaces to external applications/systems. As an example, for some business areas, where "human expertise" is considered desireable (logistics, forecasting, etc.), "heuristics" applications are available to permit the human experts to interact with the ERP system through validating interfaces, without jeaprodizing the core ERP system functions.

As to your "bottom line" question "is it better to have a monolithic solution or something more customised and flexible?", I'd say that the lowest risk, highest return answer is to implement standard ERP packages on proven methodologies. SAP or Oracle may not be the perfect solution for all businesses, but the businesses that successfully implement these systems will perform so much better than those who don't, that the successful implementors become the market leaders. ERP is increasingly a foundation on which higher level management applications in BI (business intelligence) and GRC (governance, risk and compliance) are built. Since the power of the derivative applications is enormous, no one running a complex, expanding business can do without them, and so low level functions in ERP systems have to be solid.

At the low end of the complexity range, small businesses operating on low margins may not be able or willing to afford the costs of full ERP systems, nor may they immediately benefit from the features that systems such as SAP and Oracle offer. If I were running a small machine job shop in the Southeastern U.S., without ambition to grow the business beyond current size, I doubt I'd need or want SAP's job cost control functionality, or that my customers would pay for it. My keys to remaining in business are probably not efficiency or cost management, but some level of service relationship to my customers that cover my inefficiencies. The problem with this kind of thinking however, is that we live in a shrinking world, and such relationships and the assumptions on which they are founded, are more and more fluid. It's just harder and harder to remain local and invisible in a flatter and flatter world.
posted by paulsc at 3:53 AM on October 31, 2006 [1 favorite]