Бизнес-процессы в стиле RESTful

Чрезвычайно насыщенная неделя не оставила времени для написания сообщений. Неделя еще продолжается, свободного времени не предвидится, потому сообщение в телеграфном стиле.

На НЕконференции BPMS.ru практически не удалось затронуть тему адаптивного кейс-менеджмента. Времени было мало и потому в ACM решили не погружаться. Я не думаю, что ACM что-то слишком сложное. Сложно понять ACM, находясь на позиции традиционного BPM. Разницу взглядов этих парадигм на процесс Jim Sinur сформулировал больше года назад своим противопоставлением Design by Doing – Doing by Design Перефразирую известного консультанта: в ACM процесс управляется людьми, а в BPM процесс людьми управляет. Что может предложить процесс, описанный в нотации BPMN людям в качестве рычагов управления? Практически ничего. Максимум, что может сделать сотрудник, это протолкнуть процесс дальше или же сгенерировать из назначенной на него задачи некоторое событие (безусловно, разработчик процесса должен при проектировании предусмотреть для сотрудника такую возможность).

А чего хочет сотрудник от BPMS? Возьму на себя смелость предположить, что как минимум определить следующую активность для данного экземпляра процесса. По сути, работа knowledge worker заключается в том, чтоб «гонять» процесс по определенному набору состояний (Ну, иногда еще порождать экземпляры вспомогательных бизнес-процессов). Таким образом, если вы хотите реализовать минимальный ACM, вам необходим движок, в котором реализован набор состояний и разрешенных переходов. Вопрос – где его взять? Не спешите с ответом. Я хочу предложить более «вкусный» вариант. Однажды Рой Филдинг придумал идею Hypermedia as the Engine of Application State Вообще-то, он придумал архитектурный стиль REST, а HATEOAS это скорее некоторый критерий соответствия программного интерфейса стилю RESTful, не суть. Существенно, что состояния – это разбросанные по интернет страницы(ресурсы), а допустимые переходы – гиперссылки между ними.

Обобщаем на бизнес-процессы: участник процесс получает страничку и набор гиперссылок в ней, определяющих переходы, допустимые из этого состояния в другие; думает головой, выбирает необходимую гиперссылку и тем самым «передвигает» бизнес-процесс в следующее состояние. Реализация довольно проста. Назначение задачи на сотрудника можно сделать сообщением электронной почты с набором гиперссылок. Нужно получить визу начальника – отправляем ему e-mail c гиперссылками: «утвердить», «отклонить», «отправить в спам» (Очень удобно в связи с поголовной «мобилизацией» руководителей. Компьютера может рядом и не оказаться, а мобильник с почтовым клиентом – всегда под рукой).

Ни тебе BPMN-ов, ни тебе BPMS-ов, поменять процесс «на лету» – вообще не проблема. Хотите Social BPM – перешлите письмо подчиненному с соответствующей резолюцией или же эксперту с традиционным вопросом: «Мне следует это подписывать?». Немного ловкости в проектировании формата гиперссылок на соответствующие активности, немного интеграции с почтовым сервером, причем как на рассылку, так и на получение сообщений и ваш мегагибкий BPMS готов. А кроме того, отсюда и до сетевых бизнес-процессов всего пара кликов рукой подать

Бизнес-процессы в стиле RESTful: 6 комментариев

  1. Максим, мне кажется, когда Вы критикуете “процессы, управляющие людьми”, вы говорите с позиций менеджера (неважно, какого звена), т.е. с позиций _ответственного_ участника процессов. Меж тем огромное количество процессной автоматизации делается для _безответственных_ участников, задача которых – выполнить в срок задание. Им любой Case management только навредит, вернее, не им, а процессу :). Вообще, ИМХО, истина где-то посередине – настоящий сквозной процесс должен включать в себя как “жесткие” участки, так и “адаптивные”. Инструментарий для этого, в целом, существует, а вот нормальные методологии, сочетающие в себе оба подхода, отстают 🙂

    1. Пожалуй, я соглашусь. У меня даже картинка такая есть http://wp.me/pRljZ-dh С левой стороны участвуют “безответственные” сотрудники, реализующие сервис в соответствии с регламентами и инструкциями. А с правой стороны – потребители сервисов. Естественно, роли не постоянны и в одном процессе сотрудник может выступать исполнителем, а в другом потребителем сервиса.

  2. Да, очень похоже, только надо добавить непосредственно связанный с BPM/ESB квадратик “process workers”, а то получается, что “жесткие” процессы живут только в вертикальных системах, а BPMS всего лишь проводник к сервисам.
    Кстати, про Вашу идею с выполнением задач по E-Mail. Я сам в каком-то смысле внедренец BPMS, и сначала зацепился за эту идею. Но потом посмотрел на нее более тщательно, и вот что получилось – если мы говорим о мобильном устройстве, которое способно только по почте работать, то будут проблемы куда-то перейти по гиперссылке. А если куда-то можно перейти по гиперссылке, то зачем тогда почта, можно и web-интерфейсом попользоваться :). Решение будет актуальным, если у нас в качестве BPM-движка выступает сам почтовый сервер. Но тут уже какое-то Exchange-дежавю начинается 🙂 Не об этом мы мечтали долгими зимними вечерами 🙂

    1. В 90-х годах сервера списков рассылок (listserv и др.) все это решили. Операции делались ответным письмом на определенный почтовый адрес, а ссылки приводились как альтернатива этому механизму. Я просто неаккуратно это описал.

  3. >>участник процесс получает страничку и набор гиперссылок в ней, определяющих переходы, допустимые из этого состояния в другие; думает головой, выбирает необходимую гиперссылку и тем самым «передвигает» бизнес-процесс в следующее состояние

    Ну, собственно, все web-приложения так и работают, тоже мне бином Ньютона 🙂

    Чрезвычайно ненасыщенная неделя (поколесив по странам и континентам тихо сижу на даче вдали от Родины 🙂 оставила кучу времени для того, чтобы подумать о глобальном

    Придумал нечто, коррелирующее с темой данного топика – datatags – теги данных, позволяющие ссылаться на структурированные данные, например, элементы справочников

    >>думает головой, выбирает необходимую гиперссылку и тем самым «передвигает» бизнес-процесс в следующее состояние

    Собственно, как инструмент управления в общем виде такими операциями и нужны не просто HTML-ссылки, а datatags – ссылки, управляющие структурированными данными

    >>Немного ловкости в проектировании формата гиперссылок на соответствующие активности

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

    Думаю, как для всякой фундаментальной сущности, кода должно быть немного, гораздо больше времени уйдет на осмысление реализации

    Кстати, очередной раз убеждаюсь, что в южных приморских странах работать, в том числе головой, действительно не хочется, хочется лениво лежать, пить кофе и зеленый чай – поэтому нынешние проблемы Греции, Италии и Португалии вполне естественны, неестественно их желание не работая богато жить. Так что причина извечной проблемы “богатый Север – бедный Юг” это только солнце

    Всем в жаркой Москве привет

    Лето, ах, лето …

  4. Так и в случае BPMS участник процесса также по сути получает страничку со ссылками на те действия, которые процесс для него предусматривает. REST это не движок, а просто элегантный способ реализации stateful диалога между клиентом и сервером через stateless протокол. Для него безразлично что там по ту сторону: бизнес-процесс или адаптивный кейс.

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

Ваш адрес email не будет опубликован. Обязательные поля помечены *