Налоговая проверка. В переговорке сидят финансовый директор, главный бухгалтер, руководитель ИТ-инфраструктуры и человек, который вчера ещё спокойно закрывал заявки на ноутбуки, мониторы и списание старого железа.
На экране две выгрузки: в мониторинге, CMDB и сервисных данных видно 980 единиц оборудования, а в 1С на балансе числится 1420 активов. Zabbix показывает живые узлы, CMDB хранит заведённые конфигурационные единицы, сервис-деск помнит выдачи, ремонты и обращения пользователей. Бухгалтерская система держит свою картину: инвентарные номера, даты принятия к учёту, стоимость, подразделения и документы.
Разница составляет 440 активов. В деньгах это примерно 35 млн рублей по первоначальной стоимости, если считать серверы, сетевое оборудование, рабочие станции, мониторы, оргтехнику и всё, что годами закупали «под проект», «на филиал», «временно» и «потом разберёмся».
ИТ смотрит на таблицу и раздражается первым: половина этого оборудования давно не участвует в эксплуатации. Что-то сломалось, что-то заменили, часть лежит в шкафу без блока питания, часть уехала в филиал и пропала из центрального учёта. Бухгалтерия смотрит на ту же таблицу и раздражается не меньше. Пока нет акта, инвентарного движения и подтверждённого списания, актив числится в учёте. Даже если оборудование относится к обычному движимому имуществу и не попадает в налог на имущество, по нему остаются первичка, материальная ответственность, отчётность и вопросы аудитора.
Мы в команде SimpleOne ITAM часто видим этот конфликт на проектах. Обычно он начинается с попытки «просто сверить списки» и быстро упирается в разницу подходов. Для ИТ актив связан с эксплуатацией, для бухгалтерии — с документами. Обе стороны по-своему правы, поэтому данные расходятся снова и снова.
Два мира, два учета
Для ИТ актив существует, пока он работает и участвует в инфраструктуре. Сервер отвечает в мониторинге, ноутбук выдан сотруднику, коммутатор стоит в стойке, рабочая станция выходит в сеть, устройство передаёт данные в EDR или MDM. Если оборудование умерло окончательно, его надо вынести из эксплуатации, заменить, утилизировать и закрыть инцидент.
Бухгалтерия смотрит на актив через документы. Актив существует, пока его приняли к учёту и пока его движение подтверждено документами. Он может лежать в коробке, три года не включаться и выглядеть как экспонат музея офисной техники, но для бухгалтера это всё ещё актив если по нему нет списания, перемещения, передачи ответственному лицу или другого закрывающего документа.
Отсюда и конфликт: для ИТ оборудование давно перестало существовать, а для бухгалтерии продолжает числиться в учёте до появления необходимых документов.
Возьмём ноутбук за 60 тысяч рублей. ИТ хочет списать его после поломки материнской платы. Ремонт стоит половину цены нового устройства, сотрудник уже получил замену, старый ноутбук лежит на складе. Для ИТ вопрос закрыт: чинить устройство экономически бессмысленно.
Бухгалтерия просит акт технического состояния, решение комиссии, подтверждение списания и данные по материально ответственному лицу. ИТ воспринимает это как лишнюю бюрократию. Бухгалтер воспринимает просьбу ИТ как предложение убрать актив из учёта на основании фразы «он умер». В проверке такая фраза не работает.
У айтишника появляется понятный вопрос:
«Вы хотите три документа на ноутбук, который дешевле кресла в переговорке?»
У бухгалтера встречный вопрос:
«Вы хотите, чтобы я подписал исчезновение имущества, которое компания купила за деньги и поставила в учёт?»
При этом проблема редко возникает из-за чьей-то ошибки. Достаточно, чтобы техника была выдана без серийного номера, передана между сотрудниками без фиксации или зависла между складом и бухгалтерией. После нескольких таких событий технический и финансовый учёт начинают расходиться.
Спор идёт вокруг одного актива, который в двух системах выглядит как два разных актива. У ИТ есть hostname, MAC-адрес, серийный номер, пользователь, статус в мониторинге и последняя активность. У бухгалтерии есть инвентарный номер, дата принятия к учёту, стоимость, срок полезного использования, подразделение и документы. Пока между этими данными нет прямой связи, любое расхождение выглядит как ошибка соседнего отдела.
Где расхождение превращается в деньги
Цифры ниже условные, но ситуации рабочие. В каждой компании сумма будет своей: зависит от парка, филиалов, правил списания, договоров поддержки, склада и дисциплины инвентаризации. Логика повторяется: разный статус одного актива быстро превращается в деньги, спорные отчёты и вопросы аудитора.
Недавно мы провели исследование российского рынка управления ИТ-активами, о нем написали в Forbes.
В нём участвовали более 100 компаний из разных отраслей, а среди самых частых проблем респонденты называли потери оборудования, избыточные закупки, сложности с обслуживанием активов и длительные согласования при выдаче техники. Всё это выглядит как разные симптомы, но на практике часто растёт из одной причины: у разных подразделений нет единой картины по активам и их статусам. Ниже — несколько типовых сценариев, в которых такое расхождение превращается в вполне осязаемые деньги.
Сценарий 1. Активы, которые никто не нашёл
На балансе числится 140 активов, которые физически никто не может найти. В ИТ-системах они не отвечают, в филиалах их не видели, на складе их нет.
Если средняя остаточная стоимость таких активов 30 тысяч рублей, в отчетности висит 4,2 млн рублей имущества с сомнительным статусом.
В такой ситуации нужна инвентаризация, после которой у каждого актива появляется понятное состояние: найден, отсутствует, передан, готов к списанию или требует уточнения. Пока этого нет, каждая сторона продолжает защищать свою выгрузку.
Сценарий 2. Технически списали, бухгалтерски оставили
ИТ давно вывел оборудование из эксплуатации, но бухгалтерия об этом не знает. Сломался старый сервер, из него вынули диски, блок питания пригодился в соседней стойке, корпус увезли на утилизацию вместе с другим списанным железом. Через полгода бухгалтерия спрашивает, где сервер с таким-то инвентарным номером.
Если он проходил как амортизируемое имущество, амортизация могла идти по графику. Бюджет на обновление инфраструктуры строился на данных, где часть парка выглядела действующей. План закупок тоже опирался на эту картину.
В результате управленческие решения начинают опираться на недостоверную картину. По отчётам оборудование ещё существует, а фактически часть инфраструктуры уже работает на временных или резервных решениях.
В такой ситуации нужен маршрут списания: диагностика, решение о выводе из эксплуатации, подтверждение ответственного, документы для бухгалтерии, закрытие актива в учетной системе. Если процесс останавливается на техническом выводе из эксплуатации, актив продолжает числиться в отчетности.
Сценарий 3. Двойные закупки
На складе лежат 17 ноутбуков. Их купили под проект, который перенесли. Потом часть сотрудников ушла, часть техники не выдали, коробки переехали в другую комнату. Бухгалтерия видит приход, склад ведёт свой файл, сервис-деск не видит свободный резерв и заводит новую заявку на закупку.
Если средняя цена ноутбука 85 тысяч рублей, компания легко покупает ещё почти на полтора миллиона рублей техники при живом запасе. Через месяц финансовый директор смотрит на расходы и спрашивает, почему парк рабочих станций растёт быстрее штата.
Причина обычно проста: информация о доступном резерве хранится в разных системах и не видна всем участникам процесса.
Здесь нужен единый учёт резервного оборудования: что лежит на складе, что закреплено под проект, что доступно для выдачи, а что требует проверки. Когда склад, ИТ и закупки ведут разные списки, компания покупает технику быстрее, чем понимает собственные остатки.
Сценарий 4. Поддержка оборудования вне эксплуатации
У оборудования закончилась гарантия. Бухгалтерия видит актив в учёте и продлевает сервисный контракт по списку. ИТ в это время уже исключил часть устройств из эксплуатации и чинит оставшиеся по своему бюджету через другой договор.
Компания платит дважды: за поддержку активов, которые уже не участвуют в работе, и за фактический ремонт тех, которые действительно нужны. Например, сервисный контракт на 120 единиц оборудования по 9 тысяч рублей в год даёт 1,08 млн рублей. Если 20% активов давно выведены из эксплуатации, 216 тысяч рублей уходят на поддержку лишних позиций.
Причина снова в расхождении данных: список оборудования в договоре не совпадает с фактическим составом работающего парка.
Здесь нужна единая логика управления сервисными контрактами: какие активы покрывает поддержка, какие выведены из эксплуатации, какие требуют продления, а какие пора исключить из перечня. Когда эти данные расходятся с фактическим состоянием парка, поддержка превращается в статью расходов с ручной проверкой перед каждым продлением.
Сценарий 5. Лицензии на тех, кто давно не работает
С железом можно устроить обход: пойти на склад, открыть шкаф, посмотреть стойку, найти коробку под столом у руководителя филиала. С лицензиями такой способ не работает.
В договоре куплено 500 лицензий на инженерное ПО. В каталоге пользователей активны 470 учётных записей. В отчёте по установкам видно 620 инсталляций. Финансы каждый год оплачивают продление, ИТ ставило ПО по заявкам, закупки покупали лицензии по согласованной потребности. Потом приходит аудит вендора и спрашивает, почему использование выше купленного объема.
Часть лицензий висит на старых рабочих станциях, часть закрепили под проект, который давно закрыли, часть пользователей открывала программу один раз в квартал, но лицензия всё равно занята, часть установок осталась после переезда отдела. Если одна лицензия стоит 40 тысяч рублей в год, лишние 80 назначений дают 3,2 млн рублей риска или переплаты. Для серверного ПО, СУБД, виртуализации и инженерных пакетов арифметика быстро становится неприятной.
Здесь помогает SAM (Software Asset Management) — модуль ITAM для управления программными активами и лицензиями. Он позволяет понять, кто использует ПО, где оно установлено, какие лицензии не используются и где есть риск переплаты или нарушения лицензионных условий. ИТ видит установки, финансы видят договор, вендор видит метрику лицензирования. Без связанного процесса все снова спорят по разным таблицам.
Сценарий 6. Проверка снаружи
Расхождение между техническим и бухгалтерским учётом — как у компании из начала статьи, где разошлась почти треть парка, — выглядит как внутренняя проблема ровно до тех пор, пока его не увидит внешний проверяющий. После этого появляются вопросы к контролю активов: кто отвечает за наличие оборудования, кто подтверждает перемещение, кто согласует списание. Почему один серийный номер встречается в двух строках? Почему актив в филиале, хотя ответственное лицо уволилось год назад? Почему устройство без EDR до сих пор считается рабочим?
В этот момент выясняется, что проблема давно вышла за пределы одного подразделения и затрагивает ИТ, бухгалтерию, закупки, ИБ и руководство компании.
Цена расхождения измеряется риском для отчётности, замороженными закупками, лишними договорами, спорными списаниями и потерянным доверием между подразделениями.
Шесть сценариев, одна компания:
4,2 млн висит в отчётности мёртвым грузом
Около 1,5 млн ушло на технику при живом резерве
216 тысяч в год — на поддержку выведенного железа
До 3,2 млн — риск по лицензиям.
Где-то это переплата, где-то замороженные деньги, где-то риск штрафа — но сумма в любом случае больше годового бюджета на ITAM-систему. И это без учёта времени руководителей на разборы и ручные сверки.
Почему это не решается совещанием
Каждый квартал компании пытаются сверить ИТ и бухгалтерский учёт. Данные собирают из 1С, мониторинга, CMDB, сервис-деска и других источников, после чего начинается ручной поиск расхождений. Одни активы отличаются по названиям, другие — по владельцам или статусам, третьи вообще не удаётся однозначно сопоставить.
Часть проблем удаётся исправить, часть откладывается до следующей сверки. Команды договариваются о новых правилах работы, но через несколько месяцев сталкиваются с теми же расхождениями.
Люди могут работать добросовестно и всё равно получать расхождения. Их инструменты проектировались под разные задачи.
ИТ-система отвечает на вопрос «что работает, где находится и кто использует». Бухгалтерская система отвечает на вопрос «что принято к учету, на каких основаниях и как отражается в документах». Между этими вопросами должна быть связь. Во многих компаниях эту связь годами пытаются заменить периодическими сверками. Но они фиксируют расхождения уже после того, как процесс разошелся.
Где все ломается при внедрении ITAM
Снаружи задача выглядит простой: завести ITAM, связать его с 1С, подтянуть данные из Service Desk, добавить мониторинг, склад и HR. В жизни первый импорт данных обычно приносит боль. После первой загрузки данных быстро выясняется, что разные системы содержат разные фрагменты информации об одном и том же активе. Где-то есть финансовые данные, где-то технические атрибуты, где-то сведения о пользователях и перемещениях. В результате появляются дубли, расхождения и активы без владельцев.
После первой загрузки данных у компании появляется список неприятных вопросов:
Почему один серийный номер встречается дважды?
Почему ноутбук числится на сотруднике, который уволился год назад?
Почему сервер есть в бухгалтерском учёте, но не отвечает в мониторинге?
Почему в договоре поддержки 120 устройств, а ИТ подтверждает только 96?
На этом месте многие ITAM-проекты начинают буксовать. Система уже есть, данные загружены, статусы настроены. Но команда не договорилась, кто имеет право менять стоимость, кто отвечает за серийный номер, кто подтверждает физическое наличие, кто запускает списание и кто закрывает актив после утилизации.
Разные подразделения отвечают за разные части данных:
Бухгалтерия — за стоимость и документы;
ИТ — за техническое состояние;
Склад — за физическое наличие;
Закупки — за договоры;
HR — за сотрудников и структуру компании.
Пока эти зоны ответственности не согласованы, ITAM легко превращается ещё в один источник расхождений.
Что меняет ITAM
ITAM работает, когда одна карточка актива нужна всем: ИТ видит в ней техническое состояние, бухгалтерия — стоимость и документы, склад — где лежит, закупки — какой договор, безопасники — есть ли агент. Не пять разных записей в пяти системах, а одна — с серийником, владельцем, историей и всем остальным.
Но карточка сама по себе мало что даёт. Она начинает работать, когда за ней стоит понятный маршрут: закупили → привезли на склад → выдали → сотрудник работает → сломалось → отправили в ремонт → починили или списали. И на каждом шаге понятно, кто отвечает и что произошло.
Интеграции помогают не вбивать всё руками. 1С отдаёт стоимость и инвентарный номер, сервис-деск — кому выдали и по какой заявке, MDM — включается ли устройство вообще, HR — что сотрудник уволился. Но сами по себе интеграции не наведут порядок. Главная польза ITAM — показать исключения: вот дубль, вот ноутбук на уволенном, вот сервер без активности три месяца, вот лицензия без пользователя.
Со списанием то же самое. ИТ говорит «устройство мертво», но для бухгалтерии это ещё не списание — нужен акт, комиссия, документы. Пока всё не закрыто, в системе честно висит статус: «технически выведено, бухгалтерски числится». Неприятно, зато видно, кто должен сделать следующий шаг.
В компаниях с филиалами это бьёт особенно больно. На местах технику двигают быстрее, чем обновляют центральные системы. Локальная команда знает, где что лежит, а центральный офис смотрит в устаревшую выгрузку. ITAM не решает это магией — но делает расхождения видимыми и назначает ответственных. Для руководителя инфраструктуры это полезнее, чем ещё одна ручная сверка в Excel перед аудитом.
Это не значит, что ITAM решает проблему автоматически. Он делает расхождения видимыми. Решать их всё равно придётся людям — но хотя бы с понятным списком, а не с двумя выгрузками в Excel.
С чего начинать, если цифры уже разошлись
Самая частая ошибка — попытка сразу описать весь парк. В enterprise-инфраструктуре такой подход быстро превращается в большой проект без понятного первого результата. Лучше начать с класса активов, где ошибка имеет понятную цену: ноутбуки, серверы, сетевое оборудование, дорогое инженерное ПО или устройства с повышенными требованиями ИБ.
Сначала нужно определить основные источники данных и принять тот факт, что между ними будут расхождения. Финансовые системы отвечают за стоимость и документы, ИТ-инструменты — за эксплуатацию активов, HR — за сотрудников и структуру компании, закупки — за договоры и поставщиков.
Следующий шаг — договориться о правилах сопоставления данных. На практике серийные номера, hostname, пользователи и инвентарные номера часто заполнены не полностью или хранятся в разных форматах, поэтому часть активов почти всегда требует ручной проверки.
После этого можно смотреть на исключения. Руководителю ИТ нужны не тысячи карточек, а список исключений: активы без владельцев, устройства на уволенных сотрудниках, активы без активности, проблемы с лицензиями и договорами поддержки.
Когда такие метрики появляются, разговор с финансами меняется. ИТ приходит не с абстрактной просьбой «дайте бюджет на систему учёта», а с цифрами: сколько денег зависло в запасах, сколько платится за лишнюю поддержку, сколько лицензий можно вернуть, сколько активов висит на уволенных сотрудниках, сколько времени уходит на ручную сверку перед аудитом.
Резюме
Конфликт ИТ и бухгалтерии редко начинается с плохих людей. Обычно все работают по своей логике. ИТ считает то, что работает, ломается, чинится, ездит в филиалы, висит в мониторинге и мешает закрывать заявки. Бухгалтерия считает то, что принято к учёту, закреплено за ответственным, амортизируется, перемещается по документам и может всплыть на проверке. Закупки считают договоры и поставки. Склад считает коробки. ИБ считает риски. Бизнес хочет одну цифру.
Однажды эта цифра понадобится срочно: перед аудитом, налоговой проверкой, крупной закупкой, переездом офиса, объединением филиалов или сокращением бюджета. В этот момент выясняется, что мониторинг и CMDB показывают 980 активов, 1С показывает 1420, договор поддержки покрывает железо, которое давно не работает, а часть лицензий закреплена за людьми, которые уже ушли из компании.
Дальше можно спорить. В этот момент обычно выясняется, что проблема давно вышла за рамки одного подразделения. Расхождения влияют на закупки, поддержку, лицензирование, аудит и бюджетирование, а значит становятся общей проблемой бизнеса.
Если расхождение уже дошло до 10–15%, очередная сверка поможет найти часть ошибок, но не устранит причины их появления. Для этого нужен процесс, который связывает технический и финансовый учёт на протяжении всего жизненного цикла актива.
На сколько процентов ваши ИТ-данные расходятся с бухгалтерией прямо сейчас? И кто первым узнает точный ответ — вы, бухгалтерия или аудитор?