If you have Progress skills, and want to work in Brisbane.. WE want to hear from you.

See the Employment page

Home arrow Articles arrow Custom systems vs. Packaged systems dilemma (agile 100% fit vs. 80% inflexible compromise at best)

Custom systems vs. Packaged systems dilemma 

Many businesses recognize the need for better information technology systems to serve their business. Often this can be a result of outgrowing the existing systems or just recognizing shortcomings and inefficiencies.

Once the quest has begun to find a new system, many businesses find themselves evaluating all kinds of ERP systems which can come in many flavours from the small to the mega-large.

The choice of an integrated package for a business is a very difficult and challenging one, and it goes without saying that the best solution will not the same for all businesses.

Customising a packaged ERP system

You will often hear horror stories about how projects failed because the users demanded massive amounts of customisation, the customised version of the packaged ERP system can't be upgraded so therefore the only answer is to go with a plain vanilla package. This is a very complex decision, but we can make some observations:

  1. Packaged ERP systems rarely achieve a high degree of fit without some customisation (most need a lot if you are to achieve savings and efficiencies)
  2. Packaged systems CAN be modified or enhanced in such a way that you do not lose any ability to take on later upgrades, but you have to plan and architect the changes "the right way".
  3. Packaged systems are necessarily far more complex than equivalent custom systems, this is a double-edged sword.
  4. Just the implementation costs for large ERP rollouts (100 users+) can often easily exceed the cost of a custom system and still compare poorly on the degree of fit. (this is counterintuitive but is due to the exponential complexity factor with packaged software)
(an interesting case study - we suspect having been burnt by a previous poor customisation effort Hawker may have gone to the opposite extreme and still not found a good result.  By isolating, planning and designing any customisations "the right way" you can have the benefits without the problems)

Some of the key factors to consider are:

  • What are the prime or most challenging processes in your business success, and how well does the proposed solution meet these needs
  • Can the proposed solution meet all the business needs, or are there still some aspects that might require a custom solution. This is a quite common problem.
  • To what degree will the business need to change to suit the system vs. Should the system be changed to suit the business.
  • Is the goal of the complete integrated package worth attaining, or can some level of non-integration be tolerated or addressed by other means (often a MUCH cheaper solution)
  • Can the proposed solution actually pay for itself – if not, the decision should be carefully re-evaluated.
  • Does the whole system need replacing or just part of it.
  • In large scale implementations (100 users and above) – is the cost of the proposed system in excess of what a custom solution might cost.

We feel the above questions are integral to a beneficial outcome, yet they are unlikely to be in the checklist of your software vendor.

Often, we see large companies spending tens of millions of dollars on a packaged solution from a big-name vendor when a custom or a hybrid solution could be had for a mere fraction of this amount.

Why is this so?

Well for a start many companies simply never consider the custom approach. They are not in the business of developing software and have no confidence that they could pull it off. It is safer to put ones faith in a large corporation with a reputation (even if it costs ten times the amount)

Often times the systems that are about to be thrown out are actually meeting the needs of perhaps 80 percent of the business quite well, but failing dismally in the other 20 percent. In this situation, again a properly integrated custom solution for the area of pain may be a good solution. At least the other 80 percent of the business would not be subjected to the agony of a new systems implementation.

Change the business or customise the software

This is one of the most difficult problems faced as part of a systems implementation. Most software vendors will advise against custom modifications of a packaged solution.

The logic behind this is as follows:

  1. The system has been developed with the best business practices in mind
  2. All businesses are essentially the same. If your business doesn’t follow these best practices it probably should
  3. Modifying the software will be expensive and time consuming and will compromise your future ability to take upgrades.

Whilst the above is probably true to some degree, it has been our experience that very few businesses are as generic as most software vendors would have us believe. Almost all will have unique needs that will not be met by a standard package. How these issues are dealt with is critical.

Accordingly, there are other factors that should be considered:

  1. A generic solution will of necessity need to cater of all manner of options for different types of businesses which may overly complicate a fairly simple task. Accordingly, have we just made the process more complicated and time consuming instead of less.
  2. Are there still some genuine needs unique to our business that can’t be easily dealt with by the standard package, or that require an inefficient workaround.
  3. Is the proposed solution unnecessarily complex
  4. Do other businesses in our industry use this package or are we being shoehorned into a solution for a different type of industry.

Typically the standard package will only be about a 70-80 percent fit, so the problem of dealing with the remainder becomes a very crucial one. Few of the options are attractive.

  1. Contract the package vendor to modify the core software
  2. Contract the package vendor to build a custom module
  3. Contract a third party vendor to build a custom module (with or without integration)
  4. Give up and find another package with a higher degree of fit
  5. Consider a complete custom package.

It is only with a very clear understanding of your needs, and of the software in question that the above can be dealt with effectively. Unfortunately, it is often the case that this level of understanding is not achieved until well into the implementation phase – after considerable resources have been expended – often after it’s too late to back out.

The mistake many companies make is thinking that they can buy in an expert that will take care of everything. Nothing beats having a dedicated team of internal experts driving the implementation/evaluation project.

If the above make sense to you – perhaps we can help set your company on the right path. Call us for an obligation free initial discussion.

see also
CIO magazine: To buy or to build? Is it better to buy enterprise IT applications, or to custom-build one of your own?


< Prev   Next >