В первую очередь, я хочу выразить признательность участникам обсуждения сообщения Маргинальный подход к моделированию бизнес-процессов. Конструктивное обсуждение подходов позволяет не только взглянуть на проблему с различных точек зрения, но и своевременно отсеять неверные предположения.
В комментариях к этому сообщения я упомянул сделанный Анатолием Белайчуком перевод статьи Jean-Jacques Dubray Семь заблуждений из области исполнения бизнес-процессов Эта работа дает нам отличную возможность не просто порассуждать о преимуществах или недостатках того или иного подхода, но и проверить свои выводы на изложенном в статье конкретном примере. Dubray достаточно основательно расписывает задачу приема сотрудника на работу. Проанализировав возникшие при этом проблемы, он подводит нас к выводу о необходимости дополнения традиционного набора инструментов компонентной архитектурой (Service Component Architecture, SCA). Я не являюсь приверженцем SCA, но разделяю идею автора об использовании композитных приложениях в автоматизации управления процессами предприятия.
Но, что более важно, приведенный в статье анализ дает нам возможность увидеть несколько большее, чем возможности и ограничения тех или иных инструментов, а именно – реальные практические потребности управления, обычно скрываемые нотациями и методологиями.
Итак, у нас есть три действующих лица: соискатель, рекрутер и интервьюер. Относительно наличия последнего персонажа у меня имеются сомнения, но на BPMN модели присутствует отдельная дорожка, потому я считаю, что интервьюер – это отдельная роль. Это не единственный неясный момент в статье. Например, непонятно, ведет ли каждого соискателя один рекрутер от резюме до приема на работу, или же функции проверки резюме и подготовки предложения соискателю могут выполнять различные сотрудники. Не буду додумывать, а постараюсь держаться максимально близко к описанному в статье случаю, хотя по ходу дела обращаться к здравому смыслу все равно придется.
Соискатель — а именно он является главным действующим лицом — заинтересован в получении работы. Минимальным набором шагов, приводящих его к достижению цели, является:
- Отправить заявление о приеме на работу;
- Пройти интервью;
- Подписать job offer;
- Оформиться, т.е. подписать предложенные работодателем документы.
С целями рекрутера ситуация не столь ясная. Однако, из опыта работы с управлением персонала, рискну предположить, что рекрутер отвечает за быстрое закрытие вакантных позиций. И его работа выглядит следующим образом:
- Получить и опубликовать заявку на подбор;
- Выбрать откликнувшегося кандидата;
- Организовать интервью;
- Убедиться, что кандидат подходит, и подготовить job offer;
- На основании подписанного кандидатом предложения и других документов оформить прием на работу.
Очевидно, что 4-ый шаг сценария допускает частое исключение «кандидат не подходит», возвращающее нас ко 2-ому шагу сценария. А шаг 3 скрывает итерационную работу по согласованию времени интервью между соискателем и интервьюером. Кроме того, если рекрутер не является сотрудником работодателя, то количество представляемых кандидатов, как правило, ограничено договором. Что привносит в сценарий вариант досрочного неуспешного завершения.
Ну и наконец, последний участник сценариев – интервьюер. В изложении Jean-Jacques Dubray ему была отведена довольно пассивная роль. Однако на практике интервью с кандидатом обычно проводит его будущий руководитель. Т.е. в реальной деятельности именно запросы этого персонажа на закрытие вакансии заставляют весь этот механизм двигаться. И он является не только главным действующим лицом, а заказчиком, т.е. тем самым «бизнесом», о котором в предыдущих обсуждениях было сказано так много слов. Именно этот участник процесса формирует заявку на подбор, собеседует кандидатов, принимает решение о выставлении предложения на занятие соискателем позиции. К слову, в ходе реальной деятельности по подбору персонала заказчик будет изменять требования к кандидату, например, если обнаружить кандидата со всеми необходимыми навыками долгое время не удается. Он же будет настаивать на необходимости проведения интервью с несколькими соискателями до принятия окончательного решения о выборе нового сотрудника; назначать дополнительные интервью и, возможно, рекомендовать кого-либо из кандидатов на другую позицию, более высокую или более низкую по отношению к исходной.
Принимаясь за написание этого поста, я намеривался отрисовать свое видение в нотации BPMN. Но, даже поверхностно перечислив основные моменты, я практически не сомневаюсь в безуспешности такой попытки. Смотрите, как много нужно учесть: пул рекрутеров, которые обрабатывают кейсы по закрытию вакансий; соискатели, имеющие возможность претендовать на несколько открытых позиций (или же отправившие резюме без привязки к конкретной позиции, что называется, про запас); руководители, являющиеся заказчиками сервиса по подбору персонала, работающие одновременно по нескольким вакансиям с разными рекрутерами и отсматривающие нескольких соискателей, иногда по несколько раз. А еще в ходе исполнения процесса соискатель может найти себе другую работу, рекрутер временно передать свои дела коллеге по причине болезни или отпуска, а заказчик передать свою вакансию в другое подразделение. Не представляю, какая нотация позволит нам справиться с решением этой задачи. На практике такой процесс будет делаться исходя из возможностей имеющихся систем: сервисов форм, групповых календарей, worklist-ов и т.д. Причем все эти, с позволения сказать сервисы имеют проприетарные интерфейсы, придуманный кем-то давным-давно набор состояний и переходов, а так же туманные перспективы развития.
Есть ли выход из сложившейся ситуации? Как может выглядеть разумный подход к управлению реальными бизнес-процессами?