...
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!