От качественных данных и процессов — к контролю, экономическому эффекту и цифровому суверенитету
Максим Кантарович
Партнер Фонда «Кристалл роста» по цифровизации
Бизнес-архитектор проектов по автоматизации и цифровизации, методолог по ИТ и финансам, эксперт по построению информационных систем управления для холдинговых структур
В первой части «Десяти Заповедей цифровизации» речь шла о фундаменте цифрового проекта: единой терминологии, участии руководства, оценке ИТ-зрелости компании, приоритете функциональности перед выбором программного продукта и различии между интеграцией и синхронизацией.
Но правильно выбрать систему и построить архитектуру недостаточно. Цифровизация начинает приносить реальный результат только тогда, когда компания умеет управлять данными, приводит в порядок процессы, контролирует экономические показатели, заранее считает эффект от проекта и обеспечивает устойчивость критической ИТ-инфраструктуры.
Ниже — вторые пять Заповедей.
Заповедь 6: управлять НСИ как активом
Нормализация нормативно-справочной информации — без нее проект цифровизации не начинать. Ведь для чего вообще нужна система? Для качественной, доверяемой, проверяемой отчетности. Данные вводятся для последующей обработки, получения показателей, дашбордов и план-фактного анализа. Если в справочниках есть дублирование, много старых записей, нет синхронизации справочников между собой, то результат получения отчетности может содержать много ошибок.
Финансовые, операционные и технические справочники нельзя рассматривать отдельно друг от друга. Справочник проектов должен быть связан с договорами, договор — со статьями БДР и БДДС, подразделение — с ЦФО, а бухгалтерские аналитики в целом — с управленческими. Эти связи надо сначала продумать методологически, а уже потом настраивать технически.
При переходе на новую систему важно смотреть, какие элементы действительно использовались в последние годы и по каким есть остатки. Все старое переносить не надо. Если в базе 10 млн записей, а реально работают 500 тыс., остальные 9,5 млн не становятся ценностью только потому, что накоплены исторически. Чаще это мусор, который мешает поиску, миграции и контролю.
Но чистка дублей — только начало. Нужна иерархия, реквизитный состав и правила управления: кто создает новый элемент, кто его согласует, кто меняет и кто архивирует. Без этого через год новый справочник станет таким же «грязным», каким был старый.
Справочники — не техническая мелочь. Это скелет управленческой модели, по сути актив компании. И если он кривой, то и самый красивый дашборд просто покажет такие же кривые данные.
Заповедь 7: не автоматизировать процессный бардак
Эта фраза хорошо известна и заслуживает отдельной заповеди: «Результатом автоматизации бардака всегда становится автоматизированный бардак».
Технология хорошо закрепляет то, что ей дали на входе. Если роли не определены, регламенты противоречат друг другу, а решения принимаются «по ситуации», система не наведет порядок сама. Она просто сделает хаос формальным и добавит к нему новые поля, статусы и кнопки.
Поэтому методология — основа проекта внедрения любой информационной системы. Учетные политики, положение о бюджетировании, казначейский и договорной регламенты, положение о документообороте, правила закупок, принципы управления проектами, требования к справочникам и к интеграции должны хотя бы в рабочем виде существовать до начала разработки.
Причем регламент — это не сотня страниц для налоговой или папки на общем диске. Регламент должен отвечать на понятные вопросы: кто создает документ, кто проверяет экономический смысл, кто согласует исключение, какой показатель контролируется, когда процесс считается завершенным. Сначала все это нужно прописать внутри компании и только потом передавать эксперту по внедрению, чтобы методология превратилась в работающий процесс внутри системы.
В таких проектах основная работа — изменение/оптимизация процессов и людей, а технология идет следом.
Заповедь 8: требуется управление — научись считать
Формулировка восьмой заповеди: «Если что-либо сосчитать, больше этого не станет. Но если не считать, то может стать сильно меньше».
Контроль нужен не только ради отчетности. У любой компании есть ошибки, потери и, конечно же, злоупотребления. Поэтому надо проверять, кому и по какой цене продают, у кого и по какой цене закупают, как меняется рентабельность проекта, где возникло отклонение от бюджета.
Особенно опасно, когда первоначальный расчет существует только в голове собственника. Из практики: подрядчик принимал решение об участии в проекте так — читал конкурсную документацию, оценивал себестоимость в уме и говорил: «Идем». Потом фактическая себестоимость могла оказаться совсем другой, но сравнить ее было не с чем. И на реплику «В целом компания же работает» нужно отвечать: это не план-фактный анализ, который показывает управление бизнесом.
До запуска проекта должна быть исходная оценка, смета или финансовая модель. В процессе — лимиты и контроль отклонений, после — разбор причин. И нужен человек, который умеет считать и задавать неудобные вопросы. Иногда сильный сметчик или специалист внутреннего контроля полезнее еще одного красивого отчета.
Смысл цифровизации здесь очень практичный: перенести контроль из конца периода — пост-контроль — в момент принятия решения — пред-контроль. Узнать о перерасходе не после закрытия проекта, а тогда, когда на него еще можно повлиять.Заповедь 9: требуется результат — готовь бюджет
Девятая заповедь продолжает восьмую: «Сосчитать что-то почти всегда дороже, чем не считать вовсе». Проверяемые данные и качественная отчетность требуют затрат на методологию, внедрение и поддержку. Вопрос не в том, платить или нет, вопрос — за что и кому.
Подрядчика часто выбирают по красивым логотипам на сайте: вот десять известных клиентов, вот крупные проекты. Но проекты делали конкретные люди, и эти специалисты могли давно уйти, открыть отдельную компанию или перейти к конкуренту, а логотипы остались.
Поэтому совет прямой: смотреть резюме тех, кто реально придет в проект, — архитектора, руководителя проекта, аналитиков и разработчиков. Важно выяснить, что именно каждый делал, на какой платформе, с какой функциональностью и каким результатом. Опыт внедрения одной системы нельзя автоматически перенести на другую только потому, что отрасль та же.
И заранее считайте эффект. Он не всегда означает сокращение людей. После одного внедрения собственник спросил: сколько из 40 юристов теперь можно уволить? Ответ: нисколько. Проверка в отделе показала другое изменение: раньше люди уходили с работы ближе к ночи, теперь — в шесть вечера. Сотрудники вспомнили о семьях — это важнейший результат, а также меньше перегрузки, меньше ошибок, выше качество работы.
Эффект может быть и финансовым: быстрее закрывается период, сокращаются ручные сверки, уменьшаются непредвиденные расходы и стоимость владения старыми системами. Но его надо зафиксировать до проекта и измерять после запуска, иначе через два года никто не вспомнит, зачем все начиналось.
Причем именно «непредвиденные расходы» — самые затратные из непланируемых: они съедают прибыль из-за «тушения пожаров», а «пожары» постоянно появляются из-за слабого неавтоматизированного планирования и контроля. По экспертной оценке автора, основанной на мировой практике, таких расходов может быть до 10% оборота компании. Поэтому всегда можно сказать, что при годовом обороте в 10 млрд рублей после внедрения систем потенциально возможно сэкономить 0,5–1 млрд рублей в год.
Заповедь 10: импортозамещение как цифровой суверенитет
Если в критичном ИТ-контуре стоит система, которую нельзя нормально поддерживать и развивать, рано или поздно придется принимать решение о ее замене. Но эту заповедь не стоит сводить к простой замене «западного» названия на «российское».
Сначала все равно действует четвертая заповедь: какая функциональность нужна? Потом — пятая и шестая: как решение войдет в архитектуру и что будет с данными? Затем — девятая: есть ли команда, которая умеет это внедрять и поддерживать?
Нужно заранее решить, что переносим, что очищаем, какие интеграции переделываем, как обучаем пользователей и как работаем в переходный период. Иначе компания поменяет одну зависимость на другую, а старые проблемы просто переедут в новую систему.
Импортозамещение — частный случай более общего принципа технологической устойчивости, цифрового суверенитета. Компания должна понимать, от каких поставщиков, платформ и отдельных специалистов зависит критическая работа, и иметь понятный план действий, если эта зависимость становится опасной.
Заключение: цепочка Заповедей
Если собрать все десять Заповедей в одну цепочку, получится простой маршрут. Сначала — общий язык, поддержка руководителя, понимание зрелости и нужная функциональность. Потом — архитектура, справочники, методология, контроль, сильная команда и заранее посчитанный эффект. И только после этого — технология, в том числе цифровой суверенитет.
Новые программы, BI, роботы и искусственный интеллект — полезные инструменты, но они не могут решить за компанию, как ей работать. Поэтому главный вопрос цифровизации — не «какую систему купить?», а «что именно должно измениться и как компания поймет, что это действительно изменилось?».
Именно поэтому цифровизация — не отдельный ИТ-проект, а последовательное управленческое изменение. Технология здесь важна, но становится эффективной только тогда, когда компания заранее договорилась о правилах, процессах, данных, ответственности и критериях результата.
