Бесплатный фрагмент - ERP-Лабиринты. Где выход?

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

Первый том «Мы теряем контроль над сложной 1С: ERP. Что делать?» показывал систему с другой стороны: как предприятие постепенно теряет объяснимость собственных решений, связей и изменений. Здесь вопрос становится предметнее. Во втором томе «ERP-Лабиринты. Где выход?» нас интересует не то, почему ERP превратилась в лабиринт вообще, а чем именно предприятие управляет внутри каждой области и почему привычный документ, экран или большая процессная схема не заменяют предметную архитектуру.

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

Логика проектной работы в этих главах одна и та же. Сначала определяется граница предметной области и различаются бизнес-предметы, которые внутри неё действительно живут. Затем для предметов фиксируются состояния, события и процессные роли; из изменений предметов раскрываются самостоятельные процессы и межпроцессные передачи. Когда такие области соединяются между собой, становится видна уже не отдельная схема отдела, а связанная модель предприятия. Рабочая цепочка этой книги проста: предметные области → бизнес-предметы → состояния и события → процессы и передачи → единая бизнес-модель предприятия.

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

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

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

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

Часть I. Когда привычный объект перестаёт быть всей предметной областью

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

Глава 1. ERP-лабиринты: автоматизация ремонтов — заявка ещё не процесс

Почему аккуратная BPMN-схема не раскрывает предметную архитектуру ТОиР

Задача, которую получает аналитик, обычно звучит просто: описать процесс ремонта оборудования и показать, как он должен поддерживаться в 1С: ERP. Аналитик проводит интервью, определяет участников, собирает формы документов и рисует понятную BPMN-схему. В ней есть инициатор, ремонтная служба, руководитель, склад, несколько развилок, ожидание запасной части, выполнение работ и закрытие заявки.

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

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

Первая попытка: обработать заявку от начала до конца

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

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

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

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

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

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

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

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

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

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

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

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

Она стала больше. Но не стала яснее.

В ней действительно присутствует почти всё предприятие, однако предметы не разделены. Одни возникают и обрываются. Другие несколько раз меняют название. Третьи считаются реквизитами общей заявки. Четвёртые появляются только в дорожке того подразделения, которое ими занимается. Пятые скрываются внутри документа 1С, куда постепенно добавляют новые вкладки, статусы и поля.

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

Попытка обслуживать прибор по его тени

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

Тень не является ложью. Она действительно создана прибором. По ней можно понять общий силуэт и приблизительное положение объекта.

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

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

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

Предмет-драйвер не существует в одиночестве

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

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

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

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

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

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

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

Именно этого не видно, когда весь предметный мир сворачивается в единую «заявку».

Зачем предмету нужен таксон

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

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

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

Таксономический паспорт должен позволять ответить на практические вопросы. Что именно считается потребностью в техническом обслуживании или ремонте? Что ею не является? Чем она отличается от факта дефекта, решения о воздействии и задания исполнителю? Каким основанием подтверждается? В каких состояниях находится? Где фиксируется? В какие процессы передаётся? Какие процессные роли выполняет?

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

ТОиР не является островом внутри предприятия

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

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

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

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

Выполненные работы создают учётный след. Материалы списываются, труд и услуги образуют затраты, возникает экономическое событие, влияющее на стоимость владения оборудованием и результат периода. Эти предметы связаны с ремонтом, но не превращаются из-за этого в его внутренние статусы.

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

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

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

Тринадцать процессов вместо одной заявки

В предметно-процессной модели ТОиР выделены 13 бизнес-предметов и 13 бизнес-процессов. Процессный слой раскрыт через 43 процедуры и 86 операций.

Эти числа нужны не для демонстрации размера таблицы. Они показывают разницу между плоской проекцией и объёмной архитектурой.

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

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

Один процесс в правильном окружении

Рассмотрим только регистрацию и обоснование потребности в техническом обслуживании или ремонте, но не будем изображать этот процесс изолированно.

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

Каждый из этих предметов имеет собственное происхождение. План не является дефектом. Диагноз не является решением. Факт повреждения не является заданием. Но каждый из них способен стать основанием для возникновения потребности.

Предметом-драйвером рассматриваемого процесса является потребность в техническом обслуживании или ремонте.

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

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

Процесс заканчивается здесь.

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

Именно такая граница делает процесс коротким, но не примитивным. Она позволяет точно определить, что является результатом, кто отвечает за регистрацию, кто предоставляет доказательное основание и кому передаётся обоснованная потребность.

Почему один документ 1С не решает предметную задачу

