By Dallas Sutton
It goes without saying that, as an industry, we are suffering from a dwindling workforce. A consequence of this is a commensurate dwindling of “unique knowledge,” typically possessed by a more seasoned workforce.
In a 2018 article on knowledge loss from HR Daily Advisor by James David (Knowledge Loss: Turnover Means Losing More Than Employees – HR Daily Advisor (blr.com)), it was identified, “that on average, 42% of the skills and expertise required to capably perform in a given position will be known only by the person currently in that position. In other words, should that person leave, their remaining colleagues won’t be able to do 42% of their work, and someone hired into that role will need to learn 42% of it from scratch.” While this figure might not be 100% applicable to all HTM departments, you can see the correlation and potential impact of the departure of one of your two anesthesia (or vent or MR or CT, etc.) trained technicians. If the departing technician happens to be the more seasoned, the impact can be much greater as they take years of troubleshooting experience with them.
Efforts to maintain/gain experience can take several forms such as continuing technical training, and retention, but most neglect more tangible tools such as formalized local knowledge bases, mentorship programs and detailed documentation of unique troubleshooting experiences. The aforementioned article suggests that, on average, a new hire will spend 200 hours “reinventing the wheel” in an effort to duplicate the experience of their predecessor, but I’m sure we can all agree that filling a technical vacancy can be much more time consuming than many administrative roles. According to research, “a firm with 1,000 employees can expect to lose $2.4 million in productivity annually due to these day-to-day inefficiencies.” Although there are no 1,000-technician HTM shops, some system programs, third-party providers and OEMs are working towards that number, making the costs associated with the loss of experience very real.
As referenced earlier, “unique knowledge” is that knowledge drawn from professional experience over the course of a career. This knowledge is self-taught though the process of learning on the job and developing ways to be more efficient and/or effective and in some ways is a product of individual motivation to get the job done. While research suggests that unique knowledge is 42% of the total knowledge that an average employee uses to fulfill their current role, it has also been identified as the hardest type of expertise to replace. So, how do you develop experience or minimize the impact of its loss?
Documentation
While not a substitute for personal experience (living though a task), an effective documentation program can go a long way to closing the problem-resolution gap for a lot of troubleshooting events. We cannot always control the description of work required as submitted by the clinical user of a device, sometimes as cryptic as “broke,” we can definitely control the documentation of the resolution beyond simply “fixed.”
I am making a presumption that most reading this are using some sort of computerized maintenance management system (CMMS), so no one out there is physically putting pen to paper. Documentation is not overly complicated or difficult, its real cost is in the time it takes to create it. Conversely, its benefit is the time it saves during the next service event. Beyond actual content, effective documentation programs are characterized by two key elements – participation and consistency.
Participation in documentation is probably not an issue, I mean everyone knows they need to document their work activity, time, parts consumption, etc. The problem comes in when you try to force a specific pattern of documentation. Most CMMSs record a maintenance activity as a function of request, fault and resolution codes, which can be helpful when searching a database for a generalized type of fault but requires a manual search of work order notes that, at minimum, will be tedious and may, in the worst cases, be completely unproductive.
The intent of documentation, beyond the standard regulatory, liability, and financial analytics, should be its use as a tool to minimize the investment in labor and downtime when accomplishing like tasks. The rub is that in order to make this a useable tool, you must invest labor on the front end to get the data into a searchable format. Labor is consumed in requiring maintenance events to be recorded in a format that is logical and sufficient to convey the activities of tasks to technical staff at a later time. We already require the documentation of maintenance events from everyone (participation), but what does this look like in practice (consistency)?
Here I am going to add a complementary tool that is present in most modern CMMSs – the knowledgebase (KB). A knowledgebase is essentially a topic/term searchable repository of data specific to a particular organization, industry, department, customer, etc. The data contained within an HTM knowledgebase should be complimentary and/or consistent with the data recorded within service work orders but may include other non-service event specific data such as testing procedures. The key to both a knowledgebase and work order documentation are their ability to be logically and accurately searched – unfortunately, this is also where most fail.
The searchability of work order notes and KB content are generally based on keywords. These keywords should be associated with a logical approach as to how your team would search for information regarding a specific event. As an example, this may start out at a very high level such as manufacturer or model number, narrow to specific software revision or platform option and drill down to a detailed error code or subassembly. The key is your technical team’s willingness to be active participants in ensuring the quality and consistency of the data submitted. There should be no requirement to write a book when completing a work order, but there should be an established minimum expectation. You may require that the error code as displayed on the device be in a specific format or specific failure codes be used for certain service events. The most important requirement should be that the data is usable and repeatable. If I were to search for a specific error code, I should be able to find it for every device it has occurred on as often as it has occurred. The data found should tell me what was done to correct the error in each of those instances.
Incidentally, your most seasoned team members should be the greatest contributors to this type of data, which leads us to the most important resource when developing experience.
Next month, my thoughts on mentorship and its effect on developing experience – hope to see you then!