Предыдущая часть Service Strategy — это искусство планировать ИТ-услуги так, чтобы к моменту, когда они окончательно сломаются на этапе Service Operation, вы уже успели уволиться или пойти на повышение.

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

Основные принципы «Сначала Согласуем» Определите горизонт правдоподобного планирования. Обычно он заканчивается ближайшим пересмотром бюджета, сменой руководителя или появлением новой срочной инициативы. Детальный план за пределами этого горизонта не нужен. Достаточно указать направления развития, ожидаемые эффекты и несколько стрелок, направленных вверх. Сохраняйте резерв ресурсов. Свободные люди, серверные мощности, лицензии и деньги необходимы на случай внезапных поручений, сокращений, реорганизаций и других форм стратегического управления. Полная загрузка ресурсов опасна: она может показать, что подразделение умеет планировать и способно отвечать за сроки. Избегайте окончательной оптимизации. Рационализация и консолидация сокращают число обходных путей. Система, построенная из нескольких частично дублирующих решений, значительно лучше приспособлена к изменениям приоритетов и поиску ответственных. Документируйте только необходимый минимум. Документация должна подтверждать наличие процесса, но не ограничивать разнообразие способов его исполнения. Если все сотрудники действуют одинаково, организация становится чрезмерно зависимой от повторяемого результата. Ограничивайте обратную связь. Актуальные метрики способны вызвать вопросы и привести к незапланированным решениям. Отчётность должна поступать с достаточной задержкой, чтобы описываемую проблему уже нельзя было исправить в рамках отчётного периода. Не допускайте бесконтрольного постоянного улучшения. Если сервис признан условно работоспособным, любое изменение создаёт риск нарушения этой хрупкой определённости. Улучшать следует только то, что уже получило статус стратегической инициативы и отдельный бюджет. Осторожно относитесь к инициативам снизу. Сотрудник может предложить полезное решение, не зная, что руководство планирует через полгода внедрить другую систему для решения похожей проблемы. Самостоятельная реализация лишит будущий проект части обоснования. Проявляйте инициативу в ответ на указания сверху. Объём работ должен быть достаточным, чтобы продемонстрировать вовлечённость, но не настолько большим, чтобы организация начала ожидать измеримый результат. Не создавайте полноценное дублирование компетенций. Большинству сотрудников достаточно поверхностно ориентироваться во всех системах. Исключением является последний специалист, понимающий старую платформу. Подготовка его замены может неоправданно продлить жизнь устаревшего решения и лишить организацию аргумента для дорогостоящей модернизации. Передавайте важные решения наверх. Самостоятельное решение создаёт персональную ответственность. Если передать вопрос достаточно высоко, его ответственность растворится в рабочей группе.