Подписаться
Рубрикатор
Полный список
Развитие организации
Управление процессами
Моделирование процессов
Регламентация процессов
Автоматизация процессов
Бережливое производство
Менеджмент качества
Управление проектами
Дайджесты по Business Studio

Облако терминов
12-процессная модель 4PL ACM Activity diagram AQPC ARIS ARIS 9 ARIS eEPC Balanced Scorecard Big Data & Analytic BMPN BPA BPEL BPM BPM accelerator BPM CBOK BPM-система BPM-системы BPMN BPMS BPR BPWin BS Portal BSC Business Intelligence Business Performance Management Business Performance Management (BPM) Business Process Management Business Process Management Systems Business Process Manager Business Rules Business Studio Business Studio 3.6 Business Studio 4 Business Studio 4.0 Business Studio Portal CA ERwin Data Modeler Case Management Casewise Casewise Corporate Modeler CFFC Corporate Modeler CPM CRM Decision Management DFD Directum ECM

Разработка архитектуры бизнес-процессов компании в Business Studio
Опрос

Польза от регламентации процессов для бизнеса:

Библиотека

21.02.2011 17:36
  от автора
  bell

Вульгарное представление о кросс-функциональных бизнес-процессах

Оценки за материал: 4.00 (5)

Первая из трех статей о моделировании и оптимизации кросс-функциональных бизнес-процессов. Перепечатка с блога автора.
Напомню, что кросс-функциональным называется процесс, в котором участвуют несколько подразделений верхнего уровня (по-английски «функций» – отсюда название). С точки зрения процессной методологии, именно на такие процессы в конечном счете должны нацеливаться инициативы BPM, поскольку именно здесь обычно кроются самые большие проблемы, а следовательно, наличествует самый большой потенциал улучшения. Ведь любая иерархическая организация, достигая определенного размера, сталкивается с тем, что собственные интересы подразделений начинают преобладать над интересами компании в целом.

Собственно, это не новая идея: «сломать стены между подразделениями» – это призыв еще реинжиниринга образца начала 90-х. Другое дело, что предложенный классическим реинжинирингом подход к реализации через однократное радикальное преобразование оказался не вполне удачным. Современный BPM принес новые взгляды на то, как это надо делать, но цель осталась та же самая.

Для иллюстрации кросс-функциональных проблем часто используют метафору силосной башни –«functional silo». Аналогия тут следующая: после того, как крестьянин заложил скошенное сено в силосную башню, добраться он может только до небольшой части этого богатства – до верхнего слоя. Точно так же ресурсы, информация, знания, процедуры в иерархически организованной компании оказываются погребены в недрах функциональных подразделений – большая часть этого богатства недоступна для потребителей из других подразделений и не работает на достижения целей компании в целом.

Чисто функциональный взгляд на вещи влечет за собой искаженное представление о том, что для того или иного подразделения «свое», а что «чужое». Так, например, для бухгалтерии естественно считать, что основное ее занятие – это учет и отчетность. А выставление счетов за поставленный товар нужно кому-то другому, например, отделу продаж; для бухгалтерии это досадная помеха ее основной деятельности. Но с точки зрения бизнеса ведь все наоборот: выставление счета – это часть важнейшего с точки зрения ценности для клиента процесса «от заказа до оплаты», а учет и отчетность – это вспомогательная деятельность. Необходимая, так как ее требует государство и она нужна для планирования собственной деятельности. Но все же она не создает ценность, а следовательно, это затраты, которые по возможности следует минимизировать.

Бухгалтерия – это только один пример. Разработка новой продукции, подготовка коммерческого предложения, выполнение клиентского заказа «от и до» –- в компании есть множество вещей критически важных для клиента, а следовательно для бизнеса, но про которые нельзя сказать, что за них отвечает какая-то одна служба.

Кросс-функциональные бизнес-процессы обычно иллюстрируют примерно так:



Рис. 1. Функции и кросс-функциональные процессы.

Однако картинка типа приведенной выше создает совершенно ложное представление о том, как следует решать проблемы, возникающие на стыках между подразделениями. Она порождает вульгарное представление о бизнес-процессе как о простой последовательности шагов: «делай раз – делай два – делай три». Но бизнес так не работает.

