Process Product: что процесс производит, кроме того, что вы продаёте

Вторая точка отсчёта для процессной архитектуры

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

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

Для кого это

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

Что вы заберёте

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

0. Почему это важно, а главное интересно

Допустим, мы выпускаем карандаши. Готовый карандаш в упаковке - очевидный продукт: за него платит клиент, у него есть цена, артикул и место на складе.

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

Именно такие результаты я дальше называю Process Product, или процессными продуктами.

В процессной модели обычно виден только карандаш.

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

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

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

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

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

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

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

В классическом описании процесса в центре стоит последовательность действий. Это логично: BPMN, EPC, IDEF и другие подходы хорошо отвечают на вопрос «что происходит?». Для корпоративной архитектуры одного этого ответа мало.

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

ISO 9000 даёт полезную базовую рамку. В актуальной терминологии выход (Output) определяется как результат процесса.

Оригинал: “output - result of a process”.

Перевод: «output - результат процесса».

Источник: международный стандарт, ISO 9000:2026 Quality management - Fundamentals and vocabulary, ISO, 2026, п. 3.7.8.

Ещё важнее другое замечание того же стандарта: выходы одного процесса обычно становятся входами других.

Оригинал: “Inputs to a process are generally the outputs of other processes and outputs of a process are generally the inputs to other processes.”

Перевод: «Входы процесса обычно являются выходами других процессов, а выходы процесса обычно становятся входами других процессов».

Источник: международный стандарт, ISO 9000:2026 Quality management - Fundamentals and vocabulary, ISO, 2026, п. 3.3.1, примечание 2.

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

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

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

Путаница начинается почти сразу. В разных стандартах и профессиональных сообществах используются слова result, output, product, outcome, value, benefit, deliverable, impact. Их часто переводят одним словом «результат», после чего обсуждение становится почти бессмысленным.

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

Термин	На какой вопрос отвечает	Сквозной пример: карандаш	Зачем различать
Результат (Result)	Что вообще получилось или произошло?	Всё, что возникло вследствие производства карандаша или его последующего использования	Самая широкая категория результата
Выход (Output)	Что процесс непосредственно произвёл?	После производства получена партия карандашей	Непосредственный результат конкретного процесса
Процессный продукт (Process Product)	Какой выход процесса имеет собственную дальнейшую судьбу и требует отдельного управления?	Готовая партия карандашей, паспорт качества, решение о выпуске, брак, отходы	Самостоятельный объект управления и архитектуры
Последствие (Outcome)	Что изменилось после использования результата и у кого?	У покупателя появилась возможность писать и рисовать, которой до покупки не было	Изменение состояния после использования продукта. Всегда у кого-то конкретного
Ценность (Value)	Почему этот результат или изменение важно и для кого?	Школьнику важно, что написанное можно стереть; чертёжнику - что линия держит толщину	Ценность всегда чья-то, и у разных сторон она разная
Выгода (Benefit)	Какую измеримую выгоду получили и кто именно?	Производителю - снижение себестоимости на 8%; школе-закупщику - расход на ученика ниже на 12%	Измеримый эффект. Субъект обязательно называть: здесь он сменился с покупателя на производителя
Воздействие (Impact)	Какой более широкий и долгосрочный эффект возник?	Переход отрасли на более экологичные материалы из-за массового отказа от древесины	Самое широкое кольцо: последствия для рынка или среды, за пределами отдельной сделки

ISO 9000 в редакции 2026 года разводит две формы результата: то, что непосредственно произвёл процесс, и эффект от использования произведённого.

Цитата: «результат (result) - итог чего-либо. Примечание 1 к определению: Он может иметь форму произведённого процессом результата (3.7.8) или полученной ценности (например, эффект использования или применения)».

Источник: международный стандарт, ISO 9000:2026 Quality management - Fundamentals and vocabulary, ISO, 2026, п. 3.7.1, примечание 1. Приводится по русскому тексту.

Терминов outcome, value и impact в ISO 9000:2026 нет вообще. Раздел 3.7 «Термины, относящиеся к результату» содержит семнадцать терминов - среди них результат, произведённый результат (output), продукт и услуга, - но ни одной из верхних ступеней моей цепочки там нет. Слово benefit стандарту знакомо, однако в другом контуре: в разделе 3.4 определены экономическая выгода (economic benefit, п. 3.4.13) и финансовая выгода (financial benefit, п. 3.4.14), обе в узком финансово-экономическом смысле, а не как ступень между результатом и эффектом его использования.

У других стандартов те же слова означают другое: в ISO/IEC 33001 process outcome - это наблюдаемый результат достижения цели процесса, которым может быть и сам изготовленный продукт. Сам ISO 9000 признаёт эту зыбкость прямо: «будет ли результат процесса называться произведённым результатом, продуктом или услугой, зависит от контекста, в котором встречается термин» (п. 3.3.1, примечание 1).

Поэтому верхние ступени приведённой выше цепочки - Outcome, Value, Benefit, Impact - это моя рабочая операционализация, а не терминология стандарта: трёх из них у ISO нет вовсе, а Benefit в моём значении с финансовой выгодой ISO не совпадает.

Для практической работы я предлагаю фиксировать границу ещё жёстче. Output отвечает на вопрос «что процесс непосредственно произвёл?». Process Product - на вопрос «какой из этих непосредственных результатов является самостоятельным объектом управления?»., а Outcome - на вопрос «что изменилось после использования этого результата?». Граница между первыми двумя проходит по критериям из раздела 5, граница между вторым и третьим - по факту использования.

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

3. Почему обычного продукта (Product) мало, чтобы описать реальные результаты процесса

