KPIA #4: Identifying Data Sources

Progress has been made! We are moving to the next part of the KPI assessment process. As referenced in the second blog post entitled, KPI Assessment Timeline, we are moving from the project plan to the data retrieval stage. I cannot tell you how many times I have been asked directly or been in the presence of others who were asked “How complicated is it to retrieve data?” When the technical answer begins to roll off the tongue, some seem to get bored. I really don’t know why that is as it is a truly amazing process! In an over-avoidance of not getting too technical, let's talk about a data retrieval process like going grocery shopping. There are different types of “trips” to the grocery store. Data retrieval processes are not like stopping to get a gallon of milk, it is more like stopping to get the necessary ingredients for a family reunion style Thanksgiving dinner. If you have been to a large family event you can appreciate the amount of time and effort that goes into planning and preparing for numerous guests. If you have not had this pleasure, think about a big gathering that you participated in recently. Now think specifically about the family member/person who was in-charge of the event. I would venture to say that they:

1. Were focused on the end goal-a great meal/event
2. Knew what the diners will be expecting as far as food
3. Had the details as to what ingredients are necessary to make the dishes to serve
4. Knew where to get the ingredients. 
   ​

​These characteristics are reflective of a great data retrieval team, they know:

1. What the KPIs are.
2. What format the data needs to be organized into in order to be used by analysts
3. What data attributes need to be included in the data set.
4.  Where to retrieve the data from

In both the large family type event or the data retrieval team examples, you cannot get to the top of the list (number one) until you know where the ingredients/data are located. You aren’t going to go looking for corn bread at the hardware store, you know it is at the grocery store. You might not know the aisle that the corn bread is located, but you know how to navigate a grocery store to find this item. Data retrieval is similar. You might not have the name of the table containing the needed data memorized, but you know the correct application to use and can navigate the tables to find the necessary information.
​
Often, data retrieval is simplified by routinely extracting the same data. This routine process makes the location of the data continually familiar. However, routine is not best practice. Documentation is a process that makes the location of data known. If your organization has not yet documented the location of all data attributes, the applications that store them, and the servers that house them it is time to set aside some time in the near future and complete this task. This documentation is organized in a manner that has similarities to Figure 1. Applications are stored on servers, and tables of data are associated with each application. 

​Having an inventory of each of these three aspects of information architecture is extremely important. Figure 1 only considers one server, but most organizations have multiple servers. (If everything you do is cloud based consider each cloud application its own application and the cloud as the server.) If your organization does not have a detailed mapping at this point in time, create a data map skeleton for the time being. An example of a data map skeleton is shown in Figure 2.

If documentation does exist, it is time to cross check and verify that all information is up-to-date. Even if the documentation has a “last reviewed” date that is within a couple of weeks or days, spend the time to verify. Today’s step is all about checking and inventorying what you have. Some of this data may not be used in the KPI assessment process, but in order to know what you are going to be using you need to be aware of all of the data attributes available.
Some organizations may have an inventory of data that they store in a database of its own. Even in this case, it is time to do a data audit to make sure that the system has captured all that you intended it to capture.

Other organizations may feel comfortable in the fact that they mapped out the data they would need to assess their KPIs from the time that the KPIs were set. Having been consistent throughout is wonderful. Make sure you take an inventory to verify. Another data point(s) may have been collected since the KPIs were put into place and may be a better fit than the data that was available at time of the original mapping.

Check and recheck. That is today’s bottom line. By investing in taking an inventory of what you have, it will help prevent a missing piece from being discovered at a later time. A significant amount of time can be wasted when a critical piece is over looked and later discovered. This waste of time is not only effecting performance but patience as frustration is certain to rise. Stay a step ahead by being thorough.

Blog #4’s Question: Do you know what data your organization has, where it is stored, and how to retrieve it?
​
Blog #5 sneak peek: Data Review