Letter to CFO

Read my Whitepaper in ITToolBox

Dear Maa'm,

Congratulations on finally choosing the ERP product and an implementation partner!!

No wonder you are heaving a sigh of relief. The last few months have been hectic for you, hasn't it? Endless negotiations with various product vendors each claiming their product superiority, endless negotiations with the system integrators, each trying to prove that their implementations capabilities are the best in business, endless internal meetings and discussion trying to sell the concept of ERP, discussions on hardware, software, team composition, resource requirements, budgeting, convincing the top management, streamlining the finance practices of the newly acquired companies, travel....

Wow!! no wonder you are wearing that sigh of relief on your sleeve.

Now it is very easy, isn't it? You just have to implement the product and stabilize this. Isn't that what we IT Companies are experts at? Implementation should not be that hard?

Pardon me for saying this, but what you went through in the ERP implementation process was cakewalk compared to what you are about to be in.

You have a challenge ahead of you. Of course, I know that that is what you relish. If not properly handled an ERP implementation can explode on your face leaving you with a sullied reputation and your organization in a confused mess.

It has happened before. It need not happen that way in your case.

By ensuring that business and not IT owns the project, you have started brilliantly. It has been found that 90% of projects succeed if they are owned by the business against 50% owned by IT. That is good news.

There are a few golden rules that you must follow to make your implementation successful. Below in this article I am giving you a set of 15 such guidelines.

1. Have a clearly defined ERP philosophy: Think through your ERP implementation philosophy. Every ERP implementation is a conflict between process requirements which calls for customization and future product upgrade requirements which call for a vanilla implementation. Have a clear idea as to how you will handle the situation if it occurs. You could probably make a statement like " while reports customization is acceptable, the business users must make a strong case for any move away from the product features. The users will have to give the current feature available in the project, the expected feature, the cost benefit of the new process and the implementation consultant should sign off saying that such feature is not available in the product and that a workaround is not possible. Each process customization request should go thru a change request process which involve a review by the top management team."

In one of the projects that I worked on, the philosophy was clearly documented and read like "We understand that Oracle applications comes with best of breed processes which we want to implement in our organization. We are prepared to make the necessary sacrifices in terms of internal process changes to ensure that our processes meet the requirements of ERP". While this may be an extreme case, you get the point.

2. Hype it up: You are the CFO and not a marketing person. You are comfortable in the world of debits and credits and do not possess expertise in marketing. However remember that ERP entails change in the roots of of the organization. Every one in the organization is impacted. It is your duty to hype up the implementation to let the organization get ready for change. First aspect of hype is selecting the project name. Have a flashy name that every one can easily relate to. Names like 'Spotlight' and 'Transform' are passe. Have a name which communicates spirit and optimism to the organization. Spend some time on this. Having a competition in the organization to select the name is a good idea.

For continuous communication, use company newsletter and other avenues extensively. If possible start a separate news letter for your ERP implementation. Ensure wide circulation. Ensure that the organization never gets tired of hearing about your ERP implementation.

Other than those mentioned above, use the common tools like team lunches, incentives etc to ensure the hype. Your team deserves to be widely known.

3. Ensure scalability: Think through all the possibilities by which you are planning to grow. It could be organic and inorganic growth. It could be different units in the same country or different units in different countries. They may have different accounting conventions and different statutory requirements. Ensure that your implementation covers all aspects. In one of the implementations that I know, different units were kept under different business groups in Oracle. Since employees are linked at the business group level, they had severe problem handling senior managers (like CFO) who were common to all units. Ensure that you have only one business group created for your implementation.

4. Identify your key implementation objectives: This normally comes in the form of a structured statements in three parts. First part involves noting down your three main problem areas. It could be a) Period closing, consolidation and statutory reporting requirements due to your acquisition plans, b) Need for scalability due to the above reason and c) Effective project accounting to ensure correct project profitability. Second aspect is identifying the correct matrices and the current values for the same. For example for the first problem mentioned above, the matrices could be number of days taken to close the period (currently 10 days), number of days for consolidation to be prepared after the last entity is closed (another 5 days) etc.

The third aspect is to decide on the benchmark values for the above matrices. Involve the implementation consultant in this exercise and get his views. Never forget to sign off these KPIs or at least ensure that the consultants commit to these matrices from day one.

Have separate set of matrices for Finance and HR.

5. Decide on your chart of accounts: In case you are going to rollout the ERP across countries, it is a good idea to have a global chart of accounts and control access to country specific accounts using 'Security rules' available in your ERP package. The Global CoA could be a superset of all the accounts likely to be used in all the countries. For example the nominal account used for Service tax interim recovery in India will remain in the same CoA as the withholding tax account you are using in Canada. Remember to start very early in the exercise and document all your plans and actions. Make sure to create the security rule matrix linking the responsibility to the Chart of Account values very early in your implementation.

6. Select a good team: The project team comprises of the implementation consultants and the core team from your organization. Since you own the project, you have to ensure that the team as a whole has the requisite qualifications. For example, if your implementation is driven from finance process improvement perspective, you have to have implementation consultant who is qualified in Finance. At least make sure that you have well qualified and experienced consultants who can achieve the key implementation objectives mentioned above in point 4. Remember that quality of the team is your responsibility.

