В первую очередь, я хочу выразить признательность участникам обсуждения сообщения Маргинальный подход к моделированию бизнес-процессов. Конструктивное обсуждение подходов позволяет не только взглянуть на проблему с различных точек зрения, но и своевременно отсеять неверные предположения.
В комментариях к этому сообщения я упомянул сделанный Анатолием Белайчуком перевод статьи Jean-Jacques Dubray Семь заблуждений из области исполнения бизнес-процессов Эта работа дает нам отличную возможность не просто порассуждать о преимуществах или недостатках того или иного подхода, но и проверить свои выводы на изложенном в статье конкретном примере. Dubray достаточно основательно расписывает задачу приема сотрудника на работу. Проанализировав возникшие при этом проблемы, он подводит нас к выводу о необходимости дополнения традиционного набора инструментов компонентной архитектурой (Service Component Architecture, SCA). Я не являюсь приверженцем SCA, но разделяю идею автора об использовании композитных приложениях в автоматизации управления процессами предприятия.
Но, что более важно, приведенный в статье анализ дает нам возможность увидеть несколько большее, чем возможности и ограничения тех или иных инструментов, а именно – реальные практические потребности управления, обычно скрываемые нотациями и методологиями.
Итак, у нас есть три действующих лица: соискатель, рекрутер и интервьюер. Относительно наличия последнего персонажа у меня имеются сомнения, но на BPMN модели присутствует отдельная дорожка, потому я считаю, что интервьюер – это отдельная роль. Это не единственный неясный момент в статье. Например, непонятно, ведет ли каждого соискателя один рекрутер от резюме до приема на работу, или же функции проверки резюме и подготовки предложения соискателю могут выполнять различные сотрудники. Не буду додумывать, а постараюсь держаться максимально близко к описанному в статье случаю, хотя по ходу дела обращаться к здравому смыслу все равно придется.
Соискатель – а именно он является главным действующим лицом – заинтересован в получении работы. Минимальным набором шагов, приводящих его к достижению цели, является:
- Отправить заявление о приеме на работу;
- Пройти интервью;
- Подписать job offer;
- Оформиться, т.е. подписать предложенные работодателем документы.
С целями рекрутера ситуация не столь ясная. Однако, из опыта работы с управлением персонала, рискну предположить, что рекрутер отвечает за быстрое закрытие вакантных позиций. И его работа выглядит следующим образом:
- Получить и опубликовать заявку на подбор;
- Выбрать откликнувшегося кандидата;
- Организовать интервью;
- Убедиться, что кандидат подходит, и подготовить job offer;
- На основании подписанного кандидатом предложения и других документов оформить прием на работу.
Очевидно, что 4-ый шаг сценария допускает частое исключение «кандидат не подходит», возвращающее нас ко 2-ому шагу сценария. А шаг 3 скрывает итерационную работу по согласованию времени интервью между соискателем и интервьюером. Кроме того, если рекрутер не является сотрудником работодателя, то количество представляемых кандидатов, как правило, ограничено договором. Что привносит в сценарий вариант досрочного неуспешного завершения.
Ну и наконец, последний участник сценариев – интервьюер. В изложении Jean-Jacques Dubray ему была отведена довольно пассивная роль. Однако на практике интервью с кандидатом обычно проводит его будущий руководитель. Т.е. в реальной деятельности именно запросы этого персонажа на закрытие вакансии заставляют весь этот механизм двигаться. И он является не только главным действующим лицом, а заказчиком, т.е. тем самым «бизнесом», о котором в предыдущих обсуждениях было сказано так много слов. Именно этот участник процесса формирует заявку на подбор, собеседует кандидатов, принимает решение о выставлении предложения на занятие соискателем позиции. К слову, в ходе реальной деятельности по подбору персонала заказчик будет изменять требования к кандидату, например, если обнаружить кандидата со всеми необходимыми навыками долгое время не удается. Он же будет настаивать на необходимости проведения интервью с несколькими соискателями до принятия окончательного решения о выборе нового сотрудника; назначать дополнительные интервью и, возможно, рекомендовать кого-либо из кандидатов на другую позицию, более высокую или более низкую по отношению к исходной.
Принимаясь за написание этого поста, я намеривался отрисовать свое видение в нотации BPMN. Но, даже поверхностно перечислив основные моменты, я практически не сомневаюсь в безуспешности такой попытки. Смотрите, как много нужно учесть: пул рекрутеров, которые обрабатывают кейсы по закрытию вакансий; соискатели, имеющие возможность претендовать на несколько открытых позиций (или же отправившие резюме без привязки к конкретной позиции, что называется, про запас); руководители, являющиеся заказчиками сервиса по подбору персонала, работающие одновременно по нескольким вакансиям с разными рекрутерами и отсматривающие нескольких соискателей, иногда по несколько раз. А еще в ходе исполнения процесса соискатель может найти себе другую работу, рекрутер временно передать свои дела коллеге по причине болезни или отпуска, а заказчик передать свою вакансию в другое подразделение. Не представляю, какая нотация позволит нам справиться с решением этой задачи. На практике такой процесс будет делаться исходя из возможностей имеющихся систем: сервисов форм, групповых календарей, worklist-ов и т.д. Причем все эти, с позволения сказать сервисы имеют проприетарные интерфейсы, придуманный кем-то давным-давно набор состояний и переходов, а так же туманные перспективы развития.
Есть ли выход из сложившейся ситуации? Как может выглядеть разумный подход к управлению реальными бизнес-процессами?
Вот это грабли так грабли! Все любят задачу приема на работу, рассматривая ее как простой полигон, и практически все совершают одну и ту же ошибку: пытаются решить ее в рамках одного процесса. Причем совершают ее даже BPM-вендоры. В свое время видел кривую схему у Lombardi, а вот более свежий пример http://blog.processmaker.com/?p=465
Задача эффективно решается средствами BPMN, я это гарантирую. Но без хореографии (нескольких процессов и обмена сообщениями между ними) не обойтись.
Всем учить матчасть! Лениво, но, видимо, все-таки придется мне взяться за чтение курса по BPMN.
Бизнес-аналитики сами не понимают, во что они ввязываются. Не буду утверждать, что я внимательно изучил четвертую сотню страниц беты спецификации BPMN 2.0 посвященную хореографии. Наверняка OMG аккуратно проработал правила рисования между строк (прошу прощения, между пулов). Лучше опять вернемся к примеру. Давайте возьмем какое-нибудь одно взаимодействие. Пусть это будет формирование job offer. Рекрутер получает от интервьюера задание предложить работу одному из соискателей. Его действия:
Во-первых, неплохо бы убедиться, что на данную позицию уже никому не сделано предложение. Если предложение было сделано, то надо либо его отменить (например, если предложение было сделано полгода назад, а соискатель так и не откликнулся) либо аварийно завершиться.
Во-вторых, хорошо бы понять, а нет ли у нас назначенных интервью по данной вакансии. Ведь после того, как мы отправим предложение соискателю, мы будем ждать его решения. Если интервью назначены, то мы их отменяем (или переносим?). Вообще, не хочется отпускать других соискателей до тех пор, пока у нас нет подписанного job offer-а. Наверное, есть смысл определить срок действия предложения (вот это уже, действительно, грабли; узнаю ситуацию совмещения в одном процессе заданий планирования и исполнения, но это отдельная тема).
Далее, мы проверяем, а не рассматривает ли в текущий момент наш кандидат другие позиции. Ну, как-то нелогично собеседовать будущего начальника отдела, которому сделано предложение, на соискание позиции младшего бизнес-аналитика.
Пока мы все это делаем, соискатель разочаровывает нас отказом от предложенной позиции. Т.е. не дожидаясь предложения, он просто берет и уходит, о чем нас корректно извещает. Естественно мы запускаем компенсирующие действия: уведомляем соискателя, от которого уже полгода нет ответа, что мы его все еще ждем, переназначаем отмененные интервью, нотифицируем инициатора подбора на данную вакансию и т.д. и т.п.
Это не шутка, у нас в интеграции такие задачи более-менее успешно реализуются последние несколько лет. Вот только до моделей пока руки не доходили. Впрочем, у нас на работе есть огромный плоттер. На нем один человек раз в год распечатывает целевую архитектуру. Весь год рисует, а потом один день печатает. Я думаю, этот девайс как раз подойдет и для печати моделей процессов координации независимых процессов.
Максим, извините, но Вы не с того начинаете. Прежде чем разбираться с подробностями, определитесь: сколько у вас в этой задаче процессов и какие? По-вашему, один?
Вопрос абсолютно лишен смысла. Сколько процессов в вашем автомобиле? Сколько информационных систем в вашей компании? Кто-то ответит сто, а кто-то тысяча. Когда мы говорим об абстрактных вещах, все зависит от того, как мы сами проводим границы. В примере я выделил три класса действующих лиц. Мог бы выделить два или сто пятьдесят четыре. Зависит от того, как я буду классифицировать вакансии, соискателей и сотрудников отдела персонала, а так же интеракции между ними. Буду ли в ходе деятельности компании обновлять процессы или же предпочту заменять их новыми и т.д.
Мы работаем с постоянно развивающимся сюжетом, в котором действующие лица преследуют значимые для них цели. Наша задача поддерживать этот сюжет, реализуя некоторый контракт о взаимодействии.
Напротив, вопрос абсолютно конкретен и вопрос этот ключевой. Сколько процессов в рассматриваемой задаче приема на работе? Бизнес-аналитику простительно об этом не задумываться, архитектору – нет.
Пока вы пытаетесь решить ее с помощью одного процесса, у вас ничего не получится. На самом деле процессов здесь минимум три. Больше, при желании, сделать можно, меньше – вряд ли. При этом я не рассматриваю и классификации вакансий.
читать “не рассматриваю разные версии процессов”
Максим,
самое смешное в этом диалоге – это то, что мы с Анатолием очень часто обращаемся именно к этому примеру – приему на работу – для демонстрации хореографии и вообще о том, как выявлять процессы :))) То есть берем маркер – и рисуем именно BPMN диаграмму!
Поэтому держу пари: этот спор Вам не выиграть 🙂
Зато тренинг по BPMN рекомендую! Не Вам лично, конечно, а, к примеру, группе сотрудников компании.
Юлия, да мы вроде ни о чем и не спорим. Дискуссия распалась на два монолога. Я рассказываю о том, что хореография – это сложно. Тем не менее, подавляющее большинство integration centric задач это именно хореография. Оркестровка применима только в очень вырожденной ситуации – создание решения в виде зонтика поверх систем, предоставляющих синхронные интерфейсы. Я думаю что таких “правильных” проектов практически не осталось. Их все давно реализовали и рассказали об этом на конференциях. Так что я скорее не верю в оркестровку, чем в хореографию.
Анатолий ведет параллельный монолог, призывает меня учить матчасть. Я по секрету скажу, что ни в моем департаменте, ни в других подразделениях компании нет бизнес-аналитиков, которые хотели бы что-либо рисовать в BPMN. В свое время, не поверили они в эту идею. Я знаю как можно изменить ситуацию, но не знаю зачем это мне.
PS> Кстати, в разделе “ссылки”, в правой колонке блога я разместил ссылку на очень познавательную статью про подходы к моделированию
12 Different Ways to Model Business Processes
Тогда я Вас не понимаю. Вы предлагаете отказаться от BPM в пользу кейс-менеджмента просто в силу того, что BPMN- это сложная нотация?
Наоборот, я предлагаю заниматься BPM да же тем, кто не верит в окупаемость моделирования процессов при помощи BPMN 😉
На мой взгляд, разница между традиционным BPM и ACM существенно глубже. Это не просто вопрос нотаций или платформ, а различные подходы к управлению