The 'How To' guide to ERP Solution Design: Part 1

Having elicited the requirements, (Check out my article on 'The How to guide to Requirement Gathering'),  and having documented the same, you are now ready for the next step in your ERP Implementation

Solution Design.

As you read in my post on Requirement Gathering, the process ends with you preparing the MOSCOW List. If you remember, MOSCOW is an acronym for Must Have, Should Have, Could Have and Wont Have. It groups the requirements based on the above criteria. The advantage of MOSCOW list is that it helps you to directly focus on the top requirements that fall under the 'Must Have' and the 'Should Have' category.

Lets get to work.

The most important point to keep in mind while designing ERP Solution is this. There are two types of configurations in in any ERP. One is the permanent configuration. Once frozen, and after the first transaction is entered in the system, these cannot be modified except at a significant cost to the implementation. The others are the rest, the modifiable configurations.

Suffice to say that, one, the consultant should be aware of this difference, two, thoroughly educate the customer on the difference, three, give multiple solution options to the customer on those configurations that are permanent in nature.

The starting point in an Oracle Implementation is the design of Organization Structure. You have to place your HQ, the plant, the warehouses, various sourcing offices and the branches in some sort of logical grouping that the ERP can understand. While this looks easy, it is not very easy. While the mechanical aspects of design is not very difficult, it is the task of logical grouping that can prove to be a tough cookie. The problem is compounded by the fact that, this is normally the first task in ERP implementation and the consultants as well as the customer are only starting to wet their feet into the mired world of ERP.

While designing the Organization Structure, you have to consider the following impacts.

• Simplicity and ease of maintenance
• Intuitive
• Country Localization Requirements
• Impact on different applications
• Accounting and reconciliation requirements
• Access to Banks and Bank Accounts

It is better to give this time as it is the structure the organization has to live with for the rest of its life. ERP offers multiple options to design your organization structure. Take it slow. Understand that ERP offers multiple options and accept that as a consultant your knowledge may not be complete. Take your time to understand the physical structure of the organization. Work with the customer.

It is not easy. I can bet you this. If you go and ask 100 companies that are on ERP as to what is the one thing that they will change in ERP if given an option, 80% of the responses will be related to Organization Structure.

It is that important.

Lets say that you get the structure right. The next major design element is Chart of Accounts. The most important aspect of Chart of Account design is to get the balance between accounting requirements and reporting requirements. Yet another aspect is to consider the future expansion plans of the company. You can check out my article on Global Chart of Accounts for details of the design considerations for CoA

Having completed the design of Organization Structure and your Chart of Accounts, now you are ready to start with the requirements list.

MOSCOW List is the only document that you need to consider for your solution design. If you have done your MOSCOW list correctly and got it signed off from the customer, you need to focus only on that list.

Read my article on Requirement Gathering to refresh upon MOSCOW List.

Start with the 'Must Haves'. These requirements are critical to customer and have to be met by the ERP System. Customer is almost unwilling to change their process to suit the capability of ERP. For example, in one of my implementations, the customer was insistent on 'Specific Costing' (Check out my article on Costing Methods and Inventory Valuation and related articles) and the product vendor had to design a costing method to handle this process. If the requirement is a 'Must Have' and if your ERP do not handle this, then the same has to be customized.

Once you identify the 'Must Haves', the next step is to do CAR.

CAR (Causal Analysis and Review) is a process of reviewing the requirements and coming out with multiple options to meet the same. Always under time pressure, the natural tendency for a Consultant is to latch on to the first solution available for a requirement, freeze it, and move on. However CAR works on the principle that for every requirements, there are at least three solution design options possible and normally the third option is the optimum option.

CAR forces the consultant to think beyond the first option, identify multiple options and come up with the pros and cons of each option. CAR is one of the ways in which the consultant can add significant value to the customer.

The customer should ensure that CAR is followed for each requirement in the 'Must Have' and 'Should Have' category in the MOSCOW List.

Many ERP consultants get stressed out a lot when it comes to 'Must Have'. To me 'Must Haves' are simple. You either handle it through standard application or customize the same. The decision is much easier and quicker when it comes to 'Must Haves'.

