Хабр Курсы для менеджеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Менеджмент доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 34
Нет ни одного комментария, может и не надо?
Буков много, а слов ещё больше.
Плотная, отстоявшаяся коллоидная взвесь информации.
Пойду читать вторую часть, может кристаллизируется.
Такое ощущение, что нахватали где-то разных текстов на тему оргструктуры и процессов, разбили их на кусочки, перемешали и сложили в случайном порядке. Получилось вот это. Ни смысла, ни логики, непонятные ссылки, непонятно что подтверждающие, бессмысленные утверждения и прочее. Первое предложение в заключении - вообще феерия. Феерия мысли.
С уважением отношусь к труду автора и огромному количеству проработанного материала. И хочу сказать, что структурирование chat gpt в конце для меня гораздо более стройное, нежели в самой статье. Ощущение, что сказано +- тоже самое, но в разы короче и структурированнее. Отсюда делаю вывод, что статью стоило бы переработать не по содержанию, но по структуре. В целом все равно интересно, пойду читать часть 2, спасибо
Отсутствие понятного и структурированного описания системы «процессный подход к управлению» приводит к наличию большого количества заблуждений в среде российских менеджеров%2C консультантов …
Процессному подходу посвящены международные стандарты ИСО серии 9000. Это ни в коем случае не учебник с разъяснениями, поэтому, возможно, не всем все будет понятно, но все же НУЖНО и ДОЛЖНО считать содержащееся в них тексты "структурированным описанием процессного подхода"! Если ставится задача исследования процессного подхода, то игнорировать этот источник систематизированных знаний ИМХО не правильно!?
По мне (это, конечно, не доказательство объективности оценки) - это лучшее описание смысла, устройства (нотация, требования) "процессного подхода" к управлению организациями.
Еще один аргумент в пользу внимательного отношения к этому источнику - огромная потребительская аудитория в почти 3 млн. организаций по миру (это только официально сертифицированные организации, а есть такие, которые им руководствуются, но не хотят сертифицироваться).
Процессному подходу посвящены международные стандарты ИСО серии 9000.
На примере (и "на пальцах") можете пояснить?
Берем две компании, которые изготавливают скрепки. У них идентичные процессы, например, 5 шт.. Считаем, что в первой компании не процессный подход (какой кроме функционального может быть?), а во второй - процессный.
Во второй, - назначили Владельцев процессов, например, как совмещение с руководством отдела (иначе начальников будет перебор).
Какие будут в компаниях еще отличия?
Короткий ответ: по разному будет исполняться цикл управления PDCA: разная длина, разные маршруты и разная информация будут циркулировать по системе управления Дерево и по системе управления Сеть. До тех пор, пока внешняя среда стационарна, эта разница не существенна, как только мы представим, что все клиенты требуют специфические скрепки (разные материалы, свойства, размеры, форма, объемы, сроки, надо проверять готовы ли, сможем, когда, все согласовать, сообщить клиентам корректные сроки/стоимости и т.п.), то разница в маршрутах и скорости/качества реакции отделов 1.Продажи (и его подразделения службы продаж), 2.Планирование производства (цеха и диспетчерские подразделения цехов), 3.Закупки (и подразделения по закупке), 4.Производство (цеха операции), 5. Поставка (подразделения по организации поставки) если они представлены как Функциональная иерархия (информация движется только по вертикалям) и если управление этой деятельностью возможно напрямую (управляется как процессы), то разница будет существенной.
У нас с Вами несовпадение в оценках и, согласен, в этом надо разобраться!
Изложу свои несовпадения и сомнения:
1. Вы говорите, что нет разницы и все одно и то же (что функции, что процессы). Но моя практика и мои наблюдения говорят об обратном. На какое бы предприятие я не попал, вижу одни и те же проблемы–следствия функциональной иерархии, как модели управления:
· Производство говорит, что им портит жизнь служба продаж, заключают такие контракты по объемам и срокам, что никакой эффективности производства нет и в помине, исполнить контрактные обязательства, которые обещала клиентам служба продаж не возможно!
· Закупки загнали в запасы огромные средства, гораздо больше нормативов, и при этом нужные комплекты материалов выдать в производство не могут;
· Снабженцы закупают такие инструменты, метизы, и т.п. которые не обладают требуемыми свойствами от слова совсем, их срок службы минимален, стойкость, надежность – неудовлетворительные;
· Конструкторы множат такую большую номенклатуру изделий, пренебрегая унификацией, что производство и снабжение вешаются, а договорится об унификации – это пройти 7 кругов ада;
· Технологи разрабатывают такие техпроцессы с такими нормативами, которые с реальными возможностями производства не совпадают (причем в обе стороны);
· Плановая служба генерит неисполнимые планы, предполагая у производства такие мощности и возможности, которых в производстве никогда и не было;
· Производственные цеха получают премии за выполненные объемы производства, а предприятие не может из готовых деталей набрать нужные комплекты для сборки заказанных продуктов;
· Один цех обрабатывает сейчас те детали, которые в ближайшее время никому не нужны, а нужные и не думает брать в работу;
· И многое, многое другое…
О какой согласованности действий и планов, присущей процессному прямому взаимодействию, Вы говорите!? Только хаос, разбалансированность и несогласованность присущие функциональному подходу!? Какие такие сквозные процессы!?
2. Вы простите меня, но я за свою долгую практику работы с предприятиями (можете посмотреть мое резюме в моем аккаунте) ни разу не слышал, чтобы использовали термин «сквозные процессы»!? Может это не рабочий термин предприятий!? Может это навязанная им сущность (IT шниками), которая им не нужна, не используется?
3. Извините, понудю еще немного: что это за приставка «сквозной» к процессам? Масло масленное!? Процессный подход по определению и нужен для того, чтобы любой процесс через прямые связи мог выйти на любой уровень (прежде всего на Потребителя и его требования). Т.е. любой процесс по определению участник «сквозных» процессов (ибо доступны связи каждый с каждым).
4. Еще нудю, должен уточнить – Вы свои оценки «одно и то же» на основе каких артефактов сделали? На бумаге можно предположить что угодно (все одно и тоже), на практике же все совсем не так, как в теории. Поэтому у меня и вопрос про Вашу практику и специфику (моя специализация и наблюдения – промышленные предприятия и холдинги). Может разница в оценках связана с отраслевыми отличиями?
Надеюсь, мои мысли Вас не обидели и мы конструктивно пообщаемся?
Вы говорите, что нет разницы и все одно и то же (что функции, что процессы).
Я только повторяю Шеера, а более связанной теории BPM чем изложена в книжках ARIS (библия BPM) – я не встречал.
Бизнес-процесс таким образом, представляет собой сложную функцию, которую можно разбить на подфункции, чтобы уменьшить ее сложность. Термин «функция» может использоваться на всех уровнях иерархии. Однако другие термины, такие как процедура, процесс, подфункция или элементарная функция также используются для обозначения уровня иерархии.
Ссылка на источник.
Процессному подходу посвящены международные стандарты ИСО серии 9000.
Там изначально – было про «системный подход», типа комплексный анализ и эмерджентность (новые свойства «целого») и т.п., но потом «старый» Cистемный подход обернули в более «свежий» термин Процессный подход.
Какие такие сквозные процессы!?
ни разу не слышал, чтобы использовали термин «сквозные процессы»!?
Извините, понудю еще немного: что это за приставка «сквозной» к процессам? Масло масленное!?
Сквозной – это про «длинный». Это от end-to-end ("от начала до конца"), но каждый нарезает этот Сквозной по-своему, т.е. задает каждый «end» – как ему хочется.
ИИ: В контексте бизнес-процессов Сквозной процесс (End-to-End процесс): Комплексный подход к управлению бизнес-операциями, который охватывает весь жизненный цикл продукта или услуги, от зарождения идеи до её доставки клиенту. Такой процесс проходит через разные отделы и объединяет разрозненные функции в единое, согласованное движение, помогая избежать "разрывов" на стыках между подразделениями.
Однако тут может возникнуть путаница с кросс-функциональными процессами, см. math
Конечно чаще всего сквозной процесс – он же и кросс-функциональный, т.к. обычно в нем задействовано несколько подразделений. Однако понятие "сквозной" - условное, т.к. редко, когда их нарезают как "от самого начала" до "самого конца".
Да, и лучше давать ответ в текущее дерево ответов, а не начинать новое дерево.
Я только повторяю Шеера, а более связанной теории BPM чем изложена в книжках ARIS (библия BPM) – я не встречал.
Я повторю свою т.з. про то, что представление о процессном подходе, основанное на BP CBOOK и ARIS (библия IT мира) и в изложении международных стандартов ИСО серии 9000 (библия прикладного мира) - это две большие разницы!!! (здесь на ХАБРе я эту мысль уже озвучивал).
Сформулирую резкое/категоричное оценочное суждение: Представители IT-отрасли страшно далеки от Прикладной области знаний, в котором живет и которым руководствуется реальный мир, для которого IT-мир разрабатывает IT-решения!
ISO серии 9000 - это свод знаний по УПРАВЛЕНИЮ обеспечивающему устойчивое развитие предприятий/организаций (эти стандарты даже называются стандартами на СИСТЕМЫ МЕНЕДЖМЕНТА!!! как и в каком мире знаний надо находится, чтобы отрицать этот факт!?). Это такая же библия по управлению для Реального мира, как BMP CBOOK для IT-мира. Количество организаций реального мира, сертифицированных (т.е. продекларировавших что они в управлении руководствуются требованиями стандарта ISO 9001) около 3 000 000!? Но увы и ах, и в этом, повторю свою мысль, ОГРОМНАЯ проблема заключается в том, что эти две области знаний (международные стандарты ISO серии 9000 и BMP CBOOK) практически НЕ ИМЕЮТ ПЕРЕСЕЧЕНИЙ!? В ISO Вы не найдете ссылок на нотации BPMN, IDEF... - там продвигается другая нотация и механизмы процессного управления. Верно и обратное утверждение: в BPM CBOOK нет ссылок на нотации и механизмы из ISO. ЧТД(((( It мир разговаривает на своем "птичьем" языке, реальный - на своем((( Страшно далеки они друг от друга!
Вероятно по этой причине существенно отличаются наши представления о "процессном подходе" и этим и объясняются связанные с этим споры и оценки?
Мой анализ ситуации (как субъективная т.з. эксперта от Прикладного мира) в качестве ремарки про "библию ARIS от Шеера":
Следует учесть факт того, что ARIS появился в 1994 году (как развитие методологии автоматизации деятельности предприятий разработанной в 60х годах) , а Прикладной мир сформировал свою т.з. на процессный подход в 2000 году. Т.е. на момент разработки своей библии про процессный подход Прикладной мир знал что есть ARIS, но НИЧЕГО из этой системы знаний в свою библию по факту не взял. Возникает законное любопытство (А) ПОЧЕМУ международная группа разработчиков этих стандартов проигнорила ARIS вместе со всеми его нотациями BPMN и IDEFx!? (Б) Зачем и что напридумывали СВОЕГО Прикладники, игнорируя все наработки ARIS? (B) Почему BPM CBOK вышедший на свет в 2003 году (т.е. на момент разработки уже хорошо было известно, что понимает и какой процессный подход хочет иметь у себя Прикладной мир) имел шанс гармонизироваться с ISO серии 9000, но ответил взаимностью, и НИЧЕГОШЕНЬКИ из библии Прикладного мира по факту не взял? (Г) Почему за 25 лет не посчитали нужным гармонизироваться друг с другом две параллельно существующие области знаний про процессный подход (тем более что по определению IT отрасль должна обслуживать и работать на Прикладной мир, т.е. должны были, как минимум, внимательно изучать друг друга, а вместо этого обе стороны ВЗАИМНО и упорно игнорят друг-друга)?
На момент разработки ARIS (1994 год) господствовал функционально-иерархический подход к управлению. Поэтому сущность и описание процессов и процессного подхода Шеером определяется через терминологию функций (ИМХО, именно поэтому для Вас это одно и тоже и Вы правильно при этом ссылаетесь на первоисточник такого восприятия). Т.е. де факто ARIS являлся разработкой IT отрасли в решении задачи "Как перенести в компьютер с помощью процессных нотаций BPMN и IDEFх функционально-иерархическую модель управления, которая работала на 100% предприятий Прикладного мира" на тот момент времени
В 2000 году Прикладной мир объявил о потребности коренного преобразования систем управления (переходе с функционально-иерархического подхода к управлению предприятием, на процессный подход к управлению предприятием, как более эффективной альтернативы) и выпустил для этого свою библию ISO серии 9000. Обращу Ваше внимание, что термин функция ДЛЯ ОПИСАНИЯ И ОПРЕДЕЛЕНИЯ процессного подхода к управлению предприятием НЕ ИСПОЛЬЗУЕТСЯ! Разработчики ISO серии 9000 логично посчитали, что раз нужно заменить функционально-иерархичный подход на процессный (уйти от функций к процессам), то будет методически неправильным определять новую управленческую конструкцию процессного подхода с помощью старых элементов функций! По той же причине (повторюсь) Вы не найдете в этих стандартах и упоминаний про оргструктуру, т.к. в новой управленческой парадигме "процессный подход" она не нужна (она необходима была исключительно в старой модели).
Про восприятие ISO серии 9000 - я с этим неправильным и снобистким восприятием IT отрасли смысла и назначения этих стандартов сталкиваюсь постоянно! Все мои оценки, что озвучиваемое восприятие КАТЕГОРИЧЕСКИ не верное, попытки и призывы пересмотреть свое отношение и изучить эти стандарты наталкиваются на категорическое отторжение (поэтому я и применил термин СНОБИСТСКОЕ отношение). Такое отношение и реакция на ИСО серии 9000 - удивительно устойчивое и воспроизводимое, с каким бы представителем от IT отрасли я не общался!?
Моя версия причин такого СНОБИСТКОГО отношения к библии (смыслу и инструментарию процессного подхода) Прикладного мира:
(А) циничная и рациональная бизнес-позиция IT отрасли "А Зачем нам что-то переделывать/переучиваться/вкладываться в разработку чего то нового, если и так все хорошо продается!". Результаты в виде "Автоматизации ХАОСА" IT отрасль не очень беспокоят, т.к. по сложившемуся стандарту взаимоотношений, ответственность за это несет ИСКЛЮЧИТЕЛЬНО ЗАКАЗЧИК (очень удобно устроились - завидую, как консультант, черной завистью) и
(Б) а так исторически сложилось, что IT отрасль с момента рождения всегда сама была поставщиком задачи и у Прикладников ничего не брала/не училась (они не могли выступить в роли Постановщиков задачи) . Для того времени 60-90ее годы по другому, наверное, и нельзя было, т.е. это было правильное поведение. Но начиная с середины 90х годов Прикладной мир консолидировался и существенно рванул вперед, а IT отрасль, по привычке, этого не заметила и проигнорировала, т.к. привыкла к роли самодостаточного постановщика задач, от которой отказываться не хотела/не могла!
По той же причине (повторюсь) Вы не найдете в этих стандартах и упоминаний про оргструктуру, т.к. в новой управленческой парадигме "процессный подход" она не нужна (она необходима была исключительно в старой модели).
Есть ли подробное описание реального внедрения процессного подхода на предприятии? Особенно предприятия "без орг-структуры".
Есть ли подробное описание реального внедрения процессного подхода на предприятии? Особенно предприятия "без орг-структуры".
Прикладная задача звучит так: как предприятие, управляемое здесь и сейчас по функционально-иерархической модели (в ней обязательно есть оргструктура, как базовый элемент этой системы управления), перевести на процессное управление (в которой нет оргструктуры как необходимого элемента системы). Люди остаются, но описание их взаимодействия теперь будет определятся не оргструктурой (получаю задания только от своего начальника и работаю по регламенту), а их полномочиями и задачами в рамках взаимодействия с другими процессами (процессы сами для себя осуществляют весь цикл управления PDCA согласуют планы, осуществляют мониторинг на прямую, не через начальника)
В самой первой версии от 2000 года в стандарте iso 9000 "Основные положения и словарь" был такой раздел с описанием этапов перехода на новую систему управления (в последующих версиях его исключили):
А в стандарте ISO 9001 "Требования..." предъявлялись детальные требования к тому, что должно быть определено для выделенных процессов, что обязательно должно быть получено в результате их работы и т.п.
Этапы перехода: Создание проекта процессной модели, Формирование проектов описаний процессов и управления ими (как будет на основании взаимодействия с другими процессами формироваться план работы процесса, ...), Согласование процессов в рамках процессной модели (утверждение регламентов, должностных инструкций, полномочий,..) , Апробирование/Тестирование, Переход на созданную модель управления (упразднение старой функциональной иерархии Дерево, переход на управление предприятием Сеть, где объектами управления являются процессы с Владельцами процессов))
Люди остаются, но описание их взаимодействия теперь будет определятся не оргструктурой (получаю задания только от своего начальника и работаю по регламенту), а их полномочиями и задачами в рамках взаимодействия с другими процессами (процессы сами для себя осуществляют весь цикл управления PDCA согласуют планы, осуществляют мониторинг на прямую, не через начальника)
Например, сотрудник участвует в 20 процессах. У него нет ни одного начальника? Как он определяет приоритность процессов \ своих работ? Кто оценивает его загрузку, качество работы, у кого он должен отпроситься "уйти пораньше" и т.п.
Процедуры аналогичные:
Хочешь уйти, но ты сейчас должен работать в 20 процессах - нужно согласовать свой уход для 20 процессов, иначе как они будут работать, если ты неожиданно уйдешь не предупредив!?
В каждом процессе у него своя загрузка, свои критерии оценки
При разработке процессов, которые предусматривают участие одного человека в 20 процессах должен быть рассмотрен вопрос его допустимой (бесконфликтной для работы этих 20 процессов) загрузки. Если этого нельзя обеспечить, то такое использование человека (такие процессы) не должны быть согласованы (зачем планировать такой вариант выполнения работ, который гарантированно не будет исполнен)!? Если же процессы одобрены, т.е. конфликтов не обнаружено, то у человека будет должностная инструкция Как он работает в таком-то процессе, как в другом... Если конфликт загрузки произойдет - будет рассматриваться вопрос решения проблемы (пересмотр процессов или загрузки человека)
Если один и тот же человек планируется к работе в 20 процессах одновременно, то на момент разработки плана работы этих процессов "проблема" всплывет и будет решаться и разрабатываться н допустимый план этих процессов
Смыслы, логики и решения аналогичные. А как по другому то?!
Смыслы, логики и решения аналогичные.
Не понятные смыслы и логики.
Сотрудник обычно участвует куда более чем, в 20 процессах компании.
Если его нагрузка становится высокой, то из "функционального подразделения" (из пула) выделяется помощь (второй сотрудник, выполняющий ровно такую же роль). Все это (перераспределение нагрузки внутри подразделения) осуществляется начальником подразделения (функциональным начальником = начальником структурного подразделения). Должностная инструкция не определяет нагрузку и резервирование исполнителя в процессе, т.е. оперативное управление ресурсом (живой силой) должно кем-то обеспечиваться. И это не Владелец процесса.
Более того, Владелец процесса ничего не понимает в узкой специализации каждого сотрудника и не может оценить ни его квалификацию, ни загрузку (нормо-час).
Если конфликт загрузки произойдет - будет рассматриваться вопрос решения проблемы (пересмотр процессов или загрузки человека)
Кем? Всеми 20-тью владельцами разных 20-ти процессов?
Прежде чем отвечу, не могу не поделиться ощущением о формате и содержании нашего общения: мы общаемся как представителей разных миров/планет! Т.е. диспозиция такая))) Вы, в своем мире, находитесь в полной гармонии со своими знаниями, тут появляюсь я "чудик из другого мира" с непонятными т.з., которые могут нарушить Вашу гармонию, и Вы из вежливости лениво поддерживаете беседу с целью тихонечко меня выпроводить восвояси))) По содержанию: мне Ваши вопросы/оценки кажутся неожиданными/странными, а вопросы, которые должны были бы задать - не задаете!? Вы, видимо, аналогично воспринимаете мои ответы и т.з. По формату: Я пишу большие тексты, стараюсь аргументированно и структурированно описать свою т.з., ожидая ее обсуждения. Вы - системно уклоняетесь от оценок и обсуждения (понятно/не понятно) моих описаний, вместо этого задаете, как мне кажется, вопросы, чтобы "срезать" и не погружаться в изучение/обсуждение моей т.з. как заведомо неприемлемой! В общем непримиримая война миров какая то...
Теперь, собственно, ответ:
Мне очень сложно представить ситуацию:
Сотрудник обычно участвует куда более чем, в 20 процессах компании.
Вот базовая процессная модель предприятия о которой говорю я. В ней всего около 20 процессов. Возможны варианты, когда каждый из указанных процессов необходимо детализировать (разбить на 1-3 подпроцесса) или когда некоторые процессы будут объединены. Попробуйте на этом перечне процессов привести пример сотрудника, который участвует в 20 (получается во всех) процессах? Очевидно что Вы не эти процессы и не эту процессную модель имели ввиду? Какова Ваша процессная модель (приведите пример)? В чем наше не совпадение, мы сможем выяснить?
не могу не поделиться ощущением о формате и содержании нашего общения:
Отдельное Спасибо за режим Thinking (прямо как у ИИ).
Вы, видимо, аналогично воспринимаете мои ответы и т.з.
Точно. Действительно, мне кажутся Ваши вопросы и утверждения странными и не практичными \ не логичными. Поэтому я стараюсь задать вопросы, которые наиболее четко выявят эти противоречия.
а вопросы, которые должны были бы задать - не задаете!?
Скажите какие, - задам
Какова Ваша процессная модель (приведите пример)?
На примере производства мебели. Например, есть цех комплектования заготовок, потом отдельные цеха: цех деревянной мебели, цех металлической, цех пластиковой и т.п. Даже могут быть отдельные цеха по видам мебели (для кухни, для ванной и т.п. или стулья, кровати и т.п.).
Отдел (цех) столяров (распил, вытачивание, строгание) передает в отдел сборщиков (сборка изделия, склейка), а те в свою очередь собранный, например, деревянный табурет передают в цех покраски. Поэтому сотрудник цеха покраски участвует в 20 разных сквозных процессах (end-to-end: от получения заготовок со склада до готового изделия):
1 Изготовление (вкл. покраску) металлического стола артикул такой - то
2 Изготовление пластиковой (вкл. покраску) табуретки (3D печать) артикул такой - то
3 Изготовление деревянной табуретки артикул такой - то
…
У каждого сквозного процесса - свой продукт (или группа схожих продуктов).
Аналогично со скрепками см. Рис. 2 Схема (VAD) процесса Изготовление скрепки (лист visio)
Спасибо за пример!
Неожиданно для меня, то, какие вопросы Вы мне задавали, то, какой пример привели, на что акцентировали внимание (я все это сам никогда не смог бы предположить) дали мне так много пищи для ума, что у меня сложились все пазлы, и я для себя сформировал логичное объяснение специфики и различий наших подходов и т.з.! Естественно, все «с моей колокольни», т.е. не факт, что Вы мои объяснения одобрите?)))
Важные различия, которые я для себя отметил (дополните/поправите меня при необходимости):
1. Мой пример – процессная модель для организации в целом, Ваш – про производство только. Т.е., Вы сочли приемлемым, в качестве примера привести «кусочек», а в моей парадигме «процессный подход» не имеет смысла, если он не охватывает организацию в целом. Все по Фрейду)) мне бы и в голову не пришло показать «фрагмент» (для меня это категорическое искажение смыла), а для Вас – это приемлемо (потому что все равно, что показывать, т.к. смысл, с Вашей т.з можно увидеть и в «фрагменте»).
2. С Вашей т.з. (я так понял) чем детальней описание (больше процессов), тем лучше. А у меня совершенно другая установка: как подобрать минимальное количество процессов, которого будет достаточно для эффективного управления предприятием (у меня точно нет критерия «чем больше, тем лучше», для меня это ненужное усложнение задачи управления предприятием).
3. В моем представлении нотация описания процесса чрезвычайно нагруженная (для описания требуется огромное количество связей (напомню, граф СЕТЬ, связи каждый процесс с каждым), полей, логик, метрик, предполагается сложное внутреннее содержание процесса, допускается большое количество участников процесса с разными ролями, и много другое, все есть в ИСО 9001), а у Вас, по сравнению с моим представлением, описание процесса предполагается минималистическое и участник(и) с одинаковой ролью. Я бы эту разницу оценил минимум раз в 100 (а может и в 1000). И тогда понятно, почему, я дорожу количеством процессов (это очень дорого управлять процессом, нужно совершать очень много действий, обрабатывать большое количество данных, согласовывать работу сети процессов при обнаружении важных отклонений/изменений в любом из них, …), а Вам увеличить количество процессов - легче легкого!
4. У меня небольшое (по сравнению с Вашей моделью) количество процессов, потому что моя процессная модель подразумевает связи каждый с каждым (для обеспечения гибкого и быстрого согласования работы всех процессов предприятия при обнаружении потребности изменения), и любое добавление нового процесса в модель кратно увеличивает количество связей и сложность согласования (поэтому нет цели «чем больше, тем лучше» в т.ч.). Ваша же модель строится на линейной последовательности процессов, в которой требовать связи каждый с каждым – глупость (я теперь понял Вас и Вашу реакцию на СЕТЬ и связи каждый с каждым))))
5. Требование наличия владельца процесса в вашей модели, как мне кажется, излишняя надуманная избыточная опция, особенно, учитывая такое огромное количество процессов и желание увеличивать их количество для точной детализации соответствия. В моей модели без владельца процесса НЕЛЬЗЯ, и их в организации не много (по небольшому количеству процессов), и их роль (нагрузка, ответственность и полномочия, управление регламентами, ресурсами, участниками процесса, распределение работ, управление отклонениями/изменениями и т.п.) чрезвычайно значима (поэтому и так много рождено текстов в инете, что без них нельзя, но для какой модели?).
6. Границы процесса – у меня по сравнению с вашей моделью, просто огромные. Ваши процессы с примера целиком влезли бы в один процесс в моей модели с названием производство (ну или в 2-3). Поэтому я и ответил, что не вижу проблем с «отпроситься» - это рутинная обязанность владельца процесса, и сотрудников, которые участвуют сразу во многих процессах в моей модели нет (ну может быть в 2-3 смежных), и для меня это не является сколь-нибудь важной проблемой! Поэтому для меня выглядело диким предположение о том, что практически все сотрудники организации участвуют в огромном (от 20 и больше процессах), что для Вас это важный аспект и что это критерий работоспособности процессной модели (для меня вообще не существенно).
Теперь, собственно, мои выводы и анализ причин (все с моей колокольни и делаю оценки более категоричными, чем на самом деле есть, чтобы подчеркнуть мою мысль/идею)
1. Ваша модель родом из задачи «автоматизировать» деятельность предприятия (создать двойник в компьютере). Для этого в 60е годы с появлением первых компьютеров была придумана соответствующая технология и нотации. На самом деле эта модель и нотации описывают элементарные ОПЕРАЦИИ и их последовательность (чем подробнее, тем лучше). Это почему то назвали процессами и процессным подходом. Правильней/ближе сейчас это называть созданием цифровых двойников, наверное. При таком описании, никакой разницы для технологии переноса операций нет функционально-иерархическая модель управления у предприятия, процессная ли, функциями ли называются переносимые действия или операциями. Поэтому я теперь понимаю, почему для вас это все одно и то же, и почему BPM CBOK такой (он весь про перенос операций, там ничего нет про управление из стандартов ИСО серии 9000, понятно теперь и почему эти стандарты про управление IT шникам как 5 колесо в телеге, для решения задачи автоматизации они не нужны)
2. Моя модель (ИСО серии 9000) родом из 2000 года, когда прикладники, замученные неприемлемой эффективностью предприятий, пришли к консенсусу, что коренная причина проблем - господствующий функционально-иерархический подход к управлению, который в условиях роста номенклатуры, непредсказуемой изменчивости спроса и т.п превратился в генератор проблем. Прикладники провозгласили, что выход из кризиса не эффективности – совершение революции в области управления - переход на процессный подход. Цели этой революции – повысить эффективность работы предприятий. Цель автоматизация, или перенос операций в компьютер НЕ СТАВИЛАСЬ и НЕ РАССМАТРИВАЛАСЬ от слова СОВСЕМ! Рассматривалась ИСКЛЮЧИТЕЛЬНО задача создания быстро и эффективно реагирующей системы управления (все действия сотрудников организации согласованы и все в любой момент времени в организации делают только то, что нужно, и не делают что не нужно). Поэтому и другая процессная модель (другая цель - другое решение). Поэтому в стандартах ИСО серии 9000 нет ничего из BPM CBOOK.
3. Большая причина проблемы - терминологическая и те и те используют термины процесс и процессный подход с абсолютно разной смысловой нагрузкой для совершенно разных целей. Если в задаче автоматизации и использования для решения этой задачи нотаций вместо терминов Процесс и Процессный подход, использовались термины ОПЕРАЦИЯ и КАРТА ОПЕРАЦИЙ, а процессы и процессный подход как термины оставили стандартам ИСО серии 9000 с их управленческой нагрузкой, было бы проще всем. Так что Шеер мог бы быть поаккуратней)))
У меня все сошлось! Еще раз, Спасибо Вам за помощь – Вы мне сильно посодействовали в осмыслении!
Поделитесь своими мыслями?
1 Уточните про сквозные процессы. Вы их не признаете в своем подходе?
2 Дайте ссылки на статьи, где показана схожая с Вашей позиция.
3 Применительно к автоматизации vs bpm. Если брать классический BPM, он как раз не про автоматизацию. Тот же реинжиниринг процессов (ключевой элемент BPM девяностых) основан на тезисе: Не автоматизируй это!
Подробнее показано тут.
В моем примере нет ничего про автоматизацию, ни с табуреткой, ни со скрепкой. Сквозной процесс и его владелец это отсылка к Аркадию Райкину: к пуговицам претензий нет, но костюм (процесс) негодный
4 Рассуждения про Менеджмент (вкл. СМК) vs наука. И обертка здравого смысла.
Меня так развивают Ваши вопросы - Вас мне Бог послал!))) Как Вас зовут, где я могу посмотреть информацию о Вас (кому мне позитивные отзывы посвящать)?
Сначала сформулирую то ГЛАВНОЕ, на что продвинули меня Ваши вопросы, потом постараюсь пройтись по Вашим пунктам (поработаю на Вас и Ваши непонятки).
В моем предыдущем посте и мысли не было думать о Вашем подходе к управлению, как о подходе который не способен управлять. Моя мысль была в том, что Вы (понятно что не Вы, а обсуждаемый подход к управлению на основе BPMN и Co (подход IT отрасли), и так же верно в обратную сторону не мой подход, а процессный подход на основе ИСО серии 9000 (Подход Прикладного мира), просто так короче) к задаче управления пришли через задачу автоматизации (я написал РОДОМ из автоматизации). Упрощенно Ваш подход: создаем подробную КАРТУ ОПЕРАЦИЙ и управляем ею, в т.ч. делая реинжиниринг КАРТЫ ОПЕРАЦИЙ. Чем подробнее карта, тем понятней и лучше будут результаты реинжиниринга и управления (т.е. качество результата, определяется детальной проработкой КАРТЫ ОПЕРАЦИЙ (качеством описания содержания), или это подход к построению системы управления "от частного к общему")
В ИСОшном все с точностью до наоборот: подход к построению системы управления предприятия строится на принципе "от общего к частному". Ставка делается не на детальность описания (не на качество описания операций), а на качество управления предприятия сразу. Стандарт "говорит": не важно какие у Вас операции, сколько их и чем Вы занимаетесь (скрепки, стулья, парикмахерская, синие стринги, или красные боксеры,... - все равно), если сотрудники в организации не правильно взаимодействуют, если Вы при принятии решений не имеете такой то информации, не делаете таких то вещей, то у организации будут ОГРОМНЫЕ проблемы (драку заказывали? не важно за все уже уплачено! т.е. мина замедленного действия с названием "дефектное управление" в организацию заложена и будет работать как часы генерируя ей проблемы). Поэтому идеология стандарта: выделите ваши основные процессы (например, Продажа, Закупки, Разработка, Производство, Поставка, Управление ресурсами, Управление организацией). Не важно сколько Вы их выделите, важно, чтобы они эффективно между собой взаимодействовали (Сеть, каждый с каждым) и могли вырабатывать и реализовывать исполнимые и нужные Потребителям согласованные планы действий. Т.е. каждый выделенный процесс системы должен работать в такой среде: В каждый момент времени у любого процесса системы уже есть согласованный с другими процессами, исполнимый внутри процесса план действий (например ваш процесс производства таких-то наборов стульев на сегодня для процесса Производства) , который нужен для удовлетворения Потребителей, который Процессом внимательно мониторится, и если вдруг произойдут какие-то проблемы, то процесс тут же сгенерирует сигналы об обнаруженных отклонениях другим процессам (закупки, Продажи, ...) и будет вырабатываться новый скорректированный план действий в организации с учетом произошедших изменений (Изменится план закупок, Уйдет предупреждение клиентам о том, что обработка его заказа задерживается, Поступит сигнал в процесс Разработки о том что конструкцию или технологию надо улучшить по таким то аспектам и т.п.), если таких сбоев много, то будет инициирован реинжиниринг процесса и системы в целом (при необходимости). При этом, так как изменчивость требований потребителей и их спроса огромные, риски не выполнения планов процессов не нулевые (допустили брак, задерживается поставка, сломался инструмент, медленнее стало работать оборудование, маркетинг ошибся в оценках, изменилась цена на электричество и т.п.), то процесс разработки согласованных планов процесса и системы в целом непрерывный (это не акт, а не прерывный процесс). Тот самый цикл PDCA который вшит в управление, как обязательная нотация. Кроме того, стандартом помимо требований умения работать в вышеописанной среде, перечислены обязательные умения и процедуры, которые необходимо для эффективной работы любого состава процессов в организации (например устанавливать такую то информацию от потребителей, регистрировать несоответствия, осуществлять корректирующие действия, проводить внутренние аудиты и т.п. всего около 400 требований, к "умениям", если которых нет, то организацию не спасет и отличный навык согласованно работать как сеть в режиме PDCA в вышеописанной среде). Все разъяснения привел для Вас, чтобы объяснить специфику создания системы управления от ИСО.
Попробую резюмировать разницу подходов построения эффективного управления организацией:
IT отрасль: сначала операции и КАРТА операций (описание содержания деятельности, чем подробнее-детальнее, тем лучше), потом их реинжиниринг (как увидели и смогли) и управление описанными/улучшенными (не факт что получилось лучше, критериев то нету) операциями как КАРТОЙ операций, и тогда наступит СЧАСТЬЕ.
Прикладники (ИСО): сначала отрабатываем правильность управления (PDCA, Сетевое взаимодействие, 400 "умений") - отработка такого управления и умений вынудит нас по другому выполнять операции (происходит реинжиниринг КАРТЫ операций под критерии правильности управления с предыдущего пункта, реинжиниринг КАРТЫ операций процесса - осуществляет Владелец этого процесса, Реинжиниринг СЕТИ процессов - Координационный совет владельцев процесса или Владелец процесса Управление СИСТЕМОЙ), такой подход создаст необходимое эффективное управление (когда каждый процесс в любое время согласованно делает только то, что нужно (и не делает того, что не нужно) Организации=Потребителю) под которое произведен необходимый реинжиниринг КАРТЫ ОПЕРАЦИЙ в каждом процессе. И тогда наступит СЧАСТЬЕ.
Я старался написать это объяснение понятным не для себя, а для Вас, т.е. старался описать его так, чтобы оно было понятным и непротиворечивым с т.з. адепта и носителя знаний IT мира. Получилось ли мне понятным для Вас образом донести мысль про разницу подходов?
Теперь Ваши вопросы:
1 Уточните про сквозные процессы. Вы их не признаете в своем подходе?
С т.з. ИСОшного подхода, во первых, это избыточная сущность, потому что все равно какие процессы сначала, потом все настроим. Во-вторых, концепция TQM (лежащая в основе ИСО серии 9000) построена на аксиоме, что в организации нет таких видов деятельности, которые не оказывали бы влияния на конечный результат "Высокая степень удовлетворенности Потребителя" (в Вашей терминологии TQM транслируется в утверждение все они должны быть привлечены и участвовать как СКВОЗНЫЕ). Поэтому попытка выделять часть видов деятельности не важно с какими критериям важности (сквозные процессы в Вашем вопросе), с т.з. TQM управленческая ошибка. Но это не означает, что в ИСО не используются классификации процессов (есть управленческие, обеспечивающие, процессы жизненного цикла (ПЖЦ) продукции, иногда их еще называют бизнес-процессами (на моем примере процессной модели это группа процессов желтого цвета) - возможно именно они наиболее близки термину СКВОЗНЫЕ. Просто в Прикладном мире, видимо, в отличии от IT мира такой термин не распространен от слова СОВСЕМ (используются близкие к нему аналоги в виде ПЖЦ или БП)
2. Дайте ссылки на статьи, где показана схожая с Вашей позиция.
Фрагментарно следы описываемой мною логики много где есть (лучший свод - сами стандарты ИСО серии 9000). Так концентрированно и в таком виде (благодаря Вам родилось из под моего пера только сейчас) - не знаю. Я по приглашению руководства НИУ ВШЭ читаю свой курс "Теория организации" для студентов Бизнес-информатики в Нижнем Новгороде, и поэтому используемое мною с Вами изложение интерпретации ИСО 9000 и подхода к построению системы управления - это мои лекции, моя 35 летняя практика работы на земле по повышению экономической эффективности производственных Предприятий/Холдингов/Цепей поставок, моя авторская отсебятина, чтобы понятно было студентам 3-курсникам (последний вариант в нашем диалоге - отсебятина под Вашим воздействием))).
3.Применительно к автоматизации vs bpm. Если брать классический BPM, он как раз не про автоматизацию. Тот же реинжиниринг процессов (ключевой элемент BPM девяностых) основан на тезисе: Не автоматизируй это!
Про BPMN с моей т.з. я уже ответил выше. Только еще раз здесь акцентирую Ваше внимание на Важном артефакте, который с моей т.з. свидетельствует о принципиальной разнице подходов: В ИСО серии 9000 (первая редакция 2000, вторая 2008, третья 2015 годы) нет ни слова о BPMN (разработчики подхода к построению эффективных систем управления от Прикладного мира де факто проигнорировали/открестились от идеологии и подхода by BPMN), и, что не менее интересно, верно наблюдение и в другую сторону: подход к построению эффективных систем управления by BPMN от IT мира НИЧЕГО не взял из ИСО 9000 (в библии BPM CBOK нет ни одной смысловой ссылки на ISO 9000, нет ничего про PDCA или 400 требований - ПОЧЕМУ?! Почему IT мир подверг анафеме важные знания Прикладного мира? Казалось бы клиенты IT мира (Прикладники), расстарались, провели исследования, и "на блюдечке с голубой каемочкой" смогли сформулировать что-то с их точки зрения очень важное (3 млн. организаций!!!!! строят свои системы управления по модели ИСО 9000), а IT мир снобистки все эти наработки своих клиентов ОСОЗНАННО пропустил "мимо ушей"!!!!???? Каких только глупостей о роли и смыслах ИСО 9000 для жизни Прикладного мира и их значения для построения эффективных систем управления я не наслушался от представителей IT мира!? А все мои попытки сказать им, что они не правы в своих оценках воспринимаются ими как советы идиота! "У нас в IT мире ГАРМОНИЯ!!! Не нарушай ее своими глупыми предположениями!!! Ты просто плохо знаешь, то что мы делаем, иначе бы ты не задавал своих глупых вопросов, а вместе с нами пребывал бы в нашей ГАРМОНИИ!". Все! ВСЕ (я не шучу)!!!! мои диалоги с представителями IT отрасли идут именно так((( Я устал от этого невежества, мой консалтинговый бизнес от этого невежества может пострадать, но что еще хуже, здесь и сейчас предприятия не по детски страдают из за этого конфликта подходов (фактически живут/должны управляться и жить по ИСО, а вынуждены существовать через КИС по видению системы управления IT подхода, а они разные и не сходятся в результатах!!!). Поэтому я и пришел на ХАБР, чтобы разобраться во всей этой ситуации и найти из нее согласованный выход!!!
4. Рассуждения про Менеджмент (вкл. СМК) vs наука. И обертка здравого смысла.
Менеджмент не наука, потому что в нем, прежде всего, невозможно провести научные эксперименты и на их основе вывести строгие доказательства (научный подход в строгом смысле не возможен). Ибо не возможно дважды (а с т.з. научного подхода к исследованию лучше проводить сопоставимые эксперименты столько раз, сколько потребуется) поместить одну и ту же организации в идентичные исходные условия, поменять в организации какие-то управленческие решения и сравнить полученные результаты (прокрутить один и тот же год работы организации с одинаковыми условиями, только с разными управленческими решениями, увы, НЕ ВОЗМОЖНО, поэтому и менеджмент - не наука)))) и с этим трудно поспорить!)
Вторую ссылку не осилил (слишком много букв и много воды, чтобы найти зерно), поэтому не понял что Вы ею хотели сказать (какую мысль донести). Если это важно - сформулируйте ее не заставляя меня читать такие большие тексты? Про ТРИЗ - это восторг и восхищение гениальностью автора! Сильнейший инструмент - библия для конструкторов!!!! За рубежом во многих инженерных центрах - это обязательная область знаний, без которой с тобой даже разговора не начнут при приеме на работу!!! Там это признанная КЛАССИКА, у нас же в стране - это, увы, забытая мелодия для флейты(((
Написал в личку.
По наиболее "вопиющиму" фрагменту:
в библии BPM CBOK нет ни одной смысловой ссылки на ISO 9000, нет ничего про PDCA или 400 требований - ПОЧЕМУ?! Почему IT мир подверг анафеме важные знания Прикладного мира? Казалось бы клиенты IT мира (Прикладники), расстарались, провели исследования, и "на блюдечке с голубой каемочкой" смогли сформулировать что-то с их точки зрения очень важное (3 млн. организаций!!!!! строят свои системы управления по модели ИСО 9000)
BPM - это "перепев" ISO9k \ СМК. И частично lean, например, Standard Operating Procedures - это просто "процесс".
Уже давно BPM - "съел" рынок ISO9k \ СМК. Последний в РФ внедряют в основном "для галочки" (участвовал и нужно было только для "формальной сертификации"). Тот же ИИ говорит: "Организации часто внедряют ISO 9001 под давлением внешних требований: тендеры, требования ключевых заказчиков, вход на международные рынки. Это во многом вынужденное решение".
Даже целевые странички ISO 9000 содержат (tadviser): Почему внедрение ISO 9000 превратилось в тотальную халтуру?
Несколько цитат по BPMvsISO9k:
ISO 9000 — не цель, а так, побочный продукт: будет в компании полноценный BPM — ISO получится автоматически (Президент ruABPMP)
BPM-система, как правило, не идеальна (например, некоторые процессы могут существовать лишь на бумаге, а некоторые детали «живут» только в умах определенных людей), но она существует. Например, любую реализацию ISO 9000 можно рассматривать как пример BPM-системы (А. Самарин).
ISO 9000: трамплин для BPM (bptrends.info)
А цикл PDCA в BPM CBOK упоминается десятки раз. Этот цикл вообще упоминается очень часто, - как к месту, так и нет. Ответ ИИ "цикл PDCA, глубоко интегрированы в саму ткань знаний по управлению бизнес-процессами".
Мир изменился: Идеи (и деньги) "процессного подхода, PDCA" и других "очевидностей" перетекли от ISO9k в BPM. Это ответ также к комментарию. Другой пример сравнения: посчитайте число ruТГ-каналов по СМК vs BPM.
Всё-таки: можете привести несколько современных публикаций, поясняющих Вашу концепцию / позицию? Желательно с упоминанием по тексту "процессный подход". В принципе достаточно ответа ИИ.
Вторую ссылку не осилил (слишком много букв и много воды, чтобы найти зерно),
У меня были ссылки в основном на мои короткие комментарии, а не на статьи (к тому же не мои), например, xxx/comments/#comment_27225328 - это ссылка на конкретный комментарий. Читать можно только комментарий (не статью).
Прежде всего, я потерялся в логике нашего диалога про разницу подходов, потому что вместо прямых оценок приведенных мною описаний этих отличий, от Вас последовали вопросы и возражения не про описанную мною разницу, а про интерпретацию взаимосвязей BPM и ИСО вообще!? Правильно ли я понял Вашу позицию, что Вы пытаетесь провести логику BPM=ISO поэтому разницы подходов НЕТ, и обсуждать мои описания не хотите (опять IT снобизм)? Ничего в этом мире не меняется, мне не привыкать...
Хорошо, по Вашим вопросам/возражениям
BPM - это "перепев" ISO9k \ СМК. И частично lean
Я как эксперт по LEAN и стандартам ISO 9000 прочитал BPM CBOK4.0 и никаких текстов, которые хоть как то раскрывали бы содержание и смыслы этих концепций не нашел, там и близко ничего похожего нет (или Вы продолжаете относится к мои оценкам - как к бреду сумасшедшего)!? Если хотите, даже Вы не будучи экспертом в этих дисциплинах можете самостоятельно этот факт проверить: поиском по книге последовательно ищите ISO, ИСО, LEAN, PDCA и, о открытие, Вы не найдете ни одной содержательной ссылки!? Как из этого по Вашему следует "BPM - это "перепев" ISO9k \ СМК".
Поэтому выскажу свое искреннее удивление: на основе каких данных Вы утверждаете совершенно обратное!? Кто в Вас вложил эту мысль!? На основании каких аргументов вы можете это утверждение обосновать?!
А цикл PDCA в BPM CBOK упоминается десятки раз. Этот цикл вообще упоминается очень часто, - как к месту, так и нет.
Ни одного упоминания я не нашел (возможно плохо искал)!!!! Вы читали BPM CBOK4.0? Можете привести скрины упоминаний, где обсуждаются смыслы ИСО, LEAN, PDCA? Или описание какого либо процесса в нотации BPMN по которой было бы видно работу цикла PDCA (если он вшит)?
Уже давно BPM - "съел" рынок ISO9k \ СМК.
Вообще не понимаю смысла этой фразы. Для меня, здесь и сейчас, это две ничего общего не имеющие дисциплины (мягкое с мокрым, мороженое и самокаты). Что может означать утверждение рынок мороженного съел самокаты!? Что это вообще может означать, а уж тем более что то доказать? Что мороженным выгоднее сейчас заниматься? Может быть, но это не означает что самокаты перестали быть нужными. Это всего лишь сегодняшнее фото конъектуры рынка. Сегодня одно фото, завтра - другое
Последний в РФ внедряют в основном "для галочки" (участвовал и нужно было только для "формальной сертификации"). Тот же ИИ говорит: "Организации часто внедряют ISO 9001 под давлением внешних требований: тендеры, требования ключевых заказчиков, вход на международные рынки. Это во многом вынужденное решение".
Даже целевые странички ISO 9000 содержат (tadviser): Почему внедрение ISO 9000 превратилось в тотальную халтуру?
Рынок ИСО разделился на два лагеря: тем кому нужно здоровье (эффективность) и тем кому достаточно справки о здоровье (эффективность не нужна, достаточно справки). И тех, кому нужна справка гораздо больше! Что это доказывает? Доказывает ли это, что процессный подход и СМК от ИСО 9000 не работает? Нет, конечно! Это лишь доказывает что огромному количеству компаний (руководителям этих компаний) Прикладного мира ничего менять не хочется! А вот это большая проблема, потому что руководители то в накладе не останутся, а предприятия могут уйти в закат. Тут вопрос жесткий: ИСО (СМК и процессный подход) - это реальный выход, тогда те кто этого не понимает - смертники (или убийцы). Либо надо доказать, что ИСО - это пустышка, но только это надо доказать, потому что то что указано в Вашей цитате выше, повторюсь, не доказательство!
Мир изменился: Идеи (и деньги) "процессного подхода, PDCA" и других "очевидностей" перетекли от ISO9k в BPM. Это ответ также к комментарию. Другой пример сравнения: посчитайте число ruТГ-каналов по СМК vs BPM.
Это Ваша точка зрения, что идеи перетекли (объективных доказательств кроме деклараций и свидетельств от AI (который постит такие глупости, например, по LEAN - практически все не правильно, что я постеснялся бы иметь его в качестве свидетеля) Вы не привели). Моя т.з.: идеи BPM - идеологически устаревшая пустышка из прошлого века (прошлогодний снег) и до идей ISO им 200 световых лет лететь и лететь. По деньгам здесь и сейчас - согласен. Что мир изменился - то же согласен, только я считаю что он изменился так, что идеи BPM родом из 60х, из кареты превратились в тыкву, и именно на замену им и разработан подход ИСО.
Всё-таки: можете привести несколько современных публикаций, поясняющих Вашу концепцию / позицию? Желательно с упоминанием по тексту "процессный подход". В принципе достаточно ответа ИИ.
Пожалуйста смотрите Алису https://yandex.ru/search/?lr=47&rq=1&text=процессный+подход+в+системе+менеджмента+качества&src=ref&serp-reload-from=rec_bottom
Но я настоятельно рекомендую изучать первоисточник
про интерпретацию взаимосвязей BPM и ИСО вообще!? Правильно ли я понял Вашу позицию, что Вы пытаетесь провести логику BPM=ISO поэтому разницы подходов НЕТ,
Я считаю, что в обоих завернут ровно такой же Процессный подход и его продают в разных обертках. Может быть есть исследования на этот счет? Изначально в ISO был только системный и его потом переименовали в процессный.
обсуждать мои описания не хотите
я тоже потерялся в потоке обсуждений. Лучше так: Тезис (Ваш) - и мой (в Вашем понимании) АнтиТезис (с нумерацией).
Некоторые Ваши утверждения, типа "В BPM CBOK нет про PDCA" - меня вводят в ступор.
BPM CBOK vs PDCA
Цикл PDCA (Plan-Do-Check-Act) является одной из фундаментальных концепций в BPM CBOK версии 4.0. Он лежит в основе процессного подхода и непрерывного улучшения (Continuous Improvement), которым посвящена целая глава.
Типичные места, где PDCA упоминается в BPM CBOK 4.0:
Глава 1.0: Введение в BPM и CBOK — PDCA представлен как базовая концепция управления процессами.
Глава 2.0: Процессный подход — Подробно обсуждается цикл PDCA как методология управления процессами. Это, вероятно, основное место, где он описан.
Глава 4.0: Управление, культура и структура — Может упоминаться в контексте создания системы управления.
Глава 7.0: Постоянное улучшение процессов — Это ключевая глава, где PDCA (и его развитие в виде PDSA — Plan-Do-Study-Act) разбирается детально как основной инструмент улучшения. Он связывается с другими методами, такими как Six Sigma (DMAIC) и бережливое производство (Lean).
Глава 8.0: Управление качеством процессов — PDCA является стержнем многих систем качества (например, основанных на ISO 9001).
Если нужно скрины - пришлю.
Моя т.з.: идеи BPM - идеологически устаревшая пустышка из прошлого века (прошлогодний снег) и до идей ISO им 200 световых лет лететь и лететь.
Где можно почитать про это?
Пожалуйста смотрите Алису
Это не статья - а "подмена понятий". В названии нужно было указать не LEAN, теория ограничения систем (и про ISO), а вписать BPM. Это статья ровно про BPM. Откуда в лин, ТОС, iso9k взялись: IDEF, VAD, BPMN, EPC, Владелец процесса и др.?
ISO 9001 упоминает Владелец процесса?
Нет, в тексте стандарта ISO 9001:2015 прямой термин «Владелец процесса» (Process Owner) не упоминается. Там есть похожее, но если в статье хабра речь не про BPM, то и нужно указывать термины из тех улучшайзингов (лин, ТОС, iso9k), которые упомянуты в статье.
В статье согласен с тем, что и ТОС - это тоже про процессный подход. Кстати, iso9k не из него заимствовала его? В изначальном iso9k не было про него.
Вторая часть (третьей не нашел)
Математика спасет BPM
Применительно к терминам Треугольник орг-структур компании. Часть 1 сделал пояснения к терминам в стиле math for BPM
Я считаю, что в обоих завернут ровно такой же Процессный подход и его продают в разных обертках.
Обеими концепциями (BPM и ISO) декларируется "Процессный подход" - да, это так (термин один и тот же, цель декларируется идентичная - процессное управление организацией)
Моя т.з. BPM и ISO описывают различные подходы как к построению, так и к составным элементам итоговой конструкции и каким образом будет осуществляться управление. Очень схематично, в ИСО мало процессов но архи много требований к тому, как они должны взаимодействовать и управляться как система процессов, в BPM очень много процессов и минималистическая нотация.
Т.е. я утверждаю НЕ СХОДИМОСТЬ результатов при разработке процессного управления by BPM vs ISO. Для одной и той же организации получаться разные по составу процессы, подходы к управлению ими как системой и очень разные результаты такого управления (я считаю, что получаемые результаты by BPM неудовлетворительные)
Я утверждаю, что такая НЕ СХОДИМОСТЬ - это большая проблема.
Может быть есть исследования на этот счет?
Увы, я не слышал о подобной постановке задачи (гипотезе о существенной разнице и НЕ СХОДИМОСТИ) вообще, как следствие не видел и соответствующих исследований. Считается, как Вы и озвучили, что по умолчанию это все одно и то же.
Изначально в ISO был только системный и его потом переименовали в процессный.
Это не так. С момента рождения в 2000 году, это был и остается стандарт процессного подхода. Просто вместо 8 принципов менеджмента в версии 2000 года, начиная с версии 2008 года их осталось 7 (принцип Системного подхода к менеджменту исключили). Никакого переименования не было. Как был процессный подход, так и остался.
С моей т.з. то, что Вы озвучили такое мнение, является для меня очевидным маркером того, что Вы стандарты ISO не знаете, не понимаете (иначе никогда бы такое не сказали бы). Я этим не хочу Вас обидеть (возможно Вас этим стандартам ISO учили), я лишь хочу обратить Ваше внимание на то, что информацию/знания, которые Вы получили, как бы помягче выразится, я, как преподаватель этой области знаний из Прикладного мира, считаю не очень корректными. А Вы можете вспомнить/поделиться данными о том откуда Вы получили знания о стандартах ИСО серии 9000 (кто учил, что за учебный процесс был)? Я пытаюсь понять, откуда такой искаженный и очень сильный источник знаний в IT отрасль пришел?
я тоже потерялся в потоке обсуждений. Лучше так: Тезис (Ваш) - и мой (в Вашем понимании) АнтиТезис (с нумерацией).
Согласен, в обмене "портянками" каждый отвечает на то, что ему кажется важным. Надо бы уйти от портянок)))
Некоторые Ваши утверждения, типа "В BPM CBOK нет про PDCA" - меня вводят в ступор
У меня есть бумажная версия BPM CBOK 3.0, в ней действительно есть упоминание про цикл PDCA (2 глава Управление бизнес-процессами, раздел со странным длинным названием 2.8 "Чтобы обеспечить целостность процесса и возможность непрерывного совершенствования, управление бизнес-процессом должно осуществляться по замкнутому циклу). Но это упоминание - справочная информация и декларация (даже в этом разделе никаких примеров). И в дальнейшем в примерах описания процессов по тексту я найти практическую реализацию цикла PDCA не увидел. Т.е. декларируется что это важно, что это основа, а в примерах об этом 0.
У меня есть электронная версия BPM CBOK 4.0, так там уже нет и такого раздела и упоминания цикла PDCA (я искал текстовым поисковиком и не верил своим глазам). Поэтому я и попросил скрин шоты из 4.0 если можно, и примеры описаний из него же, где по Вашему мнению описывается применение этого цикла на практике. Если в 4.0 нет таких примеров, то может из других версий найдутся скриншоты (мне очень интересно посмотреть).
Пожалуйста смотрите Алису
Я имел в виду эту сводку от Алисы только, глубже в публикации со страницы поиска я не смотрел и не рекомендовал. Статью которую Вы посмотрели по моей вине я даже не читал. Могу сказать только, что ИМХО Теория ограничений НИКАКОГО отношения к ИСО 9000 или процессному подходу не имеет
Однако прикладную теорию надёжности под себя «подмял» риск‑менеджмент, а его в свою очередь управление качеством (ISO 9000), притом с замахом на «всеобщее» (TQM). Начало было положено в 1993 через двойные стандарты МЭК 300–1 / ИСО 9000–4 и это называлась: гармонизация стандартов МЭК по управлению надежностью (серия 300) и стандартов ИСО по управлению качеством (серия 9000) [Depend3]. В заставке к статье обыгрывается обратный путь («возвращение к истокам»): От Управления качеством к Управлению надежностью.
Это из Надежность в процессах. Часть 1. Тоже не согласны?
Это не так. С момента рождения в 2000 году, это был и остается стандарт процессного подхода. Просто вместо 8 принципов менеджмента в версии 2000 года, начиная с версии 2008 года их осталось 7 (принцип Системного подхода к менеджменту исключили). Никакого переименования не было. Как был процессный подход, так и остался.
Так история iso9k вроде бы раньше началась. Если есть, что добавить в файлик с историей - скажите.
Т.е. я утверждаю НЕ СХОДИМОСТЬ результатов при разработке процессного управления by BPM vs ISO. Для одной и той же организации получаться разные по составу процессы, подходы к управлению ими как системой и очень разные результаты такого управления (я считаю, что получаемые результаты by BPM неудовлетворительные)
Я утверждаю, что такая НЕ СХОДИМОСТЬ - это большая проблема.
Т.е. мы хотим внедрить в компании один и тот же Процессный подход, но разными методиками (BPM vs iso9k) и получаем разный результат - разный Процессный подход? Хотелось бы что-то типа сравнительной таблички.
А Вы можете вспомнить/поделиться данными о том откуда Вы получили знания о стандартах ИСО серии 9000 (кто учил, что за учебный процесс был)?
Самое начало 200-х. Тогда было Пришествие ARIS в РФ и одновременно бум СМК. Деталей не помню, но оба улучшайзинга (Best Practice) изучались параллельно. Тогда было модно использовать BPM для СМК: на подобном или таком.
Про Историю стандартов ISO серии 9000, то как ее видят в Прикладном мире (как рассказываем своим клиентам ее мы - консалтинговая группа компаний Приоритет):
ГЛАВНОЕ, нужно понимать причины появления этих стандартов. Прежде всего, это потребность обеспечивать необходимую эффективность работы цепей поставок в условиях все увеличивающегося давления со стороны потребителей (ужесточение требования цена/качество, сокращение сроков и увеличение точности поставок, лавинообразный рост номенклатуры из-за персонализации требований, радикальное сокращение сроков на разработку новых изделий, работа в отсутствии "твердого ТЗ" от Потребителей (Agile в промышленности), глобализация рынков поставщиков (в цепях поставок представителей каких только стран нет)). Стандарты должны были все эти вопросы решить (единый язык для взаимосвязей в секторе B2B на требования компании финишера в цепи поставок, который поставляет готовую продукции Пользователям, быстрое согласование процессов, понятные вектора в развитии цепей поставок и т.п.).
Плохие результаты работы цепей поставок (плохое качество и срыв поставок, медленные сроки разработки и согласований, ...) - это следствия, причина - плохое управление: потери ориентации на требования Потребителя в цепях поставок, рассогласование действий подразделений внутри предприятий цепей поставок, и т.п. Управлять нужно не следствиями, а причинами, поэтому появились стандарты на системы управления Предприятий, которые отлично настраивались бы на требования Потребителя в цепях поставок В2В и могли их точно реализовать (соответствовать своим же обещаниям) - т.е. настраивались на требования по КАЧЕСТВУ от Потребителей - системы управления предприятий участников цепей поставок должны стать СМК.
Версии с 1987 - 1994 - до 2000 - попытка обеспечить выполнение вышеописанной задачи в рамках текущего функционально-иерархического подхода к управлению. Стандарты - это 20 разделов - 20 групп требований к функциональным подразделениям. Эти стандарты на УРА вписывались в BPM, т.к. в 20 разделах перечислялись операции, которые должны были выполняться в подразделениях. ГАРМОНИЯ между ISO и ARIS (который разработан в то же время - будущая основа BPM, базис как и у ИСО - управление на основе функциональной иерархии, нотации для описания операций из 60х - то что доктор прописал для этого). Тогда же создаются решения класса ERP (SAP) которые также ориентированы на модель управления на основе функциональной иерархии. Это время ГАРМОНИИ ISO-ARIS-ERP и фактически действующих на предприятиях функциональных иерархий. Тогда утверждения что ISO и ARIS (BPM) - это одно и то же, были верные!
Все бы хорошо, но проблема не решилась - результаты работы цепей поставок лучше не стали. И ERP созданные на основе ISO и ARIS - автоматизировали хаос (честно/хорошо описывали функциональную иерархию на предприятиях в виде карт операций, но в итоге получались те же неприемлемые результаты работы цепей поставок, предприятия не могли выполнить свои же обещания/планы)
Поэтому в 2000 году произошла революция в понимании, как нужно управлять цепями поставок: главным виновником была объявлена функциональная иерархия, ее предлагалось предать анафеме, а вместо нее строить системы управления на основе прямо настраивающихся непрерывно взаимодействующих процессов верхнего уровня, чтобы требования Потребителей без искажений доходили до всех сопричастных, любые изменения/отклонения - сразу обнаруживались и принимались согласованные сбалансированные корректирующие действия. Поэтому и появились стандарты 2000 года про Процессный подход, в которых в явном виде описывалось, как должно быть реализовано такое процессное взаимодействие (и именно эта нотация описания процессов в 100-1000 раз многоаспектней и сложнее, чем нотации IDEF[ или BPMN? поэтому я в т.ч. и говорю, что не может быть одинаковых систем управления, которые описаны настолько разными нотациями). Никакой преемственности со старыми версиями стандартов НЕ БЫЛО. Предприятиям, у которых были сертификаты соответствия на старые версии стандартов был дан 3х летний срок, чтобы они перестроили свои системы управления с функциональных иерархий на процессный подход в понимании ISO версии 2000.
Именно тогда сформировался идеологический разрыв и с ARIS (и с ERP решениями), которые на самом деле описывали функциональные иерархии. К сожалению, благодаря Шееру, совпало название "процессный подход" и IT отрасль де-факто проигнорила изменения в Прикладном мире, посчитав, что они давно уже "процессный подход", и снобистски не стали разбираться с тем, что в ИСО была заложена совсем другая идея, как управлять организацией, которая тоже назвали "процессный подход"!
Про надежность
То что описано в ссылке на Вашу публикацию - это точно другой язык, другая проблематика и другие решения вроде бы универсальной задачи про надежность, чем родственная постановка задачи в Прикладном промышленном мире. В Вашей публикации говорится про какую-то IT надежность (как я это воспринял).
Постановка задачи надежности в Прикладном мире - это термины стабильности/воспроизводимости технологических операций, процессов, соответствующие индексы CP/CPk, планы управления операциями и контрольные карты Шухарта (в автомобильной отрасли) или хорошо распространенная аналогичная по идеологии (немного другая по исполнению и инструментам) методология 6sigma. Их идеологическая основа - изучение влияния факторов изменчивости действующих на процесс, и выработка планов управления процессом на основе наблюдения за особо сильнодействующими факторами изменчивости. Алгоритм: выявить факторы изменчивости действующие на процесс, определить какие из них и как влияют на процесс, выделить существенно влияющие, научится наблюдать за ними, построить план управления процессом в зависимости от результатов наблюдения. Эту революцию в управлении качеством процессов IT-отрасль, с моей точки зрения, так же проигнорила/проспала, т.к. этих решений нет в текущих релизах ERP, и в специализированных IT решениях (которые я наблюдаю в компаниях-клиентах) для конструкторов, технологов, производственников, ремонтников оборудования(((
И мой главный вопрос, который меня интересует (из за чего я пришел на ХАБР): за какие ниточки нужно подергать, чтобы IT отрасль "повернулась передом" к знаниям Прикладного мира (которые откровенно проспала, и поэтому де факто кормит Прикладной мир только идеологически устаревшими продуктами, т.к. других у нее нет) и начала процесс изучения и интеграции этих знаний в IT продукты?
Как и кому нужно эту идею донести? Что сделать, чтобы IT отрасль начала учиться (перестала думать что все знает и так)?
Именно тогда сформировался идеологический разрыв и с ARIS (и с ERP решениями), которые на самом деле описывали функциональные иерархии. К сожалению, благодаря Шееру, совпало название "процессный подход" и IT отрасль де-факто проигнорировала изменения в Прикладном мире, посчитав, что они давно уже "процессный подход", и снобистски не стали разбираться с тем, что в ИСО была заложена совсем другая идея, как управлять организацией, которая тоже назвали "процессный подход"!
Так я и прошу в каждом своем ответе сравнительную табличку. Например, четыре графы:
1 Критерий Процессного подхода (чем детальнее, тем лучше)
2 Реализация критерия Процессным подходом в СМК\iso9k
3 Реализация критерия Процессным подходом в BPM (BPM CBOK\ARIS - у них в целом одинаковый взгляд на Процессный подход)
4 Комментарий по их несовпадению
Из нее будет понятно, какой Процессный подход - именно процессный, а какой не очень.
Покажите источники и цитаты, из которых Вы сделали вывод, что Шеер и CBOK неверно понимают смысл Процессного подхода.
Приведу цитату гуру:
Требованиям процессного и системного подхода наиболее удовлетворяет инструментальная система ARIS 6.1, реализующая одноименную методологию.
Обращаю внимание, что указанная публикация по ARIS в контексте именно "уже процессного" ИСО 9001:2000. Более того, ARIS и до ИСО 9001:2000 был вроде как процессным и ему не нужно было "на лету переобуваться" в 2000, как это сделал iso9k. При этом концепт ARIS Шеера имеет более длительную историю чем iso9k.
Конечно, чтобы продать ARIS (другую BPM-систему) или консалтинг BPM или сертификат ИСО 9000 (причем вначале не процессный, а потом еще раз, но уже процессный) можно было для маркетинга использовать разнообразные "громкие лозунги", поэтому в сравнительную табличку хотелось бы записать концептуальные различия со ссылкой на контекст.
И ERP созданные на основе ISO и ARIS - автоматизировали хаос (честно/хорошо описывали функциональную иерархию на предприятиях в виде карт операций, но в итоге получались те же неприемлемые результаты работы цепей поставок, предприятия не могли выполнить свои же обещания/планы)
Повторюсь, что ARIS - это не совсем про автоматизацию, а скорее про Реинжиниринг с его лозунгом "Не автоматизируй это!". Именно моделирование + процессный подход были "визитной карточкой" ARIS в РФ.
Так я и прошу в каждом своем ответе сравнительную табличку
Странное дело, я считаю, что все уже про разницу Вам разжевал (и не по одному кругу), а Вы мои аргументы "в упор" не видите, все требуете эту разницу описать!? Смотрите, что получается: для меня, то что я пишу - ОТВЕТ с большим смыслом, а Вы этот мой ОТВЕТ из-за того, что его либо не понимаете, либо не видите в нем смысла, либо в Вашей системе знаний это совершенно не значимый факт, что то еще... но пропускаете (не воспринимаете) как ОТВЕТ!
Вот попробовал свести в табличку мои ответы (правда не знаю, как ее корректней отобразить - исходник сделал в worde):
Обращаю внимание, что указанная публикация по ARIS в контексте именно "уже процессного" ИСО 9001:2000. Более того, ARIS и до ИСО 9001:2000 был вроде как процессным и ему не нужно было "на лету переобуваться" в 2000, как это сделал iso9k. При этом концепт ARIS Шеера имеет более длительную историю чем iso9k.
Услышьте уже меня: то что называется процессным подходом в ARIS и в ISO 9000 - две огромные разницы!!!! ARIS НИКОГДА не мог и не может (в нем даже средств таких не предусмотрено) реализовать процессный подход by ISO 9001. То что Шеер обозвал процессами и процессным подходом не соответствует тому, что в ISO 9001 называют процессами и процессным управлением. Модель процессов которую способен сформировать ARIS - это описание функциональной иерархии языком операций, которое обозвали процессами и процессным подходом! Именно этот снобизм IT отрасли, который не видит и не понимает разницы, при этом не хочет учиться, меня поражает! Я Вам уже наверное более 10 раз явным образом сказал что разница огромна, написал кучу текстов, аргументов. Вы в ответ не привели ни одного аргумента, кроме деклараций что подход by BPM одно и то же и все он реализует (и Lean - что категорическая неправда, и PDCA - до сих пор не увидел примера применения, в ИСО - PDCA вшит в нотацию, в BPM - ничего и близкого нет), но каждое сообщение мне опять и опять утверждаете что процессней ARIS и BPM ничего на свете нет, он может все (сильно во что-то верить, это может быть и хорошо, но не плохо бы уметь рационально объяснить, привести аргументы, доказать, а не просто ВЕРИТЬ)!!! Я устал уже Вам повторять, что ARIS (ИЗЬ by ARIS) может мало чего, и результаты дает неприемлемые, именно на замену ему ISO версии 2000 придумали!!! Видимо, Вам как специалисту по BPM это принять очень не просто...
Повторюсь, что ARIS - это не совсем про автоматизацию, а скорее про Реинжиниринг с его лозунгом "Не автоматизируй это!". Именно моделирование + процессный подход были "визитной карточкой" ARIS в РФ.
Да я Вам уже говорил, что я не делаю НИКАКОГО упора на "только автоматизация" или "есть еще реинжиниринг с управлением". Я Вам говорю о том, что подход к формированию процессного управления by BPM такой, что автоматизация ли, реинжиниринг ли, управление ли - все вместе это будет реализовано, или по отдельности, но эти решения будут давать НЕПРИЕМЛЕМЫЕ результаты!!!! Потому что модель процессов и процессного управления by ARIS (BPM) слабенькие, в ISO намного интересней/мощней идея!
Несколько сравнений. Финал - конкретные методики.
Спасибо за проделанную работу с AI и присланные материалы по АРОСА.
По AI (оценка результатов от AI, а не Ваших усилий): результат на 3чку, т.к. сдается мне Вы в них увидите подтверждение своих тезисов, я - своих, т.е. это такой "набор снарядов" под любой вывод, и именно это я считаю системным интеллектуальным недостатком возможностей AI (ничего никому доказать не сможет).
PS: AI тоже, как и я, не нашел PDCA в BPM и АРОСА и рекомендовал последним этот цикл внедрить)))
По АРОСА - готов дать обратную связь по проекту АРОСА, если Вам это интересно (скажите куда, и где - может в телеграмм для оперативности?)
По АРОСА - готов дать обратную связь по проекту АРОСА, если Вам это интересно
Интересно.
Полагаю, что пока ближе к "ничья", но мне качество Методик внедрений Проц. Подхода из "лагеря BPM" пока не нравится. Буду искать.
Как вариант, самим (с ИИ тоже) скомпилировать Большую подробную методику внедрения, где не только будет "много шагов" - причем с указанием шаг из iso или bpm, но и с организацией самого проекта (как в Простой методике) - со ссылками на PMBOK, а также с финальным чек-листом, по которому можно проверить, что внедрено именно то, что хотели вначале, т.е. Процессный подход.
У Вас нет каких-либо подробных методик внедрения Процессного подхода, может из lean?
Также мне видится, что может быть классификация этих самых Процессных подходов. Есть идеи?
По PDCA в личку написал.
(1) По результатам работы AI как я понял между тезисами «ОДНО и ТО ЖЕ» и «НИЧЕГО ОБЩЕГО» ничья
(2) Мои мысли/восприятие результатов работы AI как инструмента чуть подробнее:
· ГЛАВНОЕ я не понял, что он доказал или опроверг, неопределенность как была, так и осталась! Как я понял, у Вас такое же мнение?
· Я увидел много элементов/выводов подтверждающих мою логику и тезисы. Вместе с тем, количество элементов/выводов их опровергающих так же существенно много.
· Очень много текста, очень много повторов, «мясо надо искать» (редкие хорошие выводы и аргументы находятся в огромном море «воды» и вызывающих сомнения артефактов и заключений, при этом эти хорошие выводы могут в этом же тексте опровергаться и/или вступать в противоречия с другими выводами).
· Какой-то цельной линии смыслов с логичным взаимосвязанным повествованием не прослеживается – материалы воспринимаются как лоскутное одеяло полное противоречий. Такая ситуация, думаю, позволяет любому читателю «надергать свидетельств от AI» и увидеть в этом тексте «свою» правду и подтверждение «своей» логики.
· Выводы в стиле «и ты прав, и так можно, а еще лучше все объединить» настолько общие, что их можно было сделать до проведения этого исследования.
Например:
AI упорно сужает рамки ISO до «управление качеством продукции/процессов» (не знает он видимо концепции TQM или не способен связать ее с ISO и СМК), по сравнению с BPM, который работает на целостное управление организацией, и при этом тут же утверждает, что ISO носит более стратегический характер по сравнению с BPM!? В каком воспаленном мозгу эти два утверждения могут сосуществовать одновременно)))
Я так же как и Вы остался не доволен тем, как AI описал и трактовал процессный подход by ISO
(3) Что делать с этим материалом-заготовкой от AI? Можно провести эксперимент: Вы и Я на основе текстов AI составим каждый свое резюме с доказательствами от AI и посмотрим что получилось? Можно попробовать его совместно «причесать», только сможем ли мы договорится и согласовать наши правки!?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Треугольник орг-структур компании. Часть 1