Когда говорят «продукт», большинство людей автоматически представляет то, что получает конечный клиент: автомобиль, кредит, страховой полис, консультацию, программный сервис. Часть стандартов это представление поддерживает. ISO 9000:2026 определяет продукт как произведённый результат организации, а не процесса, и отличает его от услуги по одному признаку - нужно ли для его получения взаимодействие с потребителем.

Цитата: «продукт (product): произведённый результат (3.7.8) организации (3.1.1), который может быть получен без осуществления каких-либо операций между организацией и потребителем (3.9.1)».

Источник: международный стандарт, ISO 9000:2026 Quality management - Fundamentals and vocabulary, ISO, 2026, п. 3.7.9. Приводится по русскому тексту.

То есть у ISO выход (Output) привязан к процессу, а продукт (Product) - к организации: продукт - это то, что организация кому-то отдаёт. ArchiMate ставит границу там же: Product - набор сервисов и объектов, «который предлагается как целое (внутренним или внешним) потребителям» (п. 8.4.1; подробнее в разделе 11). Кому именно отдаёт - вопрос отдельный, и скобка в определении ArchiMate на него уже отвечает.

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

PMBOK 7 обходится вообще без организации и потребителя, зато прямо называет промежуточный результат: «Product. An artifact that is produced, is quantifiable, and can be either an end item in itself or a component item» - «продукт: артефакт, который произведён, поддаётся количественной оценке и может быть либо конечным изделием сам по себе, либо составной частью» (PMBOK Guide, седьмое издание, глоссарий).

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

Цитата: «3.1.65 продукт (product): Конструкция, являющаяся специализацией конструкции Объект предприятия, которая отображает желаемый выход (результат) или побочный продукт Бизнес-процессов предприятия».

Источник: национальный стандарт, ГОСТ Р ИСО 19440-2010 «Интеграция предприятия. Конструкции для моделирования предприятий» (= ISO 19440:2007, IDT), п. 3.1.65. Оговорка: это редакция 2007 года; действующая ISO 19440:2020 мною не проверялась, расхождение между редакциями не установлено.

ISA-95 доходит до уровня учёта затрат и перечисляет результаты производства списком, в котором брак стоит рядом с основным продуктом: «Results are typically identified by products, by-products, co-products, and scrap. This information would be in sufficient detail to identify all costs by product, co-products, and scrap» - «результаты обычно идентифицируются как продукты, побочные продукты, сопутствующие продукты и брак (scrap); информация должна быть достаточно детальной, чтобы отнести все затраты к продукту, сопутствующим продуктам и браку» (ANSI/ISA-95.00.01-2010, п. 6.5.11 «Production performance and costs»). «Брак» здесь взят за привычность: scrap в ISA-95 - категория разнесения затрат, а не термин стандарта, и с браком из ГОСТ 15467-79 (раздел 7) она пересекается, но не совпадает.

Советская традиция ставила акцент туда же, куда ISO 19440. ГОСТ 15467-79 в справочном приложении описывает продукцию как «материализованный результат процесса трудовой деятельности» и тут же оговаривает, что результаты труда бывают овеществлёнными и неовеществлёнными - энергия, информация, некоторые виды услуг, - хотя сами термины стандарта относятся только к первым.

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

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

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

Оригинал: “A traditional requirement of Process modeling is to be able to model the items (physical or information items) that are created, manipulated, and used during the execution of a Process.”

Перевод: «Традиционное требование к моделированию процессов - возможность моделировать объекты (материальные или информационные), которые создаются, обрабатываются и используются в ходе выполнения процесса».

Источник: стандарт нотации, Business Process Model and Notation (BPMN), Version 2.0.2, Object Management Group, December 2013 (formal/2013-12-09), § 10.4.1.

Технически это выражено в спецификации входов и выходов действия: «The InputOutputSpecification defines the inputs and outputs and the InputSets and OutputSets for the Activity» (там же, § 10.3). Оговорку стоит сделать сразу: сама нотация оперирует данными, а приведённая формулировка - это требование к моделированию, а не утверждение, что BPMN представляет материальные продукты.

Data Mesh поворачивает вопрос ещё сильнее: аналитические данные предлагается рассматривать как продукт, если вокруг них появляется продуктовая ответственность.

Оригинал: “Analytical data provided by the domains must be treated as a product, and the consumers of that data should be treated as customers - happy and delighted customers.”

Перевод: «Аналитические данные, предоставляемые доменами, должны рассматриваться как продукт, а потребители этих данных - как клиенты, причём довольные клиенты».

Источник: архитектурная концепция, Data Mesh Principles and Logical Architecture, Zhamak Dehghani, 2020.

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

Из этого, однако, не следует, что любой объект данных (Data Object) или любой документ автоматически становится Process Product. Иначе архитектурный репозиторий за несколько недель превратится в кладбище технического мусора.

3.1. Внутренний клиент: продукт не обязан уходить наружу

Для Process Product принципиально важно другое: потребитель результата не обязан быть внешним клиентом. Никакого открытия здесь нет - это давно записано в стандартах, и напоминать об этом приходится только потому, что на практике о внутреннем потребителе забывают. ISO 9000:2026 говорит об этом прямо, а в примере к тому же пункту среди потребителей отдельно назван получатель продукта или услуги из внутреннего процесса.

Оригинал: “A customer can be internal or external to the organization.”

Перевод: «Клиент может быть внутренним или внешним по отношению к организации».

Источник: международный стандарт, ISO 9000:2026 Quality management - Fundamentals and vocabulary, ISO, 2026, п. 3.9.1, примечание 1.

То же самое зафиксировано и в языке моделирования: определение Product в ArchiMate 4 говорит о наборе, который предлагается «внутренним или внешним» потребителям (п. 8.4.1).

