Сколько ITAM-система стоит на самом деле

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

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

Три цифры, по которым выбирают систему

В коммерческом предложении стоят три суммы:

1. Лицензия — плата за право пользоваться системой. Считается по числу пользователей или по числу учитываемых активов.

2. Внедрение — стоимость проекта запуска: исследование процессов, настройка системы, перенос данных из прежних реестров, интеграции, обучение администраторов и работа проектной команды.

3. Техническая поддержка на первый год — фиксированный платеж за обращения к поставщику с оговоренным в договоре временем реакции.

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

Дальше первого года расчёт не идёт. Но ведь ITAM-система живёт в компании годами, переживает несколько бюджетных циклов, реорганизаций и смен руководства ИТ. Оценивать её по первому году — значит смотреть на самый нетипичный период её жизни: в это время система настраивается под уже собранные требования и почти не меняется.

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

Первый год уходит на запуск

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

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

• этот процесс сейчас не нужен, вернёмся к нему через год;

• интеграцию с кадровой системой отложим до следующего этапа;

• отчётность для финансового блока соберём, когда накопятся данные за несколько кварталов;

• мобильные устройства и лицензии на программное обеспечение возьмём на учёт вторым заходом.

Такое решение помогает запуститься в срок и уложиться в согласованную смету.

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

Процессы не стоят на месте, и это стоит денег

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

Сами процессы при этом не стоят на месте. Вот поводы переделать уже настроенное, которые встречаются чаще других:

• компания открывает офис или производственную площадку, и появляется новое место хранения со своим ответственным и своим маршрутом согласования;

• меняется структура подразделений, а вместе с ней владельцы активов и согласующие;

• на учёт берут новый класс активов: лицензии, мобильные устройства, сетевое оборудование, технику в аренде;

• меняется схема закупки или сама учётная система, и интеграцию приходится переписывать;

• внутренний аудит просит отчёт в разрезе, которого в системе нет;

• процесс, собранный в первый год, оказывается неудобен исполнителям: его настраивали по регламенту, а на практике шаги идут в другом порядке.

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

Кто вносит изменения — заказчик или поставщик — и почему это главный вопрос

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

Второй вариант на практике выглядит так. Добавление поля в форму, нового статуса в жизненный цикл актива или ещё одного шага согласования превращается в процедуру:

1. Оценка трудозатрат

2. Согласование сметы внутри компании

3. Допсоглашение или списание часов из пакета поддержки

4. Работа поставщика

5. Приёмка на тестовом контуре

6. Перенос в промышленную среду

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

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

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

Кейс: розничная сеть, которая настраивает систему сама

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

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

Если бы у этой сети была платная модель доработок, шаг «поняли, что собрали не то» превратился бы в новую закупку с новым согласованием сметы — а на такую закупку чаще всего не идут: объяснить финансовому блоку, почему за один и тот же процесс платят дважды, сложно. Компания в этом случае осталась бы жить с тем, что получилось с первого раза. 

Счёт за обновление версии

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

От подписания договора до первого крупного обновления проходит несколько лет, поэтому в сравнительную таблицу эта статья расходов не попадает. 

Что спросить у вендора до покупки

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

1. Какие требования войдут в первый год, а какие отложены? 

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

2. Сколько будет стоить реализовать отложенное через год? 

Ответ «оценим позже» здесь равнозначен отсутствию оценки.

3. Какие объекты системы команда заказчика меняет без поставщика?

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

4. Сколько времени занимает типовая доработка силами поставщика? 

Срок считается от обращения до промышленной эксплуатации; готовность на тестовом контуре отдельного значения не имеет.

5. Что происходит с накопленными доработками при переходе на новую версию и кто оплачивает их перенос?

6. Сколько собственных инженеров нужно, чтобы развивать систему самостоятельно, и какое обучение они проходят? 

Здесь же уточните, есть ли документация по настройке и учебная среда.

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

Резюме

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

А как менялась цена вашей ITAM-системы после первого года — совпало с ожиданиями или нет? Расскажите в комментариях.