В формуле First Time Resolution (FTR) при расчёте в разрезе рабочих групп используются два основных операнда: Nj и Sj. Sj представляет собой количество объектов, возвращённых на доработку в j-тую группу. Nj — это количество обращений, полностью обработанных j-той группой, включая как закрытые без рекламаций обращения (Cj), так и возвраты на доработку (Sj). Таким образом, Nj = Cj + Sj, где Cj — количество обращений, закрытых без рекламаций. Расчёт выполняется за период, когда завершена проверка решения, а не само решение задачи.

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

Конфигурационная единица (КЕ, CI) - это любой элемент, который должен быть управляемым для обеспечения услуги или части ИТ-инфраструктуры. Это может быть физическое оборудование (серверы, коммутаторы), программное обеспечение (приложения, операционные системы), документация, сетевые компоненты или даже персонал. Каждая конфигурационная единица характеризуется уникальным идентификатором и набором атрибутов, которые описывают ее свойства и состояние. КЕ служат основными элементами в процессе управления конфигурациями, позволяя отслеживать изменения, устанавливать связи между компонентами и анализировать влияние изменений на ИТ-услуги.

Внедрение модели SIAM (Service Integration and Management) дает организации несколько существенных преимуществ. Прежде всего, это позволяет эффективно управлять сложной экосистемой из нескольких внешних и внутренних поставщиков услуг. Модель устанавливает четкие роли и процессы для сервис-интегратора, который обеспечивает координацию всех поставщиков, минимизируя риски дублирования функций или пробелов в предоставлении услуг. Это приводит к повышению качества конечных услуг для бизнеса, снижению накладных расходов на управление множеством подрядчиков и улучшению управляемости сложных ИТ-ландшафтов. SIAM также способствует более прозрачному распределению ответственности и упрощает мониторинг выполнения обязательств поставщиками.

Путаница возникает по причине того, что стандарт ITIL V3 описывает процессы и общие подходы к управлению, но не детализирует организационные роли на уровне исполнения. Например, роль "Практик изменений" (Change practitioner) включает обязанности по мониторингу и проверке, но не прямо указывает на необходимость координации действий, которая скорее относится к процессу управления изменениями в целом. Аналогично, в процессе управления релизами координация формально не закреплена за конкретной ролью, хотя в обязанности менеджера процесса входит координация ресурсов и взаимодействие с другими процессами. Это приводит к неоднозначности в реализации процессов на практике и необходимости адаптировать стандарт под внутренние структуры организации.

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

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

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

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

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