How can you use ERP to create 'Lean' Organization?

Introduction

The concept of 'Lean' is the adaptation of Toyota Production System into western manufacturing processes. The lean involves elimination of any non-value adding activities to ensure that the customer pays for only value adding features in the product. The five principles identified in Lean are:

1. Specify what creates value from Customer's perspective

2. Identify all the steps along the process chain

3. Make those processes flow 

4. Customer Pull rather than stock push 

5. Continuous removal of wastes. 

The principle of Lean identifies 7 wastes. These are:

                                                                                                                                     

1.   Over Production

2.   Over stocking of inventory 

3.   Waste of transportation 

4.   Processing wastes 

5.   Waste of idle time 

6.   Waste of operator time 

7.   Waste due to bad quality 

While the above wastes are related to manufacturing processes, there are many hidden, unidentified wastes in an organization. Most of the time, these wastes are generated due too years of suboptimal business practices.

This article is divided into three sections. In the first section of this article I point out some of the non-manufacturing wastes that keep piling up over the years and make the organization suboptimal. I follow this up with some design considerations that the ERP Implementation Consultant can use to ensure an optimal, high class ERP Implementations. And in the third and final section, I illustrate the implementation of these design considerations by focusing on Oracle General Ledger module as an example.

Various Wastes in any organization

Years and years of inefficient business practices lead an organization to progressively perform at a suboptimal level. These practices lead to many wastes in the organization, none of which are related to manufacturing processes, and which together make the organization slow, lethargic and perform at a significantly lower potential. Some of these wastes include,

1.    Waste related to Obsolete data: The record books of most of the organizations are teeming with reams of obsolete data. The data gets piled up over a period of time, year after year, without the organization not even being aware of the piled up data. Examples include Obsolete stock, Inactive suppliers, Inactive customers, Delayed (and sometimes Forgotten!!) receivables, Delayed payments which has incurred late payment penalty, Open Purchase Orders without any transactions, Inactive Customers data etc.

2.    Waste related to bad naming conventions: Sometimes badly designed naming convention can cause wasteful data. I have seen same customer created by different users in the same organization. While one created customer as XYZ Ltd, another created as XYZ Ltd. And another created as XYZ Limited! This happens because the organizations do not have a well designed naming convention in place, and even if a naming convention is available, there is no disciplined process to ensure that it is closely followed. If we can design naming conventions properly, searching of data becomes easier and faster. For example, it is faster for the system to index and retrieve numerical data rather than alphabetical data.

3.    Waste due to data duplication: In many an organization, different systems exist in silos leading to data duplication. The same data with minimal variation in the details exist in multiple systems. If you take supplier master data for example, a supplier exist in the Procurement System, the same supplier exists in the receiving system and finally same supplier exists in the financial systems. This is like the proverbial story of blind men and the elephant.

Another example of data duplication is in the Finance department. Different sections need different variants of the same data. For example, a payable accountant wants to know the pending invoices and payments from the ‘Due Date’ perspective, the legal department wants to know the details from the ‘Vendor Dispute Redressing’ perspective and finally the general accounts department wants the same data from the reconciliation perspective. Since these departments do not talk to each other, the data duplicates and multiples within the organization. Most of the times, they present different picture altogether!!

4.    Waste due to excessive transactions: Many a time, an organization indulges in wasteful manual transactions. For example, in many organizations, Bank Reconciliation is a manual activity. So are Vendor Payments. Most of the ERPs provide facility to easily automate these manual transactions thereby saving lot of energy, time and money to the organization.

5.    Waste due to Excessive usage of Paper: Many ‘Old Economy’ companies, even now, demand that all the auditable transactions be accompanied by copies of physical documents and reports. An ERP can easily automate these processes thereby leading to a ‘Paperless’ organization.

6.    Waste of manual labour: An offshoot of the manual process is the need of personnel to carry physical documents from one location to another. The reason is the physical requirement of multiple data verification coupled with the Silos approach that we discussed earlier.

