Управление ИТ-бюджетом

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

Посмотрим на ИТ-проект с точки зрения управления его бюджетом.

Стихийная модель

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

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

Централизованная модель

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

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

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

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

Бюджетная модель

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

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

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

Хозрасчетная модель

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

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

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

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

• операционные расходы (OPEX) будут дробиться по макропродуктам, продуктам и вплоть до приложений, оцениваться по составу выделенных на сопровождение и техническую поддержку эксплуатации ресурсов, а также проведение приемки систем в эксплуатации;
• капитальные затраты (CAPEX) на развитие ИТ-инфраструктуры будут делиться по департаментам (внутренние задачи ИТ в том числе) и по отдельным инициаторам. Если возникает проект в пользу нескольких департаментов или организации в целом, тогда расходы можно соотнести на отдельную единицу учета либо по заданным правилам распределить по департаментам. С точки зрения ИТ каждая инвестиция может быть разнесена по продуктам, по оценкам, связанным с необходимостью работ по тому или иному приложению.

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

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

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

Конечно же, в этой модели имеются свои нюансы, но подобная схема с некоторыми оговорками уже давно работает в ряде российских компаний, а их руководство быстро получает точный ответ на вопрос: когда и за сколько можно реализовать очередные требования растущего бизнеса?

Артак Оганесян (Artak_Oganesyan@epam.com) – директор по развитию бизнеса компании EPAM Systems (Москва).