A key parameter in selecting consultants is their ability to patiently train the users. You must ensure that the team that you have is very passionate about knowledge transfer. Incentivize the training. Make sure to recognize those trainers who do a good job. Along with this, you must ensure that the trainees also receive good value from their training. It may be a good idea to have all the training sessions ending with a quick test to see how much users have imbibed. This is especially applicable to the core team since they are going to train the other users in your organization.

7. Spend a lot of time on set of books and organization structure: Normally it is recommended that you use a single set of books if the units share the same calendar, currency and Chart of Accounts (3Cs). This causes two constraints vis. Closing a period in one business unit closes the entire set of books and document sequencing ie. the logic that generates invoice numbers, payment voucher numbers etc is decided at a set of books level. I have seen projects where the western region is not able to close its books since the east and north have not closed theirs because all of them are in same set of books. Probably this is not applicable in your case.

The easiest solution will be to have separate set of books for each business unit. This depends on whether the period closing is centrally done or is decentralized.

8. Involve your auditors from the beginning of the project: We are talking of finance systems and controls which need to be externally audited. It is a good idea for your auditor being a part of the steering committee so that he can ensure that all the controls are put in place from an audit and control perspective. The flip side of having an auditor is that the control of the project could shift to the auditor and this is detrimental to the implementation. If you are selecting an auditor, ensure that she is exposed to your ERP product and its features. A good auditor can provide valuable inputs to your implementation based on her experience.

9. Plan data requirements early: In any ERP project, the customer is expected to provide four important inputs. 1. Product Configuration Inputs 2. Masters - Suppliers, Customers, Open POs and Open SOs for example, 3. Details of transactions - Open Payable Invoices, Open Receivable Invoices etc and 4. Test Scripts for product testing during CRP, UAT etc. For items 2 and 4 above, start preparing early - may be as soon as the implementation commences. You have to provide master information in templates which will be provided by your implementation partner. Ask him to provide you with the final version of template as soon as possible so that you can start collecting data in the required format. Mind you, most of the implementation teams will not have the correct template immediately available. Immediately availability of such template may be a signal that you have chosen the right partner for implementation.

Remember, you have to have as many masters as there are business units. So you will have a number of templates to fill up. Most of the implementations get delayed because the customer is not able to provide full and accurate data when required. Ensure that it does not happen to you.

Same is the case with test scripts. Most of the time, you see that test scripts test only the obvious transactions whereas they should focus on exceptions. These are normally the bottlenecks. Test for errors and exceptions. At least you will be ready when this happens after go live!!

10. Have clear reference values for comparison: Work on your KPIs for each process Keep them ready along with the expected improvement levels. This will help you validate the success / failure (touch wood!!) of your implementation. As you go on, try to improve upon the matrices over a period of time.

11. If you are going for a global roll out, work on the global template: You must have most of your setups and processes common across the organization and changes should be applicable only to specific local requirements. Work on the global template, sell it across the organization. Global template for example would mean a single chart of account, same payment terms, delivery terms, delivery method etc across the organization, same supplier categorization, same expense types , shipping methods, transporter etc..... These are called as sub masters in some ERP terminology. If possible make the customizations common across organizations. This exercise should consider the scalability and organizational growth requirements. You could call it ' (Your Company Name) Operating Framework' (Delta Operating Framework [DOF] for example). Remember that this is more than an ERP concept. It is a kind of cultural change that you could initiate through ERP.
 
12. Document, Document, Document: Drive your team (especially your core team) to specifically document their learning. Bring in a process of review at multiple layers of the project team and sign off so that the document moves to repository. Design appropriate incentives early in the project to document. In addition to the rigor it brings to the deliverables, it also ensures quicker knowledge transfer.
 
Another aspect associated with documentation is version controlling. Make some version control tools available at the beginning of the project. There are many such tools available as free downloads in the Internet.
 
13. Control timelines: You are dealing with multiple parties in an ERP implementation and every one will have his own requirements. Some of these are bound to cause scope creep and corresponding cost and time overruns. Watch the scope creep, make sure that it is kept to minimum. One way to do this is to demand from your core team that all their requirements must be documented and signed off during the AS IS discussion if you have one. (You may not need it if you are going for vanilla implementation or you may need only discussion on some of the management reports. ) Any scope changes after sign off of requirements doc should be considered as a Change Request and creation of CRs should be disincentivised.
 
14. Involve a third party consultant to oversee the timelines: It is a good idea to appoint a third party consultant to focus on the project plan and ensure that it is met stringently. He could also oversee the test plan preparation and UAT. This could work out to be highly cost effective.
 
15. And finally, Keep it simple: Simple is the way to go. If you have three ways of doing the same thing, go for the simplest. It may sound easy, but it is not so. There is a tendency among the implementation consultants to go for the solutions they are comfortable with, but which may not be simple. Unless you demand, you will not get simple solutions. One way to do this is to ask for minimum of three options for any problems that you face. Believe me, ERP provides this ability for most of the common problems. Have a 'Simplicity Quotient' defined with a reference value for most of your processes and try to better the reference value.
 
It makes some sense to stand back once in a while and see if your implementation is simple or it is acquiring 'creeping complexity'.

Conclusion:
An ERP implementation brings in a cultural shift in the organization. Unless handled carefully and thoroughly, there will be a tendency for it to go out of hand and the implementation landing in a mess. Most of the time, the proof of bad implementation is in the pudding of period end closure when all the accumulated mistakes pile up forcing you to do manual closure of your accounts.
Following the above 15 steps will ensure that your ERP implementation is highly successful.