GDPR Declaration !!

I am not collecting any personal information of any reader of or visitor to this blog. I am using Blogger, provided by Google to host this blog. I understand that Google is using cookies to collect personal information for its Analytics and Adsense applications.

Thursday, July 23, 2009

Analytical V/s Transactional Information in an ERP Implementation

Based on the type of decisions they help to make, information can be divided into two types. One, analytical information and two, transactional information. Analytical information is a derived information. This information is derived (summarized, detailed, complemented) from the information that you enter in the transaction system. Analytical information help the organization to analyse the data. This is used mostly by managers and senior management in making managerial and strategic decisions. For example, a trend of purchase price of a raw material is an example of analytical information. Normally you do not take a business decision (like increasing the selling price) based on a single jump in the procurement price. Analytical information might ultimately end up generating a transaction decision (organization deciding to increase the selling price) but the main purpose of the analytical information is to help the organization analyse the transactional data.

Transactional information on the other hand is an information which help to take a decision in the current transaction. This is mostly used for making tactical decisions at the operator level. For example, checking of quality samples is a transaction information. Based on an output of quality testing, the organization may decide to discard a production run altogether. The decisions based on transaction information is short term and immediate and alter the flow of the transaction. In jewellery industry for example, any change in the procurement price is reflected in a change in selling price. In this example, the procurement price of gold is a transactional information.

The above is depicted in the diagram below.

The above differentiation has a lot of implications in ERP solution design. First of all, a consultant should know if a particular requirement relate to data input or analysis. This decision is easy in case of some information and for others will need judgement from the consultant. If it is related to data input, it is probably a transactional information and the system should be configured to capture the information. Take the requirement for 'Product Segment wise profitability' for example. This requirement implies that the information on product segment should be captured in all the sales and material transactions and the same should flow to GL. This is an example of transactional information. System should be designed to capture this information in all the relevant transactions. Since analytical information is used to for analysis and reporting, it need not impact the transactional flow and hence need not be configured in the system. For example, if fluctuation in Procurement price is an analytical information, every single fluctuation need not be captured in the item cost. You can design a report that will provide the analytical data that you want from the above information.

Unfortunately this does not happen in real life implementations. A consultant who creates a GL flex field to capture the customer master is converting an analytical information into a transactional purpose. Another example could be that of a consultant increasing the number of balancing segment because client wanted 'Product (or State) wise trial balance'. Or that of a consultant designing an elaborate procedure to provide accurate 'average' price based on every little fluctuation in Procurement price.

Transaction information, as mentioned above, impacts decisions relating to the flow of transactions. Normally, the system should be designed to capture this type of information. Remember that the transaction information will most likely be used for analytical purposes, but the chance of analytical information being used for transaction purposes is very rare.

Let me illustrate this difference with another example typical in a manufacturing industry. Let us say that the customer has two production lines (Line 1 and Line 2) to produce the same product. Both lines are identical in nature. The requirement is to capture Line wise efficiency. How do you do it?

The transactional approach is to create two separate routings for the same product. When you create a production order, select the correct routing and proceed. This is a simple solution, configured by most consultants.

There are problems with this approach. Some products allow only one 'Active' routing. If this is the case, then you will have to complicate the above solution by adding a customization to 'activate' the selected line and 'deactivate' the other.

See how the solution is becoming more and more complex?

The analytical (and leaner) approach will be to create a single routing, and enter line number as an additional information while creating a new production order. This enables you to get the required information, 'Line wise efficiency', while keeping the solution leaner and efficient.

(This is an example from one of the projects that I had worked on)

As a consultant, it is very important for you to differentiate the information requirement into the transactional and analytical categories. This will help you in creating an optimum, leaner and efficient solution.

1 comment:

Cooking4yosoul said...

I was recently turned down a job that required the use of SAP/ERP. They told me I was too analytical but not transactional enough. This really cleared it up for me. I need to enroll in an ERP course.