Унифицированный процесс — это процесс относящийся к группе процессов, характеризуемых схожим сценарием обработки и взаимодействия. Унифицированные процессы являются готовыми блоками, которые можно многократно использовать в технологических/бизнес процессах, тем самым удешевляя разработку и уменьшая количество ошибок.
Примеры:
1)
Для проверки объекта учета (под объектом учета может быть все, что угодно — человек, товар, описанный в виде документа или группы документов), перед его сохранением в БД нужно выполнить некоторые стандартные шаги:
Предположим, что мы получаем какие-то данные для сохранения в БД (не важно — наши эти данные или мы получили их со стороны) и предположим, что таких объектов учета у нас 100500. Тогда в УП (унифицированном процессе) «Проверка объекта учета» первым будет следующий шаг:
— обращение к ODM движку для получения списка шагов проверки (проверка ЭЦП, xlt преобразование, ФЛК, сравнение атрибутов нескольких документов между собой, когда есть список документов и опись, проверка документа по сервисам, какой-то ответ-квитанция отправителю и т.д.).
— далее — шаги по каждому типу проверки. Сразу обращаю внимание, Flow один и состоит из всех возможных шагов, те из них, которые неактуальны для какого-то объекта учета, считаются NULL.
— Далее выполняются только актуальные шаги УП.
Что дает УП:
— один унифицированный Flow — при добавлении нового объекта учета здесь ничего не меняется.
— вся логика в ODM — при добавлении нового объекта учета просто добавляем для него новую запись в таблицы.
— при каких-либо изменениях (например, СМЭВ новый регламент выпустил и теперь квитанцию туда с дополнительными атрибутами нужно отправлять), Вы имеете одну точку, требующую изменения, которая покроет все бизнес процессы. Если у Вас 100500 объектов учета, это архиважно.
2)
На выходе из процесса «Проверка объекта учета» мы получаем либо ОК/Не ОК, либо квитанцию, в которой написано ОК/Не ОК + список ошибок, если они были. Для самой квитанции может быть нужно выполнить преобразование, обогащение, добавление ЭЦП и маршрутизацию N контрагентам. Это тема еще одного УП.
> Если BPMN движки, хоть как то стандартизированы, то ODM движки (BRM) — нет. Не будет ли такой «вынос логики» шагом назад?
Нет — Вы будете использовать этот ODM движок в качестве сервиса. По сути Вы сложное разбиваете на 2 части попроще, а это хорошо. В высоконагруженной системе Вы еще получаете возможность вынести часть нагрузки с BPMN движка на сторону — и это опять хорошо.
>Про «унификацию бизнес-процессов» — Вы это серьезно? В современной капиталистической России?
>Для унификации требуются, как минимум, соответствующая инфраструктура и реинжиниринг стереотипов «владельцев процессов».
Серьезно, ибо сам этим занимаюсь. Относитесь к унифицированным процессам как к сервисам, которые реализуют часть востребованного всеми функционала. Понятно, что за этим «базовым» набором процессов должен быть повышенный контроль, что они должны быть специфицированы и доведены до конечного потребителя (разработчиков процессов).
Когда появляется новый большой процесс 4/5 которого уже «живет» в виде унифицированных процессов + пары табличек в ODM, реализовывать его гораздо веселей… При этом не нужно делать регрессионное тестирование, потому, что старое Вы нигде не затронули. А если таких процессов несколько десятков…
>В целом, как автор «Выбор CASE инструмента для разработки процессов в BPMN», с чем Вы согласны и не согласны в моей статье? Хотя бы, с двумя последними рисунками.
Сложно сказать, с чем соглашаться или нет, так как информации довольно много… Сама классификация BPM понравилась…
Что касается использования BPMN в крупной компании, то осталось за кадром следующее:
— К BPMN движку нужно добавить еще ODM движок, куда выносится вся логика.Это позволяет сильно упростить логику в самих Flow (как раз в соответствии с принципом «no code».
— Кроме реализации каждого бизнес процесса по отдельности, есть следующая стадия зрелости, когда бизнес процессы реализуются посредством унифицированных процессов (сокращаются издержки на разработку, уменьшается количество ошибок). Вместе с ODM в SOA архитектуре, когда вся реализация функций вынесена в сервисы, вполне досягаемо в BPMN оставить только набор самих FLOW и достичь таким образом дзена :) (когда в BPMN движке нет кода). Но путь этот очень тернист и далеко не всегда оптимален…
>Полное описание бизнес-процессов крупной компании — это утопия.
Но стремиться к этому надо, иначе при смене сотрудника, либо даже небольшой паузе в работе над этими процессами, вместо того, чтобы продолжить разработку/оптимизацию, на процессы все будут смотреть «баранами» с вопросами, вроде "… а что это у нас здесь за фиговина такая???"
Просто надо понимать, что описание процессов это тоже процесс — с итерациями от как есть и как надо до как реально сделали (например, с использованием унифицированных процессов в качестве кирпичиков для реализации бизнес процессов)…
Вот интересно, а если это дрон какого-либо маньяка/киллера с замаскированным огнестрелом/пневмостволом с токсином под брюхом… Подвесил несколько дронов перед входом и «клиент» ничего не сможет сделать…
Когда-то тоже писал универсальный календарь для всех своих проектов :)
При желании двигаться дальше — добавил возможные варианты развития Вашего решения.
Про диапазон и клавиатуру уже писали выше. Вот еще, что мне многократно пригодилось в моих проектах:
1) Возможность указания допустимого периода для выбора даты.
2) Возможность указания дат исключений, не допустимых для выбора (как конкретной даты, например, какого-нибудь праздника, так и в виде дня недели, например — субботы, воскресенья).
3) Возможность указания списка дат, допустимых для выбора (данная фича нужна, если, например, нужно выбрать, кого-то с режимом работы «сутки, через трое» или «последняя пятница месяца»).
За ссылку меня в бан уже отправили :-) Еле упросил что бы без ссылок опубликовать после этого.
Сталкивался с такой-же ситуацией. Мне пояснили следующее:
Если хотите разместить ссылку на свой сайт в тексте публикации — то это можно сделать в категории «Я пиарюсь». Если категория другая — делаете публикацию без ссылки и добавляете ссыль в комментарии.
Так что за комментатора выше можно быть спокойным :)
Не могу ничего возразить по сути, но внутри такое чувство, что меня в чем-то обманывают.
Ну не могут два зрителя одновременно быть замедленными друг относительно друга...
https://www.youtube.com/watch?v=K2slWzooD2w
Примеры:
1)
Для проверки объекта учета (под объектом учета может быть все, что угодно — человек, товар, описанный в виде документа или группы документов), перед его сохранением в БД нужно выполнить некоторые стандартные шаги:
Предположим, что мы получаем какие-то данные для сохранения в БД (не важно — наши эти данные или мы получили их со стороны) и предположим, что таких объектов учета у нас 100500. Тогда в УП (унифицированном процессе) «Проверка объекта учета» первым будет следующий шаг:
— обращение к ODM движку для получения списка шагов проверки (проверка ЭЦП, xlt преобразование, ФЛК, сравнение атрибутов нескольких документов между собой, когда есть список документов и опись, проверка документа по сервисам, какой-то ответ-квитанция отправителю и т.д.).
— далее — шаги по каждому типу проверки. Сразу обращаю внимание, Flow один и состоит из всех возможных шагов, те из них, которые неактуальны для какого-то объекта учета, считаются NULL.
— Далее выполняются только актуальные шаги УП.
Что дает УП:
— один унифицированный Flow — при добавлении нового объекта учета здесь ничего не меняется.
— вся логика в ODM — при добавлении нового объекта учета просто добавляем для него новую запись в таблицы.
— при каких-либо изменениях (например, СМЭВ новый регламент выпустил и теперь квитанцию туда с дополнительными атрибутами нужно отправлять), Вы имеете одну точку, требующую изменения, которая покроет все бизнес процессы. Если у Вас 100500 объектов учета, это архиважно.
2)
На выходе из процесса «Проверка объекта учета» мы получаем либо ОК/Не ОК, либо квитанцию, в которой написано ОК/Не ОК + список ошибок, если они были. Для самой квитанции может быть нужно выполнить преобразование, обогащение, добавление ЭЦП и маршрутизацию N контрагентам. Это тема еще одного УП.
Нет — Вы будете использовать этот ODM движок в качестве сервиса. По сути Вы сложное разбиваете на 2 части попроще, а это хорошо. В высоконагруженной системе Вы еще получаете возможность вынести часть нагрузки с BPMN движка на сторону — и это опять хорошо.
>Про «унификацию бизнес-процессов» — Вы это серьезно? В современной капиталистической России?
>Для унификации требуются, как минимум, соответствующая инфраструктура и реинжиниринг стереотипов «владельцев процессов».
Серьезно, ибо сам этим занимаюсь. Относитесь к унифицированным процессам как к сервисам, которые реализуют часть востребованного всеми функционала. Понятно, что за этим «базовым» набором процессов должен быть повышенный контроль, что они должны быть специфицированы и доведены до конечного потребителя (разработчиков процессов).
Когда появляется новый большой процесс 4/5 которого уже «живет» в виде унифицированных процессов + пары табличек в ODM, реализовывать его гораздо веселей… При этом не нужно делать регрессионное тестирование, потому, что старое Вы нигде не затронули. А если таких процессов несколько десятков…
Сложно сказать, с чем соглашаться или нет, так как информации довольно много… Сама классификация BPM понравилась…
Что касается использования BPMN в крупной компании, то осталось за кадром следующее:
— К BPMN движку нужно добавить еще ODM движок, куда выносится вся логика.Это позволяет сильно упростить логику в самих Flow (как раз в соответствии с принципом «no code».
— Кроме реализации каждого бизнес процесса по отдельности, есть следующая стадия зрелости, когда бизнес процессы реализуются посредством унифицированных процессов (сокращаются издержки на разработку, уменьшается количество ошибок). Вместе с ODM в SOA архитектуре, когда вся реализация функций вынесена в сервисы, вполне досягаемо в BPMN оставить только набор самих FLOW и достичь таким образом дзена :) (когда в BPMN движке нет кода). Но путь этот очень тернист и далеко не всегда оптимален…
Но стремиться к этому надо, иначе при смене сотрудника, либо даже небольшой паузе в работе над этими процессами, вместо того, чтобы продолжить разработку/оптимизацию, на процессы все будут смотреть «баранами» с вопросами, вроде "… а что это у нас здесь за фиговина такая???"
Просто надо понимать, что описание процессов это тоже процесс — с итерациями от как есть и как надо до как реально сделали (например, с использованием унифицированных процессов в качестве кирпичиков для реализации бизнес процессов)…
Никогда еще работа киллера не была столь простой…
Подозреваю, что Вы изобрели тест, с помощью которого можно начать выделять группу социума с определенным типом мозга :)
При желании двигаться дальше — добавил возможные варианты развития Вашего решения.
Про диапазон и клавиатуру уже писали выше. Вот еще, что мне многократно пригодилось в моих проектах:
1) Возможность указания допустимого периода для выбора даты.
2) Возможность указания дат исключений, не допустимых для выбора (как конкретной даты, например, какого-нибудь праздника, так и в виде дня недели, например — субботы, воскресенья).
3) Возможность указания списка дат, допустимых для выбора (данная фича нужна, если, например, нужно выбрать, кого-то с режимом работы «сутки, через трое» или «последняя пятница месяца»).
15 разворотов из грядущего артбука по Fallout 4: www.yaplakal.com/forum2/topic1235976.html
Сталкивался с такой-же ситуацией. Мне пояснили следующее:
Если хотите разместить ссылку на свой сайт в тексте публикации — то это можно сделать в категории «Я пиарюсь». Если категория другая — делаете публикацию без ссылки и добавляете ссыль в комментарии.
Так что за комментатора выше можно быть спокойным :)
В любом случае — задача очень интересная!
Нет ли материала по нагрузочному тестированию?