Четыре системы — четыре версии правды: почему руководитель перестаёт верить отчётности и решает по ощущениям

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

В чём собственно разрыв

На вебинаре ERP Band «Когда компании пора в ERP? Сохранить маржу» четвёртым и последним разбирали разрыв «все ↔ данные». Первые три ощущаются как конфликты подразделений — продаж и производства, закупок и плана, производства и финансов. У четвёртого нет двух сторон: стороной является вся компания сразу.

Устроен он просто. Систем исторически несколько: учётная база или ERP, CRM у продаж, складская программа, бухгалтерия, а рядом десятки файлов Excel. Каждая ведёт собственные справочники, а обмены настраивались по мере надобности. Через несколько лет получается конструкция, где у каждого показателя несколько источников и ни одного эталона: четыре системы — четыре версии правды. Один контрагент живёт в трёх базах в четырёх написаниях, и это не небрежность операторов: решение «как именно мы записываем контрагента» никем и никогда не принималось.

Как разрыв выглядит изнутри компании

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

Дальше склад: одно и то же ТМЦ приходит от трёх поставщиков под тремя наименованиями и лежит тремя позициями, система не видит суммарного остатка и продолжает рекомендовать закупку — излишки, затаренность, рост стоимости хранения. Производство от того же самого не может планировать: ресурсные спецификации ссылаются на разные записи. Формулировка Клавдии Мальцевой, партнёра ERP Band, однозначна — для производства первостепенно единое наименование. Добавьте два хронических конфликта: бухгалтерии и производства за справочник номенклатуры и зависимость от одного разработчика, который единственный знает устройство обменов.

Симптомы, причины и цена вопроса

Ниже — то, что мы слышим на диагностике, и что за этим стоит.

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

Сколько это стоит: три составляющие цены плохих данных

Главная методическая мысль этого блока — про то, как считать. Обычно стоимость плохих данных оценивают через работу аналитика: три дня финансового менеджера в месяц на его стоимость. Цитата с вебинара: «Стоит смотреть на стоимость этих плохих данных не как на работу аналитика… а стоит смотреть на это именно через призму плохих данных» — то есть на последствия того, что в решение попал неверный контрагент или не та номенклатура.

1. Ручные сверки

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

2. Задержка решений

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

3. Потеря доверия к отчётности

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

Почему «каждый с каждым» и один разработчик — управленческий риск

Слова «интеграция точка-точка» звучат как тема для ИТ-совещания, и потому этот риск не попадает на стол собственника. Между тем измеряется он в тех же категориях, что износ станка или зависимость от единственного поставщика.

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

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

Что меняем в процессе — до всякой системы

Логика вебинара: идти от бизнес-проблемы к процессу и только потом к системе. Для данных это особенно верно: новая система наследует качество тех данных, которые в неё перенесут. Реплика Романа Соловьёва, генерального директора ERP Band: «Входящие данные — это тоже процесс… если у нас там себестоимость кривая пришла из другой системы, то первые заказы опять же будут проблемами».

Целевая архитектура данных — до внедрения, а не после

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

Владельцы справочников и регламент жизненного цикла записи

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

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

График документооборота и система показателей

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

Что закрепляем системой

Когда правила есть, их нужно сделать неотменяемыми. Здесь появляются продукты — причём в этом разрыве, единственном из четырёх, ядро контура не 1С:ERP.

MDM и шину принципиально не стоит смешивать: MDM отвечает на вопрос «какая запись правильная», шина — «как её доставить». Главное в MDM для менеджмента не техника сопоставления дублей, а заявочная система с согласованием: справочник перестаёт быть зоной ответственности одного человека. И MDM не требует единой ERP: «Необязательно у вас должна быть ERP и MDM, у вас может быть 10 ERP и одна MDM».

Когда MDM и шина не нужны

Этот раздел обычно опускают, потому что он сокращает объём продажи. Но без него разговор нечестный. На вебинаре границы проговорены прямо: MDM оправдан при больших справочниках и множестве систем, когда свести всё в один контур нельзя; шина — когда интеграций действительно много. В остальных случаях есть путь дешевле.

