Типы основных ИТ-систем

6 июл. 2021 г.

21 мин. чтения

Обновлено: 1 сент.

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

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

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

Обновление 2026 года. У темы появился жёсткий срок: Минцифры установило дедлайн перехода на отечественные ERP — 1 января 2028 года («Ведомости», июнь 2026). Для субъектов критической инфраструктуры и госсектора это норматив; для остальных — вопрос рисков поддержки и обновлений. С марта 2026-го ERP-системы субъектов КИИ отнесены к значимым объектам критической информационной инфраструктуры. Оговорка важна: класс ПО сам по себе объектом КИИ не становится — категорируется конкретная система у конкретного субъекта. При этом SAP, по тем же данным, всё ещё работает в 80–90 % крупнейших промышленных холдингов. В конце карты — сводная таблица российских аналогов, проверенных по единому реестру отечественного ПО (август 2026). И полная карта порядка внедрения: кому нужен каждый класс, после чего его ставить и почему именно в таком порядке.

Шесть разборов цикла: как читать дальше

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

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

Каждая статья разбирает контуры целиком. Ни один класс не остался без разбора, и ни один не разобран дважды.

1. Производство, активы и склад — 4 Производство и активы · 5 Логистика. общий признак статьи: управляют физическим миром: станком, насосом, партией, паллетой
2. Клиенты и продажи — 3 Клиенты и рынок. общий признак статьи: собирают историю отношений с покупателем
3. Деньги, планирование и аналитика — 1 Учёт и планирование · 2 Аналитика · 10 Проекты и цели. общий признак статьи: четыре вопроса руководителя: что произошло, что планируем, что происходит сейчас, чем мы заняты
4. Данные и документы — 6 Документы и данные. общий признак статьи: где живёт эталон и кто за него отвечает
5. Автоматизация рутины и ИИ — 7 Процессы и автоматизация · 11 Искусственный интеллект. общий признак статьи: три способа закрыть задачу без большой разработки, с разными порогами входа
6. Люди и ИТ-функция — 8 Люди · 9 ИТ-служба, безопасность и рабочая среда. общий признак статьи: пользователь здесь сотрудник, а не клиент и не станок

В каждой статье по каждому классу: что он делает и чего не делает, кому нужен и после чего внедряется, какие есть российские решения, где реальная граница ИИ и что проверить до покупки.

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

Карта классов по контурам управления

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

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

Контур 1. Учёт и планирование

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

Классы контура: ERP · EPM и CPM

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

EPM и CPM, бюджетирование и консолидация. Надстройка над учётом: бюджетный цикл, консолидация группы компаний, сценарии «что если», OKR и отчётность по устойчивому развитию. Инструмент финансового директора; рынок ожил после ухода Anaplan и Hyperion. Внедряется, как правило, после ERP и аналитики: консолидировать можно только то, что уже учтено. Подробный разбор

Контур 2. Аналитика и поддержка решений

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

Классы контура: BI · хранилища данных и озёра данных · СППР

BI, бизнес-аналитика. Собирает данные из систем и превращает их в отчёты, дашборды и сводные показатели. Ставится после первого стабильного источника данных и дорастает вместе с ландшафтом. Главное ограничение простое: аналитика поверх хаоса визуализирует хаос, а не наводит порядок.

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

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

Подробный разбор всего контура: Деньги, планирование и аналитика, раздел про аналитику.

Контур 3. Клиенты и рынок

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

Классы контура: CRM и SRM · MarTech и CDP · контакт-центр и речевая аналитика · e-commerce, CMS и кассы

CRM и SRM, работа с клиентами и поставщиками. CRM ведёт путь клиента от первого касания до сервиса. Это первая система для малого бизнеса и источник клиентских данных для всего остального ландшафта. SRM — зеркальный класс для закупок и работы с поставщиками. Подклассы: продажи, маркетинг, сервис, программы лояльности, а для сложных B2B-предложений ещё и CPQ, конфигуратор коммерческих предложений. Подробный разбор

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

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

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

Контур 4. Производство и активы

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

Классы контура: SCADA и АСУ ТП · MES · APS · IIoT · BMS и BAS · EAM и ТОиР · QMS, EHS и LIMS

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

EAM и ТОиР, управление активами. Политика ремонтов, планирование технического обслуживания, экономика каждого актива. Подклассы: реестр активов, мобильные обходы, склад запчастей, предиктивная диагностика. Международный термин для среднего сегмента — CMMS, для недвижимости — IWMS и CAFM. Главные грабли здесь не технические: сопротивление ремонтных служб и риск превратить систему в формальную отчётность, где выполнение планов стопроцентное, а простои растут. Подробный разбор

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