It is the 'Should Haves', that should ideally stress out the consultants. These are process which the customer is ready to take a re-look at. In case of these, the consultant should give a cogent reason as to why the customer should modify his process. Most of the time the reason given is that ERP doesn't meet the processes and hence customer should change their processes to suit the ERP processes. That is not a valid reason to ask the customer to change his processes in my opinion.

The good news is that if you rigorously follow CAR, the best option will automatically be generated based on the analysis. Most of the time, the first solution option given for a 'Should Have' is a complex ERP standard process where the customer has to navigate multiple windows, click on multiple buttons, enter mandatory data in some obscure field lying in the fifth window....

You get the idea. Such solution options will quickly lead to user disenchantment with the solution, and with the ERP. The rigors of CAR will ensure that such issues are identified much in advance and can be easily arrested and customer can be given an excellent ERP system to work on.

One key caveat when it comes to Solution Design is this. Never create / modify a solution to meet a specific document requirement. Wherever possible, modify the document (or the solution to generate the document) and keep the solution simple.

Let me give an example.

In India, we have something called a 'Form H' sale. If a manufacturing company is producing something for sale to an exporter, who in turn is going to export the same, then that sale will not incur any Sales Tax. Such sales are known as Form H Sales.

For Form H sales, there is a document known as Form H Document, which has to be submitted to the Tax authorities. The key requirement in Form H document is a running sequence number.

What are the two flows involved here? (For refresh on various flows on ERP, check out my article on '7 Flows in ERP Implementation')

One is the document flow. Form H document with a running serial number has to be generated. And the other is the material flow. Material flows from the manufacturer to the exporter. 

What is the critical requirement? Form H Document with a running serial number.

In this specific case, both manufacturer and exporter are two different companies under the same group. Essentially the material is being transferred from the manufacturing unit of the company situated in one location to the exporting unit of the same company situated in another location.

What are the multiple solution options available here?

One option is to use the IR-ISO process. In IR-ISO process, the exporter in this example will create an Internal Requisition (IR) on the manufacturer and the manufacturer will in turn create Internal Sales Order (ISO) and ship the material to the exporter based on the ISO. The exporter can do an Internal Order Receipt of the same item. This transaction will automatically generate Form H Invoices. 

Another simpler option is to do the material transfer from manufacturer to exporter to handle the material flow and create a Form H report to handle the statutory requirements.

Option 2 is simpler and has many more benefits like elegant design (Check out my article on Elegant Design in ERP), intuitive process etc. Will the customer accept it? I don't know, but it deserves to be placed on the table.

If CAR was done, both the options would have been on the table. Since each design option has long-term maintenance implications, it is all the more reason that these are discussed thoroughly. 

Another concept that is useful to a consultant is 'Normalization'. This is a database design concept which helps to handle data redundancy and various data related anomalies, like insert, update and delete anomalies.  In ERP design, the primary focus is on eliminating redundancy. This is especially important when designing customizations since standard ERP Applications are designed to eliminate redundancy. Many a times, when designing customizations, the tendency is to replicate the data with all the details in both the custom tables as well as the base tables. In many custom designs, you will observe that the same data is lying in multiple tables leading to waste of table space (Read my article on how ERP can be used to implement Lean) and data mismatches. One has to ensure that different views of the same data are available in different tables and in different applications. For example, when you import an invoice from another application, the details can lie in the initiating application and the summary can be brought into the Payables application. This will create an elegant design that eases maintenance and improves system performance.

I want to finish this Part with one of the most important design considerations that gets missed in almost all implementation. Naming Conventions. These are one aspect of ERP that lingers, that adds value, that reduces waste and that increases customer satisfaction. Without naming convention, your implementation is worth only 25% (It is a conjecture, but I guess many senior professionals will agree with me), with Naming Convention, the satisfaction level improves. Use naming convention wherever possible, it adds value everywhere. Also, they are great to generate analytical reports.

There are other aspects to be considered like, 

• Always consider the flows when designing the solution
• Always consider financial impact
• Start from reports
• Avoid customization wherever possible
• Differentiate between Transactional and Analytical information.
• Start from the user perspective

I will cover these in the Part 2 of this topic.

How did you like this article? Your comments will help me to improve the quality of content of my articles.