Product Catalog - Best Practices

The Product Catalog is a library of the hardware and software that is used by a company's technology environment. When employees use the ITSM, the Product Catalog make it easy for them to know which hardware, software, and services are available to them.

The normalization engine, as well as many menu selection options such as the Category, Type, and Item, rely heavily on the Product Catalog to function correctly.

Creating a Product Catalog entry

To learn how to add a new entry to the Product Catalog, see Adding-product-model-and-version-information-in-the-Product-Catalog.

Product Catalog hierarchy

Before creating a bunch of product catalog entries, it is important to understand the hierarchy of the product catalog, as misuse of this will cause failures with normalization of CIs, which can cause failures in reconciliation, and eventually resulting in poor data quality in the production dataset in the CMDB.

The following image is a representation of how a Product Catalog hierarchy is designed:

As shown in the hierarchy diagram, a Manufacturer (Company) can have many Products Suites or Products. Each Product Suite can have many Products as well. Each Product can have multiple Versions, and each Version can have many Patches.

All these hierarchy levels can be enabled, disabled, and managed individually.

Scenarios for adding entries in Product Catalog

Let's review a few common examples for both hardware and software style products.

Before continuing to specific examples, it is important to understand that the Product Catalog attribute labels are slightly different in Asset Management and CMDB. Use the following table as a reference to understand the differences:

Product Catalog	CMDB	Asset Management
Product Type
CI Type	ClassId
Product Categorization Tier 1	Category	Tier 1
Product Categorization Tier 2	Type	Tier 2
Product Categorization Tier 3	Item	Tier 3
Manufacture	ManufacturerName	Manufacture
Product Name	Model	Product Name
Version	VersionNumber	Model/Version
Patch	PatchNumber	Patch Number

Hardware - Server

The first example is of a common processing server, the HPE ProLiant DL380 G8.

Notice that this has a company, product, and model/version in the name. There are several versions of this product, so it makes a great use case. This is an example and isn't reflective of all organizations or discovery products.

First, let's look at the Product entry:

This is how the device is discovered.

However, there could be a need to record the model and version of this product series.

The following image is an example for the DL380 G8 MODEL/VERSION entry:

This gives us more granularity to keep the version of the same series of product.

The following image shows an example of what a full model/version might look like when it is complete:

This allows the Product Catalog Administrator to have a lot of control over products in their environments.

As seen in the screenshots above the G8 is Discontinued Availability and the G7 is Discontinued Support. This indicates that there might be many Proliant systems, with different statuses in our environment. This can also include other models under the same umbrella that the DL380's are under.

Software - Operating System

Operating Systems are another common scenario. The most common example is the Microsoft Windows 10 operating system.

The following image shows a potential Product Catalog entry:

Notice that it is missing Windows 10, but has entries back to Windows 2000 (which launched in December of 1999, and is "Discontinued Support" in this product catalog), so we need to create a new entry for Windows 10. This is a great example of how a product catalog shows some history as well as the current state of the IT Infrastructure in an organization.

Important

For versions, it is usually considered a best practice to include an unknown version in your product catalog. Sometimes automated discovery, from any product, will have a hard time finding versions for software and hardware. Especially if it is new software or a totally new version scheme. This will allow products to pass normalization later on in this process without a version needed at runtime. If a version is particularly important for your organization to track, you can create a report on unknown version numbers, and then review and resolve each record.

Other techniques, such as making other datasources the authority for version, might be critical for your organization's IT process.

In the following image, Windows 10 is entered as a Planned version of the Windows product. Once again, this example shows the usefulness and dynamic nature of the Product Catalog:

In addition, build numbers can be added to versions to further classify what the versions further. With Windows 10, this is very apparent in their release schedule. Here is an example:

This shows that Windows 10 is available through the version state.

Now, consider an older patch, like 1507 that is marked obsolete, which further qualifies the Product Catalog as shown in the following image:

Software - Software Suite

The last example is of a Software Suite, which is a collection of individual software products.

One of the prime examples is Adobe Creative Suite, otherwise known as Adobe CS.

The sample data in the following image has an example of this software suite already for CS5, which is an older version:

The Products in Suite table for CS5 is populated with 4 entries - Acrobat, InDesign, Photoshop, and Illustrator.

Let's add the new CS6 suite details to these entries, as shown in the following image:

To add the CS6 suite details, we need to create all new software entries for Illustrator, InDesign, and Photoshop, along with a new Creative Suite Software Suite product.

The ability to create new products in the Product Catalog and then package them together under a software suite, allows us flexibility with the products entries.

For such cases, we can create Alias mappings to our Product Catalog entries so that the normalization engine changes it to our preferred choices when it finds the specific product sequence.

Creating a Product Catalog alias

To create a Product Catalog alias mapping, see Mapping Discovery Categorization to Product Categorization