И смежный разбор: почему именно в производственном контуре ИИ-пилоты чаще всего не взлетают — восемь барьеров внедрения ИИ на производстве.

Контур 5. Логистика

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

Классы контура: WMS · TMS · SCM

WMS, управление складом. Адресное хранение, приёмка, размещение, скорость набора заказа, контроль сроков годности. Складу нужен эталон номенклатуры и поток заказов, поэтому контур ставится, как правило, после учётного. Правило простое: система разложит по адресам ровно тот беспорядок, который лежал на полках, только теперь за деньги.

TMS, управление транспортом. Маршруты, тарифы, слоты, контроль перевозок и подрядчиков. Работает и на собственный парк, и на привлечённых перевозчиков. Эффект здесь считается в километрах и простоях, а не в интерфейсах.

SCM, управление цепочкой поставок. Цепочка целиком: прогноз спроса, нормирование запасов, планирование пополнений, работа с поставщиками. Самый зрелый участок для ИИ во всей карте, потому что прогноз спроса — задача с длинной историей и понятной метрикой. Но и требования к данным здесь соответствующие: два-три года истории и чистая номенклатура.

Подробный разбор всего контура: Производство, активы и склад, раздел про склад и логистику.

Контур 6. Документы и данные

Логика контура. Эти классы не автоматизируют ни один бизнес-процесс. Они держат то, чем пользуются все остальные процессы: документ и эталонную запись. Признак объединения — предмет хранения, а не участок работы. Сюда же относится модель изделия: состав, версии и чертежи — это тоже эталонная запись, просто об изделии, а не о клиенте или материале. Отсюда и место контура в очереди: он становится нужен не тогда, когда болит, а тогда, когда систем стало больше двух и они начали расходиться в показаниях.

Классы контура: СЭД · ЭДО · CLM · MDM · PIM · интеграционные платформы · Data Governance · PLM, PDM, BIM и САПР

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

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

PLM, PDM, BIM и САПР, данные об изделии и объекте. Изделие и объект в цифре. САПР отвечает за проектирование и расчёты, PDM хранит инженерные данные и версии, PLM ведёт жизненный цикл изделия целиком, BIM держит информационную модель зданий и инфраструктуры. Модель изделия, как правило, первична к производству: техпроцесс приходит из неё, а не из головы технолога, поэтому контур разворачивается до MES. Формально это проект конструкторов, по сути проект про данные, и именно поэтому он стоит здесь, а не среди производственных систем. Подробный разбор

Интеграционные платформы и Data Governance. Интеграционная шина и облачные интеграционные сервисы связывают системы между собой, заменяя паутину прямых связей «точка-точка». Data Governance и каталоги данных задают политику: кто владелец данных, по каким правилам они меняются, что считается эталоном. Это тот слой, который обычно покупают последним и жалеют, что не первым. Разбор — там же, где справочники.

Контур 7. Процессы и автоматизация

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

Классы контура: BPM · RPA · IDP · low-code и no-code

BPM, управление бизнес-процессами. Моделирование, исполнение и контроль процессов: где, когда, кто и какую работу выполняет. Process mining восстанавливает реальный ход процесса по цифровым следам в системах, а не по тому, как процесс описан в регламенте. Автоматизировать имеет смысл тот процесс, который описан и имеет владельца. Подробный разбор

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

Low-code и no-code, приложения без программистов. Бизнес собирает рабочие приложения из готовых блоков, не занимая очередь к разработке. Сила класса — скорость: недели вместо кварталов на мелких задачах. Границы две. Первая — сложная логика и производительность: то, что легко на старте, упирается в потолок платформы. Вторая — сопровождение: без общих справочников, реестра приложений и правил публикации класс за год-полтора плодит зоопарк, которым никто не управляет. Подробный разбор

Контур 8. Люди

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

Классы контура: HRM · ATS · КЭДО · WFM · LMS · базы знаний

HR-tech: HRM, ATS, КЭДО, WFM. Кадровое ядро обязательно по закону с первого сотрудника и обычно предопределено учётной системой компании. Дальше идут надстройки, и каждая подключается по своему триггеру: система подбора примерно от тридцати наймов в год, управление сменами при сменном персонале, кадровый электронный документооборот убирает бумагу из кадровых процедур, пульс-опросы меряют вовлечённость. Один из самых быстрорастущих сегментов рынка. Подробный разбор

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

