Как и в случае производства информационных объектов (программирования/моделирования/онтологизирования), я бы делил производство физических объектов (и сервисов как производство физических объектов, оказывающих эти сервисы) на производство-в-малом и производство-в-большом (production-in-the-small, production-in-the-large), при этом включая сюда не только собственно производство, но и проектирование с инжинирингом.
Производство-в-малом -- это когда группа людей, имеющих общий капитал (запасы материалов и денег, станки, накопленные базы знаний и т.д.) и общую управленческую волю (часто только подразумеваемую, знаем мы "общую волю и единое намерение" пары тысяч человек, в том числе их руководителей), производит что-то, не выходя при этом за границы собственных материальных и людских ресурсов. Условно говоря, производство-в-малом, это "производство внутри предприятия", как "программирование-в-малом" относится к созданию одной программы, которая исполняется, как в классической драме, с соблюдением единства времени, места и действия. Когда же единство времени, места и действия обеспечить уже нельзя, то мы переходим к программированию/моделированию/онтологизированию-в-большом.
Тем самым, когда мы говорим о том, что комплектующие/предметы снабжения и готовые изделия (которые где-то будут комплектующими или предметами снабжения) пересекают границы предприятий, то речь идет уже о производстве-в-большом. И программирование корпоративных информационных систем, которые это поддерживают в плане обмена информационными моделями данных физических объектов (спецификациями, чертежами, технологической документацией и т.д.) и другими информационными артефактами (планами, прогнозами, заказами этих физических объектов и т.д.) является программированием-в-большом.
Успешное программирование-в-большом на сегодня реализуется как обмен сообщениями между акторами. Как и в случае программирования (в котором интернет рассматривается как практически единственный успешный и масштабный пример программирования-в-большом), и моделирования (эта тема только-только начинает подниматься группой AtlanMod с их понятием мегамодели), мы можем представить производство/инженерию, осуществляемые сетью независимых акторов, которые ведут собой обмен сообщениями (информационными объектами -- коммуникацию) и продуктами/сервисами (физическими объектами -- логистика), и это происходит согласно каким-то программам/планам и графикам, передающимся в контрактах.
Это классическое объект-ориентированное программирование, если отвлечься от того, что контракты нужно заключать. А с кем их заключать обычно непонятно, и происходящее потом существенно зависит от того, с кем этот контракт заключен. Поэтому акторское программирование тут более адекватная метафора. Впрочем, это неважно, ибо развитие данной темы оставит в обсуждении только тех, кто сможет поддержать разговор про объект-ориентированное и акторское программирование, а мы добиваемся другого: нам нужно показать "на пальцах", как это всё функционирует, без отсылки к каким-то теориям.
Итак, складывающаяся на сегодня капиталистическая производственная система, замешиваемая на корпоративных информационных системах, общающихся между собой через границы организаций, представляет из себя что-то типа "интернета комплектующих/предметов снабжения" -- сложной производственно-коммуникационно-логистической системы отдельных производственных и транспортно-коммуникационных предприятий, связанной в единое/интегрированное/общее целое стандартами. Стандарты (в том числе Гражданский Кодекс или его аналоги в других странах, но также и множество других -- например, стандартов ISO или даже стандартов IETF, раз мы уж помянули интернет) определяют собой правила обменов материальными и нематериальными сообщениями между акторами.
Поскольку любому перемещению физических объектов сопутствует информационный обмен (нет информации -- контракта, накладной, адреса доставки, позиции в каталоге и т.д. -- физические объекты, быть может, и производятся в порядке "производства-в-малом", но дальше оседают на складе и не перемещаются), то кроме логистики появляются соответствующие информационные дисциплины, ответственные за это "программирование масштаба больше предприятия" -- прежде всего работа с мастер-данными [опустим тут длинную дискуссию о переводе master на русский]. Мастер-данные как раз и определяются как данные, которые приходят откуда-то извне, но хранятся и используются затем везде внутри предприятия (впрочем, понятие это довольно расплывчато, ибо внутри одного предприятия тоже полно мест, где данные из соседнего подразделения справедливо считаются пришедшими извне, и чуть ли не от врагов). Если делать акцент на "использовании мастер-данных внутри предприятия", то можно порождать огромные тексты типа http://www.iteam.ru/publications/it/section_88/article_3074/ -- в этом компоте разве что CAD не хватает, а ведь в САПР мастер-данных тоже используется ой-ой-ой сколько!
Но оставим сейчас вопросы разбирательства с мастер-данными внутри предприятия (хотя этим тоже придется заняться) и применим системный подход: поглядим, откуда и для чего приходят мастер-данные, и кому они уходят -- при этом просто проигнорируем регуляторов и организации стандартизации как производителей данных нормативов и потребителей данных отчетов. Нас интересует собственно проектирование и производство в условиях разделения труда между предприятиями.
Дело в том, что внутри предприятия вы можете сами придумать формат обмена сообщениями о продуктах/сервисах, а вот между предприятиями (особенно, ежели их задействована пара тысяч, как в случае проектов кораблей, атомных станций, космических аппаратов и т.д.) вам нужно будет договориться о стандарте. И этот стандарт реализовать в соответствующих корпоративных информационных системах.
Сейчас мировая товарно-сервисная производственная сеть (и соответствующая этим товарам/сервисам сеть информационных моделей товаров/сервисов) при сравнении с интернетом напоминает мне ситуацию 1987-89 года: уже есть LAN (local-area networks), хотя и не на всех предприятиях, и весьма разные (Ethernet к этому времени еще всех не съел), а WAN (wide-area networks) представлен огромным числом крошечных сетей, каждая на своём протоколе и оборудовании. Интернет (как набор протоколов TCP/IP) тогда уже был, но до словосочетания "интернет -- это сеть сетей) дело дошло только через несколько лет. А потом про "сеть сетей" как-то забылось, ибо практически все протоколы стали TCP/IP. Особо нужно отметить, что все регулирующие органы и промышленные политики всех стран в те поры строили на основе семиуровневой архитектуры сети X.400, которые и должны были бы по замыслу Мировой Закулисы стать Всемирной Глобальной Сетью, но (как это часто бывает с государственными начинаниями) как-то так само собой получилось, что стандарт TCP/IP съел стандарт X.400 (и еще пару десятков аналогичных по назначению, но различающихся способами реализации) с потрохами.
"Подключить компьютер к интернету" явно не решало проблем предприятия. Обычно проблемы решались, когда к интернету подключалась сразу локальная сеть (которой на тот момент могло еще и не быть), и тем самым "любой компьютер" становился частью интернета. Так и тут: пока не решены проблемы с мастер-данными внутри одного предприятия (аналог -- не внедрен LAN), решить проблему обмена мастер-данными с другими предприятиями (аналог -- подключиться к WAN) представляется невозможным.
Когда мы говорим про логистические цепочки физических товаров, то нас пока не будут волновать пакетные перевозки (контейнеровозы и т.д.). Нас будут волновать пока обмены информационными моделями этих товаров. Ибо перед тем, как какой-то товар X поедет в другой город, чтобы встать в изделие Y, а оно поедет еще куда-то, чтобы лежать на складе запчастью к продукту Z, соответствующие конструкторские бюро должны будут обменяться содержательными моделями этих комплектующих (CAD-часть) для попадания этих комплектующих в чертёж ("выбор оборудования"), а снабженцы должны будут обменяться моделями-спецификациями (ERP-часть) для выбора поставщика, заключения контракта и контроля этого контракта исполнения. После того, как готовое изделие будет передано конечному потребителю, он тоже бы хотел получить доступ к этой информации -- для ремонтов, модернизаций и т.д.
Итак, у нас сейчас есть огромное число стандартов, в терминах которых мы обмениваемся моделями продуктов и информацией об их закупках -- причем отдельно в двух сегментах: между разными CAD, чтобы учитывать чужие компоненты при проектировании, и между разными ERP, чтобы учитывать чужие компоненты при заказе-выдаче в монтаж-эксплуатации.
Если говорить содержательно, то прежде всего интересуют стандарты трансакций (проведения сделок, отслеживания партий товара и т.д.), каталогов промышленной продукции, классификации/таксономии на группы и классы товаров/сервисов, словарей для нивелирования разницы в терминологии и национальных языках. Это базис, на котором вырастает промышленный интернет. Ну, и нужно учитывать, что в этих каталогах (в отличие от бумажных каталогов) запросто может найтись трехмерная модель, математическая модель гидравлической системы, инструкция по монтажу, сборке и обслуживанию, и вообще всё-всё-всё. Каталог это должен уметь представить.
Сегодня нет никакой "сети сетей", а есть сплошные локальные -- а хоть и уровня странового, подкрепленного Аж Самим Нашим (вариант: Ихним) Правительством, или отраслевого, подкрепленного авторитетом Международной Отраслевой Ассоциации -- поделки, масштабируемые в весьма и весьма малой степени. Вот эта картинка давно устарела:
Сегодняшний вариант картинки будет не лучше, ибо много стандартов из этой картинки уже померли, но ведь и новые народились -- например, никто не ожидал, что NATO заплатит много-много денег самым разным организациям, чтобы вывести свой периферийный в момент рисования картинки AC/135 механизм под современным именем ISO 22745 близко к центру сегодняшней картинки!
Из этого болота движение идет по следующим направлениям:
а) создаются новые стандарты, которые надеются захватить мир за счет каких-то особых новых качеств (стандарты "электронной интернет-коммерции", которым несть числа и которые считают, что слово XML является волшебной отличительной характеристикой).
б) происходит переход с менее популярных "тяжелых" старых стандартов на более популярные и более "тяжелые" свежие (с PLIB на STEP).
в) простые стандарты из одних отраслей начинают использоваться в других отраслях (например, отраслевая ассоциация NATO вдруг решила поделиться своей системой кодификации каталогов продуктов с коммерческим сектором, появился стандарт ISO 22745)
г) стандарты вдруг поддерживаются значимыми игроками, и становятся не только "стандартами де юре", но и "стандартами де факто" (ISO 15926 вдруг поддерживается всеми вендорами CAD/PLM).
Про распространение подхода данного текста на каталоги методов работы (ибо разбирательство с методами работы на предприятиях является прямой темой PraxOS) см. http://community.livejournal.com/praxos/9600.html
Дальше нужно будет пообсуждать конкретные стандарты из показанного болота, и их перспективы, но это будет уже в другом постинге.