Part 2 of 2, All-Knowing Data Gods

Part One of “All-Knowing Data Gods”, #allknowingdatagods, asserts that adopting industry standards for identification is of little use when no methodology exists to propagate those standards throughout the enterprise.   It points to the challenges of managing that data because various software applications through the enterprise require manual input on many levels.  Those manual transactions introduce errors and unnecessary redundancies.

Though part one lays out the problems in terms of enterprise applications, business processes generate the data collected and stored by those applications.  The image below contains typical processes that affect the balance sheet and decision support in regards to capital.

All of these processes are important.  All generate information recorded by enterprise applications, standalone databases or spreadsheets.  Some capital systems are complex.  IT manages software applications and IT related hardware.  Facilities Management handles related renovations or additional hardware like a cooling system.   Clinical engineering performs first-call.  A contractor performs most of the service on the actual device. When consulting agencies come in with datasets and advice on maintenance cost spending levels, how can anyone pull a query to determine whether or not those maintenance costs are even relevant?  The data is scattered thinly and inconsistently across the enterprise.   Staff should have guidelines, from an executive leadership point of view,  on how key data needs to be collected and maintained.  

Collaboration between these departments are very helpful.  More people combing through reports to validate information is one choice.  Even so, there is another problem.  The collaborative team still requires information.   Each respective software application can have databases constructed differently.  Writing a query in some of these applications can be a challenge.  Validating the information is a greater challenge. Especially, when it comes to older database structures.  A person querying information without knowing exactly what database table and field stores that information invites trouble.  A user will have to understand, search, find, and validate this each time any report is modified.

Why would anyone outside of the CIO business unit need to know about database structure? Lean initiatives, data-driven outcome, evidence-base… that's where healthcare is headed, not database fields and tables.  The fact is that the data in data driven and evidence-base outcomes derive from someone putting information into a database from a process within the organization.  Retrieving information that reflects a valid picture of how an organization is functioning is a big problem.  A great part of the issue has to do with the database structures of enterprise applications.  From speaking with several dozen people, valid complaints are often rejected as excuses.  

1.  Staff cannot save a query.  Not save the information from a query but actually save a query.
2. Staff spend less time analyzing data versus more time removing headers, spaces, merging cells, separating cells, and other formatting.
3. Staff complains about not having access to a vital recurring requirements and must wait on someone else’s actions.

These are just a few challenges to data quality and reflect why so many people have little faith that these issues can be resolved in any useful manner.  Here are some actions to consider to finally get it right with data quality.

1. Move toward data quality
• Identify the processes that are important for the balance sheet and decision support.
• Determine what data is important
• Locate, definitively, where that data resides and how to query it
• Validate the data from these processes
• Develop processes to standardize and maintain the integrity of these data inputs
2. Build Fiscal and Physical Visibility
• Work with vendors that can help with these challenges, especially distributors and Supply Chain IT providers.  See later note
• Determine how best this data should be delivered
• Write performance standards that promote data quality standards
• Integrate IT applications
• Make a plan to migrate to one platform for asset management.  Vendors may offer add-0n applications.  This is not a bad thing if the add-on adds to the value of the application.  Make sure the add-on is fully integrated not a standalone application and that it fully meets the requirement.
3. Move to one platform.

Aforementioned Later Note:  A healthcare facility, that believes it is too small for its needs to effect a vendor's behavior, is too small.  Don't make that mistake.  Never underestimate your ability to have an impact.

In 2012, I attended a supply and material conference.  I asked about 20 material managers why not choose to work with vendors that can help with these challenges, especially in the case of RFID in the supply chain.  Supply chain is a great place to develop and leverage data quality.  The overwhelming response was to return a question to me, “Why would a distributor do that?”  I answered because it really does help both of you and the distributor.  In 2013, Cardinal (a distributor) purchased WaveMark (an RFID solution provider at the item level).  This means distributors are indeed interested, after all.  The only question remaining is, will RFID enabled supplies that show up at the receiving dock continue to be manually processed all the way to the point of use or return?