Getting data right – what the ERP Seller does not say

We are struggling with an ERP implementation in one of our assignments. Most of the time is being spent in reconciling data specially in Finance and Accounts. The company does not maintain fixed asset register and hence it does not have details of fixed assets. The fixed assets shown in the Book of Accounts are not mapped with fixed assets available physically. After months of effort, the accounts team and the plant team just gave up. After working 20 years in silos, it was too much of an effort for them to come together and reconcile what they all had done independently. Now they want two datasets for fixed assets. One for the production planning with physical data of machines and one for depreciation based on data with finance and account.

This is one example of problems with data that companies face when they migrate from legacy systems to ERPs. Some of the other problems are :

1. Setting up opening-balances in books of accounts – The chart of accounts invariably changes once any kind of ERP is adopted. Most companies assume that once they close their books of accounts, it would be easy to setup opening-balances. But it sounds easier than it actually is. The companies change their chart of accounts, that is, account codes. The companies also introduce cost centers or use more cost centers than they were using in Tally or Busy. ERPs facilitate use of multiple cost centers and most companies do not want to let go off this chance. To give some examples,

a. Vendor Balances – The company may have multiple plants. It may have vendors that are common across plants. It may happen that in Tally all of them are clubbed together. Once the company moves to ERP, it would like to segregate payable balances for each plant. In which case, it will have to analyze statements of each vendor and establish plant wise balances before the balances can be uploaded into the ERP. Ideally if they can take some transactions of previous period, especially open or active transactions, then that would be the best option.

b. Expense Breakups – Expenses is another such example specially, travel expenses. Historically most companies have one or two accounts for travel expenses. Once companies adopt ERP, they also like to break up the expenses into 2-3 account codes for easy analysis. For example, breaking up travel into fare, daily living expenses and other incidental travel expenses. Any comparison with prior period expenses will make sense only if the opening and in-period balances for last fiscal year are also segregated and setup accordingly in ERP.

2. Messy Database – ERP provides a central database but companies may have duplications in their databases. At times, different departments or locations may use different codes, notations or terms for the same item. For example, when Nestle implemented ERP, it discovered that there were 36 item codes for vanilla. ( https://mentorsunlocked.com/nestles-vanilla-problem/ ). ERP helped Nestle rationalize all of them into one item code. This also helped them negotiate better and get better rates. However, such problems become tricky when discovered in the midst of implementation. If different sites/ departments use different item codes, they also become defensive when it comes to changing them. Building a consensus amongst different stakeholders can become tricky if any of the existing term is picked up. Sometimes such duplications and redundancies in data may not get discovered.

It becomes easier for the companies if they can discover such surprises before they embark on their ERP expedition and address it before the ERP implementer comes. Such surprises during implementation are the major cause for delays.

In ERP, if a data point is updated at one place, everything else gets updated accordingly. The resultant benefit is that the departments have to coordinate and cooperate with each other. For example, if an asset is sold, not only will it have to be written off in asset register but also in books of accounts. The depreciation would get calculated automatically. The staff would save lot of time in reconciliations resulting in improved productivity and, more importantly, managers get data they can rely on for decision making.

Similarly, if the companies can review their codes and develop codes before the ERP implementer comes in, they will save lot of time and money. Therefore, we, as ERP Consultants, advise our customers to fix their data before they plan to implement ERP. There is no rush to get into ERP implementation. In fact, our approach with our latest client is as follows

This will not only help us in identifying the right ERP solution but also help us get the right implementer.

Diwali is round the corner and so is the beginning of a new Hindu financial calendar. Let us put our best foot forward in our ERP journey.