Почему ИТ узнаёт о потребностях в оборудовании позже всех

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

Всем привет, это команда SimpleOne ITAM. Разберём, откуда берётся разрыв между двумя циклами планирования и почему эффект внезапности можно убрать, не пытаясь их синхронизировать.

Два календаря: финансовый год и жизненный цикл оборудования

Бюджет верстается раз в год по графику финансового отдела: сбор заявок от подразделений, согласование, утверждение, и к декабрю цифры уже закрыты. У оборудования доступа к этому графику нет — износ аккумуляторов, деградация дисков и отказы блоков питания идут по собственной логике, а она с финансовым годом не сверяется.

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

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

Прикинем на условных цифрах:

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

Можно же было просто отправить заявку заранее?

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

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

Что делать: постоянный учёт состояния вместо разовой инвентаризации

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

Вернёмся к условному парку из 1 200 ноутбуков. Если у каждого уже указана дата ввода в эксплуатацию, цифра «около 300 замен в год» перестаёт быть оценкой на глаз и превращается в список с кварталами, когда четырёхлетний срок истекает у какой партии. Добавим историю инцидентов, и может оказаться, что одна модель ломается заметно чаще остальных, и её замену разумно планировать раньше остальных. Финансы получают понятные цифры, не срочную заявку посреди ноября: «в первом квартале точно понадобятся 70 ноутбуков, ещё 20–30 — с вероятностью около половины».

Эффект внезапности исчезает. Конкретный отказ остаётся непредсказуемым, как и всегда, но ожидаемая стоимость отказов по парку в целом попадает в бюджет заранее. Разберём на примере SimpleOne ITAM — системы управления ИТ-активами, которая сопровождает оборудование от сбора потребностей и закупки до вывода из эксплуатации. Основа здесь — единое ядро с SimpleOne ITSM: актив в ITAM и конфигурационная единица в CMDB логически связаны, а отдельную интеграцию между ними заводить не нужно.

В SimpleOne ITAM используются общие классы и модели CMDB, коллекции REM-атрибутов для хранения переменных атрибутов активов

Первое, что это даёт в разрезе двух календарей — данные копятся сами, а не к дате инвентаризации. Инцидент о поломке ноутбука открывается вместе с карточкой актива, в которой сразу видна гарантия, а стоимость ремонта при закрытии инцидента автоматически списывается на сам актив. Через год в карточке складывается история, которую раньше пришлось бы собирать по заявкам вручную: сколько раз устройство чинили, во сколько это обошлось, не проще ли его заменить.

Второе — закупка опирается на склад. Управление закупками в ITAM (подробнее о модуле уже рассказывали на Хабре) учитывает актуальные складские остатки, а потребности собираются в одном месте, с номенклатурой, контролем лимитов и согласованием.

А для финансов в системе есть то, на чём строится разговор о бюджете: контракты, расчёт совокупной стоимости владения (TCO) и распределение затрат по центрам финансовой ответственности.

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

Резюме

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

Сколько из закупок прошлого года были плановыми, и откуда вы это знаете?