Соглашусь с г-ном Шустером насчет ИСР.

Построить ИСР, даже в такой области как строительство (вроде все просто) - скорее искусство, нежели чем набор правил.
В принципе все понятно, но как только идем в детали - то все непросто

На рисунке 12 показано, что общее задание КТО распределено между тремя конструкторами, внизу конкретное задание одному из них. Отметим переход ответственности: тот, кто отвечал за разработку КД (главный конструктор) теперь является куратором всех заданий, у каждого из которых свой ответственный




Рисунок 12

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

Андрей Фефелов пишет: Построить ИСР, ... как только идем в детали - то все непросто

В принципе, все, что я до сих пор излагал, ни что иное, как построение ИСР
Есть только терминологическая разница. Я применяю термины РМ (операция, узел, график) для процессов, считая, что между ними нет никакой разницы

Согласен.
Читаю внимательно. Наконец-то скриншоты ПО про которое много слышал, но не видел.
Интересно

Про классификацию и ИСР можно спорить, но потом или в отдельной теме.
По сути все ок

Ранее говорилось, что на Рисунке 10 в процессе имеется очень хлипкая операция 2) "Обеспечить технической литературой" подпроцесса "Разработка КД" (она же операция 1322 на рисунке 11). В задаче спрашивается, можно ли с помощью процессного подхода сделать ее более надежной и как?

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

Что нужно для получения хорошей конструкции?
1) талантливый конструктор
2) его понимание, что должно получиться на выходе
3) вся необходимая информация

Что из перечисленного вообще подлежит управлению, т.е. может быть улучшено через СМК? Вряд ли первое, это дело случая, удачи. Второе довольно хлипко, хотя небезнадежно. Остается точно - третье.
Я много видел архивов и технических библиотек, в т.ч. в космическом приборостроении. Там литературы масса, при этом масса же древних справочников. Но и там нет никаких гарантий, что необходимая литература существует а) вообще б) в этой библиотеке или в) в доступных библиотеках. Кроме того, важнейший вопрос, на который нет ответа в библиотеке - нормативные требования к продукту, ссылку на которые должен дать заказчик, но делает это крайне плохо и ненадежно.
Как правило, поиск и заказ литературы - личное дело конструктора, его компетентность. Но я не думаю, что это очень правильно и полностью решает задачу. И уж точно в такой постановке вопроса СМК отдыхает.

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

Как складывается информационное обеспечение предприятия:
1) Есть архив, исторически сложившийся. Есть какой-то поисковый аппарат
2) Свободный доступ к интернет
3) Раз в год отделы заказывают периодику по каталогам
4) Предприятие подписано в Магазине стандартов
5) При переписке и изучении документации заказчиков обнаруживаются недостающие документы
6) Некоторые из недостающих документов удается добыть, в т.ч. неподдерживаемые копии
7) Свежие веяния привозят с выставок и презентаций, что-то оседает в архиве или на рабочих столах
8) Что-то нужное могут подсказать дядя Вася, Сергей Петрович и Давид Яковлевич

Если большинство этих элементов представлены-всех все устраивает. Зачем что менять?
В нашей отрасли красной нитью везде проходят слова "нормы, правила и стандарты по безопасности АЭС". Перечень этой хрени собран в талмуд 4 см толщиной - таймс 12, нормальный, интервал 0 и ищи где хочешь, что сможешь. То же в России-покупной диск, но с текстами (это очень круто и недорого).
В чем проблема - лучше покажу на примере
Когда-то раздел "Обязан знать" моей должностной инструкции представлял собой перечень в 27 листов тем же таймсом 12. Раздел этот формировался, как намывается остров в океане - из подручных материалов различными течениями и прочими кораллами инспекторской мудрости. Польза с того была одна - тебя любой мог отыметь на экзаменте по специальности, раз в три года
Но был еще за спиной шкаф с бумагами, не знать которые было себе дороже. А среди них-еще бумаги, которые стоит иногда повторять перед сном. Иными словами - селективность

Разница в том, что потребный объем знаний оператора об атомном блоке конечен и не меняется, разве что модернизацию какую проведут иногда. Но конструктор - это ведь совсем другое дело! Самая типовая проблема - когда конструктор должен сделать нечто "согласно норм, правил и стандартов по безопасности АЭС", а перед ним талмуд в 4 см таймс 12. А в библиотеке из всего талмуда 3 левые брошюрки, и все ли там листы - еще вопрос. Порыли - еще две принесли и одну прислал заказчик от щедрот.

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