Рассмотрим в качестве примера – процесс «от заказа до оплаты»: приняли заказ – произвели – отгрузили – произвели расчеты. Попробуем смоделировать его для случая производства на заказ, буквально следуя картинке на рис. 1:

  1. Процесс начинается, когда отдел продаж получает заказ клиента.
  2. Получив и оформив заказ, отдел продаж передает его в производство.
  3. Производство приступает к выполнению заказа.
  4. Изготовленный товар доставляется заказчику.
  5. Финансовый отдел производит расчеты.



Рис. 2. Кросс-функциональный процесс «от заказа до оплаты», workflow-версия.

Представьте себе: производственный цех стоит пустой, темный и безмолвный. Тут приходит заказ, мастер включает рубильник и все завертелось. Скажете, чушь? Конечно, чушь! Но наивная диаграмма, изображенная выше, предлагает именно такую картину деятельности предприятия.

Более правдоподобной выглядит следующая схема:

  1. Отдел продаж оформляет заказ клиента и размещает его в производстве.
  2. С определенной периодичностью (например, ежедневно) запускается производственное планирование, которое просматривает накопившиеся заказы и составляет производственный график.
  3. Выполнив очередной заказ в соответствии с составленным графиком, производство уведомляет процесс, связанный с клиентским заказом, о том, что товар готов к отгрузке.

В графическом виде:



Рис. 3. Кросс-функциональный процесс «от заказа до оплаты», BPM-версия.

У нас появилось два процесса, взаимодействующих через данные (БД заказов) и сообщения (уведомление о выполнении заказа). Реализовать эту схему в рамках одного пула (одного процесса) принципиально невозможно, так как у процессов «клиентский заказ» и «производство» разные триггеры: поступление заказа от клиента и таймер, соответственно.

Та же история с доставкой и расчетами: их вряд ли удастся реализовать в рамках процесса «клиентский заказ». То есть технически процессов (пулов) тут не два, а больше.

Workflow, BPM и многопоточное программирование

Кросс-функциональные процессы невозможно реализовать при помощи workflow, потому что границы между подразделениями существуют не просто так: они разделяют области с разными распорядками работы и разными ритмами. Существование этих границ нельзя игнорировать, и их нельзя ликвидировать, просто изобразив поток работ, переходящий из одного подразделения в другое так, как изображено на рис. 2.

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



Рис. 4. Кросс-функциональный процесс как координатор функций.

Workflow работает только в пределах одной функции. Как только мы выходим за ее пределы, т.е. как только беремся за кросс-функциональные процессы и начинаем разбираться со стыками между подразделениями, необходимо задействовать более изощренные механизмы взаимодействия между workflow.

Переходя от workflow к межпроцессному взаимодействию, мы переходим от однопоточного к многопоточному программированию.

К сожалению, для многих это становится непреодолимым барьером.

  • Кто-то этот барьер не видит. Бьется об него, набивает шишки, но не понимает, с чем столкнулся.
  • Кто-то барьер инстинктивно обходит: выполняет пилотный проект BPM с процессом типа «Оформление заявление на отпуск». Пилот получается успешный, только какое он имеет отношение к бизнесу?

Отсюда, как мне кажется, проистекает большая часть разочарований в BPM: те, кто сводят его к workflow, терпят прогнозируемое поражение.

Технически, многопоточность – это то, что отличает BPM от worflow. Уберите из BPM взаимодействие асинхронно исполняющихся процессов через данные, сообщения и сигналы, и это будет не BPM, а «workflow на стероидах».

К большому сожалению, это относится ко многим современным программным продуктам с агрессивным маркетингом, позиционирующим их как BPMS. Для меня главный критерий полноценной BPMS – это наличие в продукте поддержки сообщений в стиле BPMN. Есть и другие критерии, но этот на практике оказывается самым полезным, так как со всем остальным – графическим моделированием, workflow-движком, веб-порталом, бизнес-аналитикой – лучше или хуже справляются все разработчики, а с поддержкой межпроцессного взаимодействия – единицы. Скорее всего не потому, что это так уж сложно, а потому, что никто не объяснил насколько это важно.

Но сказать «осваивайте многопоточное программирование процессов» легче, чем последовать этому совету. В ответ раздается стон: «какой же сложный этот BPMN, и кто только придумал в нем 50 разных видов событий!».

Сложен не BPMN – сложен бизнес!