Контур 9. ИТ-служба, безопасность и рабочая среда

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

Классы контура: ITSM · ITAM и CMDB · мониторинг · информационная безопасность · цифровое рабочее место · облачные модели

ITSM, ITAM и мониторинг, сервисное управление ИТ. Заявки, инциденты, изменения, каталог сервисов, соглашения об уровне обслуживания. ITAM и CMDB ведут учёт ИТ-активов и их связей, мониторинг следит за здоровьем систем. Часто именно ITSM становится первой школой процессного управления в компании. Ключевое условие живучести: учёт активов должен наполняться автоматическим обнаружением, вручную построенный справочник врёт уже через квартал. Подробный разбор

Информационная безопасность. Контур эшелонированный, и классы в нём закрывают разные рубежи. DLP защищает от утечек данных. IDM, IAM и PAM управляют учётными записями, доступами и привилегиями. SIEM и SOAR собирают события и организуют реагирование. EDR и XDR закрывают конечные точки. NGFW и SASE отвечают за сеть. Отдельно стоят управление уязвимостями и резервное копирование, последний рубеж, который проверяется восстановлением, а не верой. Физическая безопасность добавляет видеоаналитику и системы контроля доступа. С приходом генеративного ИИ появились дипфейки голоса руководителя и атаки на корпоративных ассистентов, и старые правила защиты их не ловят. Подробный разбор

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

Облачные модели. Все классы карты разворачиваются либо у себя, либо по модели «как услуга». SaaS даёт готовое приложение из облака, IaaS — арендованные серверы и сети, PaaS — платформу для собственных разработок. Контроль облачных затрат называют FinOps, и он становится нужен раньше, чем компания успевает удивиться счёту. Подробный разбор

Контур 10. Проекты и цели

Логика контура. Классы этого контура отвечают на вопрос, чем компания занята, чтобы измениться. Признак объединения — управление изменением, а не текущей операцией. Особенность контура в том, что он почти не зависит от зрелости остального ландшафта: дисциплина проектов не требует ни ERP, ни аналитики, поэтому класс появляется рано.

Классы контура: таск-трекеры · PPM · PSA · OKR-инструменты

Системы управления проектами и задачами. Канбан-доски и трекинг задач для команды. PPM ведёт портфель проектов, когда они начинают конкурировать за одних и тех же людей. PSA считает экономику проектов в услуговом бизнесе. OKR-инструменты держат каскад целей от стратегии до сотрудника. Массовый спрос на российские решения возник после ухода Jira и Trello. Главное правило выбора — по размеру задачи: корпоративная платформа маленькой команде мешает, а лёгкий трекер не удержит портфель из полусотни инициатив. Подробный разбор

Контур 11. Искусственный интеллект

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

Классы контура: платформы запуска моделей · RAG-ассистенты · ко-пилоты · ИИ-агенты · MLOps · AI Governance

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

Российские аналоги по классам

В таблице — только решения, числящиеся в едином реестре российского ПО (проверка — август 2026; реестровые имена местами отличаются от рыночных). Это ориентир, с чего начинать сравнение, а не рейтинг. Российский слой остальных классов — в статьях цикла.

ERP — SAP, Oracle. российские решения из реестра отечественного по: 1С:ERP · Галактика ERP · Global-ERP · ТУРБО ERP · Монолит.ERP · ПАРУС-Предприятие 8
MES — Siemens Opcenter. российские решения из реестра отечественного по: Галактика MES · платформы «Цифры» (ZIIoT, АИС «Диспетчер») · Malahit:MES · 1С:MES
EAM / ТОиР — IBM Maximo. российские решения из реестра отечественного по: 1С:ТОИР · Галактика EAM · АКСИОМА (Интерпроком) · IBS EAM · NERPA EAM
BI — Power BI, Tableau, Qlik. российские решения из реестра отечественного по: 1С:Аналитика · PIX BI · Visiology · Modus BI · Форсайт · Luxms BI
BPM — ARIS, Bizagi. российские решения из реестра отечественного по: ELMA365 · Comindware · Business Studio
СЭД / ЭДО — OpenText, Documentum. российские решения из реестра отечественного по: 1С:Документооборот · Directum RX · ТЕЗИС · Docsvision · ДЕЛО · TESSA
ВКС — Zoom, Teams. российские решения из реестра отечественного по: TrueConf · МТС Линк · Контур.Толк · IVA One · Яндекс Телемост

В каком порядке это внедрять

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