На практике внутренним потребителем может быть следующий процесс, роль или система. Запись результата контроля потребляет производственная система (MES, Manufacturing Execution System) или система менеджмента качества (QMS, Quality Management System), решение о допуске партии - склад и процесс отгрузки, финансовую сверку - закрытие периода, набор данных - аналитический сервис.

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

3.2. Клиентский продукт (Product Offering) и процессный продукт (Process Product) - не одно и то же

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

Клиентский продукт (Product Offering) - это целостное предложение внутреннему или внешнему клиенту: товар, услуга, цифровой сервис, тариф или комбинация сервисов и условий.

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

На примере карандаша это видно проще. Коробка карандашей, которую покупатель берёт в магазине, может быть частью клиентского продукта (Product Offering). При этом производство этой коробки создаёт множество процессных продуктов (Process Products): готовую партию, паспорт качества, результаты измерений, решение о выпуске, брак и отходы. Клиентский продукт и процессный продукт иногда совпадают, но чаще находятся на разных уровнях: один описывает предложение клиенту, другой - конкретный управляемый результат работы процесса.

4. Определение процессного продукта (Process Product)

Процессный продукт (Process Product) - это непосредственный результат процесса, который является самостоятельным объектом управления и архитектуры.

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

• Непосредственный результат процесса. Process Product появляется в результате выполнения процесса. Это не последующий эффект от его использования. Например, решение «бюджет утверждён» может быть Process Product, а рост инвестиционной активности после этого решения - уже Outcome.
• Отдельный от действия. Process Product - это то, что получилось в результате работы, а не сама работа. «Провести контроль качества» - действие. «Результат контроля качества» - возможный Process Product.

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

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

Это не определение ISO, TOGAF или ArchiMate. Это моя операционализация категории на основе собранной нормативной, академической и практической базы.

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

5. Три критерия и одно исключение

Перед нами непосредственный результат процесса, отделимый от действия. Стоит ли его выделять? Три вопроса.

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

• Партия № 42017 - это конкретная партия карандашей, выпущенная в определённую смену, с известным составом сырья; на неё можно сослаться в рекламации через год.
• Паспорт качества версии 2 - это документ, который отличается от версии 1 набором показателей, и по номеру версии видно, какие данные видел клиент.
• Решение D-17 - это запись в журнале приёмочного контроля с датой, автором и основанием, и к ней можно вернуться при разборе инцидента.

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

Второй - дальнейшее использование (downstream relevance). Использует ли результат кто-то или что-то дальше: принимает другой процесс, хранит система, его проверяют, преобразуют, отправляют клиенту, перерабатывают или утилизируют? Если результат никуда не идёт, ему нечего делать в архитектуре.

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

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

И одно исключение - существенная архитектурная значимость (material architectural significance). Оно нужно для результатов, которые не проходят второй или третий критерий сегодня, но игнорировать их нельзя: если объект не выделить, мы потеряем существенный риск, стоимость, нормативную обязанность или важную связь. Пример: побочный поток, который сегодня никто не учитывает - у него нет ни владельца, ни потребителя, - но с нового года он попадает под регулирование. По обычным критериям это ещё не процессный продукт, по риску - уже да. Регулируемый отход сюда не относится: у него есть и судьба, и владелец, и он проходит по обычным критериям. Исключение - именно для того, что регулируемым только станет.

6. Классы процессных продуктов (Process Products)

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

Класс	Что это
Материальный процессный продукт (Material Process Product)	Готовая партия товара, деталь, комплект: партия карандашей П2-42017, корпус после шлифовки, собранный набор для школы
Сервисный результат (Service Result)	Идентифицируемый результат услуги: подписанное заключение консультанта, закрытая заявка с решением, акт выполненных работ
Информационный продукт / продукт данных (Information / Data Product)	Набор данных, запись, витрина, информационный пакет: витрина продаж для аналитиков, выгрузка для регулятора, результат измерения в журнале контроля
Документальный продукт (Document Product)	Паспорт качества, протокол, отчёт, спецификация
Решение / статус (Decision / Status Product)	Формализованное решение или статус, который используется дальше: «партия допущена к отгрузке»
Программный / цифровой продукт (Software / Digital Product)	Релиз, конфигурация или иной цифровой результат
Побочный продукт (By-product)	Результат, получение которого не основная цель процесса: тепло от печи, обрезки древесины, пригодные для ДСП
Отход как процессный продукт (Waste Product)	Отход, у которого есть собственная судьба, требования, стоимость и риски
Несоответствующий / дефектный продукт (Nonconforming / Defect Product)	Результат, который запускает отдельный жизненный цикл: изоляцию (quarantine), переработку (rework), ремонт (repair), разрешение на отклонение (concession) или списание (scrap)
Составной логический процессный продукт (Composite Logical Process Product)	Логический продукт из нескольких самостоятельных процессных продуктов или с несколькими представлениями: комплект документов на партию, где паспорт качества, протокол испытаний и решение о выпуске живут каждый своей жизнью, но отгружаются вместе

У четырёх классов есть оговорки, которые в таблицу не поместились.

Сервисный результат легко спутать с самим действием. «Консультирование клиента» - действие (activity). «Консультация оказана и результат зафиксирован» уже может быть самостоятельным сервисным результатом.

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

Решение как продукт опирается на прямой и довольно неожиданный прецедент. В методологии DEMO каждому виду транзакции приписан ровно один «вид продукта» (product kind), и записывается он именно как факт в перфекте - «[аренда] законтрактована», «взнос за [членство] за [год] уплачен» (DEMO Specification Language 4.7.2, разд. 7.1). Моё «бюджет утверждён» построено по тому же синтаксису, хотя я пришёл к нему независимо. Различие принципиальное, и его стоит назвать: в DEMO продукт транзакции обязателен и всегда один, а вопрос стоит «какой факт создаёт эта транзакция?». У меня вопрос другой - «какой из созданных результатов стоит вести как объект управления?», и ответом может быть «ни одного» или «несколько».