7.    Wastes related to bad Account Payable Practices: Procuring stuff and making payments to suppliers is a normal practice for any organization. Supplier returns is a major component of the Procurement cycle. Supplier Returns (also known as Return to Vendor or RTV) transactions are often accompanied by a Debit Note, which is a claim on the vendor. In many organizations, Vendor payments and Debit Note generation go on in parallel, with One Hand (which enters Supplier Payments) not knowing what the other hand (which enters Debit Notes) is doing. This leads to excessive Cash Outflow to the organization which in turn leads to requirement for additional expensive Working Capital.

8.    Wastes due to handling customer disputes: When the customer sends the cheques to you, the same is received in the mail receiving section. The same is then transferred to the Finance and Accounts section (through a Peon, another waste!!) and finally the same is netted off against the corresponding Customer Invoices.

There are multiple situations in the above communications chain that can lead to customer disputes and a dissatisfied customer. For example, the mail gets lost in the mail receiving section itself. Or the peon could deliver it to the wrong section where it lies unattended. Or the cheque is delivered to the right person, but he delayed or missed reconciling the receipts against the invoices in the system. Or there is no reconciliation process in the system at all. Or, the cheque was not accompanied by the invoice (an Orphan Cheque, my coinage) and hence the F&A section delayed the reconciliation...

What happens?

In the next round of the ‘Dunning Cycle’ a strong mail goes to the customer that his payments are pending. Customer in turn sends back the copy of your receipt acknowledgement or his bank statement showing that Cheque or Money was already received by you and gives you a sage advice to ‘Get your things in order’.

Or he will consider you as a risk to do business with and leave you in favour of your competitor.

The wastes go on....

Point to note is that all the wastes that I have mentioned above relate to processes other than manufacturing. These system and process related wastes are mostly invisible and hence get ignored by the system. Just like a lingering pain in your shoulder that make you ineffective in performing some tasks effectively, these wastes gradually pile up and increases the costs to the organization.

All the wastes that I mentioned above, and many more, can be handled by intelligent and efficient ERP Design. When we talk of 'Lean' we think of manufacturing processes and tasks relating to manufacturing and inventory. However, any process improvement which can lead to process efficiencies and lowering of costs to the customer can be considered as ‘Lean’ process. And in this endeavour there are many a tasks that an ERP consultant can implement. In the following section, I discuss some of the ERP Design considerations that can help reduce the wastes and bring much more flexibility and agility to the process system.

How can we design ERP to handle the above wastes?

By focusing more on issues and problems and less on requirements, a smart consultant can identify significant design opportunities in ERP to reduce organizational waste. Given below are some of the design considerations that, if followed, can lead to optimal ERP Design. While most of the points being discussed are ERP Vendor Agnostic, some of the terminology being used is related to Oracle Apps.

1.    Design to handle Obsolete / Redundant data: Most of the time, an ERP Implementation leads to identification of a number of obsolete data. The design to reduce wastes cuts across all phases and all the ERP related activities. For example, customer should be encouraged to give sanitized data for conversion. Customer should be asked to net off the pending Credit Notes, Debit Notes and Advances against Invoices in both receivables and payables systems before providing the data for conversion into ERP Application. Similarly, the inactive purchase orders can be cancelled, partially received purchased orders can be either received in full or remaining receipts cancelled, and any pending disputes should be addressed before the data comes into ERP System.

The list goes on...

This internal due diligence helps to identify significant wastes even before data comes into the ERP application.

Another area of waste reduction relates to configuration. By optimally considering the various configuration items, significant waste can be avoided in the future. For example, in one of my implementations, we identified over 80000 cost components for an item which was adding only 0.5% of the total item costs. Once we removed these components, the costing program which used to take more than 36 hours to complete, finished in just 30 minutes!

2.    Design high class naming conventions: Having a well designed naming convention, is the second best design consideration (first being accurate data conversion) values add that a consultant can bring into an ERP Implementation. When it comes to naming conventions, the more the better. If the naming conventions are automated, even better. When it comes to naming conventions try using numeric rather than alphanumeric values where possible. Numeric values support indexation better. Naming convention also help reduce data duplication, especially when it comes to Supplier and Customer Names (which are descriptive in nature). In these data, some of the considerations include, how to handle different vendors with same name (for example, John Smith is a very common name, I think), a convention to use, for example ‘Ltd. (Ltd with a dot)’ to specify ‘Limited’.  Naming conventions are simple but powerful tools to ensure long-term optimization of data. Naming convention can also improve system performance, for example numeric data indexes better and retrieves faster than non-numeric data. That is the reason that many of the standard application data has numeric codes as the primary key.

