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

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

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

Выбор модели зависит от требований к гибкости, сложности системы и необходимости аудита. Например, в простых системах с чёткими ролями достаточно RBAC, тогда как в динамичных средах (многофилиальные компании) гибридная модель с ABAC обеспечит точный контроль. Неверный выбор может привести к избыточной сложности (чистый ABAC) или недостаточной адаптивности (только RBAC).

Оптимальный уровень детализации учета трудозатрат определяется через баланс между слишком мелкой и слишком крупной разбивкой работ, при котором сохраняется как достоверность данных, так и их аналитическая полезность. Многим организациям не требуется видеть трудозатраты по каждому единичному инциденту или заданию, достаточно фиксировать данные по основным направлениям деятельности. Идеальный каталог работ в организации с численностью 8-12 человек включает 10-20 позиций для обычной работы и 20-25 позиций с учетом проектов. При разработке такого каталога важно помнить, что слишком мелкое дробление работ приводит к потере достоверности учета, тогда как слишком крупная группировка делает данные малопригодными для анализа. В примере, описанном в тексте, общий каталог насчитывает 54 строки, организованные в семь групп: производство, продажи и account management, маркетинг, внутренняя работа, продукты и методики, партнеры, управление компанией. Поддерживать учет по таким 20-30 видам работ является реалистичной задачей, не требующей чрезмерно сложных инструментов или больших затрат времени.

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

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

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

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

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