CIOReview
| | MAY 202519CIOReviewOperationalization: Wikipedia states, "Operationalization thus defines a fuzzy concept so as to make it clearly distinguishable, measurable, and understandable by empirical observation. In a broader sense, it defines the extension of a concept--describing what is and is not an instance of that concept." As a corollary ­ it is better stated in a change management process as follows - If you do not know what the change is going to do, you have not evaluated it in more than x number of iterations, and it was not 100 percent successful, then you cannot roll it forward. Answer the following questions: · "What could happen if it fails?" not "What do I do if it fails?" · "What friction would it introduce into the business, and will the staff there have to do something which is.... Reboot, reset, how do we notify, how do we overcome impact?" · "How does this affect the Customer and their confidence in our practice?" The 'duh' moment is 'when everyone knows this'; however, not every team takes the time and planning to build and test, monitor and test, alert, and test, then stop and assess, test and adjust, test to recover from an event. This is a conscious and intent driven act! This is just not about 'recovery'; this is about 'being operational' in all your practices and to ensure that in this new climate of cloud, hybrid, and multiple data centers, we strive not to have an event. The best support model and communication to your customers is they never knew there was an issue/event that affected them. Something we built years ago was an `11-Step drop.' In short, where do we start when we get a call for an issue? What if we started with that 11-step drop and used it as a checklist for operationalization? You can start all these sentences with "Have I thought about resiliency?" but in the beginning troubleshooting, we used this as a guide. Start each question with 'Do you have:' 1. Power 2. Network 3. Servers 4. Storage 5. Services 6. Security 7. Alerts 8. Monitors 9. Vendor integrations 10. Other dependencies 11. A list of what changed last. As understood, this must be top-level (C-Suite) sponsored and a fully sanctioned business process like cybersecurity. Each team must plan `right to left' and build this into their day-to-day process, from business stakeholders, product owners, business analysts, developers, Dev Ops, systems engineers, and support teams! Is your first question, How or Why, when a request is made to put technology into production? What about making your first question, "What does great look like." As technologists, we always think about what new thing we want to build. What if we took the `acceptance criteria' and worked backward? This is not a mission statement; it is more a comprehensive executive summary of the expectations for your customers, stakeholders, and internal teams to `dream to the theme' or `done to the thought' a.k.a `D-triple T.' Could the `why' be obvious? What is your loss per minute? People, Time, Customer confidence, all those items have a monetary impact. Are you a critical provider of utilities, healthcare, or transportation? What are your users' expectations? What are the key learnings in your segment? What mistakes have others made, and how do you prevent them? How does preparation meet possibilities meet costs? Take a moment, understand the implementation, and think 'great' backward, operationalization, done correctly, is (right to left). OPERATIONALIZATION-ARE YOU THINKING RIGHT TO LEFTBy Jim Mason, Vice President, Customer and IT Systems Support, Little Caesars PizzaJim MasonThe best support model and communication to your customers is they never knew there was an issue/event that affected themCXO INSIGHTS
< Page 9 | Page 11 >