Comments 8
>Полное описание бизнес-процессов крупной компании — это утопия.
Но стремиться к этому надо, иначе при смене сотрудника, либо даже небольшой паузе в работе над этими процессами, вместо того, чтобы продолжить разработку/оптимизацию, на процессы все будут смотреть «баранами» с вопросами, вроде "… а что это у нас здесь за фиговина такая???"
Просто надо понимать, что описание процессов это тоже процесс — с итерациями от как есть и как надо до как реально сделали (например, с использованием унифицированных процессов в качестве кирпичиков для реализации бизнес процессов)…
Но стремиться к этому надо, иначе при смене сотрудника, либо даже небольшой паузе в работе над этими процессами, вместо того, чтобы продолжить разработку/оптимизацию, на процессы все будут смотреть «баранами» с вопросами, вроде "… а что это у нас здесь за фиговина такая???"
Просто надо понимать, что описание процессов это тоже процесс — с итерациями от как есть и как надо до как реально сделали (например, с использованием унифицированных процессов в качестве кирпичиков для реализации бизнес процессов)…
Но стремиться к этому надо
Стремиться может быть и нужно, но часто это напоминает «биться головой о стену», т.к. до сих пор никто не может сказать, как грамотно подходить к описанию процессов (не говоря уже об их проектировании). Книжек, программ и консультантов — много, толку мало.
В целом, как автор «Выбор CASE инструмента для разработки процессов в BPMN», с чем Вы согласны и не согласны в моей статье? Хотя бы, с двумя последними рисунками.
>В целом, как автор «Выбор CASE инструмента для разработки процессов в BPMN», с чем Вы согласны и не согласны в моей статье? Хотя бы, с двумя последними рисунками.
Сложно сказать, с чем соглашаться или нет, так как информации довольно много… Сама классификация BPM понравилась…
Что касается использования BPMN в крупной компании, то осталось за кадром следующее:
— К BPMN движку нужно добавить еще ODM движок, куда выносится вся логика.Это позволяет сильно упростить логику в самих Flow (как раз в соответствии с принципом «no code».
— Кроме реализации каждого бизнес процесса по отдельности, есть следующая стадия зрелости, когда бизнес процессы реализуются посредством унифицированных процессов (сокращаются издержки на разработку, уменьшается количество ошибок). Вместе с ODM в SOA архитектуре, когда вся реализация функций вынесена в сервисы, вполне досягаемо в BPMN оставить только набор самих FLOW и достичь таким образом дзена :) (когда в BPMN движке нет кода). Но путь этот очень тернист и далеко не всегда оптимален…
Сложно сказать, с чем соглашаться или нет, так как информации довольно много… Сама классификация BPM понравилась…
Что касается использования BPMN в крупной компании, то осталось за кадром следующее:
— К BPMN движку нужно добавить еще ODM движок, куда выносится вся логика.Это позволяет сильно упростить логику в самих Flow (как раз в соответствии с принципом «no code».
— Кроме реализации каждого бизнес процесса по отдельности, есть следующая стадия зрелости, когда бизнес процессы реализуются посредством унифицированных процессов (сокращаются издержки на разработку, уменьшается количество ошибок). Вместе с ODM в SOA архитектуре, когда вся реализация функций вынесена в сервисы, вполне досягаемо в BPMN оставить только набор самих FLOW и достичь таким образом дзена :) (когда в BPMN движке нет кода). Но путь этот очень тернист и далеко не всегда оптимален…
Сама классификация BPM понравилась…
Приятно слышать.
К BPMN движку нужно добавить еще ODM движок, куда выносится вся логика.
У меня создается ощущение, что все хотят изгнать логику. Одни ее гонят из ESB, утверждая, что там не место бизнес-логике, другие гонят бизнес-правила из BPMN.
Если BPMN движки, хоть как то стандартизированы, то ODM движки (BRM) — нет. Не будет ли такой «вынос логики» шагом назад?
есть следующая стадия зрелости, когда бизнес процессы реализуются посредством унифицированных процессов
Про «унификацию бизнес-процессов» — Вы это серьезно? В современной капиталистической России?
Для унификации требуются, как минимум, соответствующая инфраструктура и реинжиниринг стереотипов «владельцев процессов».
> Если BPMN движки, хоть как то стандартизированы, то ODM движки (BRM) — нет. Не будет ли такой «вынос логики» шагом назад?
Нет — Вы будете использовать этот ODM движок в качестве сервиса. По сути Вы сложное разбиваете на 2 части попроще, а это хорошо. В высоконагруженной системе Вы еще получаете возможность вынести часть нагрузки с BPMN движка на сторону — и это опять хорошо.
>Про «унификацию бизнес-процессов» — Вы это серьезно? В современной капиталистической России?
>Для унификации требуются, как минимум, соответствующая инфраструктура и реинжиниринг стереотипов «владельцев процессов».
Серьезно, ибо сам этим занимаюсь. Относитесь к унифицированным процессам как к сервисам, которые реализуют часть востребованного всеми функционала. Понятно, что за этим «базовым» набором процессов должен быть повышенный контроль, что они должны быть специфицированы и доведены до конечного потребителя (разработчиков процессов).
Когда появляется новый большой процесс 4/5 которого уже «живет» в виде унифицированных процессов + пары табличек в ODM, реализовывать его гораздо веселей… При этом не нужно делать регрессионное тестирование, потому, что старое Вы нигде не затронули. А если таких процессов несколько десятков…
Нет — Вы будете использовать этот ODM движок в качестве сервиса. По сути Вы сложное разбиваете на 2 части попроще, а это хорошо. В высоконагруженной системе Вы еще получаете возможность вынести часть нагрузки с BPMN движка на сторону — и это опять хорошо.
>Про «унификацию бизнес-процессов» — Вы это серьезно? В современной капиталистической России?
>Для унификации требуются, как минимум, соответствующая инфраструктура и реинжиниринг стереотипов «владельцев процессов».
Серьезно, ибо сам этим занимаюсь. Относитесь к унифицированным процессам как к сервисам, которые реализуют часть востребованного всеми функционала. Понятно, что за этим «базовым» набором процессов должен быть повышенный контроль, что они должны быть специфицированы и доведены до конечного потребителя (разработчиков процессов).
Когда появляется новый большой процесс 4/5 которого уже «живет» в виде унифицированных процессов + пары табличек в ODM, реализовывать его гораздо веселей… При этом не нужно делать регрессионное тестирование, потому, что старое Вы нигде не затронули. А если таких процессов несколько десятков…
унифицированным процессам как к сервисам
Можно несколько примеров для корпоративного сегмента? и пояснение почему их следует считать унифицированными.
Унифицированный процесс — это процесс относящийся к группе процессов, характеризуемых схожим сценарием обработки и взаимодействия. Унифицированные процессы являются готовыми блоками, которые можно многократно использовать в технологических/бизнес процессах, тем самым удешевляя разработку и уменьшая количество ошибок.
Примеры:
1)
Для проверки объекта учета (под объектом учета может быть все, что угодно — человек, товар, описанный в виде документа или группы документов), перед его сохранением в БД нужно выполнить некоторые стандартные шаги:
Предположим, что мы получаем какие-то данные для сохранения в БД (не важно — наши эти данные или мы получили их со стороны) и предположим, что таких объектов учета у нас 100500. Тогда в УП (унифицированном процессе) «Проверка объекта учета» первым будет следующий шаг:
— обращение к ODM движку для получения списка шагов проверки (проверка ЭЦП, xlt преобразование, ФЛК, сравнение атрибутов нескольких документов между собой, когда есть список документов и опись, проверка документа по сервисам, какой-то ответ-квитанция отправителю и т.д.).
— далее — шаги по каждому типу проверки. Сразу обращаю внимание, Flow один и состоит из всех возможных шагов, те из них, которые неактуальны для какого-то объекта учета, считаются NULL.
— Далее выполняются только актуальные шаги УП.
Что дает УП:
— один унифицированный Flow — при добавлении нового объекта учета здесь ничего не меняется.
— вся логика в ODM — при добавлении нового объекта учета просто добавляем для него новую запись в таблицы.
— при каких-либо изменениях (например, СМЭВ новый регламент выпустил и теперь квитанцию туда с дополнительными атрибутами нужно отправлять), Вы имеете одну точку, требующую изменения, которая покроет все бизнес процессы. Если у Вас 100500 объектов учета, это архиважно.
2)
На выходе из процесса «Проверка объекта учета» мы получаем либо ОК/Не ОК, либо квитанцию, в которой написано ОК/Не ОК + список ошибок, если они были. Для самой квитанции может быть нужно выполнить преобразование, обогащение, добавление ЭЦП и маршрутизацию N контрагентам. Это тема еще одного УП.
Примеры:
1)
Для проверки объекта учета (под объектом учета может быть все, что угодно — человек, товар, описанный в виде документа или группы документов), перед его сохранением в БД нужно выполнить некоторые стандартные шаги:
Предположим, что мы получаем какие-то данные для сохранения в БД (не важно — наши эти данные или мы получили их со стороны) и предположим, что таких объектов учета у нас 100500. Тогда в УП (унифицированном процессе) «Проверка объекта учета» первым будет следующий шаг:
— обращение к ODM движку для получения списка шагов проверки (проверка ЭЦП, xlt преобразование, ФЛК, сравнение атрибутов нескольких документов между собой, когда есть список документов и опись, проверка документа по сервисам, какой-то ответ-квитанция отправителю и т.д.).
— далее — шаги по каждому типу проверки. Сразу обращаю внимание, Flow один и состоит из всех возможных шагов, те из них, которые неактуальны для какого-то объекта учета, считаются NULL.
— Далее выполняются только актуальные шаги УП.
Что дает УП:
— один унифицированный Flow — при добавлении нового объекта учета здесь ничего не меняется.
— вся логика в ODM — при добавлении нового объекта учета просто добавляем для него новую запись в таблицы.
— при каких-либо изменениях (например, СМЭВ новый регламент выпустил и теперь квитанцию туда с дополнительными атрибутами нужно отправлять), Вы имеете одну точку, требующую изменения, которая покроет все бизнес процессы. Если у Вас 100500 объектов учета, это архиважно.
2)
На выходе из процесса «Проверка объекта учета» мы получаем либо ОК/Не ОК, либо квитанцию, в которой написано ОК/Не ОК + список ошибок, если они были. Для самой квитанции может быть нужно выполнить преобразование, обогащение, добавление ЭЦП и маршрутизацию N контрагентам. Это тема еще одного УП.
Унификация.
Мы о разных унификациях. Вы – про унификацию на уровне сборки программы. Использование «унифицированных болтов и гаек» (вышеописанные шаги УП) конечно облегчает кодинг. Но ведь через дорогу сидит другой программер, который также лепит «унифицированные» шаги УП, которые делают почти одно и тоже, но совсем иные и нисколько не унифицированые с Вашими. А через квартал сидит еще тусовка программеров, которые тоже «как бы и что-то унифицируют».
В итоге подобная «унификация» существует в лучшем случае в составе команды (проекта) или просто в воображении программера.
Некоторые даже настолько уверовали в «свою унификацию» (свое избранность), что продают свои процессы – сервисы как «унифицированные» (конечно с соответствующей наценкой за «унификацию»).
Я же совсем про иную унификацию. Например, если посмотреть операционные модели нескольких однотипных предприятий, то они будут разные, но если присмотреться еще повнимательнее, то разные они потому, что каждый изобретает велосипед. Поле для унификации «одного и тогож» — без горизонта и непаханое. Но каждый держит в тайне свою нормативку и свои бизнес-процессы, — «врагу назло».
Именно с уровня операционной модели компании должна начинаться унификация, т.е.очень далеко от ИТ.
Поэтому я и говорю, что это невозможно «В современной капиталистической России».
«Большая унификация» возможна будет тогда, когда своими процессами будут готовы делиться как потребители, так и разработчики.
Или когда будет разработана модель взаимодействия процессов, а они могут взаимодействовать как по горизонтали, так и по принципу матрешки. Причем такую модель и спецификации процессов должна разрабатывать независимая организация. Иначе компании будут норовить подсадить «клиента на крючок», выпуская проприетарные спецификации.
Пример подхода – OSI (независимая организация) и TCP\IP (вообще министерство обороны). Пример реализации – те же самые стеки, т.е. должны быть семейства унифицированных ПРОЦЕССОВ «Название области». Тематические Референтные модели, отраслевые классификаторы информационных объектов модели, открытые спецификации ОТКРЫТЫХ процессов и т.п. Иначе «унификация останется» лишь в воображении.
Могут быть и иные пути достижения цели промышленной Унификации, например, через краудсорсинг, но для этого необходим реинжиниринг стереотипов как «владельцев процессов», так и разработчиков. В этом случае, поставка процесса – «сервиса или несервиса» должна включать как минимум схему процесса (например, в BPMN), как когда то к каждому советскому телевизору прилагали принципиальную схему.
Про промышленную унификацию, как одного из подхода НОТ, и Global BPM коснулись в комментариях ко Второй статье (AS — Мечтатель – Алхимик 80 уровня — ):
Мы о разных унификациях. Вы – про унификацию на уровне сборки программы. Использование «унифицированных болтов и гаек» (вышеописанные шаги УП) конечно облегчает кодинг. Но ведь через дорогу сидит другой программер, который также лепит «унифицированные» шаги УП, которые делают почти одно и тоже, но совсем иные и нисколько не унифицированые с Вашими. А через квартал сидит еще тусовка программеров, которые тоже «как бы и что-то унифицируют».
В итоге подобная «унификация» существует в лучшем случае в составе команды (проекта) или просто в воображении программера.
Некоторые даже настолько уверовали в «свою унификацию» (свое избранность), что продают свои процессы – сервисы как «унифицированные» (конечно с соответствующей наценкой за «унификацию»).
Я же совсем про иную унификацию. Например, если посмотреть операционные модели нескольких однотипных предприятий, то они будут разные, но если присмотреться еще повнимательнее, то разные они потому, что каждый изобретает велосипед. Поле для унификации «одного и тогож» — без горизонта и непаханое. Но каждый держит в тайне свою нормативку и свои бизнес-процессы, — «врагу назло».
Именно с уровня операционной модели компании должна начинаться унификация, т.е.очень далеко от ИТ.
Поэтому я и говорю, что это невозможно «В современной капиталистической России».
«Большая унификация» возможна будет тогда, когда своими процессами будут готовы делиться как потребители, так и разработчики.
Или когда будет разработана модель взаимодействия процессов, а они могут взаимодействовать как по горизонтали, так и по принципу матрешки. Причем такую модель и спецификации процессов должна разрабатывать независимая организация. Иначе компании будут норовить подсадить «клиента на крючок», выпуская проприетарные спецификации.
Пример подхода – OSI (независимая организация) и TCP\IP (вообще министерство обороны). Пример реализации – те же самые стеки, т.е. должны быть семейства унифицированных ПРОЦЕССОВ «Название области». Тематические Референтные модели, отраслевые классификаторы информационных объектов модели, открытые спецификации ОТКРЫТЫХ процессов и т.п. Иначе «унификация останется» лишь в воображении.
Могут быть и иные пути достижения цели промышленной Унификации, например, через краудсорсинг, но для этого необходим реинжиниринг стереотипов как «владельцев процессов», так и разработчиков. В этом случае, поставка процесса – «сервиса или несервиса» должна включать как минимум схему процесса (например, в BPMN), как когда то к каждому советскому телевизору прилагали принципиальную схему.
Про промышленную унификацию, как одного из подхода НОТ, и Global BPM коснулись в комментариях ко Второй статье (AS — Мечтатель – Алхимик 80 уровня — ):
Sign up to leave a comment.
Бизнес-процессы: Как все запущено и запутано. Глава Третья. Общая классификация BPM и философия BPMS