Guiding principle number 6, keep it simple and practical. Lots of times when there's functionality rolled out in hardware or software applications, users only use a certain percent of it because they don't understand the big picture. If you have a nice application and people are only using 20 percent of it, it's because they don't understand the complexity of it. We want to start with a simple practical solutions first and then add in our complexity and our bells and our whistles later on. User-friendly is the number 1 game. Simplicity will make it easier to adopt. Using this principle is about considering your IT solutions being useful for everyone so that there are general practical solutions and then we can add in a more complicated approach. Starting with an uncomplicated approach allows us a better path to achieving quick wins, especially in the view of our customers and users. Even large companies like Apple and Microsoft have figured out that the less mouse clicks that a user has to make, the more likely they're to use your solution. That's why it's recommended to use the minimal number of steps in delivering results because users initially want to get up and running, and then they want to learn the complexity later, so the minimal number of steps will help win over your users and consumers to considering your new approach. Consider outcome-based thinking. This is where we can see value being added and value is added from use. We want users to use our products and solutions. In some cases, we do develop a solution and people find it a little bit complicated and we do not develop exception for every one of those cases. We want to balance those demands, try to do fewer things, better if possible, and create a practical solution for all, and maybe phase in additional versions or releases at a later time. The final guiding principle, number 7, is optimize and automate, and this is very common sense as well. We want to make sure that our processes, procedures, or whatever task we're trying to automate have already been optimized as much as possible, effectively and efficiently reviewed. We want to make sure that the necessary stakeholders have taken a look at whatever we're trying to automate is practical, it makes sense, it's easy to follow. Sometimes when we automate activities, when they breakdown, stakeholders don't know how to repair them because they've never learned the manual way of how to make the fix. Automation automatically kicks in. But what happens when automation no longer works? Then you're totally out of the water. You definitely want to make sure you understand how to make fixes and repairs behind the scenes if something breaks down and the technology is not able to repair it on its own. Please remember for test purposes, technology is not always the answer to every fix. Sometimes if a step or a process or procedure is broken, you can actually make a process improvement. If a process is broken, automating it is not going to fix it. You could actually be automating a broken process. Sometimes, we see, at a service desk, or a help desk, frequently asked questions, and that is because those service technicians want to see what are the frequent issues that they can somehow add automation to. It's almost like having a web portal you can go into to reset your password on your own and you don't need a human being involved. We see this with chatbots as well with regular activities that a computer can use maybe artificial intelligence and walk us through something because we've seen it over and over again. But yet, what ITIL is recommending here is that that process or that fix has already been optimized before we automated the entire solution. The way that we do this or the way that ITIL recommends is that metrics should be used before you automate a solution. We want to know how long it's going to take to do something. We want to know how long that's going to take for the fix, and this also frees up human resources as well. Those human resources can be used for other purposes while the automation is kicking in. Automation also assists with standardization and streamlining manual tasks, and allows us to work on additional duties. This guiding principle is very beneficial, so we can see what the biggest impact is going to be where we add in the automation. We can't automate everywhere, but we can be as effective as possible and simplify some steps so that they will be easily followed by automation. We want to be as effective as possible, make it useful, make sense before we add in the intelligence. That is the end of the last guiding principle, number 7. In review, the seven guiding principles are recommendations. They're like mindsets. They are best practices on how to adopt and adapt ITIL, and apply ITIL in your organization. The guiding principles are universally applicable. They can be used with other frameworks and methodologies like Lean, Agile, COBIT, and DevOps. They're also to be looked at as an overall approach. They can be used together, they can be used in every situation and applied equally. They're equally important when you want to roll out a change initiative or make some type of improvement. The guiding principles, again, are recommendations, they're useful for stakeholders. It's an ethical approach and organizations should consider reviewing all of the guiding principles, then decide on which one is best to use depending on the situation.