Можно возразить: если все сведения удобно хранить в одном документе 1С, почему бы не считать его главным предметом?

Потому что прикладной объект отвечает на вопрос, где и как информация зафиксирована, а бизнес-предмет — чем предприятие управляет по смыслу.

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

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

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

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

Только после этого можно определить, где достаточно стандартной логики 1С: ERP, где требуется настройка, а где необходимо расширение прикладного решения.

Это уже следующий уровень работы. Его нельзя получить простым увеличением BPMN-схемы.

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

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

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

Задача книги не в том, чтобы доказать, что BPMN, 1С: ERP или документы бесполезны. Они необходимы. Но они начинают работать только тогда, когда становятся представлениями уже различённого предметного мира.

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

Один пример не позволяет самостоятельно восстановить предметно-процессную архитектуру предприятия. Это было бы таким же упрощением, как обещание собрать весь ТОиР из одной заявки.

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

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

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

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

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

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

Глава 2. ERP-лабиринты: автоматизация НИОКР — тема разработки ещё не процесс

Почему карточка темы, ТЗ и календарный план ещё не образуют архитектуру разработки

Автоматизация НИОКР часто начинается с очень понятной конструкции. Есть тема разработки, у неё есть руководитель, этапы, сроки и бюджет; дальше появляются техническое задание, план работ, конструкторская документация, испытания и итоговый отчёт. Остаётся нарисовать последовательность, назначить ответственных и подобрать объекты 1С: ERP, PLM или СЭД, которые будут сопровождать каждую стадию.

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

Проблема появляется в тот момент, когда карточку темы начинают принимать за сам предметный мир НИОКР.

Первая попытка: провести одну тему от идеи до результата

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

Для совещания такая схема удобна. Руководитель понимает общую последовательность, исследователь видит свой участок, конструктор — свой, финансовая служба получает этапы, к которым можно относить затраты. Если добавить дорожки подразделений, решения «да/нет» и несколько возвратов, получится вполне профессиональная BPMN-модель.

И именно поэтому её ограничение долго не замечают.

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

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

BPMN снова ни в чём не виновата

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

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

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

Непрерывность стрелки ещё не означает непрерывность предмета.

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

Вторая попытка: добавить в одну схему весь НИОКР

После первых вопросов аналитик обычно начинает расширять модель.

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

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

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

Схема стала значительно полнее. Но понимать её стало труднее.

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

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

Размер схемы в данном случае характеризует не глубину модели. Он показывает, насколько много различных предметных миров удалось спроецировать на одну плоскость.

Объёмная разработка и её плоская тень

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

Тень реальна. Она правильно показывает некоторую проекцию объекта.

Но по тени невозможно восстановить устройство изделия.

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

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

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

Предмет-драйвер не существует в одиночестве

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

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

И один и тот же предмет в разных процессах может играть разную роль.

Тема НИОКР является предметом-драйвером при её открытии. Но когда начинается работа с требованиями, сама тема уже становится контекстом: драйвером является базовая линия требований.

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

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

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

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

Поэтому полная картина НИОКР строится не вокруг одного «проекта», «темы» или «ТЗ», а вокруг сети предметов, которые меняют состояние и передаются между самостоятельными процессами.

Зачем предмету нужен таксон

В НИОКР особенно легко обмануться одинаковыми словами.

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

Поэтому названия недостаточно.

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

Рассмотрим тему НИОКР.

Тема — не строка справочника и не папка документов. Это идентифицированная единица управления НИОКР, которая связывает проблему, цель, границы, этапы, требования, исполнителей, сроки и ожидаемый результат. Карточка темы в ERP, PLM или СЭД является прикладным представлением этого предмета.

Теперь возьмём базовую линию требований. Это тоже не просто статус документа «ТЗ утверждено». Базовая линия — утверждённая версия согласованной совокупности требований, используемая как основание для разработки, проверки и последующего контроля изменений.

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

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

НИОКР не является островом внутри предприятия

Полный цикл НИОКР начинается не с того момента, когда сотрудник нажал «Создать тему», и заканчивается не закрытием карточки.

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

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

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

Серийное производство получает принятый и подготовленный результат, а не саму тему НИОКР.

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

Есть и финансовая проекция. В 1С: ERP темы и этапы исследований и разработок используются для детализации затрат; накопленные расходы по исследованиям и разработкам могут получать различный дальнейший учётный статус. Но это означает только то, что у предметного мира НИОКР есть финансовый след. Учёт расходов не является самим управлением НИОКР.

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

Пятнадцать групп и восемнадцать процессов вместо одной темы

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

