Данные и документы: справочники, документооборот и данные об изделии

Эта статья есть и на английском: English version.

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

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

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

Что в этой статье

• Справочники и мастер-данные: MDM, PIM, интеграционный слой — эталон по клиентам, товарам и контрагентам

• Документы: СЭД, ЭДО и договорной цикл — маршруты согласования, юрзначимый обмен, договоры

• Данные об изделии и объекте: PLM, PDM, BIM — состав изделия, версии, модель здания

• Как эти три контура связаны между собой

• Роль ИИ в работе с данными и документами

• Российские системы

• Типовые ошибки и чек-лист выбора

Справочники и мастер-данные: MDM, PIM, интеграционный слой

Что делает класс — и чего не делает

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

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

Подклассы и модули: из чего состоит класс

MDM — управление мастер-данными. Эталонные записи ключевых объектов: клиенты, поставщики, материалы, оборудование. Система находит дубли, склеивает записи, раздаёт эталон остальным системам.

Эффект: «три Ромашки» становятся одной — сквозная аналитика и интеграции начинают работать.

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

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

Эффект: одинаковые справочники во всех системах — данные стыкуются без ручного сопоставления.

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

PIM — данные о товарах. Товарный контент для каталогов и витрин: характеристики, описания, фото, локализации.

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

Недостаток: нужен владелец контента; PIM без ответственного за наполнение — пустая витрина с красивой архитектурой.

Интеграционный слой: ESB, iPaaS, API-менеджмент. Шины и платформы, по которым данные ходят между системами.

Эффект: системы связаны через управляемый слой, а не паутиной прямых доработок «точка-точка».

Недостаток: слой требует команды сопровождения; шина без владельца сама становится узким местом.

Data Governance и каталоги данных. Политика: кто владеет данными, кто имеет доступ, где что лежит, каким данным можно верить. Каталог данных — карта всего этого.

Эффект: данные превращаются из побочного продукта систем в управляемый актив.

Недостаток: легко съезжает в бюрократию — комитеты и регламенты без изменения реальной работы с данными.

Кому нужен класс, кому рано — и после чего внедрять

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

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

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

С чем связан и когда внедрять. Класс связан со всеми: он берёт данные из всех систем и всем же отдаёт эталон. По времени он идёт следом за появлением 2–3 систем. В торгово-сервисной траектории это шаг «порядок в справочниках» между СЭД и ЭДО и ERP; для производственной компании работа с НСИ разворачивается параллельно с производственным контуром и ERP. Дальше на этом фундаменте стоит аналитика — и всё, что мы говорили в хабе про гибридные системы: сердце гибрида — единая модель данных, и это ровно тот класс, который её держит.

Что класс даёт бизнесу — и его типовые недостатки

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

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

Как об этом думают мировые практики

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

В архитектуре данных сегодня спорят два подхода. Data fabric — термин Gartner — делает ставку на технологический слой: умную «ткань» поверх источников, которая сама связывает и обогащает данные. Data mesh — концепция Жамак Дегани — наоборот, децентрализует ответственность: данными владеют домены-подразделения. Один из четырёх её принципов, «данные как продукт», требует относиться к своим данным как к продукту с потребителями и качеством, а не как к побочному следу систем — принципы data mesh. Для практика важно не выбрать модное слово, а увидеть общее: в обоих подходах у данных появляются владельцы, договорённая модель и измеримое качество.

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

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

Ориентир по масштабу. Коробочные решения для наведения порядка в справочниках — единицы миллионов рублей разово, и на них закрывается большинство задач среднего бизнеса. Полноценные платформы данных — другая история: десятки миллионов в год за лицензии плюс работы, и это бюджет крупного ландшафта. Пилот занимает 3–6 месяцев, полное внедрение — 9–18. При двух-трёх системах платформа обычно не нужна вовсе: владелец справочника и регламент ввода стоят ноль и снимают половину проблемы.

Документы: СЭД, ЭДО и договорной цикл

Что делает класс — и чего не делает

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

Чего класс не делает: не управляет самими процессами компании — только их документной частью. Маршрут согласования договора СЭД проведёт, а вот перестроить сквозной процесс закупки — работа класса BPM. Граница тонкая, и переросшие СЭД компании упираются именно в неё.

Подклассы и модули: из чего состоит класс

СЭД — внутренний документооборот. Регистрация, маршруты согласования, контроль поручений, организационно-распорядительные документы.

Эффект: согласование перестаёт жить в почте и курилке — виден маршрут, сроки и то, у кого документ застрял.

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

ЭДО — юридически значимый обмен. Счета-фактуры, акты, УПД с контрагентами через операторов ЭДО, отчётность в госорганы, электронные подписи и машиночитаемые доверенности.

Эффект: закрывающие документы приходят за минуты, а не «до конца квартала»; курьеры и потерянные оригиналы уходят в прошлое.

