Модель Compass Model - это структурированный подход к анализу потребителя, разработанный Институтом Disney и упоминаемый в курсе ITIL 4 Drive stakeholder value. Модель представляет портрет потребителя в виде четырёх "сторон света": Север (потребности) - основные причины, побуждающие к выбору; Запад (желания) - менее конкретные, скрытые цели и пожелания; Юг (стереотипы) - предвзятость и установки потребителя, основанные на его опыте; Восток (эмоции) - чувства, которые проявляет или ожидаемо проявит потребитель в процессе взаимодействия с услугой. Практическое применение модели помогает структурировать понимание потребителя и определять, как создавать ценность для клиента, разделяя его ожидания на базовые потребности и дополнительные желания, а также учитывая стереотипы и эмоции.

Бизнес-услуга (или customer-facing service в терминах ITIL V3) - это услуга, которая непосредственно предоставляется заказчику и на которую заключается соглашение об уровне услуги (SLA). Это видимая для клиента услуга, с которой он непосредственно взаимодействует. Примером может служить комплексное ИТ-обеспечение процесса продаж или бухгалтерского учета, которое клиент заказывает и использует напрямую.

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

Предпроектное обследование экономически оправдано, так как оно позволяет снизить проектные риски и точно определить объем работы, что в итоге приводит к значительной экономии средств. В конкретном примере, приведенном в тексте, предварительная бюджетная оценка проекта сократилась в 4 раза после проведения обследования, при этом стоимость самого обследования составила всего 1,5% от суммы сэкономленных средств. Для консультационных проектов обследование считается экономически эффективным, если его стоимость не превышает 5-10% от общей стоимости проекта, особенно учитывая, что стандартные риски при неопределенной постановке задачи обычно начинаются от 10%.

При выборе типового процесса или системы автоматизации важно задавать следующие вопросы: что конкретно будет получено в результате внедрения, помимо документации или системы; какие задачи смогут быть решены с помощью предложенного решения; как система или процесс адаптирован к особенностям конкретной компании (организационной структуре, географической дислокации, компетенции сотрудников); какие элементы стандартных решений уже разработаны и включены в предложение; как система или процесс поддерживает работу в территориально распределенной компании; каковы требования к компетенции персонала для поддержки и сопровождения решения; как система обновляется до новых версий и какие риски связаны с этим процессом; что входит в стоимость предложения и какие дополнительные услуги предоставляются. Эти вопросы помогут понять, насколько предложенное решение соответствует реальным потребностям компании и сможет ли оно привести к достижению желаемого результата.

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

Чтобы избежать превращения разработчиков в роботов, необходимо сделать их соучастниками происходящего. Это включает вовлечение в процесс co-creation (совместного создания ценности) с другими участниками команды и конечными пользователями продукта. Необходимо обеспечивать прозрачность общего результата работы команды, а не ограничиваться предоставлением отдельных задач по разработке фич. Важно демонстрировать живое влияние их работы на пользователей и бизнес-показатели, а не ограничиваться цифрами типа увеличения конверсии на незначительные проценты. Также полезным может быть временная стажировка разработчиков в поддержке продукта или непосредственно у пользователей, чтобы они могли пережить опыт "в поле" и понять реальный контекст использования создаваемых ими решений. Создание безопасной среды, где можно свободно выражать мнения без поиска виновных и с презумпцией добросовестности, также критически важно для поддержания вовлеченности разработчиков.

Уровень доступности является одним из важнейших параметров качества ИТ-услуг, фиксируемых в SLA (соглашении об уровне обслуживания). Он определяется как отношение времени, в течение которого услуга была доступна, к общему времени, в течение которого услуга должна была быть доступна согласно установленному графику. Расчет уровня доступности основывается на учете периодов недоступности. Для однозначной трактовки и измерения используется критерий доступности, который включает в себя четкое определение границ того, что считается доступностью услуги, а что — ее недоступностью.

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

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