В ней выделено 15 групп и 18 бизнес-процессов.

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

Далее формируется и управляется базовая линия требований. Отдельный процесс отвечает за планирование НИОКР, программы и методики исследований, испытаний и измерений. Ещё один — за патентные и информационные исследования.

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

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

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

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

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

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

За этими восемнадцатью процессами находятся 105 процедур и 420 операций.

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

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

Так появляется масштаб, но не возникает ватманная паутина.

Один процесс в правильном окружении: открыть тему НИОКР

Теперь можно увеличить только один фрагмент общей карты.

Допустим, предприятие решило открыть тему НИОКР.

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

Предметом-драйвером рассматриваемого процесса становится тема НИОКР.

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

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

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

Дальше формируются материалы для научно-технического совета.

Последний участок — принятие и регистрация решения.

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

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

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

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

Граница оказалась короткой.

Но именно поэтому она стала управляемой.

Почему справочник 1С: ERP ещё не является системой управления НИОКР

Здесь обычно возникает понятный вопрос: если в 1С: ERP уже есть «Темы, этапы исследований и разработок», зачем вообще строить дополнительную предметную модель?

Потому что прикладной объект и бизнес-предмет отвечают на разные вопросы.

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

Бизнес-предмет отвечает: чем именно предприятие сейчас управляет.

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

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

И через некоторое время система задаёт вопросы, на которые карточка темы принципиально не может ответить.

Тема выполняется, но какая базовая линия требований сейчас действует?

Исследование завершено, но к какой версии разработки относится его результат?

КД выпущена, но на основании какого решения и какой версии требований?

Испытание дало отрицательный результат — изменилась тема, версия разработки, проектное решение или только появилось замечание?

Замечание закрыто — значит ли это, что требование выполнено?

Опытный образец принят — означает ли это завершение НИОКР?

Расходы по этапу признаны — означает ли это, что технический результат принят?

На эти вопросы нельзя ответить ещё одним статусом темы.

Сначала нужно определить предметную архитектуру. И только потом решать, какие её части реализуются стандартными объектами 1С: ERP, какие — PLM или PDM, какие — лабораторными и испытательными системами, какие — СЭД, а где потребуется настроить интеграцию или расширить прикладную логику.

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

В ремонтах ловушкой была заявка на ремонт. Казалось, что если провести её через все подразделения, получится процесс ТОиР.

В НИОКР такой ловушкой становится тема разработки. Кажется, что если к теме привязать этапы, ТЗ, файлы, бюджет, испытания и результат, получится система управления разработкой.

Но тема — только один из бизнес-предметов.

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

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

Документы при этом не становятся бесполезными. BPMN не становится плохой нотацией. 1С: ERP не становится «неправильной системой».

Они просто должны занять своё место. Документ — быть носителем. BPMN — показывать изменение предмета. ERP-объект — реализовывать прикладную проекцию. А предметная архитектура — объяснять, чем предприятие действительно управляет.

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

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

Эти числа показывают масштаб скрытой конструкции.

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

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

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

Если темы смешаны с проектами, требования разбросаны по файлам, версии КД не связаны с решениями, испытания не трассируются к требованиям, 1С, PLM и СЭД показывают разные картины, а каждая новая доработка только добавляет очередную связь, тогда требуется уже не новый документ.

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

Когда проект НИОКР оказался в ERP-лабиринте, выход начинается не с новой карточки темы. Он начинается с восстановления предметного мира разработки, проекциями которого являются документы, схемы и объекты информационных систем.

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

Глава 3. ERP-лабиринты: автоматизация транспортной логистики — транспортная заявка ещё не процесс

Почему маршрут, рейс, перевозчик и транспортные документы не складываются в одну «схему доставки»

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

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

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

Всё это реальные требования. Ни одно из них само по себе не ошибочно.

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

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

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

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

Потом начинаются уточнения.

Выясняется, что одна заявка может породить несколько отправлений. Одно отправление может требовать нескольких транспортных плеч. Плечи могут выполняться разными исполнителями. Маршрут может измениться после того, как условия услуги уже согласованы. Перевозчик может принять задание, но заменить транспортный ресурс. Груз может быть готов не полностью. Рейс может уже существовать, хотя часть документов ещё оформляется. Физическая доставка может завершиться, а транспортная услуга ещё не закрыта из-за расхождения по стоимости. Груз может прибыть, но получатель зафиксирует повреждение. Международная перевозка добавит собственные документы и условия. Температурный груз потребует отдельного режима контроля.

