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

Check out Part 1 of this article before you read this.

Some of the concepts that I mentioned in Part 1 included Design of Organization Structure, Design of Chart of Accounts,  MOSCOW list, CAR and Normalization. In this article, I will talk about a few more concepts including:

• Consider the flows
• Architect your solution
• Consider the stake holders
• Always consider financial impact of your solutions
• Start your design by looking at the reports
• Avoid Customization
• Differentiate between transactional and analytical information
• Always consider the end user

Lets get to work.

There are 7 flows to be considered in any ERP Implementation. (You can check out my article on 7 Flows in an ERP Implementation). These are Business Flow, Process Flow, Material Flow, Document Flow, Accounting Flow, Report Flow and Data Flow. It is very important for the consultant to understand these flows and consider the flows separately as well as together when designing the solution. For example, in the example of Form H that I mentioned in the Part 1 of this topic, you must consider the flows separately when designing a solution. However, on the other hand, if you are designing a Procurement Process for example, you have to consider the Process flow, the Accounting Flow, the Document Flow and the Data Flow together. Ultimately, the decision on which flows to consider, is a call that the consultant has to take.

Having considered the Flows, you have to start with architecting your solution. Ideally, this should have been the first step. There are multiple architectures that the consultant has to consider as I mentioned in the article in this blog on architecting your solution. These include Overall Architecture, the Context, Application Architecture, Infrastructure Architecture, Information Architecture, Operation and Control Architecture and Security Architecture, to name a few. I have observed that even when the consultant (or a Solution Architect) considers the Architecture, they end up considering only the Application Architecture. 

While designing the solution, the consultant has to keep in mind the Stakeholders. The obvious stakeholders are your Project Manager, Consultants designing the other flows,  your Organization, the Customer Project Manager, the Customer Senior Management, the Auditors who will Audit your system, the key users and the end users. Some of these stake holders are 'in your face' (like your PM, the Key Users and maybe your team members). Some others, like customer senior management, Auditors, the end users (Yes, I am not kidding, the End Users are the major stakeholders that one do not consider in a project). I will talk more about the end users in a later section of this article. 

Next one is a no-brainer that gets missed in many an implementation. Consider the Financial Impact of your solution. This goes together with the point on the flows that I mentioned previously. When you consider a specific process also consider the accounting impact, the configuration requirements and the PL or Balance Sheet Impact as it were. If you do not consider this in the early part of the solution design, it can come to hit you very badly at later stages of the project and sometime the whole solution might have to be reversed and revised at a lot of cost to the project (and to your reputation as a consultant !!)

You have to start your design by looking at the reports. I had mentioned the point of looking at the reports in my first article on the 'How to guide' series, The 'How To' guide to ERP Requirements Gathering'. Reports tell you what the organization consider as important to run its business. It tells you what the senior management consider important to run its business. It tells you what each stakeholder consider important to run their tasks. If you start with reports, you will never miss out or ignore any stakeholder. Reports are your links to the stakeholder.

Differentiating between 'Transactional and Analytical Information' while doing the ERP Solution design is very important from the perspective of designing a 'Lean' solution. Transactional information is 'Original / Input' data. This is the information necessary to complete the transactions from the customer's point of view. For example, while entering a PO, many customers will need to enter Organization Specific additional information. These are transactional information. You have to design the system to capture the transaction information.

Analytical Information, on the other hand, is a derived information. It is derived by mathematical and logical grouping of various transactional information. Many a time, the analytical information can be obtained by looking at the reports. The system should not be configured to capture Analytical Information. These need to come out in analysis reports.

Many a time, there is a blur between the two, and that is where a good consultant scores over the average consultant. A good consultant can intuitively differentiate between these two information. A classic example, is for the customer asking 'Branch wise Trial Balance'. In Oracle Apps, the moment a consultant hears the word, 'Trial Balance', he / she will create a Balancing Segment. This is the first and the easiest option to get a trial balance. But is that what the customer wants? Probably he meant Branch wise profitability statement. If he / she meant trial balance, how are they getting it now? Is he maintaining assets at the branch? does he require that tracking?

Assuming that he wants it, is creating a balancing segment, the best option? Is it the only option? What are the implications? Can you think of other options, for example, creating branch as a separate segment and configuring the system to ensure that transactions balance at that segment?

Either way, trial balance is an analytical information and you should hesitate to configure the system to add data entry to capture analytical information. Ideally they should be derived from transactional information.

I can show many examples of bad configuration. Of configuring the system to capture analytical information leaving users to struggle with data entry. In some cases this has led to users losing faith in ERP.

That takes me to my last point relating to ERP Solution design. Always consider the end user while designing the solution. Some of the questions that you should ask should be related to IT Savvy of the users, the type of access of the users to the system (Local or Remote), the type of data that they are accessing, the network capabilities etc. The consultant should visit various sites and interact with the final set of users to listen to them, understand their worries and concerns and take care of their data input, data analysis and data usage.

That winds up the section on Solution Design. I hope that this has been useful to you. Kindly give me your views on this article.