Предметно-ориентированное мышление при цифровой трансформации предприятия

Документ «Заказ поставщику» может быть носителем предмета «обеспечение потребности», предмета «обязательство поставщика», предмета «ожидаемое поступление», предмета «будущий кредиторский долг», предмета «риск срыва срока», предмета «цена закупки», предмета «условие поставки». Если проектная команда видит только документ закупки, она может не заметить, что этот документ связан с несколькими управленческими смыслами.

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

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

Отчёт по задолженности может обслуживать предмет «дебиторская задолженность», предмет «платёжное обязательство клиента», предмет «риск кассового разрыва», предмет «просрочка», предмет «лимит кредитования», предмет «финансовое поведение клиента». Если смотреть только как на отчёт, можно увидеть сумму. Если смотреть предметно, возникает управленческая картина.

Теперь нужно сформулировать, что именно делает ERP.

ERP фиксирует след изменения состояния предмета.

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

Но ERP фиксирует то, что в неё внесено и что настроено как значимое. Она не обязана сама раскрывать весь предметный смысл. Если проект не задал предметы, ERP будет честно хранить документы, регистры, статусы и отчёты, но связность смысла останется в голове людей или будет утеряна.

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

Первый предмет — клиентское обязательство. Предприятие обещает что-то поставить на определённых условиях. Второй предмет — плановая выручка. Заказ может стать основанием для финансового ожидания. Третий предмет — потребность в обеспечении. Если товара нет, заказ создаёт потребность в закупке, производстве или перемещении. Четвёртый предмет — резерв или назначение запаса. Пятый предмет — риск исполнения срока. Шестой предмет — будущая дебиторская задолженность или предоплата. Седьмой предмет — управленческий приоритет клиента.

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

Предметный анализ требует спросить: в каком состоянии находится каждый предмет, связанный с этим ERP-объектом? Клиентское обязательство подтверждено или нет? Обеспечение возможно или нет? Резерв создан или нет? Финансовое условие выполнено или нет? Срок реалистичен или нет? Риск исполнения принят или нет? Только после этого можно рассуждать управленчески.

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

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

Если проект строит модель только от ERP-объекта, он может выбрать один носитель и потерять остальные проекции. Например, увидеть партию только в складе и не увидеть её в качестве. Или увидеть только в качестве и не увидеть в себестоимости. Или увидеть только как серию, но не как управляемый жизненный цикл от выпуска до отгрузки и возможной рекламации.

Отсюда следует принцип: ERP-объект должен быть включён в предметную модель как носитель, а не как окончательное определение предмета.

Это особенно важно для методологии внедрения. Если проект начинается с перечня объектов ERP-системы, есть риск подмены. Главный предмет процесса подменяется документом. Роли начинают жить отдельно от предмета. Процедуры становятся шаблонными. ERP-привязка строится по догадке. Прикладной слой теряет связь с реальностью. В итоге команда знает, какие документы нужно создать, но не понимает, какой управленческий переход должна обеспечить система.

Конец ознакомительного фрагмента.

Текст предоставлен ООО «Литрес».

Прочитайте эту книгу целиком, купив полную легальную версию на Литрес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.