Отход требует оговорки для читателя из бережливого производства. В ГОСТ Р 56020-2014 (п. 4.11) waste переведено как «потери» и означает действие, которое потребляет ресурсы и не создаёт ценности. Я говорю не об этом, а об отходе в смысле Федерального закона № 89-ФЗ «Об отходах производства и потребления» и федерального классификационного каталога отходов (ФККО) - то есть о веществе, у которого есть масса, класс опасности и собственный маршрут.

7. Почему брак и отходы здесь особенно важны

На браке и отходах отличие Process Product от бытового понимания продукта видно лучше всего.

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

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

Цитата: «Брак - продукция, передача которой потребителю не допускается из-за наличия дефектов».

Источник: межгосударственный стандарт, ГОСТ 15467-79 «Управление качеством продукции. Основные понятия. Термины и определения», Госстандарт СССР, 1979 (с Изм. № 1 1985 г.), п. 48.

Формулировка стоит того, чтобы её перечитать. Забракованная партия не выпадает из категории продукции - она остаётся продукцией, у которой закрыт один конкретный маршрут, передача потребителю. Тот же стандарт разводит исправимый и неисправимый брак (пп. 49–50), то есть у несоответствующего результата уже нормативно предполагается собственный жизненный цикл. Одну оговорку сделать обязательно: сам ГОСТ ограничивает свои термины овеществлёнными результатами труда, поэтому на документы, данные и решения он не распространяется.

Зато на них распространяется ISO 9001 в редакции 2015 года, и формулирует он ту же норму через выходы процессов, а не через продукцию.

Цитата: «8.7.1 Организация должна обеспечивать идентификацию и управление результатами процессов, которые не соответствуют требованиям, в целях предотвращения их непредназначенного использования или поставки. […] Организация должна осуществлять в отношении несоответствующих результатов процессов одно или несколько из следующих действий: a) коррекцию; b) отделение, ограничение распространения, возврат или приостановку поставки продукции и предоставления услуг; c) информирование потребителя; d) получение разрешения на приемку с отклонением».

Источник: национальный стандарт, ГОСТ Р ИСО 9001-2015 «Системы менеджмента качества. Требования» (= ISO 9001:2015, IDT), п. 8.7.1.

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

Европейское регулирование заходит с другой стороны и вводит понятие by-product - не как самостоятельное определение продукта, а как условие, при котором результат производства вообще не попадает в режим отходов. Вещество считается не отходом, а побочным продуктом, если выполнены четыре условия. Это не то же самое, что выход из режима отходов: тот описан отдельной статьёй 6 и касается вещества, которое отходом уже стало.

Оригинал: “Member States shall take appropriate measures to ensure that a substance or object resulting from a production process the primary aim of which is not the production of that substance or object is considered not to be waste, but to be a by-product if the following conditions are met: (a) further use of the substance or object is certain; (b) the substance or object can be used directly without any further processing other than normal industrial practice; (c) the substance or object is produced as an integral part of a production process; and (d) further use is lawful, i.e. the substance or object fulfils all relevant product, environmental and health protection requirements for the specific use and will not lead to overall adverse environmental or human health impacts.”

Перевод: «Государства-члены принимают надлежащие меры для того, чтобы вещество или объект, возникающий в производственном процессе, основной целью которого не является производство этого вещества или объекта, считался не отходом, а побочным продуктом, если выполнены следующие условия: (a) дальнейшее использование вещества или объекта определено; (b) вещество или объект может использоваться напрямую без дополнительной обработки сверх обычной промышленной практики; (c) вещество или объект производится как неотъемлемая часть производственного процесса; и (d) дальнейшее использование законно, то есть вещество или объект отвечает всем применимым требованиям к продукции, охране окружающей среды и здоровья для конкретного применения и не приведёт к общему негативному воздействию на среду или здоровье человека».

Источник: нормативный правовой акт, Directive 2008/98/EC on waste, European Union, консолидированная редакция 02008L0098 - EN - 18.02.2024 - 004.002, статья 5(1) в редакции Директивы (ЕС) 2018/851. В первоначальной редакции 2008 года эта норма была разрешительной («may be regarded… only if»); действующая редакция обязывает государства-члены обеспечить такую квалификацию при выполнении условий.

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

Сама директива при этом менялась. В редакции 2008 года государство только могло признать вещество побочным продуктом. Действующая редакция обязывает государство это обеспечить, если условия выполнены. Регулятор за десять лет перешёл от права к обязанности различать эти две категории: норму изменила Директива (ЕС) 2018/851 от 30 мая 2018 года.

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

8. От продукта к процессу, а не только от процесса к продукту

Одна из самых сильных для меня находок в исследовании - проектирование процессов от продукта (PBWD, Product-Based Workflow Design). Базовая статья вышла ещё в 2003 году и важна здесь как академический предшественник самой логики: процесс можно проектировать, начиная не с перечня действий, а со спецификации продукта, который должен быть получен. Для моей идеи это академический прецедент самой точки входа: сначала определить требуемый результат, а затем уже выводить из него необходимую работу.

Оригинал: “PBWD takes the product specification and three design criteria as a starting point.”

Перевод: «PBWD берёт спецификацию продукта и три критерия проектирования в качестве исходной точки».

Источник: научная статья, Product-Based Workflow Design, H.A. Reijers, S. Limam Mansar, W.M.P. van der Aalst, 2003.

Ценность этой работы для меня в том, что она показывает: проектировать процесс от требуемого продукта, а не от существующей последовательности действий, - это уже двадцать лет как академически признанный ход. В последующих работах подход развивался вплоть до автоматического вывода модели процесса из структуры Product Data Model (Vanderfeesten и др., 2010).

