На рынке труда нет процессных аналитиков.
На форуме #processtech я участвовал в пленарной дискуссии, которую вела Даша Данилина (@DanilKa6688) из hh.ru. Обсуждали тему "кто такой процессный аналитик и как его найти". Тема заинтересовала многих, к ней возвращались и на воркшопах и во время обсуждений в кулуарах форума. Суперкороткое резюме исследования, которое сделал hh.ru - на рынке труда людей с такой специальностью нет и нет предпосылок к их появлению.
Это проблема. Для того чтобы окупить инвестиции в технологии process и task mining за пару лет нужно параллельно анализировать 2-3 процесса. И даже больше если используем FTE-first подход, в котором эффект каждого из изменений невелик. После удачного пилота или первого проекта команда должна быстро вырасти, но не может. С учетом накопленного опыта предприятие может даже отказаться от первого проекта если нет понимания того, как развиваться дальше.
Почему возникла такая ситуация? Перечислим какими знаниями и навыками обладает идеальный процессный аналитик:
1. Базовый набор знаний и навыков data engineer так как весь анализ идет на основании информации из ИС. Которые надо "достать" и трансформировать в журнал событий. А в ходе анализа писать запросы на SQL. Знание основ ML тоже не помешает для проектов с использованием task mining
2. Навыки самостоятельного системного анализа и защиты результатов. Сейчас, к сожалению, специальность "бизнес аналитик" предполагает фиксацию информацию со слов заказчика и максимум ее верификацию, но не анализ. Поэтому для этой группы знаний и навыков даже корректного названия нет
3. Знание предметной области или домена, к которому относится анализируемый процесс. Так как часто здравый смысл ("цикл в процессе — это плохо") вступает в противоречие с особенностями процесса ("несколько итераций во взаимодействии проектировщика и сметчика это нормально")
4. Умение работать с конкретным инструментом анализа
Таких людей в природе не существует. Инженеры данных не склонны погружаться в нюансы бизнеса. У методологов, которые часто отвечают за обсуждаемые проекты, провалы во втором пункте - устоявшаяся привычка фиксировать результат, а не анализировать ситуацию и защищать предложения по улучшению. Можно найти на рынке эксперта в предметной области с опытом внесения изменений, но он будет дорог.
Из своего опыта и результатов общения с коллегами я могу сформулировать следующие рабочие варианты:
-
Если у вас только проекты FTE-first, то оставляйте за собой функции развития, координации и менторства. Остальную экспертизу "арендуем" у подразделения, отвечающего за RPA которое все рано задействовано в проекте.
-
Если в компании уже есть дата платформа или ведется ее создание, то работайте с ними — это сильно снизит требования к получению информации, можно будет быстро и недорого дообучить специалиста среднего уровня из области бережливого производства которые на рынке есть. Такие специалисты умеют анализировать и обсуждать результаты анализа с прикладными экспертами
-
Если в компании уже есть или создаются подразделение, занимающееся ИИ, то можно создавать ИИ-агентов способных собирать данные и выполнять анализ на основе "здравого смысла". Успешные примеры показывали на форуме МТС и Альфа банк, но создание "с нуля" такого подразделения не окупится
-
Если у вас в списке есть процессы, которые не являются массовыми, но влияют на более фундаментальные финансовые показатели компании, то сразу делайте команду из трех человек: инженер данных, младший аналитик чтобы "рисовать" дэшборды и эксперт понимающий конкретный процесс или семейство процессов. Эффект от сокращения неликвидности складских запасов или роста конверсии их многократно окупит.
А какие рабочие варианты существуют на ваш взгляд?