Кто бы вам не обещал простые средства решения бизнес-проблем, будь то BPM или что-то другое – не верьте! Бизнес – это конкурентная область человеческой деятельности: талантливые и изощренные люди соревнуются в ней за то, кому будет житься хорошо, а кому – не очень. Поэтому бизнес был, есть и останется делом сложным.

Сложность BPMN не чрезмерна – она адекватна сложности бизнеса. У слушателей моего тренинга по BPMN не остается вопроса зачем столько событий: все нужны! И кстати, обратите внимание: в части workflow BPMN 2.0 практически не отличается от 1.x – стандарт развивается в направлении более изощренной поддержки многопоточного программирования: choreography, conversation.

Если бизнес и можно запрограммировать, то только как многопоточную систему.

BPM и ACM

Тут я сознательно ступаю на скользкую почву, так как предвижу реакцию адептов ACM (Advanced/Adaptive Case Management): «Ага! Мы всегда говорили, что бизнес в принципе нельзя запрограммировать!»

Может быть можно, может быть нельзя… Скорее всего, в каких-то случаях можно, а в каких-то нет.

Вот говорят, что доля knowledge work постоянно растет. Но где именно она растет? В США, активно выводящих всю рутинную деятельность в Азию. Вот и сообщают нам сидящие в США аналитики о своих вполне прогнозируемых наблюдениях. Но ведь насколько выросла доля knowledge work в одном месте, ровно настолько же выросла доля routine work в другом. А управлять рутинными процедурами, исполняющимися на другом конце глобуса – это ведь самая подходящая для BPM задача.

В свете вышеизложенного я хотел бы поинтересоваться у критиков BPM из числа адептов ACM: вы уверены, что критикуете BPM, а не wokflow? Не являются ли объектом вашей критики BPM-проекты, в которых либо пытались решать задачи бизнеса, не выходя за рамки workflow, либо бизнес-проблематика вообще отсутствовала?

Потому что в этом случае их провал предсказуем, но он вовсе не означает, что BPM указывает неверный путь. Просто тщательнее надо работать.

Что касается ACM, то это безусловно вещь полезная, но только как дополнение к BPM, а не как замена. Плюс к этому, ACM на сегодняшний день вещь менее зрелая, чем BPM, и поэтому тот, кто наломал дров с BPM, с ACM скорее всего наломает дров еще больших.

Комментарии

Оценки: /
21.02.2011 23:59
  от автора
  Репин
Спасибо Анатолию за интересный материал!

Некоторые соображения.

"...Существование этих границ нельзя игнорировать, и их нельзя ликвидировать, просто изобразив поток работ, переходящий из одного подразделения в другое так, как изображено на рис. 2..."

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

"...Переходя от workflow к межпроцессному взаимодействию, мы переходим от однопоточного к многопоточному программированию..."

Многопоточность - отличная идея! Не занимаясь BPMN и внедрением BPMS, тем не менее постоянно сталкиваюсь с тем, что бизнес-аналитики рисуют процессы, как показано на рис. 2. Такие схемы, чаще всего, получаются некорректными. Это похоже на рисование процесса "по хвостам" (см. в статье "Особенности создания корректных схем бизнес-процессов"). Кстати, что интересно, некорректность особенно ярко проявляется при попытке описать бизнес на верхнем уровне. Приведу некоторый учебный пример:



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

Возможно, что только описание процессов в парадигме BPMN может дать реальную многопоточную картину бизнеса. Другие нотации пока этого не могут делать так наглядно. С другой стороны, не всегда это нужно. Если стоит задача регламентации, то вполне можно обходиться традиционными кросс-функциональными средствами.
Оценки: /
22.02.2011 09:42
  от автора
  bell
Владимир

Хороший пример в тему, спасибо.

Что касается нотаций - конечно, на "описательном" уровне существует широкий выбор нотаций, и тут с точки зрения конечного результата важно не какая нотация абстрактно "лучше", а какой нотацией аналитик свободно владеет.

Но ведь мы никогда не знаем, останемся ли мы на описательном уровне или в какой-то момент перейдем к исполняемому. С BPMN, который позволяет моделировать и на описательном, и на исполняемом уровне, этот переход произойдет максимально гладко, а с другими нотациями это станет кризисом. В этом серьезное преимущество BPMN.
Оценки: /
22.02.2011 15:45
  от автора
  Репин