Отсюда — две траектории внедрения, модель Джимшера Челидзе: в зависимости от профиля бизнеса компания идёт либо по пирамиде ИТ-систем, либо от точки контакта с клиентом.

Производственная компания идёт по пирамиде ИТ-систем, в которой ландшафт строится снизу вверх — начиная с производственных систем, как дом с фундамента. Если упростить, то получается примерно следующая цепочка: АСУ ТП и SCADA → MES (иногда упрощённый, в виде производственного учёта) и промышленная автоматизация → ERP → аналитика и EPM → системы поддержки принятия решений для руководства на базе генеративного ИИ. Невозможно прийти на верхние уровни без проработки нижних. ERP без управления производством сводится к ручному вводу данных, которым нельзя доверять. Фундамент пирамиды — АСУ ТП, автоматизированные системы управления технологическим процессом: контроллеры и датчики, которые непосредственно управляют оборудованием. SCADA — мост между этим уровнем и производственными системами: она делает происходящее на железе видимым для людей и данных.

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

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

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

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

Строки производственной траектории — MES/SCADA, EAM, PLM, QMS. Строки торгово-сервисной — CRM, e-commerce и кассы, контакт-центр, MarTech. Остальные классы общие для обеих.

CRM / SRM — продажи длиннее одного касания; первый класс для малого бизнеса. внедрять после: — стартовый класс. почему такой порядок: самый быстрый эффект; источник клиентских данных для всего остального
MES, SCADA, APS, IIoT — производство со сменным планированием. внедрять после: оцифровки техпроцесса; до или вместе с ERP. почему такой порядок: данные рождаются на нижних уровнях; без них верхние системы кормятся ручным вводом
ERP — 50–100+ человек, полноценный учёт, больше одного юрлица. внедрять после: производственный профиль — после производственного контура; торгово-сервисный — после CRM и порядка в справочниках. почему такой порядок: ERP наверху пирамиды: без нижних уровней это ручной ввод и недостоверные данные
PLM / PDM / BIM — разработка сложных изделий или стройка. внедрять после: дисциплины работы в САПР. почему такой порядок: модель изделия, как правило, первична к производству
EAM и ТОиР — парк оборудования, цена простоя высока. внедрять после: справочника активов; параллельно с MES. почему такой порядок: без единого реестра активов ТОиР остаётся журналом в Excel
СЭД / ЭДО / CLM — 30+ человек или внешний документооборот; CLM — от 100 договоров в год. внедрять после: — ранний класс. почему такой порядок: главный проект стратегии цифровизации и ранний вход в процессное управление
Данные и интеграция: MDM, PIM, ESB — 2–3 системы и больше, сквозная аналитика, миграции. внедрять после: появления 2–3 систем. почему такой порядок: интеграция и справочники — фундамент; раньше этого MDM избыточен
BI, DWH, СППР — 3+ системы и сверки вручную. внедрять после: первого стабильного источника данных; дорастает вместе с ландшафтом. почему такой порядок: BI поверх хаоса визуализирует хаос
Информационная безопасность — базовый контур — всем; SIEM и SOC — от среднего бизнеса. внедрять после: базовый — сразу; SIEM — как правило, после порядка в ИТ-активах. почему такой порядок: нельзя защищать то, что не инвентаризировано
WMS / SCM / TMS — склад от 1000 м², своя логистика. внедрять после: как правило, ERP или учётного контура. почему такой порядок: складу нужен эталон номенклатуры и заказов
ITSM / ITAM — ИТ-служба от 5 человек или внешние SLA. внедрять после: — по мере роста ИТ. почему такой порядок: ITSM дисциплинирует ИТ раньше, чем ИТ дисциплинирует бизнес
HR-tech: HRM, ATS, WFM, КЭДО — кадровое ядро — с первых сотрудников; ATS — от 30 наймов в год. внедрять после: ядро сразу, надстройки по триггерам. почему такой порядок: кадровый учёт обязателен по закону, остальное — по боли
LMS и базы знаний — 50+ человек или регулярный найм. внедрять после: как правило, HR-ядра. почему такой порядок: база знаний — будущее топливо корпоративного ИИ
Системы управления проектами — 5+ параллельных проектов. внедрять после: — ранний класс. почему такой порядок: дисциплина проектов не требует ландшафта
Контакт-центр и речевая аналитика — поток обращений больше пары десятков в день. внедрять после: как правило, CRM. почему такой порядок: без CRM звонки не превращаются в клиентские данные
E-commerce, CMS, кассы — продажи онлайн; кассы — розница. внедрять после: витрина — после CRM и эталона товаров; касса — фискальная обязанность, ставится сразу. почему такой порядок: витрина без чистого каталога даёт возвраты и хаос
MarTech и CDP — B2C или контентный B2B; CDP — от трёх каналов касаний. внедрять после: как правило, CRM и цифровых каналов. почему такой порядок: автоматизировать маркетинг без данных о клиенте не из чего
EPM / CPM — группа компаний, бюджетный цикл, консолидация. внедрять после: как правило, ERP и BI. почему такой порядок: консолидировать можно только то, что учтено
QMS и EHS — производство; в регулируемых отраслях — обязательно. внедрять после: как правило, базового производственного учёта. почему такой порядок: управлять качеством можно только измеренного процесса
Low-code — очередь к разработке больше трёх месяцев. внедрять после: в СМБ — общих справочников и правил интеграции; в среднем бизнесе и крупнее — как правило, интеграционной шины. почему такой порядок: иначе плодит новые силосы
BPM — описанные регламенты и владелец процесса уже есть. внедрять после: — вне общей очереди, по зрелости процессного управления. почему такой порядок: автоматизировать стоит процесс, который описан и имеет владельца
RPA и IDP — на перекладывание данных между системами уходит труд 2+ человек. внедрять после: стабилизации процессов, которые роботизируем. почему такой порядок: робот на нестабильном процессе ломается еженедельно
ИИ-платформы, LLM, агенты; СППР для руководства — накоплены данные и процессы, есть владелец. внедрять после: того контура, который усиливаем, и правил работы с данными. почему такой порядок: верхняя ступень обеих траекторий: ставится поверх зрелости, а не вместо неё
Цифровое рабочее место — всем; активно — при замещении зарубежного офисного ПО. внедрять после: — гигиенический слой. почему такой порядок: почта, офис и мессенджер — среда, а не проект

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