Для меня здесь важен не сам PBWD один в один. Он в первую очередь работает с целевым продуктом и его структурой. Интереснее расширение идеи. Если процесс создаёт множество архитектурно значимых Process Products, они годятся как отправная точка не для одного рабочего процесса (workflow), а для процессной архитектуры целиком.

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

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

Сам по себе этот довод продукт ни от чего не отличает. Ровно то же и теми же словами говорит TOGAF про способности.

Оригинал: “Unlike business capabilities (which are inherently stable), organizational structures are not enduring and frequently change in most organizations.”

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

Источник: руководство к стандарту корпоративной архитектуры, The TOGAF® Series Guide: Business Capabilities, Version 2 (G211), The Open Group, действующая редакция 2025 года, разд. 2.1.1.

Устойчивее оргструктуры и продукт, и способность.

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

9. Процессный продукт (Process Product) как узел корпоративной архитектуры

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

Дальше - моя модель связей, а не метамодель какого-либо стандарта. Процессный продукт (Process Product) может стать узлом трассировки между несколькими доменами:

• Бизнес-процесс (Business Process) производит или потребляет процессный продукт (Process Product).
• Данные (Data) описывают продукт либо сами могут быть процессным продуктом (Process Product).
• Приложение (Application) создаёт, хранит, преобразует, публикует или контролирует продукт.
• Технология и оборудование (Technology and Equipment) физически реализуют, измеряют или перемещают продукт.
• Организация и роль (Organization and Role) отвечают за создание, качество, принятие и дальнейшую судьбу продукта.
• Требования (Requirements) определяют допустимые характеристики продукта.
• Ключевые показатели (KPI) измеряют качество, стоимость, стабильность и результативность.
• Риски и контроли (Risks and Controls) фиксируют, что может пойти не так и чем это удерживается.
• Последствие, ценность и выгода (Outcome, Value and Benefit) показывают, какое изменение возникло после использования продукта, для кого оно важно и какую измеримую пользу оно принесло.

9.1. Два прохода по карандашу

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

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

Мы изменили характеристику одного продукта и потянули за собой несколько доменов корпоративной архитектуры. Поэтому продуктом, на мой взгляд, нужно управлять не только как складской учётной единицей (SKU, Stock Keeping Unit).

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

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

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

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

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

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

9.2. Продукт как единица анализа влияния изменений (impact analysis)

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

• Процессы
• Договоры и соглашения об уровне услуг (SLA, Service Level Agreement)
• Каналы продаж и обслуживания
• Данные и справочники
• Ценообразование и биллинг (pricing and billing)
• Правила допуска и прав на обслуживание (eligibility and entitlement)
• Интеграции и отчётность
• Риски и нормативное соответствие (compliance)
• Компетенции сотрудников, обучение, поддержка и эксплуатация

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

Оба прохода по карандашу показывают один и тот же механизм. Мы изменяем одну существенную характеристику Process Product и дальше идём по его связям в архитектуре. Проверяем:

• Где изменились требования?
• Какие процессы больше не обеспечивают новый результат?
• Какое оборудование или приложение перестало подходить?
• Какие данные и проверки нужно добавить?
• Какие риски появились?
• Какие KPI потеряли смысл или требуют нового целевого значения?

В этом смысле Process Product может быть удобной единицей управления изменениями: не заменять способность (Capability), процесс (Process), приложение (Application) или объект данных (Data Object), а связывать их в конкретный контекст изменения - так, как я это делал на реальных проектах.

9.3. Процессный продукт (Process Product) не заменяет другие архитектурные объекты

Обратная ошибка не менее опасна: попытаться построить всю архитектуру только вокруг Process Product. Способность (Capability) отвечает на вопрос «что организация должна уметь?», процесс (Process) - «как выполняется работа?», поток создания ценности (Value Stream) - «как создаётся ценность?», приложение и технология (Application, Technology) - «чем это обеспечивается?». Process Product отвечает на другой вопрос: «что именно возникло в результате этой работы и чем из этого имеет смысл управлять отдельно?».

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

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

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

10. Что должно быть в реестре процессных продуктов (Process Products)

У продуктового описания есть три разных уровня, которые полезно не смешивать:

• Первый уровень - общие характеристики класса архитектурного объекта: природа продукта, типология, роли, жизненный цикл, связи и принципы качества.
• Второй уровень - паспорт конкретного типа или экземпляра (Type / Instance): идентификация, потребитель, ценность, состав, требования, договорные условия, владельцы, процессы, данные, приложения, технологии, зависимости и риски.
• Третий уровень - метрики и фактические значения: качество, стоимость, SLA, сроки, риск, маржинальность и другие показатели.

Такое разделение было в исходных материалах презентации и хорошо совпало с тем, к чему я пришёл в результате исследования и построения метамодели Process Product v1.0.

Минимальный контракт процессного продукта (Process Product) я бы сделал очень небольшим:

• Идентификация (Identity) - что это за объект.
• Исходный процесс / производитель (Source Process / Producer) - откуда он появляется.
• Потребитель / назначение / дальнейшая судьба (Consumer / Destination / Disposition) - куда он идёт дальше.
• Ответственный владелец (Accountable Owner) - кто отвечает за его характеристики и судьбу.
• Тип процессного продукта (PP Type) - к какому типу он относится.

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

Поле контракта	Паспорт качества партии	Решение о допуске к отгрузке	Шлифовальная пыль
Идентификация	Паспорт качества партии P2-42017, версия 2	Решение D-17 по партии P2-42017	Отход, код ФККО, накопление за смену 2026-09-06
Исходный процесс / производитель	Контроль качества партии	Приёмочный контроль, решение принимает начальник отдела технического контроля (ОТК)	Шлифовка корпусов, участок механической обработки
Потребитель / назначение / дальнейшая судьба	Клиент, служба качества, аудит; хранится 5 лет	Склад и процесс отгрузки; основание для перевода партии в статус «к отгрузке»	Накопление, передача лицензированному подрядчику, утилизация
Ответственный владелец	Руководитель службы качества	Начальник ОТК	Эколог предприятия
Тип процессного продукта	Документальный продукт	Решение / статус	Отход

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

