Комментарии 20
Я заметил, что на Рис. 1. Методологии бизнес-процессов есть Casewise и CW, что как я предполагаю одно и то же в контексте. Хочу заметить, что такого продукта и бренда в настоящий момент уже нет. Это все ушло в erwin.
В таблице методологии потоков данных есть, а реализаций нет. Очень хотелось бы знать, почему так?
Cвязанный вопрос: почему BPM развивается отдельно от Scientific workflow? А ведь scientific workflow базируется именно на потоках данных.
Вообще мне представляется, что методология потоков данных — самая основная, остальные являются ее производными. Или даже искажениями и ограничениями. Но я в BPM не специалист. Хотелось бы узнать мнение специалиста — почему он не базирует свои работы на потоках данных.
Cвязанный вопрос: почему BPM развивается отдельно от Scientific workflow? А ведь scientific workflow базируется именно на потоках данных.
Вообще мне представляется, что методология потоков данных — самая основная, остальные являются ее производными. Или даже искажениями и ограничениями. Но я в BPM не специалист. Хотелось бы узнать мнение специалиста — почему он не базирует свои работы на потоках данных.
Вопрос реализации той или иной нотации связан со спецификой моделируемой области. Модели потоков данных, например DFD, а также и Scientific workflow, описывают именно последовательность действий (процесс продажи или отгрузки товара, работу с заявками от клиентов или закупки материалов, технологический процесс), но не являются описанием непосредственно бизнес-процесса. Т.е. в этих нотациях описывается не столько непосредственно процесс, сколько движение потоков данных. В DFD, например, нет такого важного параметра, как время.
По этой причине я не использовал модели потоков данных. А вообще, использование той или иной модели является в определенной мере делом вкуса и сильно зависит также от степени освоения той или иной нотации.
По этой причине я не использовал модели потоков данных. А вообще, использование той или иной модели является в определенной мере делом вкуса и сильно зависит также от степени освоения той или иной нотации.
«в этих нотациях описывается не столько непосредственно процесс, сколько движение потоков данных»
А что еще нужно, чтобы описать непосредственно процесс? Ведь модели потоков данных включают в себя не только потоки данных, но и реакции на вновь поступившие данные, которые производят вычисления, генерируют новые данные и т.д.
Вы назвали время — я полагаю, достаточно подключить процесс-таймер. Чего еще не хватает в потоках данных, чтобы описать процесс?
А что еще нужно, чтобы описать непосредственно процесс? Ведь модели потоков данных включают в себя не только потоки данных, но и реакции на вновь поступившие данные, которые производят вычисления, генерируют новые данные и т.д.
Вы назвали время — я полагаю, достаточно подключить процесс-таймер. Чего еще не хватает в потоках данных, чтобы описать процесс?
Инструкция, регламентирующая расчет стоимости, включает многостраничный текст, и чтобы ее прочесть и освоить, понадобится как минимум несколько дней. Диаграммы составлены в строгом соответствии с этой инструкцией, но, естественно, они ее не заменяют, а дополняют – благодаря простоте и наглядности экономят время на расчеты
Изначальную инструкцию хорошо использовать для составления тестов к функционалу, чтобы удостовериться, что код работает именно так, как написано. А уж имплементить ее именно таким образом никто не заставляет. Адекватный программист (не занимающийся BPM) вместо "процесса рассчета стоимости номера в пансионате" заимплементил бы простую и наглядную функцию с тремя условиями на семь строчек кода. А адекватный аналист пришел бы к клиенту и сказал: "а давайте вместо этой фигни попробуем сделаем простую наглядную таблицу коэффициентов для стоимости номера, которую к тому же можно будет менять в любой момент". И только BPM аналист, у которого в голове одни схемы, станет изобретать некий "процесс" для вычисления простой функции, вместо того, чтобы записать простую формулу.
Итак, что же на самом деле может получить компания, если пропишет сверху донизу все свои бизнес-процессы, что должно явиться целью подобной весьма громоздкой работы?
Это понятно, упорядочение, автоматизация и все такое. И BPMS здесь как бы даже сбоку. Скажите лучше о граблях:
- уменьшение общей гибкости взаимодействия — все жестко поставлено на рельсы, по полю уже не проедешь
- увеличение рисков нештатных ситуаций (что-то пошло не по процессу) и отсутствие соответствующих инструкций для реагирования
- формализация управления и разделение труда ведет к тому, что меньше людей имеет общее представление о решаемой задаче, что ведет к общей бюрократизации
- несмотря на предоставляемый автоматический мониторинг и обилие метрик, выявление неэффективностей в процессах будет затруднено и более того, реально никто этим заниматься не собирается. Метрики используются исключительно для составления бесполезных отчетов, а не для анализа.
И когда ситуация ухудшается полностью, вызывают бригаду "оптимизаторов бизнес процессов", которые обнаруживают, что несмотря на всю автоматизацию и BPM, треть персонала фактически ничем не занята, а все бизнеспроцессы надо (опять) менять. Иногда это помогает.
Чтобы подробно ответить на Ваш комментарий, мне придется написать еще одну статью. Но попытаюсь кратко.
В тексте исходной инструкции содержалось ровно 20 формул, а не одна. Кроме этого, следовало учесть специфику Центробанка (заказчика), который видел всю проблему отнюдь не упрощенно, а требовал пошаговое исполнение всей процедуры. Наконец, по схемам был составлен код, который содержал далеко не гигантское число строк.
Что касается Ваших опасений в связи с использованием BPMN. Эти опасения могут наложиться на любой управленческий процесс, и я целиком согласен с представленным Вами списком. Вы, очевидно, глубоко прочувствовали на своей коже, во что может вылиться любая регламентация деятельности. Как всего этого избежать, как говорится, это совсем другая история. Спасибо за комментарий.
В тексте исходной инструкции содержалось ровно 20 формул, а не одна. Кроме этого, следовало учесть специфику Центробанка (заказчика), который видел всю проблему отнюдь не упрощенно, а требовал пошаговое исполнение всей процедуры. Наконец, по схемам был составлен код, который содержал далеко не гигантское число строк.
Что касается Ваших опасений в связи с использованием BPMN. Эти опасения могут наложиться на любой управленческий процесс, и я целиком согласен с представленным Вами списком. Вы, очевидно, глубоко прочувствовали на своей коже, во что может вылиться любая регламентация деятельности. Как всего этого избежать, как говорится, это совсем другая история. Спасибо за комментарий.
Согласно моему опыту основной ошибкой клиента всегда было неправильное внедрение BPM. Последнее предполагает не только смену методики работы компании, но и определенную реструктуризацию, на всех уровнях. А к этому бывают далеко не все готовы. Кроме того есть ряд тормозящих политических факторов, например, топ-менеджеры и управляющие кадры, которые не очень счастливы, чтобы с их работы снимали различные метрики эффективности либо как-то реструктурировали. Поэтому на "попробовать" всегда берут какой-нибудь департамент из Operations и насильно втюхивают туда BPMS, где его вообще в гробу видели, и где большинство процессов уже автоматизировано на 100%. В итоге параллельно с уже работающим стеком, вторая бригада пыхтит над тем, чтобы перевести все процессы на BPMS, вызывая лютый баттхерт у первой по причине постоянного ощущения инородного тела в заднице. По прошествии n-дцать месяцев то, что добивается данная бригада, это сделать тупую прокси-надстройку с парой линейных "процессов" над уже работающими сервисами, гордо объявив это все "Orchestration Layer". После этого отчитываются наверх об успешном запуске, получают медаль и на этом все завершается.
Не могу удержаться.
Я далеко не специалист, так — интересующийся. Но отвечу. Правда, использую рабоче-крестьянскую лексику.
Уже приготовился ловить помидоры :)
Небольшой бэкграунд: работаю в ФГУП, бумаги — вагоны, бардак полнейший, BPMN — такого матюка тут даже не знают.
1. Уменьшение гибкости в большой конторе — это хорошо. Каждый знает своё дело, и информация идет по налаженным потокам именно тому, кому она нужна и в оптимальном для получателя виде. И нет ситуации, когда бумажка (да, я всё про реальность, а не про ЭДО) попадает всем, кому она не нужна, но только не тому, кому она нужна.
У нас, например, это норма жизни.
2. Если что-то пошло не по процессу, значит процесс нуждается в обновлении. Инструкция тут одна — обновить бизнес-процесс с учетом новой информации. BPMN — это не разовая штука, это непрерывный процесс. А будут ли эти функции выполнять штатные сотрудники или контора на аутсорсе — это все опционально.
3. Всё как раз наоборот. Вернее, это зависит от управленцев и их умения управлять.
Грамотное внедрение BPMN как раз ведет к тому, что каждый человек начинает видеть свой личный вклад в создание стоимости продукта(услуги), и видит своё место работы как неотъемлемую и важную часть линейки процессов создания стоимости продукта.
Грамотное внедрение — это вовсе не тот случай, когда в один прекрасный день приходит начальник, приносит кучу инструкций и говорит: «отныне и навсегда ты делаешь это, это и это, и, ради Бога, никогда меня не спрашивай, для чего и почему ты это делаешь».
4. См. пункт 2. BPMN — это не разовая штука, это непрерывный процесс.
Если приехали гераклы на авгиевы конюшни, значит руководство не поняло, что такое BPMN и зачем оно надо.
Кстати, всё это отличным, понятным даже таким альтернативно одарённым личностям, как я, прекрасным русским языком изложено в переводе труда под названием "Свод знаний по управлению бизнес-процессами (BPM CBOK 3.0)". Альпина паблишер, вы мне должны за рекламу :) Не хотите покупать — есть йо-хо-хо эдишн.
В оригинале (англ.) это гуглится как «BPM CBOK 3.0», есть на Амазоне, например.
По сути мои ответы состоят из знаний, полученных из данного источника, плюс практика «как не надо делать» в ФГУП :) Книга — действительно компиляция всего более чем 50-летнего опыта разработки и внедрения методик BPMN на предприятиях. Советую к прочтению, лишним не будет никогда.
Я далеко не специалист, так — интересующийся. Но отвечу. Правда, использую рабоче-крестьянскую лексику.
Уже приготовился ловить помидоры :)
Небольшой бэкграунд: работаю в ФГУП, бумаги — вагоны, бардак полнейший, BPMN — такого матюка тут даже не знают.
1. Уменьшение гибкости в большой конторе — это хорошо. Каждый знает своё дело, и информация идет по налаженным потокам именно тому, кому она нужна и в оптимальном для получателя виде. И нет ситуации, когда бумажка (да, я всё про реальность, а не про ЭДО) попадает всем, кому она не нужна, но только не тому, кому она нужна.
У нас, например, это норма жизни.
2. Если что-то пошло не по процессу, значит процесс нуждается в обновлении. Инструкция тут одна — обновить бизнес-процесс с учетом новой информации. BPMN — это не разовая штука, это непрерывный процесс. А будут ли эти функции выполнять штатные сотрудники или контора на аутсорсе — это все опционально.
3. Всё как раз наоборот. Вернее, это зависит от управленцев и их умения управлять.
Грамотное внедрение BPMN как раз ведет к тому, что каждый человек начинает видеть свой личный вклад в создание стоимости продукта(услуги), и видит своё место работы как неотъемлемую и важную часть линейки процессов создания стоимости продукта.
Грамотное внедрение — это вовсе не тот случай, когда в один прекрасный день приходит начальник, приносит кучу инструкций и говорит: «отныне и навсегда ты делаешь это, это и это, и, ради Бога, никогда меня не спрашивай, для чего и почему ты это делаешь».
4. См. пункт 2. BPMN — это не разовая штука, это непрерывный процесс.
Если приехали гераклы на авгиевы конюшни, значит руководство не поняло, что такое BPMN и зачем оно надо.
Кстати, всё это отличным, понятным даже таким альтернативно одарённым личностям, как я, прекрасным русским языком изложено в переводе труда под названием "Свод знаний по управлению бизнес-процессами (BPM CBOK 3.0)". Альпина паблишер, вы мне должны за рекламу :) Не хотите покупать — есть йо-хо-хо эдишн.
В оригинале (англ.) это гуглится как «BPM CBOK 3.0», есть на Амазоне, например.
По сути мои ответы состоят из знаний, полученных из данного источника, плюс практика «как не надо делать» в ФГУП :) Книга — действительно компиляция всего более чем 50-летнего опыта разработки и внедрения методик BPMN на предприятиях. Советую к прочтению, лишним не будет никогда.
Не все так плохо в России с BPM
Угу. Еще в 2001 году работал в России с этим делом.
Как раз ARIS
Крупная общероссийская торговая фирма — 40 регионов охватила на тот момент.
Извиняюсь за оффтоп, но споткнулся о текст:
«Лучшим ВРМ-проектом среди государственных организаций» признан проект «Управление бизнес-процессами», реализованный Сбербанком.
и сразу в памяти всплыло:
Тем не менее, BPM считаю темой интересной и перспективной.
GKasatkin, вот тут в группе есть ответ экспертов на вашу статью www.facebook.com/groups/bpmcafe
За основу для построения рис. 1 в своей статье я взял рисунок 2.5 по методологии бизнес процессов из книги В.В. Репина и В.Г. Елиферова «Процессный подход к управлению» (Гл 2, стр. 79) и дополнил его. Жаль, что в исходном рисунке нет КОМПАС, ЛОЦМАН, T-FLEX, исчезли ER-модели и UML, и нет также других нотаций, иначе я их обязательно бы упомянул.
Спасибо В.Г. Елиферову за высказанные замечания.
С уважением, Касаткин Г.
Спасибо В.Г. Елиферову за высказанные замечания.
С уважением, Касаткин Г.
Работаю в госкорпорации, BPM-моделирование — корпоративный стандарт.
Из практики скажу, что не раз выявлял «дырки» и «просадки» в процессах после составления BPMN-диаграммы.
Из практики скажу, что не раз выявлял «дырки» и «просадки» в процессах после составления BPMN-диаграммы.
На Рис. 1 VAD и eEPC указаны как программный продукт, что не правильно.
На Рис. 3, как мне кажется, процесс отображен некорректно: зачем делать две совершенно одинаковые ветки? Ведь процесс протекает одинаково, даже если на входе разные исходные данные (сезон-несезон). Корректнее, понятнее и нагляднее было бы сделать одну ветку с проверкой на определенном этапе сезона, в котором делается расчет.
На Рис. 3, как мне кажется, процесс отображен некорректно: зачем делать две совершенно одинаковые ветки? Ведь процесс протекает одинаково, даже если на входе разные исходные данные (сезон-несезон). Корректнее, понятнее и нагляднее было бы сделать одну ветку с проверкой на определенном этапе сезона, в котором делается расчет.
По поводу VAD и eEPC мне уже и другие читатели заметили, так что замечание правильное.
Что касается рис. 3, то тут вопрос не так однозначен. Лаконичнее и красивее диаграмма выглядит с одной веткой. Но надо было учесть специфику заказчика, который хотел «разжевать» процесс до предела. А программист, когда код писал, и так все понимал, и лишних строк не создал.
Что касается рис. 3, то тут вопрос не так однозначен. Лаконичнее и красивее диаграмма выглядит с одной веткой. Но надо было учесть специфику заказчика, который хотел «разжевать» процесс до предела. А программист, когда код писал, и так все понимал, и лишних строк не создал.
Мне кажется, на первом рисунке допущена ошибка — ни NX, ни CATIA (с остальными приведенными системами не сталкивался) нельзя отнести к PDM. Всетки это системы для моделирования, расчета, технологической подготовки производства. Корректнее было бы указать в разделе «Управление данными о ЖЦ изделия» ту же систему Teamcenter от компании Siemens…
По поводу первого рисунка завязалась довольно оживленная дискуссия и было высказано много правильных замечаний. Я удовлетворен тем, что эта тема вызвала оживление, значит она в какой-то степени востребована. Постараюсь в ближайшее время тщательно подработать данную схему с учетом высказанных замечаний. Спасибо
А Teamcenter входит как составная часть в систему NX той же компании Siemens.
А Teamcenter входит как составная часть в систему NX той же компании Siemens.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Что это такое – BPM, и как компании его строить