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

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

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

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

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

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

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

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

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

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