3.    Design to reduce data duplication: ERP, by its very design, is an integrated application and the chance of multiple versions of same data existing in the application is remote. However, a smart consultant can still identify potential opportunities to avoid data duplication. For instance, we can reduce data duplication when designing interfaces to ERP from third party applications. Most of the time, all the data that is lying in the legacy application is uploaded and updated in ERP through the interfaces. The attempt is to make ERP the ‘Single Source of Data’. While this is a laudable objective, sometimes, it is better to leave the data details in the legacy while bringing in the summary data into the ERP Application. Especially if the legacy system will continue to be used in future.

Unfortunately, we extend the same principle to the data entered into the system through custom, bolt-on solutions. These are customizations developed in the ERP Application for handling specific customer processes. The data lies within the same application database, normally in a ‘Custom Schema’. But, we still bring the detailed data into the base application database (what is technically known as ‘Apps Schema’). This is a redundant data duplication that the ERP Consultant is building into the system. This need to be avoided.    .

4.    Design to reduce manual transactions: While there is a complaint that ‘After ERP has come, we are spending more time in data entry’, the fact is that almost all ERP Applications has the facility to significantly reduce data entry thereby saving energy, time and money for the organization. For example, you can use EDI to transfer documents to the supplier and customers, you can use automatic bank reconciliation to reconcile your bank statements with the ERP Transactions, use Automatic payments through bank transfers to the vendors, electronically pay salaries to the employees, and use the ‘Payment Manager’ responsibility to effectively automate your payment processes. The list is endless...

The funny thing is that during ERP implementation, some of the above automation is handled in the application but others are not. Some departments are more application savvy whereas some others are less so. Why does this happen? I think there are three reasons to the above. Primary one is the knowledge of the consultant relating to the above features. A knowledgeable consultant will explain various automation features of the application and work effectively with the customer in implementing these features. If the consultant do not know the automation, he will not mention these features to the customer during discussions and hope that the customer do not come to know. For example, if the consultant does not know how to configure automatic bank reconciliation, he will not even mention that this facility is available in ERP. The second reason is the knowledge and experience of the customer user. Sometimes a demanding customer user can get all the automation that he wants while a passive customer user will live with whatever the consultant offers. Finally, there is a need for automation due to the sheer volume of data. For example, the Employee salary payments are high in volume and need significant level of accuracy. This means that they cannot be handled manually.

Whatever is the reason, a smart consultant can bring in intelligent design in ensuring that manual transactions are significantly reduced so that the labour can be gainfully employed and the data is more accurate.

5.    Reduce Excessive usage of Paper: In my opinion, creating a ‘Paperless’ office should be an important priority for any ERP Implementation. Since the data permanently reside in the database, there is no reason why paper trail is to be kept for audit purposes. For example, despite the fact that  both PO and GRN (or MRN – Material Receipt Note) is already available in ERP system, many organizations still insist that physical copies of these documents be attached to the Supplier invoice before making payments to the vendors. I think there are two reasons for demanding physical documents. One is cultural. Going from the safety of physical documents to the uncertain world of ‘Paperless’ office is traumatic for many finance managers. In addition, the auditing community also do not have tech savvy professionals who can understand the data flow in ERP and hence they insist on paper trail.

While this is not a design issue, ERP Consultant can play a significant role in educating the Finance Managers of the features in the ERP application so that they become comfortable with the features of ERP and they, in turn, will start embracing ‘Paperless’ office.

6.    Reduce Waste of manual labour: One of the key drivers for physical flow of paper in the organization is the requirement for approvals. Physical documents have to be approved by approval authority before the process can proceed. By the use of electronic notifications and exception reporting and digital signature, this requirement can be totally avoided in any organization. The potential is only limited by the knowledge of the consultant.

7.    Design to reduce wastes related to bad Account Payable Practices: ERP provided reams of information relating to the pending transactions against each Vendor. It only needs a clear documented process in the organization to ensure that Vendor cash payments will be made only after netting off the existing credit notes and advances. This simple measure can lead to significant reduction in cash outflow to the organization.

