То же самое, но в другом (прикладном) интерфейсе
Вот "изделие", т.е. заказ в виде спецификации узлов, которые надлежит изготовить



Рисунок 3

Время на изготовление, скажем, 9 месяцев с даты открытия заказа производству
На рисунке показан план, относящийся к спецификации приведенного выше заказа
На первом уровне плана это выглядит так



Рисунок 4

Здесь и далее важно читать содержимое колонок.
Процессы 10 и 20 соответствуют процессам "Изготовить изделие" и "Купить комплектующие" на первом рисунке
Процесс "Купить материал" для планирования недоступен из-за отсутствия данных

Разделим спецификацию на две части. Для этого добавим к заказу документ "Закупка по кооперации" и перенесем в него из основной спецификации все позиции, которые необходимо закупить. Все, что осталось - надлежит изготовить самостоятельно
На рисунке показан добавленный документ (на нем стоит курсор, обведен красным) и его спецификация из трех узлов. Спецификация узлов, изготавливаемых самостоятельно, на экране (рисунке) не видна



Рисунок 5

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



Рисунок 6

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



Рисунок 7

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

Получается, самая лучшая MES оптимально грузит производство, подхватывая весьма неорганизованный выхлоп смежных процессов. Как бы хорошо не работала исполнительная система, она задавлена GIGO - Garbage in, garbage out. Поэтому эффективность производства задается входом - организацией подготовки производства - или обеспечением. Еще на эту тему мне нравится выражение "Мобилизация - это и есть война". То есть, наука войны невозможна без искусства мобилизации ресурсов. Чтобы использовать войско, нужно его иметь в нужное время, нужном месте, количестве и оснащенности

Недавно на эту тему попалось про связь между PQ17, Сталинградом и ценой солярки для Тирпица. Редер просил у Гитлера 6 тыс тон топлива и тот в конце концов согласился. В результате до Сталинграда не дошло 430 танков, 210 самолетов, 3350 автомобилей и почти 100 тыс тонн прочих грузов, в основном - для военной промышленности СССР.

Вернемся к начальному рисунку в виде схемы, группа процессов, которые запускаются по графику. Поскольку эти графики не имеют никакой связи с планируемым заказам, их планируют и выполняют отдельно, в другом разделе плана. На рисунке - это раздел "Инфраструктура" (название-прямо как пункт 6.3 ИСО)

На закладке "Спецификация" показан список объектов применения процедуры, на которой стоит курсор - в данном случае "Техническое обслуживание и ремонт технологической оснастки"



Рисунок 8

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

Раскроем одно из направлений деятельности, скажем, 21401 Модернизация. Пусть она выглядит так:



Рисунок 9

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

Если посмотреть на другие сроки (Обучение, Ремонт и др), разве в них есть какие-то отличия со строкой "Модернизация"? То есть, все, что находится в разделе "Инфраструктура", подлежит управлению по правилам управления проектами. Для такого управления очень много чего есть: программное обеспечение, учебники, специалисты, семинары и т.п. Конечно, в РМ полно своих проблем, но я не хочу на них останавливаться. Основная мысль в том, что РМ - совершенно конкретная область, в отличие от СМК, ТПС, БСЦ, Лин и т.п. И используя недокументированные возможности РМ можно применить его для управления в самом широком смысле этого слова

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

Вернемся к графику подготовки к выполнения заказа на рисунке 7 и возьмем одну операцию "13 Разработать КД", она же процесс разработки конструкторской документации. Декомпозируем (разобъем) ее на простые операции или, как сказал Игорь, "разработаем ИСР":
1. Выдать исходные данные
2. Разработать ТЗ на изделие
3. Разработать комплект чертежей
4. Разработать проект ТУ и методику испытаний

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

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

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

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

Допустим, в результате мы сформулировали четыре проблемы:
1) Поскольку инвентаризация архива не окончена, неизвестно наличие чертежей-прототипов
2) В чертежах имеются досадные ошибки
3) Иногда производство работает не по тем чертежам, что надо
4) Конструктор может украсть чертеж и продать его конкурентам

Допустим, мы придумали такие решения по предупреждению проблем:
1) Инвентаризацию архива вести в привязке к планам разработки КД. Формировать внутренние заказы на разработку КД под перспективные заказы. Результатом считать раскрытые спецификации и сканированные копии
2) Доработать систему согласования. Архиву проводить нормоконтроль перед учетом. Задание на разработку чертежа считать выполненным только после его учета архивом. Сдавать вместе с файлом.
3) Изъять все чертежи, закрыть доступ к электронным копиям. Архиву выдавать только учтенный экземпляр под роспись. При внесении изменений учитывать версию, как в п. 2), изымать измененные экземпляры
4) В результате 1-3 конструктор может украсть только те чертежи, что даны ему в работу и которые разработал сам. Поэтому узел в целом должен разрабатывать лично главный конструктор. Часть чертежей не имеет той ценности, если такие потери будут, с ними проще согласиться

В указанных 4-х проблемах и их решениях в том числе учтены подсказки ИСО9001, которые даже для приведенного уровня проработки вопросов по детски просты:
1) Работа должна делаться по документам
2) Документы необходимо разрабатывать по правилам
3) Документы должны быть разработаны, подписаны, согласованы и утверждены
4) Изменения должны быть оформлены так же, как сами документы
То есть, прорабатывая процесс, мы тем самым удовлетворили требованиям ИСО, даже когда понятия о них не имеем. Как господин Журден, говорящий прозой.

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

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

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

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



Рисунок 10

PS: Обращаю внимание, в данном процессе очень хлипкая операция 2) "Обеспечить технической литературой" подпроцесса "Разработка КД". Она требует отдельной проработки, собственного подпроцесса

РPS: Слова "процесс", "подпроцесс", "надпроцесс" употребляются, когда нужно обозначить отношения между процессами разного уровня. В обиходе, на любом уровне допустимо использовать термин "процесс"

В машиночитаемом виде рисунок 10 будет выглядеть, как показано на рисунке 11



рисунок 11

Операция "1101 Разработать КД" (вверху) детализирована отдельным документом, содержащим график ее выполнения (внизу). График содержит конкретные задания и сроки конкретным подразделениям. "Центральная" операция графика - собственно "разработать КД" на графике, как видно, отсутствует.
Зато есть 1321 Формировать задания конструкторам. Как мы помним, на закладке "Спецификация" содержится довольно много узлов и деталей, на которые нужно разработать КД. Расписать их по конкретным конструкторам, чтобы обеспечить специализацию и ровную загрузку - отдельная задача, за которую отвечает главный конструктор. Данный рисунок на ней заканчивается

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