Почти все современные системы — гибриды

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

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

У этого требования есть мировое имя: Gartner называет такой подход composable ERP — сборкой системы из независимых блоков, packaged business capabilities. А технический стандарт автономности называют MACH-архитектурой, за буквами четыре принципа: микросервисы, API-first, облачная модель, отделённый от внутренней логики интерфейс. Так что вопрос из абзаца выше — не придирка, а мировой стандарт выбора решений.

Второе: сердце гибрида — не модули, а база данных и взаимодействие между ними. Модули приходят и уходят, данные остаются. Причём «база данных» здесь — не обязательно одна система управления базой данных (СУБД) на всё. Да, единое хранилище для всех ИТ-систем кратно упрощает развитие, аналитику и внедрение ИИ. Но основная ценность — не хранилище, а единая модель данных, согласованность, взаимодействие и переиспользование данных между модулями. И тут полезно отвечать на такие вопросы:

Как устроены справочники (НСИ)?
Кто эталонный источник по каждому объекту: клиенту, материалу, единице оборудования?
Переиспользуют ли модули одни и те же данные — или каждый ведёт свою копию? Если клиент заведён трижды — в CRM, ERP и сервисной системе — три «Иванова» уже не склеятся в одного, и сквозная аналитика между процессами и подразделениями не заработает. На тренингах мы называем это канонической моделью данных, и её отсутствие — типовая ошибка: каждая новая интеграция дорожает, справочники обрастают «костылями», а решения на основе ИИ развивать вообще невозможно. Согласованность, взаимодействие и переиспользование данных между модулями и ИТ-системами — это и есть то, что отличает единое информационное пространство от зоопарка систем под одной вывеской.

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

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

Разбор фундамента данных: MDM и PIM: управление данными и НСИ

Общий предел всех этих систем

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

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

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

Итоги

Выбирается не «коробка», а архитектура: какие классы нужны вам, в каком порядке (это критически важно, иначе будут инвестиции без возврата), насколько автономны модули и как они будут обмениваться данными. И главное, что не изменилось за годы: ИТ-системы не исправят кривые процессы, слабый менеджмент и отсутствие мотивации. Сначала процессы и люди, потом система.

Для торгово-сервисного малого и среднего бизнеса порядок обычно такой: CRM — первой, для оцифровки клиентского пути; следом товарный учёт, электронный документооборот и порядок в справочниках. ERP — когда компания переросла 50–100 человек и нужен полноценный учёт. Дальше аналитика и, всё чаще, ИИ-ассистенты над собственными данными. Малое производство идёт иначе — от производственного контура, по пирамиде: универсальной последовательности для всех не существует.

Что дальше

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