ERP-Лабиринты. Где выход?

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

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

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

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

Это очень важное различие.

Заявка не превращается в план. План не превращается в лот. Лот не превращается в закупочную процедуру. Процедура не превращается в предложение поставщика. Предложение не превращается в договор. Договор не превращается в заказ. Заказ не превращается в поставку.

Они связаны причинно и предметно, но сохраняют собственную идентичность.

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

То есть сам программный механизм вполне допускает предметно более зрелую интерпретацию.

Вопрос только в том, увидит ли её проектная команда.

Почему заказ поставщику тоже ещё не закупка

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

Но ловушка просто переместится дальше.

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

Однако до заказа существовали потребность, заявка, требования, выбор и договорное основание. После заказа остаются график и фактическая поставка.

Более того, в прикладных материалах по 1С: ERP отдельно отмечается, что заказ поставщику отражает закупочное обязательство или намерение, тогда как приёмка и складский приход фиксируются самостоятельными объектами.

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

Почему после правильного разделения закупочная схема становится меньше

На первый взгляд такая архитектура выглядит значительно сложнее привычной.

Вместо одной заявки появилось 35 предметов.

Вместо одной длинной схемы — 21 процесс.

Но происходит тот же парадокс, который мы уже видели в ремонтах, НИОКР, транспортной логистике и продажах: общая модель становится крупнее, а каждый отдельный процесс — проще.

Процесс формирования заявки больше не обязан описывать переговоры с поставщиками.

Процесс выбора поставщика не должен рисовать складскую приёмку. Договорный процесс не обязан моделировать движение машины с товаром. Мониторинг поставки не должен исполнять банковский платёж.

Закупочная функция не должна изображать внутри себя все действия отдела качества.

Каждый процесс работает со своим предметом, принимает подтверждённые входы и передаёт доказуемый результат.

Это уже не уменьшение реальности.

Это её разборчивость.

А где здесь 44-ФЗ, 223-ФЗ, ГОЗ и внешняя торговля

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

Отдельную закупку по 44-ФЗ. Отдельную по 223-ФЗ. Отдельную корпоративную. Отдельную по ГОЗ. Отдельную импортную.

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

Это очень важная инженерная экономия. Поставщик остаётся поставщиком. Потребность — потребностью. Предложение — предложением. Договор — договором. Заказ — заказом.

Специальный правовой режим делает их поведение более строгим, но не заставляет строить новую онтологию предприятия с нуля.

ERP-лабиринт начинается, когда документ становится определением бизнеса

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

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

После внедрения ERP всё это приходится материализовать.

Какая потребность сейчас обеспечивается?

Какая версия требований действует?

Почему именно эти позиции были объединены в один лот?

Какое предложение стало основанием выбора?

Какое решение разрешило заключить договор?

Какой договор породил обязательство?

Какой заказ его конкретизировал?

Какой график сейчас действует?

Какая поставка закрывает какой заказ?

Что именно показала приёмка?

Как результат поставки влияет на оценку поставщика?

Если предметная архитектура заранее не построена, ответы начинают прятаться в реквизитах, статусах, комментариях, электронных письмах и памяти закупщика.

Тогда проект получает знакомый диагноз: «1С не отражает нашу реальную закупку».

Иногда проблема действительно в функциональности.

Но иногда программе просто не дали различимую модель того, что она должна отражать.

Почему возникает ERP-лабиринт

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

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

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

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

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

Как выйти из этого лабиринта

Одна глава не предназначена для того, чтобы самостоятельно восстановить всю закупочную архитектуру. За обзорной картой остаются 35 предметных паспортов, сотни состояний и событий, 21 процесс, 126 процедур, 504 операции, интерфейсы, роли и доказательства.

Но эта глава позволяет увидеть признак проблемы.

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

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

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

В такой ситуации не поможет ещё одна общая блок-схема.

Нужно восстановить предметный мир закупки и заново определить, какие его проекции должны жить в ERP.

Заявка на закупку действительно нужна. Просто заявка на закупку — ещё не закупка.

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

Часть II. Нормы, обязательства и ресурсы как отдельные предметные миры

Дальше лабиринт становится менее заметным. Технологическая норма, заказ клиента, инструмент, автомобиль и запас кажутся хорошо знакомыми объектами учёта, но каждый из них соединяет несколько разных управленческих реальностей. Здесь особенно видно, почему прикладной объект нельзя использовать вместо предметной модели.

Глава 5. ERP-лабиринты: автоматизация техподготовки производства — ресурсная спецификация ещё не технологическая подготовка

Почему состав изделия, маршрут, нормы и ресурсная спецификация не сворачиваются в один объект 1С: ERP

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

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

Именно здесь начинается очередной ERP-лабиринт.

Первая попытка: сделать ресурсную спецификацию центром всей техподготовки

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

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

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

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

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

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

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

Итоговая ресурсная спецификация появляется уже тогда, когда существенная часть этих предметов сформирована и принята.

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

BPMN здесь тоже ни в чём не виновата

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

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

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

Если этого различения нет, BPMN просто аккуратно соединяет предметные подмены.

Стрелка остаётся непрерывной, а предметный мир несколько раз меняется.

Вторая попытка: добавить в схему всё производство

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

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

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

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

В информационной архитектуре добавляются ERP, MES, PLM/PDM и иногда CAM. Маршрут должен стать исполнимой производственной моделью. Управляющая программа должна соответствовать оборудованию и постпроцессору. Фактическое производство после запуска возвращает данные, по которым технологию придётся совершенствовать.

Каждый новый участник добавляет абсолютно обоснованные связи. Через некоторое время на схеме присутствуют конструкция, требования, модель изделия, технологичность, замечания, маршрут, операции, материалы, нормы, оснастка, рабочие центры, калькуляция, закупка, кооперация, контроль качества, план производства, MES и изменения.

Схема становится впечатляющей.

Но предметная архитектура снова исчезает.

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

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

Ресурсная спецификация как плоская тень технологии

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

Если спроецировать эту конструкцию на одну плоскость, значительная часть её содержания действительно может оказаться внутри ресурсной спецификации.

И это полезная проекция.

Но плоскость не становится объёмом.

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

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

Она представляет определённый слой производственного определения продукта.

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

Технически это иногда возможно.

Архитектурно — крайне опасно.

Предмет-драйвер техподготовки не существует один

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

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

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

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

При нормировании материалов драйвером становится норма расхода материала. Маршрут и операция задают контекст применения нормы.

При формировании итоговой ресурсной спецификации драйвером является итоговая ресурсная спецификация. К этому моменту процессы, маршруты, нормы и ресурсные требования уже должны быть приняты.

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

Так система остаётся связной без попытки объявить всё одной сущностью.