Операционный стандарт — это документ, фиксирующий уровень предоставления определённой технической услуги в рамках ИТ-инфраструктуры в целом. Например, «Операционный стандарт. Сети и каналы передачи данных», «Операционный стандарт. СУБД», «Операционный стандарт. СХД» и другие. Эти стандарты описывают параметры услуги: доступность, технологические перерывы, время восстановления, поддержку, ограничения, ответственных лиц и т.д.

Основное различие между успешной и неуспешной реализацией управления конфигурациями заключается в том, фокусируется ли процесс на создании реальной ценности для пользователей или просто формальном заполнении базы данных. Успешные реализации начинаются с анализа потребностей заинтересованных сторон и настройки процесса таким образом, чтобы информация в CMDB была актуальной, точной и полезной для принятия решений. Неуспешные проекты, напротив, сосредотачиваются на процессе ради процесса, требуют значительных ресурсов на поддержание данных без видимой пользы, что приводит к потере доверия пользователей и низкому уровню использования системы.

Учет траектории развития при найме агента изменений важен, потому что различные типы траекторий требуют различных подходов к управлению и развитию сотрудника. Компания должна понимать, готова ли она идти медленно, но с большой надежностью изменений (и тогда подойдет "подмастерье с высоким потенциалом"), или хочет двигаться быстро (требуя большей адаптивности, настойчивости и логического мышления от специалиста). Также важно учитывать, будет ли компания готова к управлению высокопотенциальными сотрудниками, которые могут быстро перерасти свои позиции, иначе нанятый человек может стать "бомбой замедленного действия".

Разбивка на мелкие шаги снижает сопротивление изменениям, так как каждый этап кажется менее сложным и рискованным. Преимущества этой стратегии: возможность применения пробных периодов и пилотных проектов, сохранение правил возврата к старым практикам, постепенное накопление критической массы изменений, упрощение возражений против возврата к прошлому. Недостатки — низкая скорость реализации и необходимость долгосрочной настойчивости руководящей коалиции. С течением времени сопротивляющиеся изменениям теряют аргументы, так как возврат к исходному состоянию становится невозможным.

Книга описывает два различных типа каталогов: Service Catalog (каталог для заказчиков) и Service Request Catalog (каталог для пользователей). Авторы подчеркивают, что это два совершенно разных инструмента, хотя и связанных общей темой предоставления ИТ-услуг. Service Catalog ориентирован на руководителей бизнес-направлений и содержит информацию об услугах, их стоимостях и уровнях сервиса. Service Request Catalog предназначен для конечных пользователей и содержит шаблоны запросов на стандартные услуги, которые пользователь может легко заказать.

Модель Value chain недостаточно подходит для описания внутренних ИТ-отношений в компании, потому что она предполагает линейную последовательность взаимодействия, где каждый субъект последовательно выступает поставщиком для следующего. Внутри корпоративной среды, особенно в ИТ, отношения значительно сложнее: могут быть множественные заказчики для одной услуги, разделение функций заказчика и плательщика, сложные пересечения требований от разных подразделений. В линейной модели один субъект принимает решения за все аспекты услуги, тогда как во внутренних корпоративных отношениях решения о требованиях, объемах и стоимости распределены между несколькими участниками с разными интересами.

Типичная структура включает следующие этапы: приветственное сообщение с упоминанием радости от звонка клиента; первый уровень IVR с выбором категории услуг, например, «Кредиты»; второй уровень IVR с уточнением направления, например, «Ипотека»; информирование о том, что услуга предназначена только для действующих клиентов; уведомление о переводе на оператора; запрос об оценке работы сотрудника; сообщение об отсутствии свободных операторов при высокой нагрузке; фактическое соединение с оператором, не специализирующимся на запрашиваемой услуге; повторное переадресовывание на профильного специалиста; необходимость повторного изложения проблемы из-за отсутствия передачи информации между сотрудниками; запрос дополнительной информации, например, номера договора; возможный обрыв связи на критическом этапе общения.

Важно для руководителя учиться отделять управленческие функции от исполнительских задач, чтобы не перегружать себя рутинной работой и иметь возможность фокусироваться на стратегических вопросах. Это позволяет эффективно контролировать процессы, развивать команду и обеспечивать соблюдение ключевых показателей эффективности. Если руководитель постоянно занимается исполнением задач, он теряет контроль над общей картиной работы, не успевает реагировать на критические ситуации и не создаёт условий для роста сотрудников, что в долгосрочной перспективе снижает эффективность всей организации.

Простого обсуждения технического плана может быть недостаточно из-за эффекта Даннинга-Крюгера и различий в понимании задачи. В тексте приводится пример, когда команда обсудила план рефакторинга компонента и разошлась с общим пониманием задачи. Однако через месяц выяснилось, что исполнитель занимался не рефакторингом, а переносом проблемы в другой слой системы. Это произошло потому, что человек не осознавал глубины своей некомпетентности: «Не уверен: то ли рефакторинг сделал мой код более читаемым, то ли я понимаю код лучше, потому что убил на него кучу времени». Таким образом, даже если все присутствовали на собрании и обсудили план, это не гарантирует единообразного понимания и правильной реализации задачи из-за когнитивных искажений и недостатка коммуникации.

Установка дедлайнов часто выступает заменой реального управления, так как позволяет создать иллюзию контроля над процессом. Если организация не обладает навыками гибкого управления, работы с неопределенностью и оценки рисков, то дедлайны становятся упрощенным инструментом для планирования. Однако такой подход не решает проблему вариативности и может ухудшить качество результатов.