Как составить карту данных компании перед автоматизацией?

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

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

Зачем составлять карту до настройки системы

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

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

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

Начните с одного решения, а не со всей компании

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

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

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

Пять вопросов к каждому важному полю

Для каждого сведения в выбранном процессе стоит ответить на пять коротких вопросов.

1. Что это значит? Не просто «статус», а точное значение: заказ принят, подтверждён, собран или отгружен.
2. Откуда оно берётся? Его вводит менеджер, присылает клиент, рассчитывает система или оно приходит из другой программы.
3. Кто отвечает за точность? Не «отдел продаж», а конкретная роль, которая вправе исправить ошибку.
4. Где находится исходная версия? Если в CRM и учётной системе разные телефоны клиента, нужно заранее решить, какая запись главная.
5. Кто и когда может менять значение? Это защищает от ситуации, когда даты и суммы корректируются задним числом без следа.

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

Отделите справочник от события

Полезное упрощение — различать постоянные сведения и то, что произошло в конкретный момент. Карточка контрагента, номенклатура товара и список сотрудников — это справочники. Заказ, заявка, счёт, согласование, отгрузка — события.

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

Не всегда нужна одна общая запись для всего. Иногда в заказе важно сохранить адрес именно на дату покупки, даже если клиент позже переехал. Главное — назвать это решение и не оставлять его случайностью.

Проверьте данные на реальных примерах

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

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

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

Не переносите спорные данные молча

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

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

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

Кто должен участвовать в составлении карты

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

Разговор стоит вести на языке работы, а не названий таблиц. Не «какой у нас идентификатор сущности», а «как вы понимаете, что это тот же клиент?». Не «какой API является источником», а «в какой программе вы сначала исправляете неверный телефон и почему?». Техническая модель появится позже, когда бизнес-смысл уже согласован.

Что сделать после первой версии

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

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

Короткий чек-лист

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

Связанные вопросы

• Как выбрать первый процесс для автоматизации бизнеса?
• Как понять, где должен быть единый источник данных?
• Нужно ли очищать всю старую базу перед переходом на новую систему?
• Какие данные нельзя давать редактировать всем сотрудникам?