Now that we've created our Product Catalog entries, we're going to need to consider how BMC Discovery will actually pick up the attributes during its scan. Let's use the server as an example. BMC Discovery finds the product as shown in the following image:

The first thing that should be noticed in the image is that the CTI, Manufacturer, Model, and Version are not what we made originally. But this is how BMC Discovery found the product, and this would fail normalization. It might seem like a easy solution to just change our product catalog to match with BMC Discovery. But, this solution would only works once. After other data sources are added, the problem will resurface.

The solution for this issue is Product Catalog Alias Mappings. These mappings allow a thesaurus of some kind to help translate the data source to what has been defined in the product catalog, as a valid CMDB CI.

The following image shows a mapping of a discovered value from a data source, with a Product Catalog value. This mapping forces the normalization engine to evaluate each one of its failures to ensure this product is changed to match what the Product Catalog Manger wants it to be.

Considerations before adding new products to the Product Catalog

It is critical that when new hardware, software, and other CI types are introduced into the environment that it is recorded to the Product Catalog.

This process will be different for each organization. But, in order for the CMDB to be the single source of truth for CIs in an environment, the Product Catalog must be the source of truth for the products in that environment.

Product Catalog Manager (PCM) must consider a proactive approach to establish the product up front before it gets added to the environment. Products should be added and updated with the correct status as soon as they're added in the environment.

Example

A help desk technician requests for a new software product to help with their daily efforts. Roughly, the following steps would occur:

Users send a request to the Product Catalog Manager (PCM).
This might also be accompanied by a manager approval so the PCM isn't inodiated with request.
The PCM should first enter the product into the Product Catalog with a status of either Future Consideration or Not Planned.
The PCM can then evaluate the use of the product in their environment by using the credentials that the organization requires.
This include steps such as security verification, cost analysis, and licensing research.
The PCM then moves the status to Planned or Alpha/Beta, based on how far along in the process the product acceptance is.
During the testing phase, ensure that all of the predefined organizational testing such as compatibility and security testing are completed. This should also include verification that it is discoverable with the discovery tools that are used, and ensure an alias is mapped to the Product Catalog values defined originally. This is the point where the determination of what group will support the product, manage the product, and use the product would be discussed. Also, it is a great time to see if training is necessary.
After the testing of the product has started, the status moves to Pre-Release.
Important
Before release, ensure optimal allocation of time and resources to manage and maintain this product. Even a simple tool like a text editor will come with updates and new features that users will want to upgrade or change. It will be critical to the success of any product catalog to ensure that newest versions are added to the product catalog in a timely manner while discontinuing older versions, such as through daily checks,
Once the product is available, change the status to Generally Available.

After this process, the product will go through normalization and will be marked Normalized and Approved and added to the golden dataset (BMC Asset). After the product is added to the BMC Asset dataset, it can be accessed by other applications for incident tickets, change requests, and so on.

Another consideration is putting a change process around this, forcing a service request to start the ask for the product, additional task to navigate the testing of the product. A Change Request to introduce the product in the environment or discontinue it. These steps can formalize the process to ensure that all of the correct steps are followed and the right people are notified.

Managing discontinued products

Lastly, there needs to be a process for choosing the discontinued date.

A good practice is always setting a future date for discontinued availability, Discontinued Avail. Date+ and a Discontinued Support Date+, as soon as the product is made generally available. This allows a PCM to ensure that old software isn't being forgotten about in the environment. This might require a specific report to be run daily, so it can be tracked and monitored regularly. The following image shows the fields in the Product Model/Version form for setting the discontinued availability for a product:

As mentioned before, the products in an environment are in use for a specified duration. After that duration has elapsed, they no longer belong in in the environment. The reason for the limited duration of usage could be licensing changes, security issues, or even product replacements. It is up to each organization to build their own rules about the products and the time after which they must be discontinued.

Every organization should run a weekly report to review the CIs with the normalization status Normalized and Not Approved. The PCM can use this report to review each instance of software or hardware found on the environment that is in the CMDB but is not approved for use by the organization. If it is a testing box and it is a known instance of testing, maybe an exception is made. But, if someone has installed a unapproved product on a workstation, that should be evaluated as per the the policy.

Although security is the primary reason for monitoring unapproved products, it is also done for a compatibility and supportability reason. If an old web browser has been discontinued, and someone has never upgraded to the latest version of the browser, it can cause problems working with newer applications that the company rolls out. This scenario could cause a large amount of tickets being created from one subset of users whose product allocation is not managed properly. This situation can overload the help desk staff and resources.

It might even be advantageous to create a report for products that are widely used and report each CI that has them installed, based on the discontinued availability date of those products. That way, when the discontinued date lapses, a large portion of users aren't left with non-functioning, non-supported, and unlicensed software or hardware, and limit the additional helpdesk tickets.