8.    Automate to reduce customer disputes: By helping to automate the flow of documents and the associated transactions, ERP help improve customer relationship significantly. Organizations can use EDI to send quotes and invoices to the customer and receive confirmations from the customer. Automatic bank transfers will help automate the receipt, automatic bank reconciliation will help in reconciliation, automatic application will help in applying the receipts to the invoices. All these will help in traceability within the organization as well as reduce disputes with the customer. This also reduces manual labour which can be gainfully employed elsewhere in the organization.

9.    Schedule Batch Processes Where Possible: Oracle applications provide you with a flexibility to schedule the batch process and run the same at a time when system load is low. There are three factors to consider in scheduling vis. compatibility, frequency and time. If there are compatible programs where the output of one is input to another, you have to design compatibility relationship between these programs so that they run in sequence. However, non-compatible programs can be run in parallel. It is also important to identify and design the best frequency to run the programs. For example, scheduling by 30 minutes frequency as against 15 minutes will potentially double your system performance!. Finally, as relates to timing, best time to schedule some of the programs is when system load is lower like midnight, lunch time etc.

Unfortunately, this is an area mostly ignored during the implementation. But this is one of the key to long-term system performance and by increasing the system speed, will reduce the time taken by the users to enter and complete their transactions. By identifying dependencies and correctly and efficiently scheduling the batch processes, most of the tedious, regular activities can be moved to the time when system load is lower.

1   Design Exception based reporting: I can’t stress the importance of this more. This is the most ignored aspect in ERP Implementation. The reason is again related to lack of focus during the implementation. Considering that identifying exceptions is one of the most time consuming activities (and hence a waste) post ERP Implementation, it is all the more reason that proper focus is given to this aspect during the ERP Implementation. As everything else related to ERP Implementation, this activity also should be driven by ERP Consultant.

Exception based reporting in not just applicable to reports. A well designed system of alerts, notifications, emails and reports can help in effectively implementing exception based reporting in the system.

11.  Encourage workarounds and process changes to creation of customizations: Early in my ERP Career, I used to work in an ERP Product named Scala. While this was a good application, there was limitation that this application could not be customized. The upshot was that we were forced think through  the requirements of the customer and were forced to come out with innovative workarounds within the application itself. If workarounds were not available, the customer had to change his process to meet with the requirements of the application.

One of the major grouses that I have with leading applications is that they allow too much of customization. The ERP Vendor justifies this by saying that this gives flexibility to the customer. The implementer wants customization since this is where he derives most of his margins. The functional consultant likes customization since it helps him transfer his responsibility to the technical consultant. The customer gets the ego satisfaction that his processes are so unique that even the ‘Great’ ERP Applications cannot handle his requirement.

Everyone is happy...

Customizations developed without proper analysis will lead to drag on system resources, become a bottleneck during future upgrades and will add to unnecessary control requirements. As mentioned earlier, a poorly designed customization will also lead to data duplication in the system.

Everyone loses in the end...

12.  Encourage use of Standard Reports: One area where ERP brings in ‘Global Best Practices’ is in area of standard reports. There are many valuable standard reports in the ERP System. However, none of them are used and Organization ends up in developing custom reports to handle all its report requirements. This is where the gap between ‘Global Best Practices’ and ‘ERP has not brought any Process Benefits to us’ happen. And also creation of custom reports, where standard reports are available, will lead to ‘Report Duplication’, errors, system performance issues and general disaffection with the ERP System.

13.  Effective design of Organizational Structure: All the ERP packages allow the configuration of the organizational structure. I have seen a few implementations where the Org. structure is either over configured (Too many Operating Units and Warehouses) or under configured. While too many Organizations will make data entry, configuration and Knowledge transfer a nightmare, too few of the organizations can lead to non-availability of effective analytical information.

14.  Encourage the discovery of useful ERP features: Traditionally an ERP implementation starts off with bare minimum features available in the ERP package. However, the full benefit of ERP package can be attained only if the organization starts using more and more features available in ERP. The most basic and easy to adopt benefit is to use some of the standard reports available in each application. However, once the ERP operations stabilizes, the organization do not show the curiosity to review the available standard reports and incorporate more and more standard reports as a part of the decision making. A few simple examples are the 'Top 10 Customer report' or the 'Top 10 Supplier List', 'ABC Analysis reports' etc. Since most of these reports are parameterized, it will take some experimentation for the organization to identify the correct parameters set to be used to obtain the information relevant and appropriate to the organization.

