Процессы и СМК без наукообразия
- Михаил Шустер
- Автор темы
- Не в сети
- Живу я здесь
- Сообщений: 1209
- Спасибо получено: 260
Начало находится здесь: www.leanzone.ru/index.php?option=com_kunena&view=topic&catid=9&id=12938&Itemid=187&limitstart=50
Мне показалось, что из темы про СМК следует отделить тему процессов. Все-таки СМК - это система взглядов, модель, а процессный подход-инструмент для обслуживания моделей. Эффективность инструмента зависит от него самого, от корявости рук, но главное-от цели применения. Перфоратором можно забить гвоздь, но молоток для этого лучше.
Я много встречал работ про процессы и они очень похожи по подаче. Сначала автор вскользь говорит про вещи, которые ему кажутся очевидными и далее переходит к вещам, которые (тоже на его взгляд) несут какую-то ценность. При этом связь между автором и читателем рвется и уже с третьего абзаца читатель видит в работе совсем не то, что имеет в виду автор.
Другой тип работ - я их называю "про крючкотворство" - сводится к садистскому исследованию нюансов там, где читателю неизвестны даже первоосновы. Это вредоносное направление т.к. нормальному человеку сразу хочется послать все на фиг, а ненормальный начинает путать луну с пальцем, на нее показывающим и принимать за "систему" то, что является мизерной ее частностью. В народе это называется "за деревьями леса не видать"
В результате такого освещения, получились три лагеря. В первом люди применяют процессное управление не зная, что они применяют процессное управление. Во втором умеют говорить о процессном управлении, но не умеют применять на практике. В третьем умеют и то, и другое.
Проще всего в третий лагерь привести людей из первого и почти невозможно - из второго.
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Дмитрий Стукалов
- Не в сети
- Администратор
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Михаил Шустер
- Автор темы
- Не в сети
- Живу я здесь
- Сообщений: 1209
- Спасибо получено: 260
Есть понятие: "Недокументированные возможности". Их можно извлечь практически из любого продукта. Далее я попытаюсь, как можно применить процессный подхода за счет недокументированных возможностей его ближайших родственников - РМ (проектного подхода) и MRP (производственной системы)
Эти стандарты развиваются в рамках принятых ограничений и я просто свирепею, видя, насколь эти ограничения несправедливы. Вот принято, что РМ хорош в строительных проектах. И если порыть интернет, все, что написано о РМ, сведется или к пересказу РМВОК, или к проектам, близким по специфике к строительным. Молодые специалисты, которым в вузах читали "Управление проектами", пересказывают РМВОК и истории околостроительных проектов. На курсах управления проектами учат тому же.
Но ведь понятно, что любую деятельность можно представить, как проект. И применить к ней документированные возможности РМ, не говоря о недокументированных
Вроде аксиома, что развитие науки ожидается на стыках дисциплин. А попробуйте посерфить на тему "MRP+PM" или любой стык между любыми системами! Найдете один маркетинг, типа "прикупите к САПу Примаверу".
Чтобы состыковать системы, нужно выделить в них общее и отсечь противоречивое. А что делать, если системы построены на разных понятиях? Выходит, и начать нужно с терминов и определений. Но я не собираюсь размахиваться на основы мироздания, поэтому предлагаю сильно упрощенный вариант. Для этого нужно вернуться к истории
Возьмем за отправную точку www.sciteclibrary.ru/gost/Index/29/29934.htm
Выделим основные сущности (слово "технологический" опускаю):
-Материал
-Процесс
-Оборудование
-Операция
-Переход
-Метод
-Документ
-Описание
-Контроль
-Контроль процесса
В РМ те же сущности, только "материал" лучше заменить на "объект"
С ПП сложнее, поскольку стандарта на термины и определения в этой области нет. Любые слова и пояснения к ним являются лишь личным мнением того, кто эти слова произносит - начиная с Хаммера и Чампи. Однако, я не вижу необходимым вводить для ПП какие-то новые ключевые сущности, взамен перечисленных
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Михаил Шустер
- Автор темы
- Не в сети
- Живу я здесь
- Сообщений: 1209
- Спасибо получено: 260
Можно создать сколь угодно сложную модель организации, но есть одно звено, без которого все остальные не нужны. Организация обязана что-то производить: товар, услугу или их видимость, но для этого нужно, чтобы этот продукт был произведен. Дабы не усложнять, пусть она изготавливает нечто машиностроительное. Изготовление продукта включает операции:
1.1 Собрать узел (ИМЯ)
1.1.1 Изготовить деталь (ИМЯ)
1) резать
2) сверлить
3) контролировать
1.1.2 Изготовить деталь (ИМЯ)
1) точить
2) полировать
3) контролировать
1.2 Контролировать узел
То же несложно изобразить в виде квадратиков и стрелочек, а также в любой нотации: блок-схема, дерево Исикавы, EDEF и т.п.; можно нарисовать художественный плакат или демотиватор. Но в данном случае свободы выбора нет, зато есть стандарт ЕСТД и хорошо. Пока мы имеем дело с одним изделием, все исключительно просто и понятно. Сложности начинаются, когда мы переходим от "изготовления" к "производству", от "детали" к "партии", начинаем планировать и оптимизировать.
Производство уже невозможно (нецелесообразно) изобразить в графической нотации ввиду многообразия объектов и связей. Прямая и последовательная логика единичного техпроцесса трансформируется в сложную параллельно-последовательную логистику множеств с заделами и запасами, сохраняясь, тем не менее, внутри нее. Чем сложнее схема - тем сложнее визуализовать ее для понимания; для этого ее упрощают математикой (MES и др), или интерфейсами (канбан и др). Тогда графическая нотация демонстрирует уже не техпроцессы, а какие-то параметры, характеризующие результат их сложной взаимоувязки
Однако, сколь сложными не были бы процессы и взаимоувязка, конечный интерфейс должен быть предельно прост и выглядеть как перечень заданий на каждое рабочее место. Внешне нет никаких отличий между оптимальным перечнем, полученным путем сложных совершенных расчетов и тем, что мастер за минуту состругал на коленке. Они отличаются по качеству - это такая незримая сущность, которую можно прощупать только по умозрительным критериям: скорость прохождения заказов, загрузка станков и т.п. А поскольку сделать это можно только когда задание выполнено, разница между "идеальным" качеством перечня и "как есть" в момент его выдачи мало кого заботит. Впрочем, я не об этом
То есть, имеем первую трансформацию: от процесса изготовления единичного узла в процесс производства продукции. Объект приложения труда при этом не меняется: материал. К перечисленным выше сущностям добавляются другие, необходимые для сохранения контроля над усложнившейся системой: типовая операция, групповой техпроцесс, партия и т.п.
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Ксенчук Евгений
- Не в сети
- Expert
- Сообщений: 1165
- Спасибо получено: 247
Михаил Шустер пишет: Есть понятие: "Недокументированные возможности". Их можно извлечь практически из любого продукта. Далее я попытаюсь, как можно применить процессный подхода за счет недокументированных возможностей его ближайших родственников - РМ (проектного подхода) и MRP (производственной системы)
любую деятельность можно представить, как проект. И применить к ней документированные возможности РМ, не говоря о недокументированных
Михаил, вопрос на понимание.
Методика построения Иерархической структуры работ в PM - это документированная возможность?
А пример недокументированной возможности?
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Михаил Шустер
- Автор темы
- Не в сети
- Живу я здесь
- Сообщений: 1209
- Спасибо получено: 260
1.1 Собрать узел (ИМЯ)
1.1.1 Изготовить деталь (ИМЯ)
1.1.2 Купить деталь (ИМЯ)
1) заказать
2) оплатить и привезти
3) контролировать
Объект приложения труда при этом не меняется: материал. Однако в процессе появляются операции "из другой оперы", выполняемые другими подразделениями и на другом "оборудовании", которое к тому же обладает меньшей предсказуемостью и несравненно большим временем переналадки. Здесь же добавляем операции совершенно подобные операции "купить материал".
Пожалуй, можно сказать, что произошла вторая трансформация: часть плана движения материалов по производству трансформировалась в спецификации к необходимым договорам и график их заключения. Каждый договор можно представить как рабочее место, обрабатывающее партию товаров
Картина сильно усложнилась, но остается в рамках предыдущего поста. К отношениям между оборудованием и материалами в производстве добавились отношения между подразделениями и через них - с поставщиками. В этом сводном процессе по прежнему главное - обеспечить "точно-в-срок" движение материала по всем цепочкам создания товара. Пока вся система качества сводится к совершенству плана и его гибкости на случай непредвиденных обстоятельств - брака, поломок и др.
При этом подразумеваем, что все необходимое для выполнения плана уже есть, а именно:
-конструкторская и технологическая документация
-исправное оборудование и рабочий инструмент
-поверенный измерительный инструмент
-обученный персонал
-и т.п.
Поскольку ничего не возникает само по себе, план нужно дополнить соответствующими действиями. Заметим, что предметы в приведенном перечне неоднородны. Конструкторская и часть технологической документации принадлежит к изготавливаемому продукту и, соответственно, планируется под него. Все остальное принадлежит производству в целом, применяется для всех продуктов и планируется иначе. Это "все остальное" является необходимым условием для выполнения действий над материалом. Если условие не обеспечено - вряд ли получится сделать товар качественным. То есть, для создания условий требуется другой вид плана. А для создания продукта нужно, чтобы были созданы и исполнены планы обоих видов
Объектом плана первого вида является узел, деталь, материал
Объектом плана второго вида является производство, станок, инструмент
На практике это выглядит как:
-Расписание, задание рабочему месту
-График (техобслуживания, поверки, проверки знаний)
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Михаил Шустер
- Автор темы
- Не в сети
- Живу я здесь
- Сообщений: 1209
- Спасибо получено: 260
Методики построения ИСР не существует. Вся методика сводится к утверждению: "ИСР должна быть". ИСР зависит от таких ненадежных вещей, как опыт, способности, искусствоКсенчук Евгений пишет: Методика построения Иерархической структуры работ в PM - это документированная возможность? А пример недокументированной возможности?
ИСР легко строят там, где их легко построить. Строительство дома, скажем. А в более сложных (но важных) вопросах обеспечения в реальных проектах вместо ИСР обычно просто декларации.
ИСР-просто имя, обозначающее иерархический классификатор. Построить его можно только тогда, когда определены все составные части задачи и их отношения. Если это сделано удачно - на такую ИСР легко станет и будет приносить пользу график. Если неудачно - то построение и пересмотры графика лишены смысла.
Принципы иерархической классификации находятся над любыми моделями, это общая часть моделирования. К теории познания относится, наверное. Страдают проблемами полиморфизма, инкапсуляции, наследования, о которых еще отпишу, если доберусь
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Ксенчук Евгений
- Не в сети
- Expert
- Сообщений: 1165
- Спасибо получено: 247
Приведи, пожалуйста, по паре примеров документированных возможностей и недокументированных возможностей.
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Михаил Шустер
- Автор темы
- Не в сети
- Живу я здесь
- Сообщений: 1209
- Спасибо получено: 260
Коротко и быстро описать документированные возможности РМ? А потом недокументированные? По паре?Ксенчук Евгений пишет: Приведи, пожалуйста, по паре примеров документированных возможностей и недокументированных возможностей.
Задачки ставишь...
Я приведу дальше, как смогу.
Термин "недокументированные возможности" общепринят
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Игорь Балакерский
- Не в сети
- Живу я здесь
- Сообщений: 816
- Спасибо получено: 177
Михаил Шустер пишет: ...Методики построения ИСР не существует. Вся методика сводится к утверждению: "ИСР должна быть". ИСР зависит от таких ненадежных вещей, как опыт, способности, искусство
ИСР легко строят там, где их легко построить. Строительство дома, скажем. А в более сложных (но важных) вопросах обеспечения в реальных проектах вместо ИСР обычно просто декларации...
...существуют методики построения ИСР. И, довольно успешно применялись лет 40 в Функционально - стоимостном анализе (ФСА). Вся суть- взаимосвязь декомпозиции изделия (Продукта) и декомпозиции технологии изготовления изделия. Продукт (Изделие) имеет приоритет. Ну, это связано ещё и с методическим правилом, что больших эффектов можно добиться от ФСА изделия, а меньших - от ФСА технологии изготовления изделия.
Познакомиться с методикой построения ИСР можно по старым книжкам по ФСА, в частности:
Справочник по функционально - стоимостному анализу/А.П.Ковалёв, Н.К.Миосеева, В.В.Сысун и др.; Под ред. М.Г.Карпунина, Б.И.Майданчика, - М.: Финансы и статистика, 1988 год.- 431 с.
Функционально - стоимостный анализ в электротехнической промышленности/ В.С.Василенок, А.А.Глезер, Е.А.Грамп и др.; Под ред. М.Г. Карпунина - М.: Энергоатомиздат, 1984 год.- 288 с.
Практика проведения функционально-стоимостного анализа в электротехнической промышленности/Под ред. М.Г.Карпунина.- М.: Энергоатомиздат, 1987.- 288 с. (вот, вся книжка построена на примере, а каждый пример начинается с той, или иной, либо структурно - элементной схемы изделия, либо структурно - элементной модели технологического процесса производства там какого-нить светильника НППОЗ-100-001 )
...также были разработаны и внедрены РД (руководящие документы) и СТП (стандарты предприятия) на Электросиле по построению структурно-элементных схем изделий и технологий в рамках проведения ФСА, где чётко описывался порядок проведения и правила. Дело в том, что в ФСА чуть не первый шаг в исследовании - это, как раз, и есть иерархическое структурирование выпускаемого изделия и технологии его производства уже на информационном этапе, в частности построение структурно - стоимостной и функционально - стоимостной модели объекта анализа. Вот и упражнялись в построении иерархических схем . Много труда и времени ушло и на методику разработки классификаторов (как точно выполнил этот этап, так и повысил шансы на успех в решении проблем)
ЗЫ...да, кстати, чуть не забыл. ФСА применяли и для совершенствования организационных и управленческих стуктур. Есть книжка братьев - чехословаков (автор Влчек, по-моему) по социалистическому лагерю Там, как раз, методы построения иерархических схем для орг.-управленческих систем (не много, правда).
...фундаментально эта тема у немцев - те, которые "наши" немцы (ГДР) - была тоже отработана
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Главная
- Форум
- Форум LeanZone.ru
- Общий
- Процессы и СМК без наукообразия