Недостаток: эффект зависит от контрагентов — пока половина из них на бумаге, компания живёт в двух мирах и поддерживает оба.

CLM — договорной цикл. Создание договора по шаблону, согласование, подписание, контроль обязательств и сроков. Это не то же самое, что делопроизводство: CLM ведёт договор как сделку с обязательствами, а не как бумагу с реквизитами.

Эффект: договор готовится по шаблону за час, а не сочиняется заново; продления и обязательства не пропускаются.

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

Электронный архив. Долговременное хранение с быстрым поиском, юридическая значимость на горизонте лет.

Эффект: документ пятилетней давности находится за минуту, а не за день в подвале.

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

Потоковый ввод. Сканирование и распознавание входящей бумаги: первичка, входящая корреспонденция. Мостик к роботизации — подробно мы разобрали его в статье про RPA и IDP.

Эффект: бумага контрагентов попадает в системы без ручной перепечатки.

Недостаток: распознавание требует контроля качества — об этом ниже, в разделе про ИИ.

Кому нужен класс, кому рано — и после чего внедрять

Нужен практически всем: внешний юрзначимый обмен сегодня — вопрос не выбора, а сроков. Внутренний СЭД становится нужен примерно с 30 человек — когда согласования в почте начинают теряться. CLM — при сотне и больше договоров в год: ниже этого порога хватает шаблонов и дисциплины. Симптомы «пора»: договор согласуется неделями; никто не знает, где документ; закрывающие собираются авралом; юристы заняты типовыми договорами вместо сложных.

Рано или не нужен: микробизнесу внутренний СЭД избыточен — почты и облачных документов достаточно, а вот внешний ЭДО нужен и ему.

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

Что класс даёт бизнесу — и его типовые недостатки

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

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

2026 год: контекст

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

Ориентир по масштабу. Проект целиком: на полсотни-сотню пользователей — единицы миллионов рублей, на несколько сотен — до полутора десятков. Облачную СЭД для небольшой компании настраивают за неделю, классический проект или миграцию — за 4–8 месяцев. Внешний ЭДО считается отдельно от СЭД: там платят за исходящие документы и электронные подписи, входящие обычно бесплатны.

Данные об изделии и объекте: PLM, PDM, BIM

Что делает класс — и чего не делает

PLM (product lifecycle management, управление жизненным циклом изделия) отвечает на вопрос «что мы производим и в какой версии»: состав изделия, документация, изменения, техпроцессы — от идеи до эксплуатации и утилизации. PDM (product data management) — ядро внутри этого контура: хранение и версионирование конструкторских данных. BIM, в российской терминологии ТИМ (технологии информационного моделирования), — тот же принцип для объекта капитального строительства: не набор чертежей, а модель здания с данными.

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

Подклассы: из чего состоит контур

САПР: CAD, CAE, CAM. Место, где данные об изделии рождаются: геометрия, расчёты, программы для станков с ЧПУ.

Эффект: без этого слоя дальше говорить не о чем — всё остальное работает с его результатом.

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

PDM: управление конструкторскими данными. Единое хранилище моделей и документов с версиями, правами доступа, статусами и связями «деталь — сборка — изделие».

Эффект: исчезает главный источник производственного брака — работа по устаревшей версии.

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

PLM: жизненный цикл целиком. Требования, конструкторская и технологическая подготовка, извещения об изменениях, передача в производство, данные об эксплуатации и обслуживании.

Эффект: изменение проходит по маршруту, а не по переписке, и все смежники видят его одновременно.

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

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

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

Недостаток: дисциплина извещений неудобна и всегда воспринимается как бюрократия, пока не случится первая дорогая рекламация.

BIM/ТИМ: информационная модель объекта. Модель здания или сооружения с составом, характеристиками и документами, среда общих данных для проектировщиков, заказчика и подрядчика.

Эффект: коллизии находятся на модели, а не на стройке, а заказчик получает объект вместе с данными о нём.

Недостаток: ценность модели определяется дисциплиной наполнения; красивая геометрия без атрибутов — это картинка, а не информационная модель.

Кому нужен класс, кому рано — и после чего внедрять

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

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

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

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

Что класс даёт бизнесу — и его типовые недостатки

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

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

Почему это проект про данные, а не про конструкторов

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

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

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

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

2026 год: контекст

Два процесса идут одновременно. В машиностроении продолжается замещение зарубежных тяжёлых САПР и PLM: российские платформы за несколько лет закрыли значительную часть функциональности. Но переход упирается не в функции. Он упирается в миграцию накопленных за десятилетия данных и в переучивание конструкторов. В строительстве действует регулирование: с 2024 года применение технологий информационного моделирования стало обязательным для застройщиков многоквартирных домов, работающих по 214-ФЗ, — сначала на проектировании, затем на строительстве. Правила формирования и ведения информационной модели утверждены постановлением Правительства РФ № 614 от 17 мая 2024 года. Точные даты вступления требований в силу различаются по типам объектов и уточнялись поправками — сверяйтесь с действующей редакцией применительно к своему проекту. То есть для этого сегмента ТИМ уже не вопрос зрелости, а вопрос допуска к работе.

