Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Possible Product Configurations

Define product by manufacturer code:

This is the preferred configuration for most organizations that sell product. A product is defined as a specific manufacturer-code combination (or potentially vendor/manufacturer/code combo). The benefit of this system is that it is extremely specific. It tracks the exact product purchased from the manufacturer, through inventory, all the way to sale. This is perfect for companies that need to track what was sold against what was purchased, by brand. The data might look something like this:

Code

Name

Supplier

Manufacturer

Manu code

TS123

Amoxicillin 250mg bot/100

Medline

Medline

457658/100

BR456

Amoxicillin 250mg bot/1000

Medline

Medline

457658/1000

GF567

Amoxicillin 250mg bot/100

McKesson

Pfizer

FGH-6780

TG407

Draeger Resuscitaire

Draeger

Draeger

RSC1001

BF305

Integrated Resuscitation System

Henry Schein

GE

IRS-1235

As you can see from the data, there are some downsides of this method for organizations that are actually delivering care. While for a medical distributor, the three amoxicillin 250mg products are fundamentally different, for a clinician or hospital administrator they are functionally the same. While it is possible to make this product structure work for care delivery using substitutions and generic products, service delivery organizations may want to consider a more generic structure.

Define product by relevant characteristics:

In this product structure, an administrator or group of administrators defines a product based on its most important characteristics. If two items have the same key characteristics, they are the same product, regardless of manufacturer information. In general, this system is preferred for organizations that are end users, not sellers, of products. The data might look something like this:

Code

Name

Supplier

Manufacturer

Manu Code

TS123

Amoxicillin 250mg tablet

various

various

various

CD167

Exam glove, Latex, Powdered, size small

FG532

Exam glove, Latex, Powder-Free, size small

GF532

Exam glove, Nitrile, Powdered, size small

In this data set, supplier and manufacturer information is irrelevant. All amoxicillin 250mg tablets fall under the same product, regardless of pack size or manufacturer. For exam gloves, there is a defined set of characteristics listed in the name that determines the product. All small latex powdered gloves are CD167, even if some gloves are extended or beaded cuff, but a powder-free glove is a different product.

While this method has the benefit of being focused on the attribute of a product that the end user cares about, it also has some significant downsides. The most obvious one is that it doesn’t track which supplier or manufacturer a given quantity of product came from. This information can be tracked via the product source function, and recalls can be managed via lot tracking, so many non-seller organizations find that they do not need the additional detail. The more significant downside to this method is the level of judgement and expertise required by users and administrators. Defining products by relevant characteristics means that there must be a group of administrators responsible for defining what characteristics are relevant for each group of products. For certain products this can be quite complex. This system also requires either that purchasers deeply understand the characteristics of products they are buying, or that subject matter experts are heavily involved in documenting which purchasing options meet spec.

Combination Method

This method is essentially a variation on the “define product by characteristics” method, where the manufacturer information is one potential characteristic. For an organization with a wide range of products, it is likely that certain product categories are better tracked by manufacturer code, while other categories are better at a more generic level. There is no reason why different type of products cannot be tracked differently. The data in this case might look like this:

Code

Name

Supplier

Manufacturer

Manu Code

TS123

Amoxicillin 250mg tablet

TG407

Infant Resuscitation System, Draeger

Draeger

Draeger

RSC1001

BF305

Infant Resuscitation System, GE

Henry Schein

GE

IRS-1235

CD167

Exam glove, Latex, Powdered, size small

HE597

Toyota Hiace Steering Wheel, 345679

Toyota

Toyota

345679

In the example above, our amoxicillin and exam gloves are still defined by their generic characteristics. However, medical equipment and car parts are defined by manufacturer code. You can see by the name the both TG407 and BF305 that both products are infant resuscitation systems. However, infant resuscitation systems have a wide range of specifications, and it wouldn't be realistic to list them all. Therefore, the different models are tracked as separate products while the name acknowledges that they serve the same basic function. For vehicle parts, every part is designated by a unique manufacturer code, and parts are never interchangeable with one another. So vehicle parts are tracked by code, with some information in the name to provide context for the user.

This method has the same requirement for knowledgeable administrators as the characteristics method, but it does remove a large administrative burden if there are clearly defined categories that should always be tracked by manufacturer code. It is also the most flexible, and the most desirable for final end users in a system because products are always tracked based on the information they need for their work.

Other methods:

While the methods listed above are the ones most commonly used in LMIS systems and are the ones recommended for OpenBoxes, the flexible product structure can accommodate a wide range of possible configurations. If your organization has another method in mind, the best approach is to mock up some demo data and try it out!