Дальше глубина управления должна зависеть от критичности. Для одного объекта достаточно пяти полей. Для критичного продукта данных (Data Product) или регулируемой производственной партии могут понадобиться:

• Требования и характеристики, критерии приёмки (acceptance criteria)
• Измерения (measurements) и статус соответствия (conformity status)
• Ключевые показатели и жизненный цикл
• Риски и контроли (risks and controls)
• Стоимость, затраты на качество и издержки низкого качества (CoQ / COPQ)
• Сроки хранения (retention) и происхождение данных (lineage)
• Система-источник достоверных данных (system of record)
• Связи с другими объектами корпоративной архитектуры

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

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

11. Что эта концепция не утверждает - и что утверждает

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

11.1. Сравнение шло не с тем элементом

Раньше я отстраивал процессный продукт от элемента Product в ArchiMate.

Оригинал: “A product represents a coherent collection of services, business objects, data objects, artifacts, and/or material, which is offered as a whole to (internal or external) customers.”

Перевод: «Product представляет собой связный набор сервисов, бизнес-объектов, объектов данных, артефактов и/или материалов, который предлагается как целое (внутренним или внешним) потребителям».

Источник: спецификация языка моделирования, ArchiMate® 4 Specification, The Open Group, 2026, п. 8.4.1.

Product в ArchiMate - объект, который предлагается клиенту как целое. Это и есть клиентский продукт (Product Offering) из раздела 3.2, то есть ровно та сущность, которую я сам уже отделил от процессного продукта. Отстраиваться от неё бессмысленно: она никогда не претендовала на то же место. Здесь же видно то, на что я обратил внимание в разделе 3: «внутренним или внешним» стоит прямо в определении, а значит, тезис из раздела 3.1 о том, что продукт не обязан уходить наружу, не моя находка, а строчка в стандарте.

11.2. Кто на самом деле конкурирует с процессным продуктом

Настоящие конкуренты процессного продукта в ArchiMate - другие элементы, пассивные:

Элемент ArchiMate 4	Определение	Что закрывает из моей типологии
Business Object	«conceptual passive element that has relevance from a business perspective»	документальный продукт, решение, статус
Data Object	«data structured for automated processing»	информационный продукт, продукт данных
Artifact	«a piece of data that is used or produced in a software development process, or by deployment and operation of an IT system»	программный и цифровой продукт
Material	«tangible physical matter or energy… typically used to model raw materials and physical products»	материальный продукт, партия, отход
Deliverable	«a result of a work package»	пересекается только по краю: это результат проектной работы, а не работы процесса

Отдельно отмечу строку про Material. Раньше я писал, что материальная партия - единственное, чему в ArchiMate соответствия нет. Это неверно: элемент Material описан в п. 10.3.2 и покрывает как раз сырьё, физические продукты и энергию, причём в определении прямо сказано, что элементы поведения могут его создавать, использовать, перемещать и преобразовывать.

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

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

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

Оригинал: “the ArchiMate Specification does support the specialization of its concrete concepts (i.e., the ones used in models)… This is sometimes called “stereotyping” of concepts. Specialized elements inherit the properties of the elements they specialize… For a specialized concept, certain attributes may also be predefined.”

Перевод: «Спецификация ArchiMate поддерживает специализацию своих конкретных концептов (то есть тех, что используются в моделях)… Это иногда называют „стереотипизацией“ концептов. Специализированные элементы наследуют свойства элементов, которые они специализируют… Для специализированного концепта часть атрибутов может быть предопределена».

Источник: спецификация языка моделирования, ArchiMate® 4 Specification, The Open Group, 2026, п. 14.2.

Рядом, в п. 14.1, описан механизм профилей - наборов типизированных атрибутов, которые можно динамически привязать к концепту. Минимальный контракт из раздела 10 - идентификация, исходный процесс, потребитель и дальнейшая судьба, владелец, тип - это и есть такой набор атрибутов. То есть раздел 10 уже написан под механизм 14.1, я просто не называл это вслух.

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

Оригинал: “A deliverable is a work product that is contractually specified and in turn formally reviewed, approved, and signed off by the stakeholders… An artifact is an architectural work product that describes an aspect of the architecture.”

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

Источник: стандарт корпоративной архитектуры, The TOGAF® Standard, 10th Edition, Architecture Content, The Open Group, глава 1.

Пустое место на позиции процессного продукта в TOGAF возникает не по недосмотру: у стандарта здесь просто другой предмет.

11.3. Чего я не утверждаю

Термин Process Product в том значении, в котором он используется здесь, - не термин ISO, TOGAF или ArchiMate.

Я не первым подумал о продукте как основе процесса, и здесь надо назвать предшественника, которого я в предыдущей версии не назвал. Это artifact-centric BPM - направление, выросшее из работ IBM Research в начале двухтысячных: A. Nigam, N.S. Caswell «Business artifacts: An approach to operational specification», IBM Systems Journal 42(3), 2003 (полный текст за платным доступом, поэтому цитировать его я не буду), и продолжающая её работа Кона и Халла.

Оригинал: “…a business artifact is a blend of data and process for a key business-relevant dynamic entity that captures its end-to-end journey”.

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

Источник: научная статья, Cohn D., Hull R. «Business Artifacts: A Data-centric Approach to Modeling Business Operations and Processes», IEEE Data Engineering Bulletin 32(3), сентябрь 2009.