Ориентир по масштабу. Пилот занимает 2–3 месяца. «Быстрый старт» на группу конструкторов короче, 2–6 недель, но и охват у него меньше. Работы стоят единицы миллионов рублей разово, лицензии — сотню-полторы тысяч на рабочее место: основной бюджет уходит не на софт. Полномасштабные проекты рынок публикует редко, их считают после обследования КБ и архива.

Как эти три контура связаны между собой

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

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

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

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

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

Правило, общее для всех трёх: сначала договорённость, потом система. Ни один из этих классов не создаёт порядок — они его закрепляют и защищают от размывания.

Роль ИИ в работе с данными и документами

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

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

Что на подходе (прогноз, не факт): агенты-стюарды данных, которые находят проблему, готовят исправление и отдают человеку на подтверждение; ассистенты договорной работы с черновиком протокола разногласий; заготовка технологического процесса по трёхмерной модели.

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

Честная граница и типовой провал. Компания покупает ИИ-очистку справочников вместо того, чтобы починить процесс ввода, — через полгода справочники грязные снова. В книге Джимшера Челидзе «Искусственный интеллект. Практическое руководство для внедрения» это ловушка №3 из шести — «ИИ как пластырь»: попытка решить организационную проблему технологическим решением. Правило: сначала починить процесс, потом автоматизировать.

Российские системы

Реестровый статус конкретной редакции проверяйте при выборе: у вендоров несколько продуктов и редакций, и в реестре они числятся по-разному.

• MDM и управление НСИ — Юнидата (Unidata) · Планета.НСИ · 1С:MDM Управление НСИ

• Интеграционный слой (ESB, iPaaS) — короткого списка не привожу: сегмент фрагментирован, шину чаще собирают на платформенных компонентах, чем покупают как продукт

• СЭД / ЭДО / CLM — 1С:Документооборот · Directum RX · ТЕЗИС · Docsvision · ДЕЛО · TESSA

• Операторы юрзначимого обмена — Контур.Диадок · СБИС · Такском

• САПР и PLM для машиностроения — КОМПАС-3D и ЛОЦМАН:PLM (АСКОН) · T-FLEX CAD и T-FLEX PLM (Топ Системы)

• САПР и ТИМ для строительства — nanoCAD · Renga · Model Studio CS

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

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

Типовые ошибки и чек-лист выбора

Ошибки во всех трёх контурах повторяются, поэтому собрал их в один список.

1. Оцифровать беспорядок как есть. Пять бумажных подписей стали пятью электронными; справочник перенесли в новую систему вместе с дублями. Стало не быстрее, а дороже.

2. Внедрять до договорённостей. Пока подразделения не согласились, чья запись эталонная и кто отвечает за маршрут, система лишь фиксирует конфликт.

3. Начинать без инвентаризации. Состояние архивов и справочников всегда хуже ожиданий. Узнавать об этом после подписания контракта дорого.

4. Делать проект силами ИТ. Без юристов, конструкторов, снабжения и делопроизводителей меняется программа, а не порядок работы.

5. Затянуть двоемирие. Без плана перевода контрагентов и подразделений компания годами держит бумажный и электронный контуры одновременно.

6. Вешать «костыли» на справочники. Доработка под нужды одной системы аукается при каждой следующей интеграции.

7. Снять контроль с распознавания. Точность ИИ-извлечения деградирует незаметно, если её не мерить выборочно.

8. Надеяться, что ИИ почистит сам. Почистит — и через полгода почистит снова, пока не починен процесс ввода.

Чек-лист перед выбором системы

1. Названы владельцы: у каждого ключевого справочника, у каждого типа документа, у состава изделия — поимённо, а не «отдел».

2. Проведена инвентаризация: сколько записей, какая доля дублей, в каком состоянии архив. Цифры на бумаге, а не «примерно нормально».

3. Описаны маршруты и правила ввода — до автоматизации, а не после.

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

5. Заложено сопровождение: кто чистит, кто утверждает изменения, с какой периодичностью. Я бы отказался от проекта, у которого этот пункт пустой, — он вернётся в исходное состояние за год.

Что дальше

Общая карта классов — в статье Типы основных ИТ-систем. Другие разборы цикла: Производство, активы и склад · Клиенты и продажи · Деньги, планирование и аналитика · Автоматизация рутины и ИИ · Люди и ИТ-функция.

Разобраться глубже помогут книги Джимшера Челидзе «Цифровая трансформация для директоров и собственников» и «Искусственный интеллект. С неба на землю» — третья редакция, скачать бесплатно. Если у вас останутся вопросы, можете обратиться к нам за обучением или консультациями.