Автоматизация БП. Почему не всегда всё идет по плану?
После того как похвастался в предыдущем посте, решил все таки оживить ленту и поделиться своими наблюдениями.
Сейчас занимаюсь переработкой одного из HR-процессов в Битрикс24. И в очередной раз убедился, что самое интересное начинается уже после того, как вроде бы всё разработано и работает (ага...) Казалось бы, достаточно стандартный процесс: прием сотрудника, согласование, оформление, адаптация. Есть определенная последовательность действий, ответственные, задачи и уведомления. Но когда начинаешь разбирать отдельные сценарии, появляются интересные нюансы. Например, что делать, если сотрудник передумал выходить на работу? Или если его уволили в процессе адаптации? А что будет с уже созданными задачами, если процесс завершится досрочно? И подобных ситуаций может быть достаточно много. В итоге приходится не просто вносить небольшие корректировки, а пересматривать саму архитектуру процесса. Например, в моем случае решили разделить прием и адаптацию на отдельные БП, чтобы у каждого была своя логика и условия завершения. Вообще, чем больше работаю с автоматизацией, тем чаще прихожу к мысли, что техническая реализация это далеко не самая сложная часть. Гораздо сложнее на этапе проектирования предусмотреть все возможные сценарии и исключения. Особенно когда в постановке задачи всё выглядит достаточно просто, а в процессе разработки выясняется, что половина бизнес-логики существует исключительно в головах сотрудников. А некоторые и вовсе, сопротивляются подобным нововведениям и пытаются выводить процесс по старинке, удлиняя сроковое плечо до максимума.
Интересно, как у вас организована работа с такими сценариями? Стараетесь максимально проработать всё до разработки или чаще дорабатываете процессы уже по факту эксплуатации?
· 27.10
Добрый день, Алексей 👋🏻 После прочтения у меня возник закономерный вопрос: а почему штатные сценарии завершения процесса и архитектурные альтернативы впервые рассматриваются вами уже после реализации решения?
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 27.10
Добрый день! Это был в принципе первый "боевой" БП который я построил. На старте, битриксовыц конструктор был для меня в новинку. Архитектурного опыта не было, строил все в рамках одного шаблона (и онбординг и прием). В дальнейшем, после доработок данного БП, появился техдолг, который пришлось рефакторить, уже имея опыт построения и оптимизации процессов.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 27.10
Благодарю за пояснение 😌 Тогда позвольте уточнить еще один момент: правильно ли я понимаю, что первоначально вы реализовали автоматизацию процесса, а уже в ходе последующих доработок начали выявлять и анализировать альтернативные сценарии его выполнения? Или эти сценарии были известны заранее, но не учитывались вами при проектировании решения?
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 27.10
Иван, все верно. Процесс дорабатывался со временем, все "переменные" не были известны на старте. В целом, для компании это стало первой, такого рода, автоматизацией. Изначально процесс состоял из, условных, 30-50 активити, сейчас же, он разросся до 502 нод, 74 веток выполнения и 111 переменных.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён