О чем надо договориться внутри компании, прежде чем выбирать систему и привлекать экспертов по внедрению
Максим Кантарович
Партнер Фонда «Кристалл роста» по цифровизации
Бизнес-архитектор проектов по автоматизации и цифровизации, методолог по ИТ и финансам, эксперт по построению информационных систем управления для холдинговых структур
Слово «цифровизация» сегодня используют так часто, что под ним можно понимать почти все: новую программу, дашборд, электронный документ или искусственный интеллект. Смотреть на это нужно точнее. Цифровизация начинается там, где компания понимает процессы, данные и ответственность, а заканчивается проверяемым результатом.
Но прежде чем выбирать конкретную систему, платформу или подрядчика, компании необходимо договориться о базовых принципах будущего проекта. В первой части — пять Заповедей, которые формируют этот фундамент: общий язык, участие руководства, понимание собственной зрелости, приоритет функциональности и правильное отношение к архитектуре систем.
Введение: что именно цифровизируется
Для начала стоит уточнить четыре уровня и то, чем они отличаются. Заранее понимаем, что точных трактовок нет и каждый эксперт любит трактовать по-своему. Последовательность следующая: информатизация автоматизация цифровизация цифровая трансформация. Произносить эти термины просто для красоты не стоит — за каждым должно стоять конкретное текущее состояние группы компаний. В дальнейшем будем использовать слово «компания», подразумевая «холдинг».
Информатизация — это когда компания в основном живет в таблицах Excel, мессенджерах и отдельных программах. По экспертной оценке автора, таких большинство — не менее 90% из 3,5 млн компаний в стране. Один из генеральных подрядчиков на вопрос об управлении проектами ответил: у нас весь контроль и согласования в мессенджере. Причем с гордостью добавил, что там уже появились отдельные темы: для прорабов, материалов и бухгалтерии. Но когда этот мессенджер на пару часов отключился, встала и работа. Это не цифровизация, а просто удобный канал связи, от которого компания стала зависеть.
И размер бизнеса здесь ничего не гарантирует. В практике встречалась компания с оборотом в сотни миллиардов рублей, где вокруг нескольких учетных систем работало около семисот Excel-таблиц. Без них сами системы не давали цельной картины. Формально программ много, а по сути все держится на ручной работе.
Автоматизация начинается, когда основная работа уже перенесена в системы, Excel остается вспомогательным инструментом — не более 25% учета и контроля ведется в таблицах, а остальные участки — в ERP, системах документооборота, CRM и т. д. По экспертной оценке автора, таких компаний около 10%.
Цифровизация, по экспертной оценке автора, характерна менее чем для 1% компаний и представляет собой следующий шаг после автоматизации: появляется единый центр данных (data lake), единые справочники, связанная интегрированная архитектура и, конечно, отсутствуют Excel-таблицы.
Последний этап — цифровая трансформация. Это уже изменение самой структуры управления, ролей и процессов в связи с широким использованием ИИ и роботизации как замены сотрудников. То есть в итоге технология — не начало, а часть большого управленческого изменения.
Заповедь 1: договоренность о терминологии
Первый шаг — общая терминология. Причем существует как минимум три ее типа: ИТ, отраслевая и финансовая. Пока функциональные заказчики из бизнеса, ИТ-служба и выбранный подрядчик не договорились о значениях терминов, далеко проект не уйдет. Точнее, результаты проекта с большой долей вероятности будут плачевными.
Например, в строительстве при обсуждении задач проекта весь разговор состоит из множества трехбуквенных сокращений, в которых планируемый эксперт по внедрению должен глубоко разбираться: ПИР, СМР, ГПР, ГРП, ПСД, ИРД, ПНР, БИМ, ЛОД, КСП, КСГ, ДДУ, СУП и «иных». А на молочном заводе говорят о белко- и жиробалансе. У финансистов отдельный словарь, и даже внутри профессии операционный учет не всегда одинаково отличают от управленческого. А потом приходит специалист по внедрению и вкладывает в тот же термин еще третий смысл.
Еще простой пример — термин «документооборот». Слово, как оказывается, неудачное: каждый понимает его по-разному. На практике есть как минимум шесть отдельных контуров ДО: делопроизводство — письма, приказы, служебные записки; финансовые документы — бюджеты, закупки, договоры, акты, платежи; производственная документация — сертификаты качества сырья и продукции, паспорта оборудования и зданий; внешний электронный документооборот с контрагентами — почему-то в деловой практике используется термин ЭДО; кадровый электронный документооборот — КЭДО; СЭДО — социальный электронный документооборот. Это разные задачи, автоматизируются они по-разному и даже в разных программных продуктах.
Типичная ошибка — начинать с длинного технического задания, не определив значения ключевых понятий. Документ получается подробным, но внутренне противоречивым. На приемке это превращается в спор о том, что «имелось в виду». Поэтому до технического задания нужен терминологический словарь: что такое проект, договор, статья, ЦФО, МВЗ, интеграция, справочник, управленческий и иные учеты. Это выглядит скучно, но в дальнейшем намного дешевле, чем через полгода выяснить, что заказчик, аналитик и разработчик все это время говорили о трех разных вещах.
Заповедь 2: участие руководства компании в ИТ-проекте
Вторая заповедь всем знакома: нужна поддержка руководства. Но поддержка — это не выступление генерального директора или акционера только на старте проекта и не подпись под ИТ-бюджетом.
Часто руководитель, особенно выросший из производства, говорит: «Автоматизацией пусть занимаются айтишники». Не получится — цифровой проект меняет не только программу, он меняет порядок согласования, зоны ответственности, прозрачность затрат и привычные способы работы. ИТ-специалист не может своими решениями перераспределить полномочия между директорами по производству, финансам и закупкам — нужен руководитель достаточного уровня полномочий, который снимет возможные конфликты. Бизнес в итоге отвечает за правила и результат, а ИТ — за технологическое исполнение и надежность.
Должен быть выпущен общекорпоративный приказ с понятными целями, владельцами решений, а также определен руководитель достаточного уровня полномочий, который сможет снять спор между подразделениями. Иначе на местах появятся нежелание, затягивание и саботаж: кто-то продолжит вести отдельные Excel-таблицы, кто-то будет согласовывать «по старинке», а потом все скажут, что система не работает.
Поэтому необходима готовность не только купить систему, но и потребовать, чтобы компания действительно стала работать по новым правилам. Без такой готовности проект цифровизации лучше не начинать, иначе он в итоге превратится в дорогую «игрушку».
Заповедь 3: анализ уровня своей компании
Третья заповедь — понимание уровня компании, в которой работаешь. Здесь важны две вещи: масштаб бизнеса и ИТ-зрелость. Количество купленных программ само по себе ни о чем не говорит.Компании условно делятся на три типа.
Первый — «Знатоки»: годами внедряли отдельные решения по запросам подразделений. На каком-либо отдельном участке все может быть хорошо, но единого интегрированного контура, единого центра обработки данных нет. Таким компаниям нужна архитектурная стратегия: что оставить, что объединить, где будет единое окно ввода данных и как убрать дублирование функций.
Второй тип — «Быстрый рост»: вчера оборот был условно 3 млрд рублей, сегодня пришло несколько крупных проектов — и вот уже 30 млрд рублей. Ни руководство, ни команда просто не успевают перестроиться под новые объемы. Здесь сначала нужна новая организационная структура, а может, еще и юридическая структура, более прозрачное распределение ответственности и отстроенные процессы. Если сразу поставить большую корпоративную систему поверх прежней организации, она не спасет — см. Заповедь 7.
Третий тип можно назвать «ИТ-стартаперы»: компания может существовать десятки лет и быть крупной, но управленчески все еще жить глубоко в Excel-таблицах. Здесь не надо сразу рисовать избыточно сложную ИТ-архитектуру, а нужен понятный типовой контур, на котором компания научится работать дисциплинированно, вероятнее всего — типовое отраслевое решение (ТОР).
Перед итоговым выбором важно учитывать также и оборот компании. При обороте до 5 млрд рублей можно сказать, что это «ИТ-малыши» — типовая 1С и Excel-таблицы. От 5 до 50 млрд рублей — средние компании: ERP, CRM, ДО, часть процессов остается в Excel. От 50 до 200 млрд рублей — крупные: элементы ИИ, единые данные. От 200 млрд до 1 трлн рублей — крупнейшие. Свыше 1 трлн рублей — уже корпорации, которые могут строить собственные ЦОДы и управлять данными.
Итого важно посмотреть, как устроено управление, кто принимает решения, какие процессы описаны, сколько систем и Excel-реестров реально используется, кто отвечает за данные. Только после этого понятно, какой масштаб проекта компания способна реализовать.
Заповедь 4: функциональность важнее ПО
Эта заповедь — одна из самых важных: пока не определена необходимая функциональность, думать о программном продукте нельзя! Типичная ошибка — приобрести узкофункциональную систему, которая хорошо закрывает один участок, но обрывает процесс на его границе. Тогда сотрудники достраивают недостающие связи вручную.
Другая крайность — объявить весь бизнес «уникальным» и отказаться от готовой функциональности, взять программистов и начать разрабатывать конфигурацию с нуля, хотя специфика чаще всего уже сосредоточена, например, в производственном контуре и, вероятно, уже есть готовое отраслевое решение.
Очень часто разговор начинается с названия продукта: ERP, электронный документооборот, BI. Но сначала нужен ответ на другой вопрос: какие функции требуется закрыть? Бюджетирование? Закупки? Согласование договоров? Казначейство? Расчет проектной рентабельности? Контроль себестоимости производства? Название класса системы ответа на вопросы функциональности не дает.
Функциональность удобно раскладывать на три больших контура: финансы, процессы и основная деятельность — бизнес. Все они связаны через единые справочники — НСИ. В финансовом контуре находятся бюджетирование, закупки, договоры, казначейство, управленческий учет, консолидация и корпоративные финансы. В процессном — разные виды документооборота, CRM, управление проектами. Основная деятельность в каждой отрасли различается, но закупать, продавать, платить, считать и согласовывать требуется всем без исключения.
Особенно важно видеть цепочку целиком. Договор — это не «документ юристов». Юристы здесь — важное сервисное подразделение: проверяют форму, риски, условия. Но сам договор связывает план и факт: слева от него — потребность, бюджет и процесс закупок, то есть подготовка к заключению договоров; справа — платеж, акты, выручка, себестоимость, то есть реальное исполнение договоров. Если автоматизировать только согласование текста, а финансовые условия потом вручную переносить в казначейство и учет, цепочка разрывается.
То же самое с финансовым управлением проектами. В практике встречались подрядчики, которые вели проекты в Excel, хотя нужная аналитика уже была в бухгалтерской системе. Например, достаточно было правильно использовать справочник «Номенклатурная группа»: появилась бы выручка, себестоимость, оборотка — и весь проект оказывался под микроскопом. То есть система уже умела нужное, но функциональный заказчик нечетко сформулировал требуемую функцию и поэтому не увидел готовое решение в типовом функционале системы.
Отсюда практическое правило: сначала делаем карту функций и сквозных процессов, потом смотрим, каким продуктом они закрываются. И обязательно задаем еще один вопрос: кто будет поддерживать решение через три-пять лет? Прекрасная система, которая держится на одном талантливом человеке, — это не только удобство, но и огромный риск — «человеческий фактор».
Заповедь 5: не путать Интеграцию с Синхронизацией
Слово «интеграция» используют все, но давайте честно: этот термин часто используют неверно — как обозначение обмена между двумя самостоятельными системами.
Разница простая. При настоящей интеграции функции работают на общей платформе, в общей конфигурации и используют общие сущности. При синхронизации же в каждой системе остаются отдельные справочники — свои контрагенты, номенклатура, договоры, — отдельные документы, а между системами настроены обмены. Это не интеграция. И хотя эти обмены можно сделать удобными и почти незаметными для пользователя, от этого они не перестают быть синхронизацией.
Почему это важно? Потому что два справочника контрагентов надо постоянно сопоставлять, два справочника номенклатуры — также. Любая ошибка обмена сразу рождает расхождение. Следовательно, поддержка таких связей всегда стоит денег, особенно когда систем много.
Показательный случай: в компании отдельно и неплохо работали бухгалтерия, бюджетирование, управленческий учет, производство и документооборот. На презентации автоматизация выглядела на четыре с плюсом. А потом сотрудница, собиравшая итоговую отчетность, рассказала о трех днях из недели, уходивших на «сверку и сводку» данных из множества не связанных между собой систем. Данные выгружались из каждой системы в Excel, затем сверялись с бухгалтерией, производством и снова с бухгалтерией. Такова цена хороших локальных решений без нормальной интегрированной/синхронизированной архитектуры.
Синхронизация не всегда запрещена, ведь иногда отдельная система действительно нужна в связи со специфической функциональностью. Но тогда надо честно назвать ее синхронизацией, определить источник данных, правила обмена, контроль ошибок и стоимость сопровождения. А все, что можно разумно держать на единой платформе, лучше не разносить без необходимости.
Заключение
Первые пять Заповедей отвечают на вопросы, которые необходимо решить еще до того, как цифровой проект перейдет в стадию полноценного внедрения. Компания должна говорить на одном языке, иметь управленческого заказчика проекта, понимать собственный уровень зрелости, сначала определить необходимые функции и только затем строить архитектуру систем.
Но даже правильно выбранная архитектура еще не гарантирует результата. Следующий уровень — качество данных, порядок в процессах, управленческий контроль, экономика проекта и устойчивость всей технологической среды.
Во второй части — еще пять Заповедей цифровизации: как управлять нормативно-справочной информацией, почему нельзя автоматизировать неупорядоченные процессы, зачем считать экономический эффект и как цифровой суверенитет связан с устойчивостью бизнеса.
