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

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

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

Использование активных RFID-меток считается непрактичным для управления конфигурациями с большим количеством единиц (тысячах единиц) по нескольким причинам. Во-первых, их стоимость достаточно высока — начинается от 20 USD за штуку, что делает решение экономически невыгодным при массовом применении. Во-вторых, активные метки требуют замены батареек, что создает дополнительные сложности в обслуживании, особенно при управлении большим парком оборудования. Для использования всего в трех конфигурационных единицах такой вариант может быть приемлемым, но для масштабных проектов его эффективность сильно снижается.

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

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

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

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

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

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