back to article The unrealised potential of ERP and CRM

With all of that money, time and effort expended on ERP and CRM systems over the years, you would expect organisations to have paid a lot of attention to getting the most from them, but a recent poll of Reg readers (including 66 ERP users and 65 CRM users) suggests that many implementations have some way to go before they …


This topic is closed for new posts.
  1. John.Paterson

    There's another reason....

    There's another reason why users "don't realised the full potential of their ERP/CRM system" - most CRM implementations are over engineered as the vendor/implementor set up every bell & whistle the product had. This results in users getting fed up with how long it takes to input data, or simply learn how to use the system in the first place.

    Most organisations would be better off with systems that just focussed on what they NEED to do, rather than being driven by what the software vendor said the product COULD do.

    John Paterson

  2. Bruce Ordway

    CR*P, not for the faint of heart.

    I just finished a 6 year tour of duty implementing Vantage, the ERP solution from Epicor.

    It finally went live since April replacing a 20 year old Unix MRP system.*

    The biggest problem with improving ERP now is manpower.

    It seems like choices are limited.

    Also, the whole organization is required, individuals are not enough.

    You can try to do your work or you can work on ERP processes.

    They are mutually exclusive.

    At least the software vendors are making money.

    *I used to hate that old unix system, Dataflo.

    Now I remember it with much more fondness.

    I guess I made some too.

  3. Anonymous Coward

    It's process, not package that causes trouble.

    I worked for an outfit that installed their ERP (including accounts modules) about 14 yrs ago.

    Some modules (bought and paid for) not used at all.

    Some used *very* clumsily leaving higher level functions almost useless.

    Senior management had never used serious mfg software (they could not manage to re-price their price list on Excel except by working out the new price on a calculator and re-imputting it. )

    Software is the easy bit. Data transfer (onto the DB) in a systematic manner. Staff training of existing staff, knowledge retention (so when the 2-3 people in a small company who had the training and know how the system works leave/retire/die their successors know how to use it to)

    Of course I presume that you have bothered to analyse your actual needs well enough to benchmark some packages and weed out the obvious bullshit merchants.

    Anon for obvious reasons

  4. MalagaView


    Keep It Simple is one of my golden rules... the 80-20 Rule is the other.... simple!

  5. Doug Thompson

    It's not knowing your process that causes trouble

    I almost agree with AC 21:33. I see the real problem to be that Senior Management have a limited, rose-colored vision of what the actual processes are and, thus, are easily persuaded by even a novice sales rep about the ease with which processes and shrink-wrapped computer programs can be made to function completely in harmony. At the opposite end of the spectrum are the charlatans who promise to move existing processes into custom 1's and 0's in little or no time and expense.

    SM don't like finding out all the dirty little details that comprise their smoothly running enterprise. They don't want to know that when Sherry from Shipping is out sick, nothing makes it onto the loading docks. They cannot stand the shock of learning that when Peter from Purchasing is away, orders aren't being sent out to support manufacturing. All of those Company Procedures Manuals that were created at great expense haven't been opened in aeons because the people actually doing the work have created their own processes and interfaces, and no computer system can pick up on the nuances of the actual environment. This means that entering into custom software development agreements without first thoroughly understanding and documenting existing methods and processes is a recipe for disaster. SM seem to consider collecting the necessary information to make rational decisions to be an expensive luxury and waste of time. Instead, they prefer to toss money down the crapper and then resort to lawsuits in a vain attempt to cover their own incompetence. Unfortunately, Boards of Directors are too lazy - or incompetent - to exercise their fiduciary responsibilities in matters of this type.

    At the risk of prolonging this semi-rant, the other side of the coin is trying to insert computer programs into the processes in order to supplant an increasingly ignorant and lackadaisical labor pool. Then again, this point seems too obvious to require elaboration. So I won't. Prolong it..

    CV: I have been employed as an engineer by one of the world's largest corporations and as SM for one of the smallest (my own). I have been in the midst of documenting processes to obtain ISO9000 certifications and making decisions about which software packages will fulfill realistic needs.

  6. Bruce Ordway

    bothered to analyse your actual needs? HA!

    How are these for reasons?

    1 - Management tries but can't get process/culture changes implemented. Final tactic, replace the existing MRP software to facilitate culture and/or employee changes.

    2 - Workers don't know how to get information out of the existing MRP system and attribute it to "old" software. Solution: put in "new" software. However, now the same people can't get meaningful info out of the new system. It's discovered that special training is required to get anything out of either system AND it's harder to find anybody with training on the new system.

    3 - The software company doesn't like to support the old version you're running. Install the new version but... by the time you are done with implementation, two major revisions rolled out. Now they still don't want to support you and you need that support more than ever.

    4 - End users don't like character based entry screens. They are used to the gui (thanks to Windows). Install new ERP software with a gui interface. Oops! Users soon learn that the gui is a LOT slower to navigate than the old character based entry systems. Also, now have only limited macro, Fkey & hotkey features.

    BTW, I wonder why this topic isn't getting more comments? ERP software is a huge market & I know of a great number of companies putting in new systems over the past few years. ALL of them are having great difficulties. Here in the mid-western U.S. is is a long painful story. I can think of more than a few companies who were brought to their knees when they flipped the switch on a new ERP system. Maybe those suffering just don't read El Reg?

  7. Anonymous Coward
    Anonymous Coward

    Here's an idea

    Anywhere groups of people are involved in making decisions, the tendency is this: The ones worth most get the least scrutiny, and the ones worth least get the most attention. Everyone has an opinion about the latter (``bikeshedding'') and everybody hopes someone else will have dissected the complex issues around the former and thus expects someone else to make intelligent comments.

    Another thing that struck me reading this is that beyond the massive bloat to deal with ``every possible issue'', getting at the data requires the ERP software to integrate with the ``office tools'', not the other way around. Those tools are also generic and usually rather poor quality things, despite all the features, and are from a vendor that doesn't want to extend as much as a pinky in help to anyone else. In techie's terms, that doesn't scale well. In executive terms it is yet another part of the expensive disaster.

    What it comes down to is trying to shotgun all your problems away by giving users overly complex tools that they don't even want to understand, and that don't mesh well with what they're used to but obviously don't understand very well either. On top of that the tools are supposed to embody ``process'' as documented but which isn't quite the same as practice, and thus the tools don't fit the actual task, and never will.

    To fix this you need better tools AND users better trained to use them, and probably both a procedure writer who goes around and observes what happens, then documents it to make it visible within the organisation, and a toolsmith who goes around and asks what is needed, and provides those tools to demand. How he does it, what existing tools he adapts or uses to create new tools is of lesser importance. But ``turn-key'' will never work, unless you can somehow clone your entire business and do the exact same thing as someone else using their tools. You know, like certain fast-food franchises.

    Note that I've off-handedly branded both the ERP vendors and our friends from redmond as big useless, and the money spent on them as largely wasted. I do think so, but given the rather strong opposition against ``user education'' (fostered by... you know who, very well done that) they will have some business yet. Because ``turn-key'' is still a buzz word.

    I also predict that this note will have very little impact because it asks people to think about Big Problems, which is Hard. Dealing with something small is easier so given half a chance they'll talk the colour of the proposed new bike shed over once again.

  8. Kevin Bailey

    Bespoke and/or best of breed

    We've implemented a couple of very successful systems. The key points were this:

    We had to analyse/study/document/discuss at great length what the company actually DID and what the staff actually DID and wanted before even drew up the first set of specs. These specs were then further analysed/discussed etc.

    Then we focussed on a couple of key deliverables - i.e. what did the staff and administrators want the system to do - what would they need in/out of the system.

    They now have a system which the staff 'love' - and now a core ERP system is in place it is being extended and new parts added on.

    One key part we've added is to allow read-only connections from Access/Open Office to allow some of the staff to produce their own reports - this is best when they link to some DB views we've implemented. Their own queries can produce incorrect data because they are not DB programmers.

    In some ways - traditional ERP/CRM software is never the best fit. It is too big and rarely works the way the company does. So a huge system is charged for and never works properly.

    Companies would be best off employing small companies (like ours!) to come in and work very closely with their organisation to produce a core system which works their way. And because it only has the parts which the company wants then the users don't get overwhelmed with massive bloated systems which only cause confusion.

    And companies have to understand that producing a clean system which works perfectly for their organisation is going to cost time/money to get right - but there are real benefits to be had.

    It may also then be a right fit to use other best of breed solutions as well - such as a Company Twiki, Request Tracker, SQL-Ledger etc which do their jobs extremely well.

    Unfortunately, as we know - the industry is full of incompetents who call themselves programmers - so when deciding which company to use they should look closely at testimonials from previous customers staff - not just a list of who has bought the companies products.

    For example - I know of a very large company portal/CRM/ERP/make tea system which was sold to a client we maintain servers for. The product is rubbish and the staff hate it and want to drop it - but know are stuck with vendor lock-in. So, if you go the website you see a list of companies using the system - looks good - but if you speak to the staff they'll tell you that it just wastes their time every day and is costing the company a fortune in lost productivity.

  9. Anonymous Coward


    Most haven't fallen for the bull***t pandered by ERP CRM companies who sell snake oil. Go open source and learn to bind a few pieces of well crafted software together - it's not that hard.

    Anon cause I'm not advertising or self promoting

  10. Anonymous Coward
    Anonymous Coward

    Another reason...

    ... ERP functions aren't used more is that they require so much time and effort to do anything with.

    Sure you've paid for the extensions to make quiche, but when it takes a whole team 6 months just to make not-too-burnt toast, quiche is not even a blip on the horizon. You've got to fix that toast as much as possible first, and then see how long adding a bit of jam will take.

    These bad metaphors just say that ERPs might be powerful, but good ROI seems rare indeed due to the extreme costs of implementation, maintenance, upgrade, let alone deploying new features.

This topic is closed for new posts.

Other stories you might like