Да, можно использовать CMDB для решения задач сервисной экономики. Основная задача CMDB — определение влияния одних элементов на другие, что по своей сути имеет экономический характер, поскольку влияние является производной от использования ресурсов. Например, сервер, использующий систему хранения данных для размещения информации, формирует взаимосвязь влияния, которая может быть использована при расчете TCO приложений. CMDB может содержать данные о всех необходимых ресурсах, включая виртуальные машины и логические диски, которые не учитываются в традиционном бухгалтерском учёте, но важны для расчёта стоимости услуг. При этом для решения экономических задач не требуется вводить специальные «экономические» связи, могут быть использованы существующие связи влияния.

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

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

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

DevOps-метрики, которые можно соотнести с элементами Causal Loop Diagram, включают: Lead Time (Time to Market), Process Time (Process Time), Deploys per day (Release Rate), процент успешно реализованных изменений (% changes successfully implemented), процент полных и точных изменений (%C/A – percent complete and accurate), PIR Coverage Index, Mean time between release implementation, Percentage of Changes Without Recurring incidents, Total time of Major incidents caused by Releases, Number of defects per release, Average number of release units per release, Emergency Change Rate, Percentage of Changes Registered.

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

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

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

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

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