Why you shouldn't underestimate cloud ERP consultant costs

The marketing messages coming out of the big cloud and SaaS suppliers have changed recently. Initially, the big selling point for these types of systems was that they were going to be cheaper to implement and run because companies would not need their own IT infrastructure and staff to support them, but nowadays the message is that they are quicker and easier to implement. That claim is, in turn, backed up by several supporting statements:

• systems are pre-configured to support 'best practice' (and who wouldn't want to adhere to best practices?)
• adopting best practice much reduces the risk of a failed implementation because many companies have walked the path before, (and surely best practices can't fail?)
• because the systems are standardized, the vendor's consultants and system integrators have extensive experience in implementing them (your project will just be a minor variation on dozens that they have done before, so the risk of failure is further reduced)

There is an element of truth in all of these but they all rely on having standardized systems that don't vary much from customer to customer. And this is where users of such systems have got to accept that they are going to have to make some changes to what they do and how they do it.

Of course, system suppliers have a major challenge also because their best practices have to cover a range of different companies and different industries.

Identifying, for example, the best practices in materials issues that are best for both pharmaceutical manufacturers and furniture manufacturers, best practices in sales order processing for both specialty vehicle manufacturers and consumer goods distributors, and best practices in credit control for both B2B and B2C companies is not something to be underestimated.

But the concept of best practice is key to cloud and SaaS ERP systems because it allows the authors and vendors to ensure that companies (especially those using multi-tenant systems) are all using the same system.

Inevitably that requires that companies be both able and willing to change their business processes because these systems don't have the range of functionality options that 'traditional' ERP systems have (and they never will have because offering too many options goes against the idea of standardization and, in many cloud systems, can be either impractical or impossible anyway).

In looking at how this affects consultancy requirements, it is necessary to consider the two broad strains of consultancy that companies need. They need management consultants who can help them define better business practices and then help them with system selection, and they need implementation consultants who can mold and configure the software so that it enables and supports those practices.

With Tier 1 systems, these two sets of consultants may be supplied by one consultancy or SI (system integrator) whilst, at the other extreme of small Tier 3 projects, they may be the same person.

In the past, consultants would have worked with their clients to identify where they wanted to be in the future and would have then helped them identify and select a system to get them there.

But nowadays, with Tier 1 systems, there may be savings because choosing one of the large consultancies to aid with the selection of a system effectively chooses the system, because they all have symbiotic relationships with one or other of the large providers and cannot be reasonably expected to recommend anything other than their partner's system.

Turning to the implementation consultants; their job is to understand the client's requirements and to configure, as best as they can, the chosen system to deliver as much as possible using standard functionality and then to develop acceptable workarounds or to specify any modifications and enhancements that are required to fill the gaps.

Their problem, when working with SaaS systems, is that most of these, as previously mentioned, do not have the breadth and depth of functionality that mature on-premise systems have. This requires the management consultants to know and agree with the system suppliers on what the best practice for their clients is and on their ability to persuade those clients to change their business practices if they don't match what the system offers.

Avoid these 5 common cloud ERP mistakes with our free guide

With Tier 1 systems, the management consultants will be aware of what the system can and cannot do but, when looking at Tier 2 and Tier 3 systems, because they usually work with a range of systems, they generally do not have detailed knowledge of the system being implemented.

They may also not always agree with the system vendor on what best practice is, so there can be considerable to-ing and fro-ing between management consultants and implementation consultants before a system configuration can be agreed on. The implementation consultants will simultaneously be hampered because 'best practice' gives them a much-reduced palette of options and functionality to work with so their ability to mold the system exactly to customer requirements is further limited.

But consultancy costs don't stop at system design. However many companies believe themselves to be adhering to best practices already, inevitably there will be instances where their opinion on what that is will differ from their system provider and consultants.

When that happens, they will have two choices: to concur with their consultants or to identify acceptable ways of working within the limitations of the system. If they concur, they are going to have to change the way they operate. For example, they might have to change the way they cost their products, the way they price and sell those products or the way they issue those products.

All of these changes need to be identified, their impact assessed, data restructured where necessary, and new operating procedures developed and tested. Then staff will need to be trained in new ways of working. But there may well be times when, on specific issues, individual companies don't feel that they can, or should, change the way they work.

Take material issues as an example. Many systems insist that issues must be carried out on a FIFO (First in, first out) basis and, indeed, in most instances this is unquestionably best practice. But there are exceptions. Take a company that purchases particular items from more than one supplier; either to take advantage of special prices or because their first choice supplier cannot satisfy all of their immediate needs.

When the items are delivered, it can happen that the items that came in last actually have the shortest shelf life remaining. When that happens, companies want to issue on a FEFO (First expired, first out) basis, and few would argue that they shouldn't. One option would be to pay for modifications to the software but, with Cloud and, in particular, multi-tenant SaaS systems, that can range from the expensive right through to the impossible.

More likely, they will have to pay for their implementation consultants to come up with acceptable workarounds that then have to be tested and documented; the alternative is to build separate systems outside of their ERP to handle these exceptions even though that might also mean developing bespoke routines and procedures to handle the transfer of data to and from the main system.

Either way; the current comparative immaturity of some Cloud and SaaS systems means that they are not yet the “plug `n go” systems that we want them to be. That said; they remain a valid option for many companies but those companies need to be very sure of what they are getting for their money, and how much they will be required to change so that they don't get unpleasant surprises after the contracts have been signed.