Вот-вот. Меня терзают смутные сомнения, что BPMN - единственный выход для корректного во всех отношениях описания бизнеса.

Если бы в Business Studio была реализована возможность моделировать в BPMN при сохранении всех ее мощных возможностей по регламентации, то с удовольствием бы использовал эту нотацию.
Оценки: /
22.02.2011 17:53
  от автора
  Дмитрий Пинаев
"Но ведь мы никогда не знаем, останемся ли мы на описательном уровне или в какой-то момент перейдем к исполняемому. С BPMN, который позволяет моделировать и на описательном, и на исполняемом уровне, этот переход произойдет максимально гладко, а с другими нотациями это станет кризисом. В этом серьезное преимущество BPMN. "
Сегодня и в далеком будущем далеко не все процессы компании будут исполняться в BPM системах. Я считаю, что их будет меньшинство от общего количества. А раз так, то явно не стоит учить весь персонал понимать BPMN, уж лучше 10-20 или 30 процессов перерисовать в BPMN.
BPMN меня отпугивает исключительно сложностью восприятия рядовым персоналом. Но если тендеция использования BPM средств будет набирать обороты, то конечно в BS эта нотация появится.
Оценки: /
22.02.2011 22:45
  от автора
  bell
Дмитрий, а что именно Вас пугает? В чем и в сравнении с чем Вы видите сложность? (Действительно интересно.)

Тезис про "учить весь персонал BPMN" я вообще не понял. Вы считаете, надо учить "весь персонал" IDEF0? Или BS? Мне кажется, персонал в массе своей должен делом заниматься. Бизнесом, а не бизнес-процессами.

Если же речь идет о регламентации, то сгенерить текстовые регламенты из BPMN можно ровно так же, как и из любой другой модели бизнес-процесса.

На стороне BPMN еще одно весомое преимущество: это стандарт, причем стандарт де-факто, принятый всеми основными игроками.

Владимир

При всей моей приверженности BPMN, он не является полным и окончательным решением. На верхних этажах - на уровне архитектуры бизнеса и цепочек создания ценностей - им оперировать неудобно.
Оценки: /
23.02.2011 01:24
  от автора
  Дмитрий Пинаев
Анатолий,
как что пугает? По-моему двух мнений здесь быть не может - изобилие похожих друг на друга графических символов. Если в версии 1.2 еще было более-менее, то в 2.0 (который еще не принят и находится в стадии утверждения 2 или 3 уже года?)- уже явный перебор.

Чтобы персонал мог заниматься делом, он должен понимать, чем ему заниматься, не так ли?
Текстовые регламенты задачи отнюдь не решают. В регламенте должна быть диаграмма. На практике если диаграмма дает ответы на нужные вопросы, текст вообще не читают.

"Если же речь идет о регламентации, то сгенерить текстовые регламенты из BPMN можно ровно так же, как и из любой другой модели бизнес-процесса."
На данный момент это голосовное утверждение.

"На стороне BPMN еще одно весомое преимущество: это стандарт, причем стандарт де-факто, принятый всеми основными игроками."
Насчет "стандарта" не принимаего годами я уже написал. А вы пробовали перенести диаграммы из Tibco в BizAgi? Ничего не получится. А в них используется еще 1.2. Хорош стандарт, нечего сказать.
Очень вероятно, что 2.0 вообше вникогда не примут.
Поэтому в чем преимущество и перед кем - непонятно.

Оценки: /
23.02.2011 01:46
  от автора
  Дмитрий Пинаев
Но тем не менее, у меня нет вопросов к BPMN 2.0 как к языку настройки BPM систем. Все события нужны, все события важны.
У меня есть только большой вопрос к позиционированию нотации - как к мосту дружбы для примерения Айтишников и бизнеса. Если это получится - буду только рад. Пока же на практике вижу как попытки использования BPMN для моделирования процессов "для всех" оборачиваются его упрощениями.
Оценки: /
23.02.2011 10:37
  от автора
  Репин
"...Пока же на практике вижу как попытки использования BPMN для моделирования процессов "для всех" оборачиваются его упрощениями..."

В этом согласен с Дмитрием.

