Психология ИТ-бюджета
Зачастую мы – те, кто так или иначе связан с управлением ИТ, – склонны считать, что управление ИТ – это в первую очередь технология и процесс, а соответственно склонны недооценивать остальные аспекты этого явления, такие, как, например, психология и финансы. Точнее, психологии мы не чужды буквально от рождения, да и про финансы-то как раз все помним. Только как-то все больше на интуитивном уровне (технарь – значит, разберется во всем). И если про психологию сказано достаточно много, то про финансы в ИТ как раз наоборот, довольно мало. По крайней мере в отраслевой популярной литературе. Хотите об этом поговорить?
Если серьезно: что мы, айтишники, хотим и что нам надо бы знать о финансах? Ну для начала мы знаем слово «бюджет». И знаем, что это некоторая сумма, которая выделяется на определенную потребность. Мы хорошо справляемся с тем, чтобы реализовать бюджет, но все ли с той же легкостью смогут его сформировать? Боюсь, что не все. И причин тому может быть достаточно много, но лично мне чаще встречались три: запутанные и непрозрачные правила формирования бюджета по компании в целом, запутанные и непрозрачные правила формирования бюджета ИТ и пресловутый человеческий фактор.
Человеческий фактор
С ним вроде все понятно. Хороший айтишник необязательно должен до последнего винтика разбираться в финансах. А если учесть, что некоторым это по большому счету не очень и надо (интереснее заниматься айтишными вещами, а не считать презренное злато), то становится понятно, почему порой в финансовом департаменте выделен сотрудник, ответственный за верстку и ведение ИТ-бюджета. Но это совсем уже крайний случай – чаще все-таки бюджет ИТ ведет тот, кто отвечает за ИТ. И тут как раз вступают в силу факторы другого порядка. Хорошо, когда понятны правила формирования бюджета – в этом случае достаточно обладать определенным кругозором и небольшим чутьем, чтобы составить план потребностей, который затем переложить в бюджет. А если нет? Я несколько раз наблюдал картину, когда сотрудники финансовых служб разных организаций совместно с ИТ-директором мучились, составляя бюджет по образу и подобию того, как это было принято в компании. И в общем не было бы проблем, да вот только компании занимались, например, оптовой закупочной деятельностью, а ИТ работало, что называется, «в розницу». Безусловно, опыт бюджетирования «розничных» процессов в компании был – например, та же бухгалтерия, административный отдел. Сложность в том, что они не занимались реализацией проектов и не закладывали в бюджет суммы на покрытие возможных сугубо проектных рисков. Да и вообще, пытаться подойти к бюджету проекта с позиции оптовых закупок, скажем честно, не самая правильная идея. Тем не менее следование принятым правилам было обязательным – потому и мучились.
Разновидностью описанной выше картины является ситуация, при которой невнятные правила распространяются на бюджет ИТ. Так происходит, например, когда бюджет пытаются слишком формализовать. Предположим, есть в нем статья «Обновление парка ПК». На нее зарезервирована определенная сумма. Собственно, а как формируется эта сумма? Где-то – методом «среднего», где-то – мониторингом рынка, а где-то нужно умножить курс евро на интенсивность свечения второй звезды в созвездии Ориона и привести к разумному методом подгона. Понимаете, о чем я? Да, о том, что при составлении бюджета можно применить массу формул, слабо имеющих отношение к действительности, а после подгонять результат под известное решение, потому что «все равно больше не дадут».
Обоснование бюджета
Это отдельный разговор. Приведу самый абсурдный пример: бюджет, в котором любая, даже самая мелкая закупка подтверждалась ТКП. В результате формирование бюджета превращалось в футбол: никто не хотел обосновывать, например, канцелярию или мелкие закупки типа винтов, гаек и т. д. В итоге канцелярию сотрудники покупали сами, мелкие закупки оформляли только в случае крайней необходимости и вообще процесс бюджетирования был «любим» всеми его участниками. Справедливости ради отмечу, что со сменой финансового директора процесс стал проще, но о «тех временах» вспоминают даже те, кто не работает в компании уже лет пять-семь.
Еще стоит упомянуть о такой замечательной вещи, связанной с бюджетированием, как процесс согласования и утверждения бюджета. В разных организациях происходит по-разному, но если подняться на «верхний уровень», то моделей может быть три:
- Бюджет защищается тем, кто ответствен за его формирование (с обоснованием по статьям) перед комиссией. Вариации в общем отличаются форматом и формой защиты (очно, заочно, презентацией, докладом), степенью детализации и составом принимающей бюджет комиссии. В целом такой вариант почти всегда хорош, за исключением случаев, когда защита бюджета превращается в перемет торгов и манипуляций. Но с другой стороны – это жизнь, и разумный торг (поиск компромисса) – одна из ее составных частей.
- Бюджет принимается личным решением. В этом случае защита как таковая обычно сводится к вопросам утверждающего и ответам того, кто бюджет готовил. А дальше результат очень сильно зависит от личностей участников. Понятно, что если между ними конфликт, то, в отличие от первого случая, бюджет будет приниматься долго. В первом же случае возможно нивелировать личные отношения за счет апелляции к коллегиальному органу. С другой стороны, если между сторонами нет конфликта, то, наоборот, вероятность принятия бюджета выше. Но и возможностей для злоупотреблений больше.
- Бюджет принимается каждый раз по новым правилам. Это вообще самый плохой случай, когда правила меняются по ходу игры. Потому что, с одной стороны, отсутствие четких и понятных правил – это хорошее поле для управленческих манипуляций, с другой –поле для откровенного мошенничества, а с третьей – это поле возможностей пробить нужное. Правда, ни один из этих случаев не гарантирует ровным счетом ничего: вполне вероятна ситуация, при которой бюджет внезапно окажется аннулирован, урезан или же отчет о его исполнении не принят на основании того, что правила уже поменялись.
Что можно посоветовать ИТ-директору в такой ситуации? По возможности договариваться о правилах формирования бюджета, делая упор на стабильности предоставляемых сервисов. Например, если не выделить бюджет на текущий ремонт ПК, то этот сервис оказывается в зоне риска – запчасти необходимо приобретать заблаговременно. А это, в свою очередь, может негативно сказаться на основном бизнесе. Подобные аргументы обычно хорошо действуют, особенно на тех, кто так или иначе отвечает за финансовый результат организации. При этом, правда, не стоит путать «нечеткие правила» и «сокращение издержек». Потому что по большому счету сокращение издержек – это временное правило над правилами. И, честно говоря, в ИТ почти всегда есть возможность сократить расходы. Только надо четко понимать и договариваться о том, к чему приведет сокращение издержек по той или иной статье. И насколько такое сокращение приемлемо для бизнеса.
Прямой и рисковый бюджеты
Говоря о сокращении издержек, можно договориться о том, что бюджет будет выделен прямой (то есть тот, который скорее всего будет потрачен) и рисковый (который будет потрачен в случае наступления какого-либо риска). Таким образом, на выходе получится ситуация, при которой часть прямого бюджета переводят в рисковый. И, следовательно, возникает определенная экономия. Поясню на примере. Предположим, проект бюджета предполагал закупку двух серверов для замены устаревших, но рабочих машин. Ввиду сложной ситуации эта закупка перешла в бюджет рисков, то есть она будет осуществлена в случае, если возникнет риск остановки сервиса, который базируется на данном сервере, с величиной, превышающий определенное пороговое значение. Тут, правда, есть несколько «но». Первое из них состоит в том, что такого рода вещи можно делать только с неосновными (или некритичными) сервисами. По моему мнению, экономия на критичном сервисе в кризис допустима только в крайнем случае, когда общая финансовая ситуация такова, что другого выхода нет: или так – или никак.
К слову, именно кризис становится зачастую индикатором правильности построения системы бюджетирования. С одной стороны, он может показать, насколько бюджет управляем. С другой – проверить, насколько бюджет оптимизирован и сбалансирован. И в-третьих – выделить действительно важные расходные статьи (так называемый «минимальный бюджет первого приоритета», то есть то, без чего ИТ просто не сможет работать). Правда, проверка эта может оказаться жесткой, местами даже жестокой. Это как, например, в лаборатории испытывают образец на механические нагрузки: выдержит – не выдержит. Правда, и образец, даже если выдержал, испытывают ровно один раз. Затем меняют. С ИТ (или с бюджетом ИТ) так вряд ли поступишь – он как бы многоразовый по умолчанию, поэтому очень важно, проводя любые оптимизации и управленческие воздействия, не пережать до состояния, когда ИТ будет проще поменять, чем восстановить. Во-первых, это достаточно дорого, а во-вторых – не факт, что сама организация переживет подобное вмешательство.
Что поставить во главу угла
Я тут много говорил о бюджете как классе. Тем не менее на просторах нашей Родины довольно часто встречается, когда бюджета в ИТ просто нет. Есть текущие расходы, которые в той или иной форме утверждаются ответственным лицом. Точнее, бюджет, может, где-то и есть (в виде суммы расходов), но вот до ИТ не доводится. Да и надо ли его доводить, если ИТ маленькое и предприятие тоже маленькое. Или если всех все устраивает. Тут, правда, можно сказать, что кто не управляет собственным бюджетом, не планирует и не исполняет, тот вроде как не управляет и подразделением: риски выше, все решения отданы вышестоящему начальству. Но, повторю свою мысль, если всех все устраивает, то неправильность ситуации – не повод что-то менять только потому, что так будет более правильно. На самом деле «более» или «менее» правильно – в данном случае весьма относительны. С точки зрения правильной организации процессов это, может быть, и так. А вот с точки зрения удобства применимости в данном конкретном случае – вопрос может оказаться весьма спорным. Хотя бы потому, что правильно, по науке выстроенный процесс сам по себе ничего не гарантирует, кроме того что описан в учебнике и при стечении определенных обстоятельств способен привести к прогнозируемому результату.
Очень хороший вопрос: что поставить во главу угла при работе с бюджетом? Наверное, не открою секрета, если скажу, что однозначного ответа на этот вопрос нет. Вернее, он в каждом случае будет своим. И зависеть от конкретных обстоятельств, конкретной организации и конкретных людей. Кто-то во главу угла поставит экономию (возможно, даже в ущерб качеству), кто-то – процесс, кто-то – сбалансированность. При этом повторю еще одну очень важную мысль: бюджет должен быть такой, чтобы с ним было удобно работать. То есть бюджет – это инструмент для работы, а не объект для поклонения. Соответственно, его предназначение – делать эту самую работу чуть более прозрачной, удобной и предсказуемой. И никак не наоборот.
Опубликовано 01.04.2015