И тогда в исходную схему начинают добавлять новые ветки.

Склад. Перевозчика. Закупки. Автопарк. Казначейство. Качество. Электронные документы. Страхование. Международную перевозку. Возвраты. Простой. Дополнительные расходы. Изменение маршрута. Повреждение. Повторное согласование.

Схема становится всё подробнее, но ясности не прибавляется.

«У нас процесс настолько большой, что мы рисуем его на ватмане»

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

Но большая схема и глубокая модель — не одно и то же.

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

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

Стрелки при этом могут быть безупречными.

Проблема не в стрелках.

Маршрут на карте — это плоская тень транспортной логистики

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

Но предприятие управляет не линией.

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

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

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

Они говорят о разных предметах.

Предмет-драйвер не означает «единственный предмет процесса»

Здесь появляется ключевое различение предметно-ориентированного подхода.

Бизнес-процесс действительно должен удерживаться вокруг одного предмета-драйвера — того предмета, изменение состояния которого задаёт начало, внутреннюю логику и завершение данного процесса. Но это вовсе не означает, что внутри процесса существует только один предмет.

Вокруг драйвера располагается его предметное окружение.

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

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

Это принципиально отличается от идеи «у нас есть одна большая заявка, внутри которой находятся все поля».

Заявка — это не форма в программе

Есть ещё одна ловушка.

Предприятие говорит: «У нас транспортная заявка находится в Excel». Потом внедряется ERP, и говорят: «Теперь заявка находится в ERP». Затем появляется TMS, и заявка переезжает туда. При этом аналитик начинает относиться к каждой форме как к новой хозяйственной сущности.

Но носитель может меняться, а бизнес-предмет оставаться тем же.

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

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

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

Транспортная логистика вообще не существует как остров

Особенно опасно проектировать её отдельно от предприятия.

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

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

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

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

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

Что находится за привычной «заявкой на перевозку»

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

Процессная проекция той же области содержит 11 бизнес-процессов, 104 процедуры, 432 пронумерованные операции и 24 структурных сценария. В неё входят управление транспортной потребностью, транспортной заявкой, отправлением, схемой доставки, маршрутом доставки, транспортной услугой, заданием на перевозку и рейсом, а при наличии подтверждённых условий подключаются управление международной перевозкой, перевозкой специального груза и температурно-контролируемой доставкой.

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

Возьмём только один процесс: управление транспортной заявкой

Теперь можно вернуться к исходной ловушке и разобрать её аккуратно.

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

Это уже граница.

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

Но самое важное находится не внутри этих семи процедур.

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

Все эти предметы связаны.

Но они не тождественны.

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

Теперь становится видно, почему нельзя просто нарисовать одну длинную стрелку «создать заявку → доставить → оплатить».

У этой стрелки нет одного предмета-драйвера.

Где именно ломаются привычные BPMN-схемы

BPMN здесь ни при чём. В хорошей предметной архитектуре BPMN прекрасно работает.

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

Формально переходы можно соединить.

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

Особенно это заметно на развилках. Например: «машина найдена?». Какой предмет изменился при ответе «да»? Транспортная заявка? Доступность ресурса? Вариант транспортной услуги? Задание? Если такого вопроса не задать, развилка остаётся понятной автору схемы, но не создаёт устойчивой проектной модели.

Другой пример: «груз доставлен?». Факт прибытия рейса, подтверждение передачи отправления и закрытие транспортной услуги могут находиться очень близко во времени, но это не одно событие. Получатель может принять груз с замечаниями. Рейс может завершиться, но спор по стоимости услуги остаться открытым. Электронный документ может получить технический статус, но сам этот статус не доказывает хозяйственного состояния доставки.

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

Хорошая архитектура не уменьшает предприятие — она возвращает ему объём

После предметного разделения модель на первый взгляд становится сложнее. Вместо одной «заявки» появляется несколько самостоятельных предметов. Вместо одного процесса — связанная система процессов. Вместо пары статусов — отдельные жизненные циклы.

Но затем происходит обратный эффект.

Схемы становятся меньше.

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

В результате общий граф предприятия становится больше, но отдельные процессы — понятнее.

Это и есть отличие сложной модели от запутанной.

А где здесь 1С: ERP, TMS, WMS и электронные документы?

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

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

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

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

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

Это совершенно разные задачи.

ERP-лабиринт начинается не там, где плохая программа

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

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

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

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

Сначала нужно восстановить объёмную модель.

И лишь затем определить, какими программными носителями она реализуется.

Из одной заявки получается карта предприятия

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

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

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

