Операционный бюджет ИТ формируется через последовательность шагов: получение бизнес-планов через взаимодействие с владельцами бизнеса (BRM/SLM), согласование планов потребления услуг с заказчиками (SLM и управление емкостью сервисов), разработка планов ресурсного обеспечения включая кадры (управление емкостью ресурсов), расчет стоимости ресурсов и услуг с учетом косвенных затрат (Финансовый менеджмент в ИТ), и финальный расчет стоимости услуг по потребителям с обоснованным формированием бюджета. Этот процесс требует тесной увязки бизнес-потребностей, технических возможностей и финансового планирования.

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

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

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

При наличии нескольких заказчиков у одной ИТ-услуги существуют три основных варианта решения: 1) Заключение SLA сразу с несколькими заказчиками, что может серьезно усложнить переговорный процесс и привести к размыванию ответственности бизнес-подразделений; 2) Рассмотрение одного подразделения как заказчика ИТ-услуги, а другого - как потребителя, с заключением SLA только с заказчиком, при этом предполагается, что договоренность с потребителем - это обязанность заказчика, однако это тоже может усложнить переговоры и не всегда устраивает бизнес; 3) Выделение для разных заказчиков отдельных ИТ-услуг, что приводит к росту каталога услуг и необходимости построения более сложных связей между ними, но обеспечивает большую ясность в аллокационной модели. Последний вариант, хотя и создает более сложный каталог ИТ-услуг, часто является наиболее предпочтительным с точки зрения четкого распределения ответственности и аллокации затрат.

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

Настройка middleware считается важной компетенцией для внутренней команды, потому что именно она определяет, насколько эффективно и безопасно приложение будет работать в условиях реальной нагрузки и специфики бизнес-процессов. Middleware требуется глубокая экспертиза по настройке под конкретную нагрузку, взаимодействие различных компонентов и обеспечение безопасности. Стандартные решения, предоставляемые IaaS или SaaS, не учитывают специфику продукта, поэтому настройка и конфигурирование middleware остаются внутренней ответственностью. Без этой экспертизы, даже при наличии качественной базовой инфраструктуры, продукт не сможет функционировать должным образом, особенно если речь идет о кастомизированном решении или высоконагруженной системе.

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

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

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