Автор статьи считает, что громкие формулировки миссий могут вызывать скептицизм у сотрудников, потому что на практике реальная работа часто не соответствует грандиозным декларациям компании. Например, миссия Asana, которая «помогает человечеству процветать», кажется преувеличенной, если продукт компании представляет собой всего лишь менеджер задач. Когда слова не подкреплены реальными делами и достижениями, сотрудники начинают воспринимать подобные заявления как «высокопарную муть». Люди, наученные опытом и критическим мышлением, быстро научатся игнорировать такие формулировки. Таким образом, если компания стремится использовать миссию для мотивации сотрудников, важно, чтобы эта миссия была реалистичной и подкрепленной конкретными действиями.

Для адаптации модели AARM к внутренним inhouse продуктам необходимо внести следующие корректировки: Acquisition (привлечение) - измерять не количество новых пользователей, а успешность продвижения продукта внутри организации, степень вовлечения ключевых стейкхолдеров и одобрение руководства; Activation (активация) - фокусироваться на скорости и простоте внедрения продукта в рабочие процессы, времени до первой полезной реализации; Retention (удержание) - оценивать стабильность использования продукта во времени, уровень удовлетворенности внутренних клиентов, продолжительность контрактов или обязательств по использованию; Monetization (монетизация) - заменить на измерение улучшения бизнес-процессов, снижения затрат или повышения эффективности. Важно создать отдельные метрики для различных ролей (владельцы процессов, конечные пользователи, руководство) и учитывать, что спонсоры и пользователи могут иметь разные интересы. Также необходимо уделять особое внимание метрике TTV (Time-To-Value), так как для внутренних продуктов быстрое достижение ценности критично для дальнейшего поддержки и развития решения.

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

Бизнесу предоставляется механизм взаимодействия, позволяющий по их собственной инициативе пересматривать соглашение. Конкретные заказчики могут заключать дополнительные соглашения по конкретным ИТ-сервисам, которые будут изменять положения общего SLA 'AS IS'. Это дает бизнес-подразделениям возможность выразить свои требования и скорректировать условия обслуживания под свои потребности, но при этом не блокирует старт процесса согласованием со всеми заинтересованными сторонами.

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

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

При наличии нескольких R (Responsible) в RACI-матрице важно четко различать, кто именно отвечает за организацию работы, а кто просто участвует в ее исполнении, чтобы избежать путаницы в обязанностях и ответственности. Если не провести это разделение, может возникнуть ситуация, когда несколько человек считают, что ответственность за организацию лежит на другом, что приведет к срыву сроков или низкому качеству выполнения задачи. Четкое определение организатора работы помогает выстроить правильную иерархию внутри задачи, определить центр принятия решений и точку ответственности за процесс. Это также позволяет руководителю контролировать именно те аспекты, которые критичны для конечного результата, не вникая во все детали исполнения.

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

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

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