Метрики могут быть использованы для оценки руководителей подразделений через систему взаимосвязанных показателей, отражающих их вклад в процессы. Решение заключается в построении матрицы, где по вертикали расположены функции (отделы, группы), а по горизонтали — процессы. Пересечение функции и процесса означает участие данной функции в реализации процесса, соответственно функциональный руководитель отвечает за предоставление необходимых ресурсов. Процессные метрики сотрудников подразделения связываются с руководителем, назначаются целевые значения, и контролируется их соблюдение. Даже если руководитель формально не несет функциональных обязанностей в процессах (например, не является ответственным в матрице RACI), такой подход стимулирует его к взаимодействию с процессным управлением. На разных уровнях иерархии метрики могут агрегироваться: например, региональные руководители оцениваются по своим метрикам, а руководитель в HQ — по агрегированным метрикам региональных руководителей. Важно, чтобы все используемые KPI были сопоставимы между собой (единая шкала от 0 до 1, одинаковое направление оценки).

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

Три основных принципа, помогающие интегрировать деятельность по развитию в повседневную работу компании: 1) Деятельность по развитию должна быть обязательной и «встроенной» в обычную ежедневную работу почти каждого сотрудника, поскольку возможности для улучшений появляются каждый день. 2) Время на развитие должно быть чётко определено и выделено явным образом, как часть работы. 3) Необходимо не позволять сотрудникам заменять выделенное время на развитие операционными задачами, поскольку рутина стремится занять всё доступное время.

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

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

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

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

Чтобы определить релевантность метрики, нужно ответить на вопрос: «Зачем мы это измеряем?» и проверить, какие управленческие решения будут приниматься на основе этих данных. Если на этот вопрос нет чёткого ответа, метрика, скорее всего, нерелевантна. Также важно убедиться, что данные невозможно легко фальсифицировать и что они действительно отражают прогресс в достижении целей, а не создают дополнительные стимулы, противоречащие этим целям.

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

На семинаре присутствовало около 70 участников. Аудитория имела неоднородную структуру: примерно треть составляли заказчики, остальные — коллеги-консультанты и интеграторы. При этом была отмечена значительная разница в уровне подготовки участников, что выразилось в диапазоне задаваемых вопросов — от стратегических вопросов управления сложными изменениями до базовых запросов о выборе инструментов автоматизации.