На семинаре были выявлены следующие проблемы в процессе управления изменениями: низкая распространенность внедренных процессов (работающий процесс у 10-12 человек из 70 участников), неоднородность знаний и опыта участников (от базовых вопросов о выборе инструментов до сложных вопросов о координации множества изменений), а также неясность границ ответственности между процессами управления изменениями и выполнения запросов пользователей.

Предложенная метрика увеличивается при регистрации новых проблем, что противоположно эффекту традиционных метрик, которые ухудшаются при росте числа новых проблем. Поскольку метрика учитывает количество новых проблем (N) в числителе формулы (N + C), увеличение N при прочих равных условиях ведет к увеличению значения метрики. Это создает положительный стимул для менеджеров процесса активнее выявлять и регистрировать проблемы, что особенно важно для процесса управления проблемами, где триггеры выявления проблем являются внутренними по отношению к оцениваемому субъекту (ДИТ).

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

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

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

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

Baseline — это эталонные данные, которые фиксируются в момент нормальной работы системы и отражают нагрузку на основные компоненты оборудования (процессор, память, дисковая и сетевая подсистемы) и характеристики потребления (количество пользователей, операций и т.п.). Эти данные нужны для сравнения с текущим состоянием системы в случае возникновения проблем с производительностью. Сравнивая текущие метрики с baseline, можно определить, какие именно элементы изменили своё поведение и стали причиной замедления работы системы.

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

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

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