DRAKON.SU

Да, и квалификация, видимо, определяется через описания техопераций (процессов), которые должен реализовать исполнитель (при заданной конфигурации РМ - напр., составе и свойствах тех же мединструментов). С учётом взаимодействия с предыдущим/последующим переделами, с одной стороны, и с членами коллектива, сотрудничающими на том же переделе (если это предполагается) - с другой. Так?

Всё правильно, но помимо этого... Кроме ГОСТов, были ОСТы (отраслевые стандарты) и ТУ (технические условия, которые разрабатывались непосредственно на предприятиях), но всё это согласовывалось и утверждалось... Кстати, в развитых странах то же самое. Если, например, какое-то предприятие задумает выпускать флэшки, оно должно будет пройти сертификацию на данный вид продукции, иначе эта продукция не сможет попасть на рынки развитых стран легальным образом.
Почему органы стандартизации, сертификации и метрологии должны быть на государственном или межгосударственном уровне? Потому что это часть механизма арбитража/разрешения конфликтов, о которой мы как-то говорили. Два или более элементов системы могут вступать в конфликт (за доступ к ресурсам, например), и тогда необходим механизм разрешения противоречий не в пользу одной из сторон, а в пользу/наименьший ущерб для системы. Все эти ГОСТы и справочники, в таком случае, ничто иное, как словари определений.
В данном случае говорят, как правило, о производственной мощности (ПМ), понимая под этим: человек или человек + оборудование, или оборудование или несколько человек (бригада), или бригада + различное оборудование или различное оборудование (автоматы/роботы/автоматические манипуляторы). Потоки работ распределяются по ПМ. Если посмотреть на сменно-суточное задание, выдаваемое на ПМ, то это и есть "меню" из тех работ, которые надо выполнить в указанном периоде времени (сутки/смена). Планирование работ обычно начинается с определения оптимального размера партии продукции, далее полученные партии "проводятся" по тех.процессу, получая приближенные затраты времени на выполнения операций. Потом на основе тянущей или толкающей методики планируется привязка операций к конкретным временам и участкам (к конкретным ПМ, с учётом больничных, ремонтов и норматива запаса времени). Наконец, получается план-производства (частный случай - объёмно-календарное планирование). А уже из него формируются сменно-суточные задания на участок/бригаду/рабочего с оборудованием или без оного/на оборудование с человеком или... без оного.
Из всего этого следует, что неважно... один исполнитель или много... суть планирования и исполнения не меняется. Да, дифференциация оплаты в бригаде/на участке может происходить на основе квалификационных коэффициентов, на основе коэффициентов трудового участия (КТУ) (вложенного труда) или на основе агрегированных коэффициентов.

Да, конечно.
Взаимодействия с другими переделами лучше формализовать и снизить до минимума. В противном случае, велика вероятность размывания ответственности... Каждый должен отвечать за своё дело, за свой участок работ, иначе начнутся ссылки на тех, что раньше или на тех, кто позже. Виноватого будет не найти... а значит, устранить проблему будет невозможно.

Второе предположение/допущение избыточно и некорректно. Именно такое допущение порождает болезнь современной науки под названием... редукционизм.

Ну вот. А вы говорили... Для выхода на широкий рынок сертификацию они вынуждены проходить не только на вид продукции, но и по ИСО 9000, предполагающую использование процессного подхода.
Вот и приходится описывать свои процессы.
Как описывать процессы там не говорится. Вот и делают это всяк на свой лад.
Цель благая - любой новый работник (соответствующей квалификации) должен легко что он должен делать, какие инструменты при этом использовать, и что, и главное какого качества, должен получить на выходе. А кроме того куда передать.
Работник более высокого ранга должен видеть всю цепочку, иметь критерии оценки и возможность производить корректирующие воздействия.
Графическое описание процессов не является достаточным условием, но оно необходимо.
Я понимаю, что нужен вдумчивый подход. Можно назвать это описание технологическими картами процессов.
Тот же мед работник, из злосчастного примера, должен быть предварительно зафиксирован в глоссарии с указанием требований к его квалификации. И многое другое тоже нужно описывать.
Я как раз таки и пытаюсь определить сферу применимости ДРАКОНА в этой сфере.

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