Анатолий, помнишь пример, который я тебе показывал (был подготовлен специалистами некоторой компании). С виду схема вроде в BPMN, но если приглядеться, то это только имитация. "Работать" она не способна. Сколько еще в компаниях таких "умельцев"?

Освоить BPMN сложно. Требуются навыки не только бизнес-моделирования, но и автоматизации процессов. Про себя не скажу, что я его вполне освоил, скорее - нет
Оценки: /
23.02.2011 17:33
  от автора
  bell
>> в версии 1.2 еще было более-менее, то в 2.0 (который еще не принят и находится в стадии утверждения 2 или 3 уже года?)- уже явный перебор.

А Вы интересовались чем конкретно 1.2 отличается от 2.0 или 1.1 от 1.2? Сообщаю: количество элементов там изменилось незначительно, отличия в другом.

>> Очень вероятно, что 2.0 вообше вникогда не примут.

Дмитрий, извините, но по-моему Вы не в теме. Уже приняли.

>> Сколько еще в компаниях таких "умельцев"?

Ну это все равно что обвинять разработчиков MS Word в творчестве графоманов.

>> Освоить BPMN сложно.

Могу только повторить: сложен не BPMN, сложен бизнес.

BPMN конечно есть за что критиковать, но по-моему это большой шаг вперед. Впрочем использовать BPMN или нет - дело сугубо добровольное.
Оценки: /
24.02.2011 12:39
  от автора
  Дмитрий Пинаев
Анатолий, к сожалению, вы не комментируете конкретные недостатки, о которых я говорю.
То что вижу я на данный момент - BPMN больше всего похож на язык программистов (со всеми его обменами сообщениями между параллельными процесссами, Отменами, Компнесацияими) и придуман по вищимому программистами. Когда я читаю его как программист, мне почти все кажется логичным и понятным, но как бизнес-пользователь, пытающийся понять логику выполнения и координации работ конкретных специалистов в целом - мне требуется тратить дополнительные усилия. Поэтому, хотел бы посмотреть на бизнес-пользователя, который разберется в этой логике сходу. Да и вопрос - зачем?!
Нормальное позиционирование для BPMN - настройка BPM системы, т.е. описание в ней 10-30 процессов. Зачем пытаться позиционировать его как язык общения бизнес-пользовательй, аналтиков и ИТ, да еще использовать его для регламентации? Этот путь, на мой вгляд, никуда не приведет.
Оценки: /
24.02.2011 12:42
  от автора
  Дмитрий Пинаев
>>Дмитрий, извините, но по-моему Вы не в теме. Уже приняли.
Ну как Вам сказать: да, ежедневно не слежу за изменениями статуса.
Но в нотации и ее версиях поразбираться пришлось для поддержки XPDL.
Оценки: /
24.02.2011 13:05
  от автора
  bell
>> Анатолий, к сожалению, вы не комментируете конкретные недостатки, о которых я говорю.

А Вы не отвечаете на мои конкретные вопросы: чем отличается BPMN 1.1 от BPMN 1.2 и от BPMN 2.0? Пожалуйста обоснуйте свой тезис о сложности 2.0.

Например, я каждого, кто жалуется на обилие различных сигналов в BPMN, прошу указать: какой сигнал он считает лишним? Пока никто не смог ответить.

>> То что вижу я на данный момент - BPMN больше всего похож на язык программистов

BPMN сознательно разрабатывался как нотация нейтральная по отношению к методологии:
- Хотите использовать ее для детального программирования процессов - можете это делать.
- Хотите использовать для высокоуровнего описания процессов - ограничьте палитру базовыми элементами (без отмен и компенсаций), научите бизнес-пользователей ими пользоваться и вперед! Получится не сложнее прочих нотаций.

Но ни в том, ни в другом случае BPMN нельзя использовать "как есть" - вы обязаны выработать для себя или для организации некоторое соглашение по моделированию.

Это непривычная для многих концепция: ведь и IDEF, и EPC идут "в пакете" с методологией.

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

Вам не нравится BPMN? А вы умеете его готовить?
Оценки: /
24.02.2011 15:59
  от автора
  Дмитрий Пинаев
Отвечаю: в BPMN 2.0 еще добавили 2 типа событий, и также на 2 увеличили количество их подвидов. При том, что и раньше их было изрядное количество. Плюс BPMN в целом сложна количеством программистких понятий, который я привел выше.
(1.1 и 1.2 сейчас разбирать не вижу смысла)

