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

CI/CD, или конвейер развёртывания, является основным и необходимым компонентом DevOps. Даже если DevOps понимается только как набор технических практик, без конвейера развёртывания невозможно говорить о существовании DevOps в принципе. Конвейер автоматизирует процесс интеграции кода, тестирования и доставки приложений в рабочую среду. Он является ключевым элементом, который обеспечивает непрерывную доставку и развертывание изменений, что критически важно для современной разработки программного обеспечения. CI/CD позволяет командам быстрее доставлять изменения конечным пользователям, снижая при этом риски ошибок и упрощая процесс выпуска новых версий продукта.

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

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

Три основные причины, почему "заложенные" в процесс KPI не очень хорошо работают: 1. Авторы KPI спроектированного процесса часто слепо копируют рекомендации из "умных" книг (ITIL, COBIT и другие), не учитывая, что приведенные там метрики являются лишь примерами для иллюстрации, а не готовыми решениями, подходящими для конкретной организации. 2. При внедрении KPI часто игнорируется здравый смысл, когда стремятся измерить всё подряд и отвергают субъективные данные (например, опросы удовлетворенности пользователей), хотя некоторые аспекты управления можно и нужно оценивать через удовлетворенность. 3. KPI отдельных процессов проектируются изолированно, без учета их взаимосвязей и места в общей системе управления ИТ. Это создает фрагментарную картину вместо комплексной системы оценки деятельности ИТ-подразделения.

В методологии ITIL приоритет инцидента определяется на основе двух факторов: уровня влияния (impact) и уровня срочности (urgency). Уровень влияния измеряет, насколько сильно проблема влияет на работу бизнеса или конечных пользователей. Уровень срочности учитывает, насколько быстро необходимо решить проблему, исходя из времени, в течение которого может сохраняться негативное влияние. Результатом комбинации этих двух величин становится приоритет, который помогает правильно расставить последовательность действий при устранении инцидента.

Учет трудозатрат необходим для оценки эффективности компании в выполнении типовых работ, унификации внутренних процессов, разработки технологических карт с нормативными трудозатратами, выявления узких мест в работе (например, регулярного превышения трудоемкости по определенному виду деятельности), расчета себестоимости услуг и понимания реальных затрат на предоставление услуг клиентам. Этот инструмент помогает оптимизировать процессы и повышать рентабельность бизнеса.

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

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

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