The continuing discussion in healthcare around implementing Lean provides evidence that it's not simple and it's not easy to change a culture nor maintain that change. It can be done, of course, but it takes some thought. As I look at my departments, I see that the simplest and most effective ways we can reduce errors, reduce variability, reduce waste and add value (all principles of Lean) are to standardize and automate, monitor, audit and repeat. It sounds simple and it is. It sounds daunting and it can be.
The most fundamental step you can take to improve IT operations is to standardize - whether your objective is Lean or ITIL or ITSM or just process improvement. Standardizing means analyzing the work your teams do, identifying recurring or repetitive tasks and developing standard work. Things like software upgrades, testing, developing or delivering education and userid creation all come to mind as areas of opportunity. If it's not standardized, it means that everyone is doing is slightly differently, which causes variation, which leads to errors, omissions, gaps and rework.
Write It Down
Once you believe you've developed a standard, write it down and use it without exception. If it's not working, analyze why. Is it not being used as intended or is there a flaw in the standard? Modify, test, repeat. Don't stick to a standard that isn't working, but don't change just because you run into a snag.
Sell It, Train It
It's relatively easy to develop standards, but getting staff to consistently use them can be a challenge. First, people need to buy into the notion of standardization. Why standardize? My best answer is that if we consistently do routine work the same way every time, we will avoid injuring ourselves with our own errors. How many late nights, unexpected downtimes or emergencies have we cause by our own errors? In my experience, errors are the most common source of unexpected downtimes. While not all errors can be avoided, many can be through standardization and automation. If your team understands the rationale for using standard work, then people will more naturally gravitate toward adhering to standard ways of doing routine tasks.
Remember, too, that the people doing the work should develop the standard work - and ideally it should be the simplest, cleanest, least complicated (though sufficiently thorough) way of doing the work. Though this may result in some team debate over the 'best' way to standardize, a thorough vetting of your standards is appropriate. Ultimately, innovative ideas to improve the work may surface in the process.
Make sure everyone is trained to do standard work. If it's well-documented, the document itself is the training.
For example, we created a standard checklist for some tricky aspects of userid management. The checklist identified every single step to be done every time. Interestingly, the only time errors occurred were when the checklist was not followed. The importance of the checklist was reiterated at a team meeting and errors became a thing of the past.
Exceptions Are The Enemy
It's easy to say "well, in this case, this standard doesn't apply" and pass off yet another one-off, another exception. Resist the temptation. Instead, ask why this appears to be an exception. What are the circumstances around this? (Using Lean terminology, ask the 5 Why's). Dig deeper into the situation to fully understand it. If indeed the situation is an exception, ask yourself (or your team) if there is a way to eliminate the exception. If not, is this exception more common than you realize? If so, you may need to simply develop another standard for these other items that appear to be "exceptions" but are simply different from the context of the standard.
For example, you may have set your EMR to time out after 15 minutes of inactivity across the entire environment (standard). However, you start getting complaints from physicians that the timeout is too short. It sounds like an exception. Upon further investigation, you find that the specific physicians requesting this are in the Radiology department doing radiology studies that take longer than 15 minutes, causing the EMR to time out. The location where these physicians work is secure. Do you make an exception or stick to the standard? Do you look at these physicians as an exception or not?
Let's complicate this further. You also get complaints from your coders who are working in two different systems simultaneously and the 15 minute timeout is causing them to lose work.
In looking at this scenario, your team might conclude that two standards are worth supporting. A shorter 15 minute timeout throughout the organization remains in place and a longer 30 minute timeout is supported for these job functions (listed) in these secure locations (listed).
The key here is to do analysis and really dig deeper into the alleged problem. Often asking 5 why's can be helpful as you dig down further (hint: the question doesn't always begin with "why", in fact, it might be a statement as simple as "tell me more" or "help me understand").
Now that you've defined, refined and tested your standards, you can automate this standardized function. Whether that's automating the setup of computers in Organizational Units or automating the setup of users by function or scripting routine jobs within an application, you can usually automate routine tasks. Automate everything you can. This ensures it is always done the same way every time. That is the very essence of Lean. Beyond that, you need to monitor and audit results. If you can automate that (for example, producing an exception or error report), all the better.
Standardizing and automating absolutely everything in IT that makes sense will enable your team to focus on the work that requires their critical thinking, their innovation, their problem solving skills and their excitement. Leave the mundane work to our silicon-based cohorts (computers, for those of you less technically-oriented).