>>Например, я каждого, кто жалуется на обилие различных сигналов в BPMN, прошу указать: какой сигнал он считает лишним? Пока никто не смог ответить.
Анатолий, выше я уже написал, дело не в лишности сигналов. Дублирую: Все сигналы важны и нужны.

"Но ни в том, ни в другом случае BPMN нельзя использовать "как есть" - вы обязаны выработать для себя или для организации некоторое соглашение по моделированию.
Это непривычная для многих концепция: ведь и IDEF, и EPC идут "в пакете" с методологией"
Не правильно: для eEPC тоже делается соглашение. И это считается минусом, а не плюсом.

>>Вам не нравится BPMN? А вы умеете его готовить?
Каждый инструмент хорош для решения определенных задач. Речь только про это.
Оценки: /
08.04.2011 15:33
  от автора
  akabanov
Забавно то, что все парадигма автоматизации проходят по одному и тому же циклу возрастания зрелости.
Каждая новая парадигма несет некую свежую идеологию, но использует крайне незрелые, нетехнологичные механизмы реализации

Так было с SQL, в идеал которого медленно проникали разнообразные чисто технические курсоры и пакетные языки управления с условиями и циклами.
Так было с GPSS, который по мере реализации конкретных проектов целиком трансформировался в тот же BPM

Так случилось и с BPM

Парадигма алгоритмического программирования от модульного к объектно-ориентированному, а далее к компонентному и распределенному, породила синхронные и асинхронные модели взаимодействия кода, что привело к модели взаимодействия сервисов.

Теперь, когда мы начинаем мыслить в контексте взаимодействия сервисов, их оркестровки, снова упускаются азы чистой технологии разработок.

Событийная модель породилась исключительно технологически, она не была рождена как некая новая парадигма. Событийная модель реализуется и в структурном программировании, и в объектно-ориентированном, но ее вершиной является именно асинхронная модель оркестровки.

Многопоточность - не является парадигмой, это техническая реализация. Парадигмой является оркестровка асинхронно взаимодействующих сервисов.

Не важно, выполняются ли процессы последовательно в рамках одного потока, или в виде множества независимых потоков - это технология реализации платформы.

Важно изменить парадимгу мышления самих разработчиков - создавать модели процессов хоть в BPMN, хоть в ACM в режиме асинхронно взаимодействующих сервисов.

Мы не выполняем расчет потребности в материалах строго в каких-то узлах бизнес-процесса. Это вполне асинхронный процесс, у которого может быть много точек входов. Но внутри сервиса процесс расчета потребности вполне себе структурный, порой даже вообще линейный.
Оценки: /
19.04.2011 18:04
  от автора
  wjulia
Дмитрий,
соглашусь с Вами, что BPMN нужен далеко не всем (и тем более показан далеко не всем, поскольку если его использовать по своему усмотрению, то это только усложнит понимание). Если аналитик описывает бизнес как показано на рис.2, то зачем ему BPMN? Достаточно MS Word.
Но как насчет того, о чем говорил Анатолий - сигналов, сообщений, компенсаций и иже с ними? Можно придумать для этих целей свои условные обозначения, которые могут быть оговорены внутри определенного сообщества. Но вот что странно: как только научишься делать это в BPMN, то все значки становятся как-то удивительно похожими на стандарт... почему бы это?
Лично мне нравится рисовать фрагменты схем на бумаге, прежде чем переносить их в моделер, но я это делаю с некоторых пор исключительно в BPMN (рука, как говорится, сама тянется). И еще замечено: сначала как-то обходишься небольшим джентльменским набором, но когда аппетиты растут, то начинаешь искать дополнительные элементы, и, что удивительно, в BPMN их находишь. Своеобразный шведский стол. Причем, способный удовлетворить и аскетов и гурманов.
Оценки: /
20.04.2011 22:58
  от автора
  Репин
"...Своеобразный шведский стол. Причем, способный удовлетворить и аскетов и гурманов..."

