Пример реинжиниринга реального бизнес-процесса или когда за деревьями не видно леса

Контекст бизнес-процесса. Историческая ретроспектива. Частичное выделение ролей

Знакомый программист сейчас в поиске работы. Регулярно посещает собеседования и делится впечатлениями:

— Как сейчас происходит среднестатистический процесс найма технического сотрудника? Да так же, как и в 18 веке – на бумаге. Только тогда фабрикант с инженером обсуждали исключительно бизнес, а современные IT компании копируют элементы HR стиля Google и на собеседовании предлагают задачи про сферических коней в вакууме, стараясь еще создать душевную шумовую обстановку. Такая модная тенденция особенно печальна именно в HR. А до этого была мода на NoSQL, когда «монолит SQL Server» стало почти ругательством. Нехороший тренд. Надо спасать отрасль!

— Кто ж их не любит.

Выявление и приоритезация целей бизнес-процесса

Цель найма — найти сотрудника, способного максимально эффективно решать текущие задачи компании в рамках ее технологического стека. Подцель – минимизировать затраты.
Замечание: в существенной части организаций подцель ошибочно ставят на первое место, уделяя основное внимание автоматизации работы HR-специалиста и повышению его квалификации.

Сценарий AS-IS (идеальный вариант)

К HR-специалисту попадает резюме: самостоятельно находит, робот находит, кандидаты присылают. Если HR видит ключевые слова — передает резюме руководителю. Руководитель дает добро, HR договаривается с кандидатом об очном интервью. На очном интервью: руководитель, ведущий программист, HR, кандидат. 1 час. Принятие решения по результату беседы.
Уточнение: столь широкий спектр интервьюеров на собеседованиях встречается редко – все-таки принципы Agile активно начинают использоваться и за границами девелопмента.

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

Пользователь–фанат: «Экспромт в инженерном деле хорош во время мозгового штурма. А то собеседование на викторину похоже. Вопрос-ответ. Вопрос-ответ. Какую-то сложно-высокую непонятную цель ставят интервьюеры, тестируя инженеров в таких фантастических условиях. Как будто космонавтов выбирают. Для вдумчивой, кропотливой работы, которая и составляет основную массу задач инженера, нужны немного другие навыки. Вектор сбит. Ну вот что полезного собеседник хочет узнать о кандидате, задавая вопрос: «Чему равно i++++++++1?».

Логические изыскания

Чтобы достигнуть основной цели бизнес-процесса, необходимо у кандидата выявить наличие практических навыков в базовых (ключевых – по желанию ЛПР ^[2]) областях технологического стека компании. На мой взгляд, эффективнее всего – выдавать тестовое задание, охватывающее сформированный выше фрагмент технологического стека. Сложность задач – соизмерима с текущими техническими задачами компании. По результату выполнения сразу можно оценить с хорошей точностью, какое количество ценности кандидат может создавать прямо сейчас.
Наличие тестовой задачи также снижает требование к квалификации HR и технических специалистов, проводящих собеседование. На мой взгляд, достаточный уровень – один технический специалист среднего звена.

Пользователь–фанат: «О-о-о, вот то, что надо! Просто и функционально».
Бизнес-аналитик: «Погоди, я еще не закончил».
Пользователь–фанат: ?!

Сценарий TO-BE (идеальный вариант)

После краткого телефонного созвона HR высылает кандидату тестовое задание. Кандидат его выполняет и присылает результат. Технический специалист компании проверяет его (15 минут). Если одобряет, то HR приглашает кандидата на очное интервью с техническим специалистом среднего звена.

Сценарий интервью:

• обсудить результат выполнения тестового задания (15 минут);
• задание-экспромт: аналогичной тематики, но из текущих задач предприятия, предоставить 15 минут тишины;
• обсудить наработки и идеи по экспромту (15 минут).

Итого – за один час один технический специалист среднего звена примет решение хорошего качества. Да и кандидат уже немного в производственном процессе.

Инвестиции, доход, риски

Инвестиции во внедрение оцениваю в один час работы специалиста среднего звена — на разработку тестовых задач.

Считаю, что бизнес-процесс TO-BE более эффективен в свете главной цели и подцели по сравнению с AS-IS. Достижение подцели является побочным эффектом, что приятно вдвойне.
По результатам внедрения новой версии бизнес-процесса, есть потенциал сокращения времени выполнения задач и их спектра для обоих специалистов компании.

Риски не внедрения:

• конкуренты обойдут, найдут сотрудников быстрее и создадут больше ценности;
• компания с увеличенным временем найма новых сотрудников генерирует упущенную выгоду по нескольким фронтам.

Пользователь–фанат: «У меня нет слов, круто. Как у Шерлока Холмса – дело на одну трубку. Молодец!»
Бизнес-аналитик: «Да, мы молодцы. Но главное – это донести идею до ЛПРов ^[2]. Довелось бы еще где-нибудь внедрять – интересная же задача. Ведь это только каркас, у меня еще несколько идеек бродит. Вот послушай, HR тут вообще не нужен, его можно заменить…»

Точное формулирование цели приближает нирвану автоматизации.

Автор: Александр Туровец

Источник ^[3]