back to article Challenging accepted ERP wisdom

So you've been through an ERP implementation before and you know how it's all done? That’s good to hear, but if your experience was a few years ago, it might be worth taking a look at the way things have been changing. The truth is that anyone reviewing their ERP requirements today won't be doing themselves any favours if they …


This topic is closed for new posts.
  1. ZedroS


    Funny, I read some time ago a study by some MIT researchers that in fact there is nothing like "industry accepted best pratices" and that companies should rather try to figure out their own practices based on their own needs and contexts.

    For sure, it didn't say that they shouldn't look at what is done around, but still it was about adapting and not just copy/pasting. Meaning that something working for some companies could very well fail for some companies in the same ballpark, depending on the context.

  2. Anonymous Coward
    Thumb Up

    What do you need?

    Agree. Thoroughly understanding what your 'enterprise' requires, through mapping out and refining the processes, prior to comparing the ERP options and deciding, is also recommended.

  3. MattCumb

    2-speed ERP

    I have some sympathy with the idea that "big iron" ERP isn't suitable across the whole of a multi-division environment, and that a more flexible solution is worth considering for the more dynamic parts of the business to sit alongside ERP across the rest of the enterprise. However, what has never been clear to me is what happens if/when that dynamic business matures and becomes the cash cow, where you want to squeeze out cost and milk the revenues (more akin to traditional ERP).

    When comes the tipping point where you consider migrating from the "flexible" solution to the "inflexible" one? Is that really a viable thing to do, or does that end up breaking the uniquely value of that dynamic business? Would it be better to accept the extra investment up front and go big iron straightaway, with a governance approach which permitted the fall out from dynamic businesses which don't end up maturing but which you've invested money on getting into ERP?

    Also, how do you prevent the proliferation of point solutions for the dynamic businesses and hence watering down the scale benefits from your core ERP? Simple answer is governance but don't you need the "critical mass" of an enterprise wide ERP to get governance to work?

  4. Paul Chambers

    One size fits all ERP against integrated specific tools.

    I think the view that is expressed in this article is interesting, but then I would do because in practice I reached a similar conclusion.

    For my MBA dissertation it was my intention to do a case study on the implementation of ERP within my organisation. This plan was somewhat compromised as in the process of that implementation, and after a change in emphasis within the various business units that compromise our organisation, a decision was made to use specific dedicated tools that communicated across the functions, rather than integrated them into a whole.

    From an implementation point of view, particularly from an IT perspective, it is 'easier' to deploy one comprehensive system. However the ability to find one system that is a good fit for all practices and operations within a diverse organisation is challenging. It often means compromise, customisation and alteration of existing processes. This can undermine the advantages of an integrated system making it cumbersome, inflexible, and hard to maintain. It is also likely that overall cost of purchase and deployment will be high.

    Choosing small dedicated tools for specific processes means that a better fit for individual work processes can be found. This allows more 'out of the box' solutions, making maintenance and upgrades easier, as well as no one failure rendering all business functions inoperable. It also allows more readily for change within autonomous business units or processes. The additional effort required is in getting the diverse tools passing necessary information required across processes.

    From an IT perspective it requires a more complex infrastructure, nevertheless I think it can benefit the performance of the business.

    It might not have been the intended focus of my dissertation, but you may be relieved to know (as was I) that this conclusion at least allowed me to satisfactorily pass my degree.

    Clearly it isn't the correct approach for everyone, but it certainly should be considered. The managers in our business units are happier, and have bought into the process more - quite simply because the business software they use is of their choice rather than an imposition from elsewhere. Unfortunately it's more onerous for me, but you don't run a business to please the IT function any more than you should rely on accountants for innovation.

  5. John Smith 19 Gold badge
    Thumb Up

    Interesting and sensible stuff

    One (hopefully) obvious point with this hub and spoke model is the issue about data transport.

    At the *very* least this should allow summary data transfer to allow divisions to seamlessly pass data upstream. Ideally it would allow a data migration path so that if the whole corp does mature into a "cash cow" they can be phased out in favor of the centralised low operating cost system.

    These are fairly dull issues, unless no one has checked up on them and they bite the team on their collective butt.

This topic is closed for new posts.

Biting the hand that feeds IT © 1998–2020