Как-то раз на о. Кипр отдыхал в отеле 5*. Там был неплохой шведский стол. Однако, для желудка это было большим потрясением. Уж лучше родные пельмени или сосиски А если серьезно, то как Вы себе представляете ситуацию, когда начальник отдела продаж или логистики (на 120% загруженный текущей работой) будет изучать BPMN и "входить во вкус этого шведского стола"? BPMN - удел профильных специалистов. Он никогда не станет массовым способом отображения деятельности в виде процессов. Именно в силу это самого "шведского стола".
Оценки: /
21.04.2011 13:55
  от автора
  wjulia
Владимир, и не говори... а уж уборщица точно не будет... а оно надо? Если этот перегруженый работой логист вдруг решит попробовать силы в процессном анализе - то дайте ему ради бога прямоугольник, ромб и кружочек (два кружочка - старт и финиш, больше не надо). И пусть себе рисует. в конце концов, чем бы дитя не тешилось - лишь бы своих не делало...
А если серьезно, то я не считаю нормальным отдавать процессы на откуп логистам, бухгалтерам и продавцам. Прежде всего, хотя бы в силу того, что они будут описывать не процессы, а свои функции. И даже если не только свои, то все равно ограниченные рамками функциональных подразделений, чьи интересы они представляют. Я все же имею в виду BPMN, как инструмент процессного управления.
Оценки: /
21.04.2011 19:59
  от автора
  Репин
"...Прежде всего, хотя бы в силу того, что они будут описывать не процессы, а свои функции. И даже если не только свои, то все равно ограниченные рамками функциональных подразделений, чьи интересы они представляют..."

Ну то есть межфункциональные барьеры настолько толстые и прочные, что пробить их может только консультант по BPMS. Остается удивляться, как вообще могу работать компании, если их сотрудники знают только "свои функции". Между подразделениями, наверное, вакуум, а сотрудники общаются телепатически
А если серьезно, то почему команда специалистов из 2-3 отделов не может описать сквозной процесс? Может, конечно. Причем не только описать, но и оптимизировать.
Оценки: /
22.04.2011 16:11
  от автора
  wjulia
Вот тут

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

Что касаемо "специалистов 2-3 отделов", то тут подходит "беда, коль пироги начнет печи сапожник, а сапоги тачать - пирожник". Пусть кассир и менеджер по продажам опишут свои процессы, но будь готовым к тому, что они опишут их только в силу своего собственного понимания, и ты получишь исключительно эффект автоматизации нескольких рабочих мест. Управленческие задачи таким образом не решаются.
Оценки: /
25.04.2011 12:50
  от автора
  Репин
А почему они должны описывать только "в силу собственного понимания"? Их можно обучить методам структурирования, описания и регламентации бизнес-процессов. Кстати, руководителям это дает инструмент структурирования своей управленческой деятельности.

"...Управленческие задачи таким образом не решаются..." - они что, решаются путем описания в BPMN и автоматизации в BPMS? )
Оценки: /
25.04.2011 16:33
  от автора
  wjulia
Владимир, у нас 100% населения обучены методам написания текстов путем графического изображения символов (писать, в общем, умеют все). Но "Евгения Онегина" не каждому дано написать.
В том-то и дело, что путем описания в BPMN управленческие задачи не решаются. Даже если зав.складом знает, что обозначают фигуры нотации.
И вообще мы о чем спорим-то? О том, что BPMN не нужен завскладу или о том, что BPMN не нужен профессионалу? Я хочу как-то обозначить мою позицию:
- завскладу или кассиру или контролеру ОТК не нужен BPMN, как не нужна и любая другая нотация.
- управленцу (бизнес-пользователю, аналитику) нужна какая-то нотация - BPMN или любая, для которой точно описано, какое поведение предусмотрено для какой фигуры.
- для айтишника нужно знать, какая нотация используется, и описание, какое поведение предусмотрено для какой фигуры.
Если нотация не является стандартом, то вот это самое описание "вот такой кружочек с крестиком означает вот это" должно быть принято на корпоративном или каком-то внутреннем уровне, чтобы не было разночтений.
Итак, нужен ли всем стандарт BPMN? Если вам не нужен - пишите свой, для внутреннего использования.
Если есть BPM-система, то у нее может быть собственная нотация, но тогда вот это трактование значения фигур уже заложено в системе. Тогда действительно не нужен.
Оценки: /
25.04.2011 21:49
  от автора
  Репин
"...Итак, нужен ли всем стандарт BPMN? Если вам не нужен - пишите свой, для внутреннего использования..."

