Designing Unit of Measure (UOM): A critical ingredient in ERP Implementation

I am very active in a couple of groups in LinkedIn. One of the groups that I am a member of is 'ERP Project Management'.

A discussion that I have initiated in this group is related to the the critical nature of Unit Of Measure (UOM) in an ERP Implementation. The discussion can be accessed via this link.

This discussion has already received about 20 comments and growing...

I initiated this discussion because I felt that a badly configured UOM is like a nagging pain that allows you to work but impedes optimal performance. I have seen my share of UOM Challenges and I wanted to get the reader's opinion if they think that UOM is as much of a challenge as I think it is.

If you see my blog, I had even initiated a poll on the importance of UOM. Only one person responded to say that in their company, Sub-optimal configuration of UOM is impacting business performance.

As I explained when I initiated this discussion, along with design of Chart of Accounts and naming conventions, designing the correct Unit of Measure (UOM) to handle the various inventory transactions is a critical aspect of ERP Implementation. The design is complicated by plethora of terminology like Base UOM, Primary UOM, Secondary (and even Tertiary !) UOM etc, In addition you have UOM classes and UOM Converstions, both standard as well as Item Specific....

In this maze of terminology, it is very difficult to miss the key aspect of identifying the UOM for each item. There is the Procuring UOM, Stocking UOM and Selling UOM. An optimal design should consider the end to end transaction flow of the organization. Most of the time the UOM is decided based on your Procurement Transaction. A suboptimal design of UOM can lead to excessive number of transactions and errors in your ERP System and can quickly end up in Organization losing confidence on your ERP Systems.

Have you faced issues with UOM? If your UOM design is perfect, please let us know how you went about designing the same. If it is not perfect, let us know how you would change it if given another chance.

There was a lot of participation in this discussion. A few of them mentioned that UOM is not a challenge, but a few others disagreed. The discussion was lively. @Thomas Webber, who is an Infor (formerly BAAN) consultant, disagreed with my premise that UOM is a challenge. He felt that Infor is versatile enough to handle any kind of UOM.

@George Papas, agreed with me that a badly configured UOM can delay the transactions and also has a potential for errors. This means that a consultant has to be very sure and clear about the various UOM Concepts as well as its implementation. 

I provided clarifications where necessary. I pointed out that UOM Challenges are different for Process Manufacturing as against Discrete Manufacturing. I also pointed out the costing impact of a poorly designed UOM especially in Commodity Industries. 

There were other esteemed contributors like @Barry Preston, @Michael Tinsay etc who participated with their valuable ideas and opinions.

Do you think designing UOM is a major challenge as I think it is?

Have you faced challenges in configuring UOM in your implementations?

Has your organization implemented ERP with a suboptimal UOM Configuration? How are you handling it.

Do take part in the LinkedIn discussion if you can, it is fun and it is illuminating...

Here is the Link