ИСО 9000 - это для бедных. Никто в мире серьёзно этим не озабочен. Руководство ИБМ неоднократно признавалось в том, что проводит регулярные анкетирования и рисование бизнес-процессов не для какой-то мифической стандартизации, а исключительно в качестве "домоклова меча" над головами "голубых воротничков" (расслабишься и... выпадешь из "бизнес-процесса"... на улицу).
Здесь много было возмущений по поводу профанации образования. ИСО и иже с ним современные методики управления - это та же профанация управления (с теми же целями и аналогичными средствами). Есть у меня такая примета (можете на досуге проверить): если приходишь в организацию и на самом видном месте видишь вывешенную "миссию предприятия", - вы попали в филиал дурдома... к добровольной и доверчивой жертве лохотрона.
Это - да... редкостный разгул самодеятельности... Но вопрос не в том... описывать или нет... Если исходить из сути предприятия, то "бизнес-процессы" формируются сами собой... гарантировано правильно. Совсем другое дело, когда ходят собирают информацию, а потом пытаются из всего этого... составить нечто цельное. Один рисует так, другой эдак... самодеятельность...
Передать - это да... На хорошем предприятии людям работать интересно, они спорят, ищут, внедряют и получают удовлетворение (не только материальное)... Приезжают консультанты... видят, что всё хорошо и люди довольные, улыбаются. Срисовали... Приезжают на другое предприятие и доходчиво объясняют, что если хотите, чтобы у вас всё было "ОК" надо часто и широко улыбаться... Вот так передаётся опыт успешных предприятий... Вы не разу не видели "деревянных" и очень широких улыбок?..
Угу... только в случае, если "цепочка" не слишком кривая, а то ведь и коррективы не будут прямее. А кривизну "цепочки" чем померяем?..
Главное, чтобы суть была... и была понятна... всё остальное вторично.
Не надо придумывать названия, ярлыки... если говорить о вдумчивости...
"Многое" - это слишком размыто: есть три базовых сущности: предмет труда, средства труда и живой труд. Вот требования к ним должны быть прописаны (с учётом того, что средства труда и сам труд могут быть основными и вспомогательными).
... думаю, сфера применимости Дракона в этой сфере должна быть... сферической...
Да, не за что... захотите подумать... приходите ещё...

Может что-то вроде этого ...

Я думаю, что Лучше исполнителей по шампуру размещать. Документ, например, слева. А основополагающие документы (руководство к действию для исполнителя) в подвал к исполнителю.
Вообще все руководства к действию, т.к. не только документы могут разрабатываться (в том числе и критерии оцеки), помещать в третью секцию.
Получим икону: исполнитель-действие-руководство.
Непонятные по названию документы и требования к квалификации исполнителя описываем в глоссарии (может быть на ГНОМе)

А идея с таймером хороша.

P.S. если исходник сделан в OpenOffice.org, то можно исходник выкладывать тоже? Что бы в нем и править

ИМХО то, что написано уважаемым топикстартером - совсем не процесс РАЗРАБОТКИ учебной программы.
А бюрократический процесс принятия решений.
Насколько я понимаю, на первой вертикале-шампуре - самая ГЛАВНАЯ ветка? Тогда непосредственно процесс разработки показан как не очень важный процесс - только на третьей ветке...

Как я понял, в итоге вообще все данные об орг[тех]процессе, описанные, скажем, в этом посте ("актив-сущность" - в данном топике синоним "исполнителя"), снова предлагается представить на одной схеме в режиме постоянного отображения... Эргономично ли?..

Угу. Свести к передаче предмета труда между ПМ-единицами (представленными вершинами актив-схемы; передачи на ней представлены метками связей).
В общем, ОПУП рулит...

Если не ошибаюсь, Владимир Паронджанов рекомендовал использовать первую вертикаль вообще для описания задачи.
В общем, сарказма не улавливаю : )

Для того рисунки и представляются, чтобы определить
эргономично ли, удобно ли, понятно ли, соответствует ли ... : )

Высказывайте свое мнение.

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

Всё понятно, что нужно проектировать, и проеЦировать из понимания цели и "сути" предприятия.
Но непонятно: а что, при проектировании фиксировать в какой-то форме это не нужно?
Формируются сами собой... ну а зафиксировать потом на бумаге то, что сформировалось, что, не нужно?

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

Подумалось...

Если посмотреть на все эти "рабочие инструкции", "описания процессов", то можно увидеть, что там большая часть может быть автоматизирована. Т.е. человек, при хорошей информатизации предприятия, не должен помнить, в каком порядке и что ему надо сделать, чтобы не нарушить регламенты. Хорошая АСУ должна в каждый момент времени показывать соответствующее "рабочее поле" с информационными объектами, человек должен принимать решения (только решения! а не следить за тем, чтобы не нарушить порядок действий), система должна переходить дальше по маршрутам процессов.
Именно так работает руководитель, у которого хорошо поставлено дело и есть хорошие помощники. Ему не подадут на подпись бумагу, в которой что-то не по правилам или ещё не выполнены те фазы, которые требуются раньше. К нему приходят за решениями, а уходят с заданиями.

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

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

Может так представить?

Причем теперь, при правильной формулировке задачи, документ уже не так уж и нужен