In the next section, I want to illustrate the practical aspects of these design considerations by taking the design of a single module, in this case, the General Ledger Module in Oracle Applications.

Illustration: Points to consider while implementing General Ledger

I want to illustrate the implementation of the design considerations pointed out above by focussing on the design of General Ledger Module. The following configuration considerations in GL will help in bringing 'Lean'

1.    The philosophy of 'Thin GL': In the pre-ERP days, the organizations are accustomed to collecting all the analytical information from the Books of accounts (GL). This includes mostly Customer Balances, Supplier Balances and Assets Details. However ERPs bring in a powerful tool in the form of Subledgers from where Organizations can get almost all the detailed information from the corresponding Subledgers. This means that only a summary information need to flow to GL. This reduces the duplication of information (both in subledger and GL) leading to a 'Thin GL' and more lean accounts operations.

2.    Too many or too few Accounting Dimensions: Associated to the above point is the design of Chart of Accounts. Since most of the ERPs offer wide flexibility in design of flexfields / dimensions, many organizations are prone to design more dimensions than necessary. Too many dimensions lead to the following wastes.

a.    Duplication of information between subledger and GL

b.    Waste of the users time in data entry

c.    Waste of users time in error identification and rectification

d.    Waste of precious hardware space

e.    Complexity in GL reporting.

3.    Too many GL Journal Entries: In the philosophy of 'Thin GL', almost all the operational accounting entries in GL should flow from the subledgers. Only the period end reversible adjustment journals should be entered in GL. However many organizations use ERP as a huge accounting package and enter far too many accounting transactions directly in GL. This leads to the following wastes.

a.    Waste of Users time in entering GL transactions.

b.    Waste of users time in manually identifying the linkage between these transactions and subledgers

c.    Waste of ERP capability in the subledger modules

d.    Waste associated with generating new reports

e.    Waste associated with manual reconciliation.

4.    Too many customized reports: In GL, the report generating tool is very flexible in generating financial reports like P&L, Balance Sheet and CFS. However, many organizations prefer to use custom reports for reporting purposes. This leads to the following wastes

a.     Waste of energy and time in designing and developing custom reports

b.    Waste of energy and time in redesigning custom reports in case of application / database upgrades

c.    Possibility of erroneous data in custom reports.

5.    Other wastes: One of the wastes relate to improper design. In this waste the key aspect relate to not incorporating realistic future considerations in the application design. For example, what is the expected life of this ERP application before business is expected to change leading to reconfiguration of this application. A practical example of this was in one of my implementations where the organization told me that they plan to use this ERP application for 15 (!) years and hence we increased the lengths of all the account dimensions to incorporate scalability. The result was a sub-optimal COA design.

Conclusion

The sad reality is that in their quest to implement ERP as a commodity, the consultants and the consulting organization focus on the customer requirement and provides the same to them through ERP. Ideally the focus should be on business issues and problems. Only by solving these will the customer get return on his ERP investment. However, since ERP is considered a commodity, the focus is on costs. To reduce the costs, the organizations (both the implementer and customer) focus on low cost, low maturity and low skilled resources, with one or two senior resources thrown in as a symbol of expertise. Under all these constraints, implementing Lean is a far cry. They (the consultants) do not pause to ask the customer some key questions relating to Business Strategy, Scalability, Application Life, and Key current pain points etc. These are the kind of questions the answers of which will lead to actionable insights on removing long term potential wastes which, in turn, lead to significant value add for the customer. 

What are the process improvements that an ERP consultant can implement to reduce waste and bring in 'Lean' in an organization? What have you implemented in your implementations? Do you approach your ERP Implementation with 'Lean' in mind? Do you factor in 'Lean' in your Design? I am keen to know.

Share your experiences and let the other implementers benefit from your experience and expertise..

Also tell me what you think of this article. (Please use the 'Reactions' check box below. Would appreciate if you follow up the 'Bad' reaction with a comment detailing how it can be improved)