Альтернатива MDM — выделенный ответственный за НСИ. Для средней компании в одной учётной системе рабочее решение звучало так: закрепить человека, ответственного за НСИ, прямо в ERP. Право заводить и изменять записи выдаётся только ему, остальные подают заявки. Это даёт большую часть результата MDM без покупки отдельного продукта — при одном условии: у человека должно быть реальное право отказать. Если любой пользователь может обойти его и завести карточку сам, схема не работает.

Часть болей, ради которых присматриваются к MDM, снимает типовой функционал.

• Одно ТМЦ под разными наименованиями поставщиков. Типовой механизм «Наименования поставщиков»: внешние наименования хранятся отдельно и однократно сопоставляются с одной вашей номенклатурой. Приёмка идёт по наименованию поставщика, склад видит привычное внутреннее название.
• Требование бухгалтерии «как в документе». Подставлять нужное наименование в поле содержания УПД либо использовать «наименование для печати» рядом с рабочим — не плодя номенклатуру, иначе управленческий учёт потом не свести.
• Небольшое число обменов. Если систем две-три, отдельная шина избыточна: разумнее описать имеющиеся обмены, снять зависимость от одного человека и настроить контроль доставки.

Разговор о продуктах обоснован, когда есть несколько учётных систем; холдинг, филиалы, распределённые подразделения; слияние или миграция справочников; расхождения в отчётности. Если ни один признак не про вас — начинайте с регламента и ответственного. И честная оговорка про сроки: «когда НСИ не в порядке… сводить целый ряд компаний, юрлиц в один управленческий контур, то тут и более года может занимать проект».

Разбор с проекта: ГК «Плодородие»

Пример, который на вебинаре приводили именно к этому разрыву, — ГК «Плодородие»: растениеводство и переработка, более 100 000 га от Краснодара до Нижнего Новгорода, четыре предприятия в разных регионах, 50 АРМ и 496 единиц техники.

Что было. Каждое из четырёх предприятий закупало самостоятельно, в своей системе. Централизованных закупок не было, единой номенклатуры тоже: одна и та же позиция закупалась в разных регионах по-разному и называлась по-разному, поэтому на уровне группы не было ни сводной потребности, ни сопоставимых цен.

Что сделали. Две вещи, обе про данные и ответственность, а не про технику: единую НСИ с одним ответственным специалистом на всю группу и нормализацию статей расходов и доходов, которую провёл главный бухгалтер четырёх организаций. Что получилось: по обратной связи спустя время после внедрения материальные затраты сократились на 15%.

Порядок работ: как мы закрываем этот разрыв

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

1. Диагностика системы отчётности. Из скольких источников собирается каждая цифра, сколько человеко-дней уходит на сведение, какие решения запаздывают.
2. Инвентаризация систем и обменов. Какие данные в каждой системе первичны, какие обмены настроены и на ком держатся.
3. Целевая архитектура данных. Эталонный источник для каждой сущности, направления движения данных и правила разрешения конфликтов — до внедрения.
4. Владельцы справочников и регламент жизненного цикла записи. Роль-владелец, правила именования, порядок заявок, проверка на дубли.
5. Нормализация и дедупликация. Номенклатура, контрагенты и статьи затрат приводятся к эталону, дубли связываются.
6. График документооборота и система показателей. Сроки передачи документов между подразделениями; определение и владелец каждого показателя; дизайн управленческого дашборда.
7. Закрепление в системе. Мониторинг показателей в 1С:ERP, единый слой отчётности, а при обоснованной потребности 1С:MDM и 1С:Шина: обмен возможен через шину, EnterpriseData, OData, веб-сервисы и файлы, согласование заявок — через 1С:Документооборот КОРП.
8. Снятие зависимости от одного разработчика. Описываем интеграции, вводим мониторинг доставки и правило: связка документируется до запуска.

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

Чек-лист самопроверки

Пройдите по пунктам с финансовым и ИТ-директором: расхождения в ответах — сами по себе диагноз.

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

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

KPI, по которым видно, что разрыв закрывается

Частые вопросы

Что дальше

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

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

Читайте также

• Разрыв между продажами и производством: срок клиенту по опыту, а не по расчёту
• Себестоимость известна через месяц: разрыв между производством и финансами
• Три горизонта планирования: где теряется маржа между бюджетом и сменным заданием
• Что нужно, чтобы начать планировать производство: шесть условий
• Статьи бюджета: как составить справочник
• Обеспечение потребностей в 1С:ERP: какой вариант выбрать