Логика узнаваемая: взять значимый результат, дать ему идентичность и жизненный цикл и строить операции вокруг него. Кроме artifact-centric BPM, тем же занимались PBWD больше двадцати лет назад, Data Mesh с данными как продуктом, DEMO с продуктом транзакции, а в советских и российских стандартах результат деятельности и продукция обсуждались десятилетиями.

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

11.4. Что я утверждаю

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

Сами по себе критерии отбора не новы. IT4IT делит объекты данных на ключевые и вспомогательные по существенности для управления жизненным циклом (редакция 2.1, разд. 3.4.2), у artifact-centric BPM есть признаки бизнес-значимой сущности, PBWD отбирает элементы спецификации продукта. Заявлять критерии как вклад было бы неосторожно.

Новое - там, куда эти критерии до сих пор не переносили. Все перечисленные подходы работают с информационными объектами: IT4IT с объектами данных в ИТ, artifact-centric BPM с записью о бизнес-значимой сущности, PBWD с информационным продуктом. Даже когда сущность физическая - как аппаратный актив в примере Кона и Халла, - моделируется запись о её пути, а не сама вещь. Ни один из подходов не берёт объектом управления забракованную партию, регулируемый отход или побочный поток, который завтра попадёт под регулирование.

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

12. Ограничения и следующий шаг

Process Product v1.0 - модель, которую я проверял на собственных проектах.

Она прошла стресс-тест на десяти классах процессов - от производства партии до формирования стратегии. Четыре класса модель прошла без оговорок, на четырёх потребовались защитные правила (например, запрет считать человека продуктом процесса найма), два случая изменили саму модель: понадобились представление (Representation) для логического продукта и разделение системы-производителя и ответственного владельца. Разбивка приведена по колонке итогового статуса рабочего листа.

Дополнительно я прогнал модель на контрольной выборке из сорока разнородных результатов процессов из пятнадцати доменов: двадцать оказались процессными продуктами, четырнадцать - нет, шесть остались на пересмотре и дали правила для пограничных случаев. Классифицировал я сам, в один проход; это помогло найти и закрыть пограничные случаи, но это не статистическая или эмпирическая валидация. Сами примеры, вердикты и правила - в рабочей таблице исследования, листы «Стресс-тест PP», «Контрольная выборка PP», «Уточнения после стресс-теста» и «Пограничные случаи».

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

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

Не только: «какие процессы у нас есть и что в них делают?»

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

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

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

Этот раздел - для тех, кто видел презентацию или кому интересно, как менялась сама модель. Для понимания концепции он не нужен.

После презентации я получил обратную связь, и она оказалась полезнее простого согласия с идеей. Возникли вопросы, на которые исходная версия отвечала скорее интуитивно: любой ли выход (Output) стоит считать продуктом; где проходит граница между продуктом и последствием (Outcome); что делать с решениями, статусами, данными, документами, браком и отходами; как отличить самостоятельный продукт от технического следа процесса; можно ли использовать продукт как точку входа в анализ влияния изменений и проектирование процессной архитектуры. Дальше - по четырём направлениям.

Подтвердилось. Идея продукта как значимого архитектурного объекта не развалилась. Доказательная база поддерживает её основные опоры: процессы производят выходы (Outputs); результаты могут быть материальными, информационными и сервисными; у результата может быть внутренний потребитель; продуктовая логика давно используется и в архитектурных, и в процессных подходах. А тезис о влиянии изменения продукта на процессы, данные, системы, роли и качество после исследования я считаю уже не внешним «доказанным законом», а рабочим тезисом.

Уточнилось. Самая важная корректировка касается старой формулы «продукт = выход (Output) процесса». Она оказалась слишком широкой. Выход - хорошая исходная категория, но если считать Process Product каждый технический результат каждой операции, модель мгновенно становится непригодной. Поэтому в версии 1.0 появился фильтр: самостоятельная идентифицируемость, дальнейшее использование (downstream relevance), самостоятельная управляемость и, в исключительных случаях, существенная архитектурная значимость (material architectural significance).

Расширилось. В презентации основной фокус был на готовом продукте, браке, данных и связи продукта с архитектурными доменами. Исследование добавило полноценное разделение выхода, процессного продукта, последствия, ценности и выгоды (Output / Process Product / Outcome / Value / Benefit); решения и статусы как продукты (Decision and Status Products); представление (Representation); уровни «тип - вариант - экземпляр - версия» (Type / Variant / Instance / Version); происхождение данных (lineage); требования и критерии приёмки (acceptance criteria); жизненный цикл; управление и ответственность (governance); стоимость и издержки низкого качества (COPQ, Cost of Poor Quality); а также формальную рамку принятия решения (Decision Framework). Не всё из этого попало в статью: представление, уровни типизации, происхождение данных и рамка принятия решения остались в рабочих материалах исследования, ссылка на них - в таблице источников. В тексте я разбираю то, без чего концепция не работает: критерии, типологию, связи с доменами и минимальный контракт.

Ограничилось. Некоторые сильные формулировки из презентационных материалов лучше не переносить буквально. Например, продукт не стоит объявлять единственным или главным центром всей корпоративной архитектуры (EA, Enterprise Architecture), а любой дефект, документ или дашборд (dashboard) - продуктом автоматически. После исследования позиция стала менее эффектной в одном предложении, зато намного лучше переживает вопрос «а где проходит граница?».

Источники и ключевые опоры

