Very simply, there is no more effective or efficient way to improve enterprise-wide knowledge management than to focus on the development, publishing and use of enterprise inventory data, information and knowledge.
Defining Inventories and Inventory Instances.
Before starting, it’s worth taking a few minutes to clearly define Inventories and Inventory Instances…
Definition of Inventory
An Inventory is a homogeneous complete set or collection of things that are important to one or more people. An Enterprise Inventory is a collection that is specifically important to an enterprise (e.g. a company or government agency). For example, an Inventory of People, an Inventory of Projects, an Inventory of Organizations, etc.
The Taxonomy of Inventory Types demonstrates examples of over 1,000 of the most common Inventory types that are collected and managed by different enterprises.
Definition of Inventory Instance
An Inventory Instance, also referred to as an Inventory Item (and sometimes a Component for inanimate instances), is a single unique element that is a part of a broader Inventory. For example, a single Project in an inventory of Projects, a single Application in an Inventory of Applications, a single Person in an inventory of People or Single Customer in an Inventory of Customers.
Inventory Instances represent focal points for enterprise knowledge
The reason why inventories are so critical to Enterprise Knowledge Management (EKM) is because every entry (Inventory Item) in every enterprise-specific Inventory has some importance to at least one person in the enterprise.
If we think of an Inventory Instance as a Node in a massive Data Network/Graph that is the enterprise, that Node will have descriptive data. For example, a Node might can be a System that is described by attributes like System Name, System Description, System Acronym, System Classification, etc. Nodes also have relationships to other nodes. So, for example, a System might be related to Documentation, People, Organizations, Facilities, etc. And, every relationship has a primary context. For example, one person might be related to the System as a System Owner while another person might be related to it as a Subject Matter Expert. Additionally, data about and relationships to/from the Node are collected and changed, over time, implying that there is a Data Lifecycle for each Node that is also important to people.
It is important to understand that every Node has at least one person that collects data for it, creates relationships to/from it, and who cares about that data. This means that every Node has a natural or organic Community of Practice (CoP) associated with it, which is a critical concept in Knowledge Management. The more common reality is that there is usually more than one person who cares about that Node, leading to the conclusion that most Nodes have CoPs of people who naturally work and collaborate around that Node. This is critical for understanding the notion of Enterprise Knowledge Management (EKM).
NOTE: CoPs will be covered in more detail, further in this article.
Enterprise Knowledge Management using Inventories
Because every Inventory Instance is a focal point for people who work with its data, properly controlling and sharing them is the key to facilitating better enterprise-wide knowledge management. This is because better coordination of Inventories translates to automatic and better coordination of the communities of people who care about them. This seems very obvious and simple until you realize just how many enterprises, especially IT organizations, do not adequately manage their inventories.
If you do not believe this statement, simply test it in your own enterprise. Can you go to one single place to find data about any one or all: Person(s), Organization(s), Product(s), Service(s), Project(s), Application(s), Customer(s), Vendor(s), Process(es), etc.? Chances are you can find some of these things but probably not from one system, and probably not in a consistent manner, and probably not in a way where you can easily explore relationships between things. Also, keep in mind that the examples used represent the simplest and most obvious things. This test usually exposes even more weaknesses when you start asking more complicated inventory-centric questions like: “Can I find all versions of all installed computer operating systems, across all machines, for a specific business division?” or “Show me everything at risk for impact if employee Jane Doe leaves the company?”
More on using Inventories for Communities of Practice
Each Inventory and every Instance within an Inventory represents a natural set of anchors or focal points for what the Knowledge Management profession calls Communities of Practice (CoPs). CoPs are groups of people who care about a topic and, when it comes to Inventories, CoPs naturally exist within and work around them. Therefore, controlling Inventories naturally has a direct impact on the effectiveness related CoPs… which are composed of your people.
For example, in the common case of an Inventory of all Projects, an enterprise may have multiple CoPs that are composed of Project Owners, Project Sponsors, Project Subject Matter Experts, Project Workers, Project Stakeholders, etc., who move between different project-related CoPs, depending on their interests at any given point in time. There are:
- the set of people who work within or care about a specific Project become the CoP for that Project,
- the set of people who care about a set of Projects become the CoP for that set, and
- the set of people who care about the full set of Projects (i.e. the full inventory of all Projects) become the CoP for the entire inventory.
Therefore, by improving access to Project Instance data and Project Inventory data we naturally improve the work experience of the CoPs that care about them. For example, if Jane Doe knows exactly where to go to find data for all Projects, she can find data for a specific Project. If she doesn’t, she will waste valuable time and money trying to find what she needs.
CoPs are fluid because people move in and out of them, over time, as needed. The people within any given CoP may care about the project’s past, present or future, depending on their needs. Therefore recording what we know about that Inventory Instance, over its life cycle, provides a history for those who care about.
This pattern of CoPs evolving and working around inventories and inventory items naturally and universally repeats itself, not just for Projects but also for every single inventory type that is important to an enterprise (e.g. Products, Services, Organizations, Applications, Facilities, Policies, Processes, Assets, etc.).
The important thing to take away from this section is that the improvement of data about and access to Inventory Instances and the Inventories they’re contained in directly influences the work experience people who care about them.
Using Inventories to implement the Yellow Pages pattern
Most people remember the old-style telephone Yellow Pages, which listed Service Categories and Service Providers, along with their contact information. The Yellow Pages book represented a Service Catalog (i.e. a Catalog of all Services) and created a simple routing mechanism that could easily route a person who cared about a Service to a specific Service Provider (through a phone number or an address).
The combination of this collection structure and routing paradigm has been adopted by many designers in many different professions because of its simplicity and elegance, and it is commonly referred to as the Yellow Pages (YP) pattern.
If we follow this pattern and treat every documented Inventory as its own context-specific Yellow Pages, we get the following results…
- a Yellow Pages for Services… Enterprise translation = Service Catalog
- a Yellow Pages for Products… Enterprise translation = Product Catalog
- a Yellow Pages for Projects… Enterprise translation = Project Catalog
- a Yellow Pages for Applications… Enterprise translation = Applications Catalog
To extend the Yellow Pages pattern, we can even have (and should have) an inventory of all inventories that is implemented via a Master Catalog that leads to all other catalog types.
Wrapping this all into a larger pattern that implements a Library Management structure, which is composed of a Master Catalog of Catalogs, where each topic-specific Catalog leads to Indices and line item entries for Inventory Instances, is called a Library. Making a Library accessible on the web is called a Digital Library.
Through the above patterns, people who care about and are looking for specific data about things can now quickly and easily go to their Digital Library’s Master Catalog, look up a topic-specific catalog, and then access the thing they care about, within that topic-specific catalog.
The reader should notice that the YP pattern makes browsing very simple and very quick, and it requires no expensive or complicated search solutions.
NOTE: Attempting to implement the YP pattern manually in traditional Content Management Systems (CMSs) usually leads to failure because the data within Inventories and the relationships between Inventory Instances (and often across Inventories) usually becomes overwhelming, very quickly.
Where and how to start
The first thing you’ll need to do is identify the inventories that you want to start with. As mentioned, you can refer to the Inventory Taxonomy. However, this may be too large. The IF4IT has narrowed the list of Inventory Types to a shorter list and has identified key attributes that are relevant for tracking about each Inventory Type. You can find this information in the free downloadable Enterprise Inventory Control Grid (EICG).
The second thing you’ll want to do is use the attributes in the EICG to quickly identify key descriptive data about these inventories, such as but not limited to…
- Who owns them (and contact information)?
- Where are they accessed and made available (e.g. systems, spreadsheets, and other tools)?
- How are they accessed and made available (e.g. by website, by phone call, by email request, etc.)?
- How are they maintained (e.g. key processes and procedures)?
- When are they updated and made available (e.g. update frequencies)?
The third thing you’ll want to do is publish this all in one easily accessible place such as your Intranet or, preferably, a real Digital Library.
Fourth, you’ll want to start want to start creating Catalogs for each relevant Inventory Type (topic domain).
Finally, you’ll want to create and publish your Digital Enterprise Library.
NOTE: It is not recommend that you perform the last two steps manually, in traditional Content Management Systems (CMSs), as it will take you forever, will yield poor quality data, and will cost you a fortune. Instead, it is recommended that you use automated library generators (like the IF4IT NOUNZ Data Compiler) that can automatically create your catalogs & indices, organize & format your data, and interlink your data, all in a fraction of the time and costs of traditional CMSs.
Examples of Use Cases facilitated by Inventories for KM
Examples of how the data and information from your enterprise inventories can be used to solve real business problems include but are not limited to:
- Faster provisioning of resources required to perform operational and project based work.
- Rapid education of employees and consultants (new and existing) about the enterprise and how to find and use things within it
- Audit & Compliance (know where everything is, at all times)
- Architecture (e.g. Enterprise, Solutions, Business, Applications, Technology, and Data & Information architecture)
- Information Security Governance (especially information services and assets)
- Data Governance (master inventories and representations of critical enterprise-related data)
- Populating Content and Knowledge Management Systems such as Intranets, Wikis, etc.
- Service Management (routing people to key enterprise services, and as a baseline for Service Catalogs)
- Business Analysis (e.g. Impact Analysis & Requirements Management)
- Service & Support (e.g. Impact Analysis & Incident Management)
Better Enterprise Knowledge Maturity
By constantly improving and publishing the inventory related data in the EICG, you will create a higher level of enterprise knowledge maturity. Both new and existing employees and consultants will be able to quickly get to the people, places and things that can help them get their work done, more effectively and efficiently.
Note that, in our experience, very few mid-sized and larger enterprises can fill in the majority of the template (at least not quickly) because there data has become so distributed and federated across so many different systems. Collecting and improving your data should be considered an ongoing Data Governance and Master Data Management process.
While Enterprise Inventory Management (EIM) is not the only way to improve enterprise knowledge, it is definitely one of the most effective and efficient ways of doing so. It helps create a Enterprise Knowledge Fabric (or Enterprise Knowledge Network) that allows workers to find what they need to know quickly, by creating routing maps through Inventory Instances that are located in highly maintained and published Inventories.
EIM also clearly establishes, helps identify, naturally coordinates and improves the operations of Communities of Practice (CoPs).
Finally, you can quickly implement highly structured and repeatable YP patterns through the implementation of Digital Libraries, via digital library generators, like the IF4IT NOUNZ Data Compiler.
Questions and Feedback
Should you decide to use the EICG, please let us know if you have any questions or feedback for improvement. Or, if you’re interested in Digital Libraries, please let us know. We’re always more than happy to help.
About the EICG document structure:
- The 1st tab provides an overview.
- The 2nd tab provides a detailed list of Inventory Types (Data Types) that are commonly tracked by many enterprises.
You might be interested in…