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

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

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

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

Аспект 'Потоки создания ценности и процессы' относится как к системе создания ценности в целом, так и к предоставлению отдельных услуг. Он включает все виды деятельности, рабочие процессы, средства управления и процедуры для достижения согласованных целей. Данный аспект рассматривает, как интегрировать и координировать различные части бизнеса для повышения ценности продуктов и услуг через создание операционной модели более высокого уровня - цепочки создания ценности. Поток создания ценности (value stream) - это последовательность шагов, которые предпринимает организация для создания и предоставления продуктов и услуг потребителю. Он представляет собой комбинацию видов деятельности цепочки создания ценности. Процессы - это набор взаимосвязанных или взаимодействующих видов деятельности, преобразующих входы в выходы, и они являются частью потоков создания ценности. Например, поток создания ценности для поддержки пользователей может включать практики управления инцидентами, службы поддержки, управления проблемами и другими процессами. Важно рассматривать процессы не изолированно, а как последовательность действий в потоке создания ценности, и определять такие потоки для каждого продукта и услуги.

При внедрении системы учета трудозатрат рекомендуется следовать нескольким ключевым принципам. Во-первых, определить оптимальный уровень детализации учета, создав каталог работ, который включает основные направления деятельности организации (для группы из 8-12 человек достаточно 10-20 позиций для рутинной работы и 20-25 с учетом проектов). Во-вторых, обеспечить своевременную фиксацию трудозатрат - лучше сразу после завершения работы, а максимальный допустимый срок - конец рабочего дня, чтобы минимизировать ошибки в учете (недельный учет может давать искажения до 10%). В-третьих, внедрить правильный подход к планированию, используя принцип 'just-in-time' с загрузкой 90-110%, чтобы избежать накопления снежного кома незавершенных задач. В-четвертых, убедиться, что затраты времени на сам учет минимальны - для специалиста около 10 минут в день (2% рабочего времени), для руководителя - до 5% на контроль. Наконец, обеспечить мотивацию сотрудников к точному учету и контролю со стороны руководства, так как без этого даже самая продуманная система может не дать ожидаемых результатов.

Бизнес-роль — это набор системных ролей из разных ИТ-систем, объединённых общей функцией в рамках бизнес-процесса или подразделения. Например, бизнес-роль 'Финансовый аналитик' может включать системные роли 'Пользователь модуля отчётности' (в ERP-системе) и 'Аналитик данных' (в BI-инструменте). Бизнес-роли отражают реальные задачи сотрудников, в то время как системные роли — технические права в рамках отдельных приложений. При масштабировании ролевой модели от уровня приложения до всего предприятия роль администратора управляет бизнес-ролями, которые автоматически распространяют доступ через связанные системные роли.

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

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

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