- так оно и происходит. Дело в том, что ни одна система BPMS не может на сегодняшний день эффективно решать задачу формирования регламентирующих документов. А это задача вполне насущная.

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

ОК. Допустим управленец начнет описывать свои процессы в BPMN. Как он сможет объяснить эти схемы рядовым сотрудникам?! Для обычных людей инструмент должен быть как можно проще...

Оценки: /
26.04.2011 12:47
  от автора
  wjulia

ни одна система BPMS не может на сегодняшний день эффективно решать задачу формирования регламентирующих документов
может. Читайте мануал )))))

Как он сможет объяснить эти схемы рядовым сотрудникам
рядовые сотрудники должны получать задания, исполнять их и иметь доступ к аналитике, в соответствии с правами. Зачем им изучать схемы? Рядовой сотрудник должен быть уверен, что задание к нему поступило со всеми необходимыми данными, и что срок его исполнения вот такой. От кого оно поступило, и кто будет за ним ему знать вовсе необязательно (хотя, в принципе, эту информацию можно на форме и показать), а уж знать всю цепочку точно не нужно.
Не надо усложнять работу там, где она должна быть упрощена.
Для того, чтобы продавать телевизор, менеджеру не обязательно разбираться в его схеме.
Оценки: /
26.04.2011 22:58
  от автора
  Репин
"...Для того, чтобы продавать телевизор, менеджеру не обязательно разбираться в его схеме..."

- да, разбираться в особенностях моделей телевизоров не нужно, а продавать можно. Вот только сколько такой менеджер продаст товара, еще вопрос.

Интересно отметить, что когда конкретных аргументов нет, идут всякие сомнительные описания типа "мудрость жизни", пословицы и поговорки . Но реально это просто подмена понятий и уход от нормальной дискуссии.

может. Читайте мануал )))))
- приведите пример, как это работает в BizAgi в виде готового регламента и разместите его на этом сайте. А так проще всего сослаться на мануал...

"...От кого оно поступило, и кто будет за ним ему знать вовсе необязательно..."

- я фигею и плачу, дорогая редакция! Консультант по бизнес-процессам предлагает:
1. сделать сотрудников механизмами, выполняющими бездумно однотипные операции;
2. герметизировать информацию о сквозном процессе в головах 1-2 сотрудников компании;
3. возвести межфунциональные барьеры ("каждый знает только свою работу...", "не надо усложнять..." и т.п.);
4. полностью передать разработку и оптимизацию сквозных процессов на откуп внешнему консультанту.

Комментарии, как говориться, излишни...



Оценки: /
27.04.2011 11:15
  от автора
  wjulia
Мне кажется, что мы уже спорим ни о чем.
Давай остановимся на твоем варианте:
Каждый сотрудник предприятия, независимо от его квалификации, образования и должностных обязанностей должен уметь моделировать сквозные процессы, описывающие работу всех подразделений.
Процессы принимаются только в случае достижения полного консенсуса между всеми сотрудниками компании.

Мне твоя позиция понятна, у меня есть собственный опыт на этот счет, который несколько отличается от предложенного варианта. В твоем случае предприятия численностью больше 30 человек не имеют шансов описать процессы в принципе, ибо консенсуса они не достигнут никогда, если только не погнушаются пунктами 2 или 4. Мы работаем с более крупными заказчиками.

Спасибо за дискуссию
Оценки: /
27.04.2011 13:41
  от автора
  Репин
"...Каждый сотрудник предприятия, независимо от его квалификации, образования и должностных обязанностей должен уметь моделировать сквозные процессы, описывающие работу всех подразделений...."

Что-то не припомню, что я так писал Моделировать не все должны уметь, но участвовать в межфункциональных группах по анализу и оптимизации процессов -
могут - почему нет?

Про "полный консенсус" тоже ничего не говорил.

Ага, спасибо!

Добавить комментарий

Комментировать материалы могут только зарегистрированные пользователи. Вы можете зарегистрироваться здесь.
©  2010-2014 В.В. Репин. Сайт основан 3 февраля 2001 г.

Все права защищены. Частичное или полное копирование информации данного ресурса возможно только с разрешения владельца.

Регистрация
О Портале
Правила
Контакты
Новости
Библиотека
Энциклопедия
Литература и сайты
Группы
Мои страницы
Тесты
Форум
Доска объявлений