ERP – ‘Jack of All Trades, Master of None?’ How to Save Time and Avoid Unrealistic Expectations when Selecting ERP Systems

Abstract:

On a weekly basis I meet with businesses looking to purchase ERP software, many of whom are looking to consolidate a fragmented system landscape. Software constraints aside, many rightly identify the ‘nirvana’ of having a single system to manage all processes. However, I see many businesses, often the smaller and medium enterprises, having unrealistic expectations of their requirements. As a result, the selection process is often extended because of an ‘educational’ phase that inevitably occurs before a buying selection can be made. So how can it be identified, when a requirement can be met by ERP functionality or whether a ‘best of breed’ product needs to be considered?

Broadly speaking, I believe the following points give an indicator when a ‘best of breed’ software product should be considered. This could also involve maintaining an incumbent system.

1)     High transactional volumes at point of data entry.

2)     Where transaction touchpoints don’t align with standard ERP transaction types

3)     Business processes heavily weighted to design, drawings and version control.

4)     Processes requiring algorithmic calculations.

5)     Needs for ‘what if’ scenario modelling either internal or external to the business.

In the article below I offer further comment to the above points and argue to what extent does this leave an ERP system as a “jack of all trades, master of none”?

Main Article: (10mins)

The functionality offered by ERP systems today is broad. This typically cements an ERP as the core or central system of businesses worldwide. Simplistically put, ERP systems allow an organisation to combine operational and financial processes to increase visibility and reduce manual processes between systems. However, many people interacting with ERP processes do so through role based access and thus only use a portion of the system. In general, it is only at the business analyst, system administrator or management level that the ERP interdependencies between different business areas is clearly understood. This level of understanding can have a profound effect on the expectations and success of selection processes.

Often with small and medium businesses there is a desire to engage multiple stakeholders in the ERP purchasing process. This is understandable given that an important part of change management is to ensure inclusivity and communication throughout an organisation. However, it can leave the business with unrealistic ‘requirements’ or expectations for a new ERP system. This is particularly pertinent when a business is looking to consolidate numerous point solutions and must therefore be prepared for some of the compromises required by ERP.

Therefore, what indicators or traits exist to indicate whether a process will reside within an ERP system or as part of ‘best of breed’ point solution?

High Transactional Volumes at Point of Data Entry

Transacting an ERP system through the user interface typically has field entry dependencies that do not lend themselves to high frequency data entry. In extremis, an example would be point of sale till systems. This data needs to be transacted into the ERP for accounting impact. However, to optimise ERP performance this is often passed through an integration. OCR (Optical Character Recognition) is another example of a system optimised for transactional volume within procurement. Typically, ‘front of house’ systems, are optimised for these high frequency/volume requirements. As a result, the requirements for the ERP are to account and not necessarily to hold a carbon copy of the original transactions; especially in the B2C (Business to Consumer) environment. Therefore, depending on volumes and the type of interaction required, an ERP might support, but not be the first point of entry in certain situations.

Transaction touchpoints don’t align with standard ERP transaction types

Different ERP systems have wide functional breadths. A common example where a point solution would be required over an ERP would be in the realms of complex or high volume (see above) contractual billing requirements. An easy example to comprehend is telecommunication or utilities billing. Often these contracts have multiple components, with base charges and other usage based elements. To complicate matters further, in the case of telecommunications, services can sometimes be stopped or resumed at short notice; resulting in high numbers of upsell and downsell transactions. Often products built to accommodate such solutions don’t have transaction types that wholly align with ERP records. However, these tools do offer standard integration points e.g. Customer Invoice, Journal Entry etc. Therefore, should a process not follow ‘standard’ ERP transaction types; it’s likely a point solution will be needed.

Business processes heavily weighted to design, drawings and version control

In a similar vein to above, processes heavily weighted to design, drawings and version control do not often lend themselves to being primarily transacted in an ERP system. However, these processes do often result in ERP transactions; for example, the procurement of prototype design components. Often however, the frequency of new items being created during design is more easily satisfied through an integration, than manually creating the items in the ERP itself. Like point one above, ERP item records have dependencies that perhaps PLM (Product Lifecycle Management) systems do not. For example, for a one-time prototype purchase, the PLM system might recognise it as a separate part number, but within the ERP for procurement purposes, the purchase order is raised on a generic part number until the product is confirmed as saleable. As a result, an investment in a PLM product, could avoid the sunk cost of increased time to maintain ERP item records.

Processes requiring algorithmic calculations

Software development resource is finite and each ERP vendor must find ways to prioritise development time efficiently. For certain businesses, much of their competitive edge hinges on processes with algorithmic calculation. An obvious example is any business that involves field service operations where employees are typically required to carry out multiple appointments per day in different locations. To ensure the best use of time, appointments are often scheduled with a combination of variables including, as an example, travel distance between sites, skill compatibility, vehicle stock levels etc. Not only does this process typically involve non-standard ERP transaction types but the algorithm required to calculate and update the schedules is likely served by a niche product, rather than an ERP system.

Needs for ‘what if’ scenario modelling, either internal or external

ERP systems typically work in the current and historical timeframes. Some transactions might be future dated and indeed some ERP reports might indicate future cash flow projection based on current transactions. Principally however, ERP is looking to capture and store transactions rather than model and project. There are two high level areas where ‘what if’ modelling and future forecasting are often met by best of breed solutions. Internal processes, for example the financial ‘what if’ scenario modelling for the business itself, is one of these. Typically, this is the realm of EPM (Enterprise Performance Management) solutions, as these systems can handle the computation of multiple forward forecasts. Usually, real-time data from the ERP will be pushed into these tools to help with accuracy in forecasting.

Secondly there are external, (customer facing), processes which align with similar “what-if” models. An example could be the configuration of a car or furniture, where there can be a high number of potential end product variants, based on different option selections. Multiple quotations, or pricing scenarios could develop if different choices are made. Furthermore, each option typically has interdependencies. For example, the selection of a seat finish might prohibit the selection of a certain structural materials. CPQ (Configure, Price, Quote) systems have evolved to support this need. Their specialty is quickly being able to allow sales teams to produce accurate quotations for customers based on often thousands of end-item possibilities. From an ERP perspective, the system needs the final item on the transaction to be able to continue the process through shipment and invoicing. However, ERP systems are not necessarily optimised for guiding an individual through multiple selections to put the particular line item on the quote line.

ERP Systems – “Jack of all trades, master of none”?

Not all ERP systems are created equal and indeed many will have a leaning towards a business type or sector. However as the above has highlighted for some processes, without the procurement of best of breed solutions, compromises in functionality might need to be made. For many businesses however, a core ERP system might handle all, or the majority of, their requirements. Even if a particular ERP system managed to consolidate processes such that 85% of the business operated in a single system, there would still likely be significant return on investment. ERP systems will always be broad in functionality, punctuated by functional depth. As a result, I believe that it isn’t fair to tarnish ERP with the “jack of all trades, master of none” statement. However, it does highlight that in selection it is important to understand any compromises being made and whether additional investment could result in creating exceptional value to the business.

Share