Прикол в том, что все требования, применимые к данному изделию, надо знать.
А как?
Вот вопрос!

Решение указанной проблемы одно: поручить ее человеку, который способен с ней справиться и дать ему возможность хорошо приложиться (собственно, это касается любой проблемы). Переходя на высокий штиль, это означает, открыть проект. Штилем пониже это называется "Мероприятие по улучшению". Штилем ИСО это "Планирование качества"

Применительно к данной статье, это значит добавить еще один внутренний заказ (проект) в раздел "Инфраструктурные проекты", как показано на рисунке 8. Как решать именно эту задачу я, может быть, расскажу позже - решал сам и видел, как это делали другие. Но не суть. Главное, что в для получения системного результата, нужно решить еще две задачи:
1) преобразовать результат в продукт, пригодный для всеобщего многократного применения
2) сделать этот продукт самоподдерживающимся, т.е. дополнять его по каждому прецеденту
Задача №2 - "чистая" задача СМК

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

Итак, разработка справочника - проект. Организация самоподдержки - процесс
Относится ли данный процесс к выпуску данного продукта - конечно, нет. Выходит, операция 1322 на рисунке 11 лишняя. Хотя к ней можно привинтить процедуру заказа-получения (например, когда какие-то справочники нужно купить или украсть)
Так куда же всунуть процесс самоподдержки справочника и как он должен выглядеть? Ведь если его не будет-через пару лет прежнее состояние гарантировано вернется

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

Навскидку, одна из схем решения:
1) В окончательных документах (КД, ТД и др) есть раздел "Нормативные ссылки", куда появившийся документ попадет с вероятностью 95%. Там его и нужно отлавливать
2) Конструктор сдает свои разработки архиву, который может отказать в их приеме по заданным условиям
3) Конструктор должен сдать архиву все новые документы, которые добыл, работая над каждым проектом. Одно из условий сдачи - заполненная и подписанная конструктором карточка, позволяющей архиву правильно классифицировать эти документы и описать в информационно-поисковом аппарате
Для такого решения необходимо:
-Разработать условия приемки КД и довести их до конструкторов и архива
-Задание на разработку КД (11011-11013 на рисунке 12) считать не выполненным, пока карточка НД не принята архивом
Можно сказать, что это пример "встраивания качества" в процесс

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

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

Рисунок 13

1. Действующие заказы. Здесь находятся графики исполнения каждого конкретного заказа, расписанные, как было показано ранее. Планирование ведется набегающей волной
2. На выходе. Это графики исполнения заказов по договорам, близким к заключению. Здесь мы планируем операции, которые имеет смысл начать с опережением, не дожидаясь формального договора
3. В проработке. Это будущие графики будущих заказов в разной степени проработки, включая просто фантазии. Это планирование маркетинговой работы. Графики каждого из будущих заказов имеют совсем другую структуру, чем действующих. ИСР в данном случае - это проект (со стандартизованными элементами), смысл операций которого - что сделать, чтобы фантазия сбылась. В графике может быть задействована хоть вся структура предприятия, если нужно - а иногда нужно и так
4. Внутренние заказы - это проекты улучшений, типа приведенного примера с нормативными документами. Система качества должна работать на то, чтобы здесь постоянно появлялись новые проекты и чтобы они были самые необходимые из всех возможных. Кроме того, здесь находятся проекты НИР и ОКР, освоения производства продукции, на которую пока нет покупателей (если это присуще данному производству). Кроме того, через эти внутренние заказы одни подразделения планируют работу других (например, конструкторский отдел управляет процессом инвентаризации архива, задавая направления ревизии)
5. Инфраструктурные - это процессы, запускаемые по отдельному графику - обучение персонала, техобслуживание и ремонт, модернизация. В принципе, это те же внутренние заказы, разница между ними чисто косметическая
6. Финансовые - это отдельные проекты, когда средствами производства являются не станки, а деньги. Если у предприятия есть лишние деньги - оно их крутит. Бывает и так

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

Скажем, на вопрос "где новые заказы?" отвечаем "а что делается, чтобы они появились?" Если у нас в разделе 3 ничего не запланировано, то откуда они возьмутся?

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