Десять лет внедрений без результата. Почему ERP не для всех

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

Без малого тридцать лет я работаю с корпоративными данными и такую ситуацию наблюдал во многих компаниях. Компания внедряет ERP. На уровне руководителей всё согласовано, совещания проведены, схемы утверждены, бюджет подписан, по этажам ходят внедренцы. Сотрудник финансового отдела, годами ведущий расчёты в Excel, получает готовую систему и указание работать в ней с понедельника. Как он привык вводить данные, в каком порядке и с какими проверками, у него не спрашивали. Через месяц он ведёт две системы. В новой отчитывается перед руководством, а для себя оставил прежний Excel, в котором цифры у него сходятся.

Сопротивление пользователей принято объяснять консерватизмом. По моим наблюдениям, причина глубже. Глобальная система приносит с собой процессную модель управления, и внедрение ERP оказывается трансформацией модели управления, упакованной в ИТ-проект. Договаривались о ней на уровне руководителей, а перестраивать работу предстоит исполнителям. С ними эту перестройку обычно не обсуждают, отсюда и сопротивление.

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

Ни одна из осей не хороша и не плоха сама по себе. Вопрос в том, какая из них в конкретной компании несущая и соответствует ли ей ИТ-ландшафт.

В архитектуре зданий сто лет работает правило «форма следует за функцией». У архитектуры ИТ-ландшафта есть свой аналог этого правила. Ландшафт следует за моделью управления. Ниже покажу, как это выглядит для обоих типов компаний.

ERP приживается там, где информационный поток повторяет физический поток товаров и материалов. Так устроены завод, ритейл, дистрибуция. Цепочку от закупки через склад и цех до отгрузки видно глазами, она жёстко регламентирована, и регламент существовал задолго до всякой автоматизации. Это не случайность. ERP выросла из систем планирования потребностей производства (MRP), производственная логика заложена у неё в основании.

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

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

Отдельная оговорка нужна про банки и брокерские компании, где процессность жёсткая, но отраслевая специфика очень глубока. Процессную ось там закрывает специализированный софт, выросший из отраслевой практики, вроде АБС, процессинга и трейдинговых платформ. Универсальная ERP в таких компаниях живёт на периферии, в кадрах, закупках и хозяйственном учёте. Это лишний раз показывает, что разговор в статье идёт про ось управления, а универсальная ERP лишь один из инструментов процессной оси.

Другая картина в многопрофильных холдингах и компаниях, где локальный менеджмент имеет большой вес и собственный способ ведения дел. Каждый домен здесь владеет своим информационным продуктом, куда входят данные, справочники, правила учёта, формы отчётности, порядок работы. Точность этого продукта способен обеспечить только сам домен, потому что специфика каждого домена видна лишь изнутри.

Пример из продаж. У сильного продавца есть ключевой заказчик, который делает заявки по телефону и без предоплаты. Кредит доверия наработан годами, заказчик ожидает, что заявка сразу уйдёт в производство. Процесс же в ERP сконструирован жёстко, и без предоплаты заявка на производство не уходит. Формально процесс прав, но по существу компания ставит регламент выше заказчика, который приносит ей заметную долю выручки. Гибкость здесь даёт специализированный CRM-инструмент, где условия настраиваются по каждому заказчику, а в процессный контур передаётся уже согласованное решение.

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

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

Всё это внутренняя сторона доменного продукта, то есть системы и порядок работы, которыми домен пользуется сам. Есть и внешняя сторона. Это данные, которые домен отдаёт другим подразделениям и руководству. В современной архитектуре данных её называют продуктом данных, и слово «продукт» здесь точное. У продукта данных есть владелец, описание, потребители и гарантии качества, как у любого изделия, которое компания выпускает на рынок. Термин пришёл из концепции Data Mesh, и функционально-доменная модель управления для неё естественная среда. Домены и так владеют своими данными, концепция лишь требует оформить это владение. Единственная поправка для среднего бизнеса касается слоя общих правил, о ней ниже.

Есть книга «Data Mesh в действии», там достаточно точно называют такой подход социотехническим. Шину, хранилище и каталог данных можно поставить за квартал, а готовность людей за квартал не строится. Проверяется он в двух местах. Во-первых, домен должен согласиться владеть. Руководитель финансов принимает качество данных как собственную ответственность, хотя раньше считал его заботой айтишников. Во-вторых, и это сложнее, владеть означает ещё и отдавать. Контракт на данные обязывает домен поставлять их соседям вовремя и в оговорённом качестве, по сути это внутренний SLA между подразделениями. Владеть своим хозяйством в доменной компании готовы все, а вот брать обязательства перед соседями соглашаются не сразу.

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

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

Дорого обходятся два сценария, и в обоих ландшафт перестаёт следовать за моделью управления.

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

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

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

Доменная архитектура работает при одном условии. Между доменами должен быть выстроен обмен, и у этой кровеносной системы три части.

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

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

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

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

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

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

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

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

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

Проверить соответствие можно шестью вопросами.

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

#erp #1с #цифровизация #автоматизация #управление #datamesh