- -
- 100%
- +
Тема выполняется, но какая базовая линия требований сейчас действует?
Исследование завершено, но к какой версии разработки относится его результат?
КД выпущена, но на основании какого решения и какой версии требований?
Испытание дало отрицательный результат — изменилась тема, версия разработки, проектное решение или только появилось замечание?
Замечание закрыто — значит ли это, что требование выполнено?
Опытный образец принят — означает ли это завершение НИОКР?
Расходы по этапу признаны — означает ли это, что технический результат принят?
На эти вопросы нельзя ответить ещё одним статусом темы.
Сначала нужно определить предметную архитектуру. И только потом решать, какие её части реализуются стандартными объектами 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, часть — электронным документооборотом, а для недостающих функций требуется расширение или интеграция.
Но программный объект не должен определять бизнес-архитектуру задним числом.
Иначе проект незаметно начинает отвечать не на вопрос «как предприятие управляет доставкой», а на вопрос «какие документы есть в нашей программе и как их соединить».