Не потому, что кто-то специально усложнил логистику.

Она такой была до автоматизации.

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

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

Следующий шаг другой.

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

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

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

В этом месте лабиринт впервые получает карту.

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

Глава 4. ERP-лабиринты: автоматизация закупок — заявка на закупку ещё не закупка

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

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

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

Казалось бы, вопрос решён. Нужно только перенести эту логику на предприятие.

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

Первая попытка: провести заявку через всю закупку

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

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

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

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

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

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

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

Даже 1С: ERP фактически предупреждает об этой ловушке

Здесь возникает интересный момент. Иногда предметное разделение воспринимается как искусственное усложнение, которое методолог навязывает прикладной системе. Но в закупочном контуре сама 1С: ERP уже показывает противоположное.

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

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

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

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

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

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

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

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

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

Схема стала значительно полнее. Но предметные границы в ней обычно становятся ещё менее заметными.

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

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

Заявка на закупку — плоская тень объёмной закупки

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

Заявка на закупку в ERP-проекте часто становится такой тенью.

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

Но за одной заявкой находится объёмный предметный мир.

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

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

Свернуть всё это в одну заявку технически возможно.

Но это всё равно будет тень.

Предмет-драйвер здесь тоже не существует один

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

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

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

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

При планировании драйвером является план закупок. Согласованные заявки становятся материалом для его формирования.

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

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

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

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

Зачем заявке на закупку нужен таксон

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

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

Формально все произносят одинаковое слово. Предметно они говорят о разных сущностях.

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

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

Таксономический паспорт позволяет задать вопросы, которые невозможно решить простым наименованием документа. Какая подтверждённая потребность лежит в основании заявки? Можно ли объединить в одном экземпляре несколько потребностей? Какая версия заявки является действующей? Что именно означает согласование? Когда заявка считается переданной в закупки? Что служит доказательством её выполнения? Как отличить выполненную заявку от заказа, который поставщик ещё фактически не исполнил?

После таких вопросов становится видно, насколько опасна фраза «ну это всё у нас одна заявка».

Закупки не существуют отдельно от производства, склада и денег

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

Производству нужен материал или комплектующее. ТОиР нужна запасная часть. Инвестиционному проекту — оборудование. Сервису — комплект. Продажам может потребоваться покупной товар. Планирование запасов фиксирует дефицит и необходимость пополнения.

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

Но даже после этого она не становится владельцем всего дальнейшего движения.

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

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

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

Граница не разрывает цепочку. Она объясняет, что именно пересекло эту границу.

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

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

В ней выделены шесть предметных групп и 35 самостоятельных бизнес-предметов. Для них зафиксированы 253 состояния, 304 события и 35 жизненных циклов; отдельно определены представления, доказательства и функциональные назначения ролей.

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

Вторая удерживает потребность и планирование: закупочную потребность, заявку, план и позиции плана.

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

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

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

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

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

Двадцать один процесс вместо одного «процесса закупки»

Процессная архитектура показывает ту же область уже в движении. В ней шесть групп процессов, 21 бизнес-процесс, 126 процедур, 504 операции и 35 интерфейсов.

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

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

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

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

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

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

Детальная — как устроено одно из них.

Увеличим один процесс: формирование и согласование заявки на закупку

Вернёмся к предмету, с которого начинался наш лабиринт.

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

Предметом-драйвером теперь становится заявка на закупку.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Зачем технологическому маршруту собственный таксон

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

Поэтому название документа ещё не определяет бизнес-предмет.

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

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

У каждого предмета должна быть собственная идентичность, даже если несколько предметов в итоге представлены одной программной формой.

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

Техподготовка не является конструкторским отделом и не является производством

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

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

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

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

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

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

Итогом является не «документ технолога».

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

Девятнадцать предметных групп и 31 бизнес-предмет вместо одной спецификации

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

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

Это не означает, что пользователь должен запомнить каталог из 31 строки.

Смысл счётчика другой.

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

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

Двадцать один бизнес-процесс вместо одного процесса техподготовки

Процессная модель раскрывает этот же предметный мир в движении. В ней зафиксированы 21 бизнес-процесс, 126 процедур и 593 пронумерованные операции.

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

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

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

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

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

За каждым процессом далее скрываются собственные процедуры и операции.

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

Увеличим один фрагмент: разработка технологического маршрута

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

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

Предметом-драйвером является технологический маршрут.

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

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

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

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

Последний участок — принятие, публикация и версионирование маршрута.

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

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

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

Почему итоговая ресурсная спецификация всё равно необходима

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

Наоборот.

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