Источник	Тип	Автор / организация, год	Что взято в статью
ISO 9000:2026 - Quality management - Fundamentals and vocabulary, пятая редакция (открыть)	международный стандарт	ISO, 2026	Определения процесса, результата, произведённого результата, продукта, потребителя: пп. 3.3.1 (прим. 1–2), 3.7.1 (прим. 1), 3.7.8, 3.7.9, 3.9.1 (прим. 1)
ISO/IEC 33001:2015 - Information technology - Process assessment - Concepts and terminology (открыть)	международный стандарт	ISO/IEC, 2015	П. 3.3.11: process outcome определён иначе, чем в этой статье, - показывает полисемию термина
BPMN 2.0.2 - Business Process Model and Notation (открыть)	стандарт нотации	Object Management Group, декабрь 2013, formal/2013-12-09	§ 10.4.1: требование моделировать материальные и информационные объекты процесса; § 10.3: спецификация входов и выходов
The TOGAF® Standard, 10th Edition (открыть)	стандарт корпоративной архитектуры	The Open Group	Architecture Content, гл. 1: deliverable и artifact как продукты архитектурной работы
ArchiMate® 4 Specification (открыть)	спецификация языка моделирования	The Open Group, 2026	Пп. 8.3.1, 8.4.1, 9.3.1, 10.3.1, 10.3.2, 12.2.2: определения Business Object, Product, Data Object, Artifact, Material, Deliverable. Пп. 14.1–14.2: профили и специализация концептов
The Open Group IT4IT™ Reference Architecture, Version 2.1 (открыть)	референс-архитектура	The Open Group, 2017 (C171)	Разд. 3.4.2: деление объектов данных на ключевые и вспомогательные по роли в управлении жизненным циклом; разд. 2.5 и 4.2: объекты данных как входы и выходы функциональных компонентов; разд. 2.8: система-источник достоверных данных. Редакция 3.0.1 (2024) не проверялась
Product-Based Workflow Design (открыть)	научная статья	H.A. Reijers, S. Limam Mansar, W.M.P. van der Aalst, Journal of Management Information Systems 20(1), 2003	Академический прецедент проектирования процесса от спецификации продукта
Automatic Support for Product Based Workflow Design (открыть)	доклад в рецензируемом сборнике	I. Vanderfeesten и др., в кн.: OTM 2010 Workshops, ред. R. Meersman, T. Dillon, P. Herrero, Springer, Berlin, 2010	Развитие PBWD до автоматического вывода модели процесса
Data Mesh Principles and Logical Architecture (открыть)	авторская архитектурная концепция, публикация в блоге	Zhamak Dehghani, 3 декабря 2020	Принцип «данные как продукт» и потребитель данных как клиент
ГОСТ 15467-79 - Управление качеством продукции. Основные понятия. Термины и определения (открыть)	межгосударственный стандарт	Госстандарт СССР, 1979, с Изм. № 1 1985 г.	П. 48: брак как продукция; пп. 49–50: исправимый и неисправимый брак; справочное приложение: продукция как материализованный результат процесса труда
Directive 2008/98/EC on waste (открыть)	нормативный правовой акт	Европейский союз, консолидированная редакция от 18.02.2024	Ст. 5(1): побочный продукт и четыре условия его признания
ГОСТ Р ИСО 19440-2010 - Интеграция предприятия. Конструкции для моделирования предприятий (= ISO 19440:2007, IDT)	национальный стандарт	Росстандарт, 2010	П. 3.1.65: продукт определён через бизнес-процессы предприятия, побочный продукт внутри определения. Редакция 2007 г.; ISO 19440:2020 не проверялась
ANSI/ISA-95.00.01-2010 - Enterprise-Control System Integration, Part 1 (IEC 62264-1 Mod)	американский национальный стандарт, модифицированное принятие IEC 62264-1	International Society of Automation, 2010	П. 6.5.11: результаты производства учитываются как продукты, побочные и сопутствующие продукты и брак (scrap), с отнесением затрат по каждому
A Guide to the Project Management Body of Knowledge (PMBOK Guide), седьмое издание	свод знаний	Project Management Institute, 2021	Глоссарий: продукт как артефакт, который может быть и конечным изделием, и составной частью
Business Artifacts: A Data-centric Approach to Modeling Business Operations and Processes	научная статья	D. Cohn, R. Hull, IEEE Data Engineering Bulletin 32(3), сентябрь 2009	Определение бизнес-артефакта; artifact-centric BPM как предшественник
Business artifacts: An approach to operational specification	научная статья	A. Nigam, N.S. Caswell, IBM Systems Journal 42(3), 2003	Исходная работа направления artifact-centric BPM; полный текст за платным доступом, в статье не цитируется
ГОСТ Р ИСО 9001-2015 - Системы менеджмента качества. Требования (= ISO 9001:2015, IDT)	национальный стандарт	Росстандарт, 2015	П. 8.7.1–8.7.2: управление несоответствующими результатами процессов и состав регистрируемых сведений
DEMO Specification Language (DEMO-SL), version 4.7.2	спецификация языка моделирования	Enterprise Engineering Institute, год в документе не указан	Разд. 7.1: Transactor Product Table - по одному виду продукта на вид транзакции, формулировка факта в перфекте
ГОСТ Р 56020-2014 - Бережливое производство. Основные положения и словарь	национальный стандарт	Росстандарт, 2014	П. 4.11: waste переведено как «потери» и означает действие - терминологическое расхождение, оговорено в разделе 6
The TOGAF® Series Guide: Business Capabilities, Version 2 (открыть)	руководство к стандарту корпоративной архитектуры	The Open Group, действующая редакция 2025 г. (G211)	Разд. 2.1.1: способности устойчивы, а оргструктуры нет - конкурирующий довод, разобран в разделе 8
«Продукт как объект корпоративной архитектуры - терминологическая матрица» (открыть)	рабочие материалы исследования	автор, 2026	Стресс-тест, контрольная выборка из сорока результатов, пограничные случаи, правила модели

Ссылки на ISO ведут на карточки стандартов в каталоге: полные тексты распространяются по лицензии.