Поймите главное - вы описываете процесс не для стола, а для людей. Если вы вставите в схему много-много-много блоков на все возможные случаи жизни, то это не взлетит. Будет красиво выглядеть и можно повесить вместо картины. Сломается на первом "да ну его". Сейвимся от распространенных сливов процесса - читаем статью.
Проблем в построении процессов куча, но результат того стоит. Представили себе идеальное будущее, сохранили впечатление и поехали.
Как фейлят с процессом
пример ситуации и что с этим делать. Рассмотрим
Разделение процесса, которое не отражено в схеме
Пример:
Клиент Вася заказывает у нас карандаши. Мы не производитель, поэтому перезаказываем у завода. Завод принимает только оптовые заказы - нам нужно собрать ещё пару таких Вась. Цепочка процесса такая: запрос от покупателя - согласование цен - заказ поставщику - прием поставки - отгрузка клиенту. Вроде все красиво. Но дьявол сидит в том, что часто один заказ покупателя входит в заказы разных поставщиков (карандаши заказываем на одном заводе, ластики на другом). Да и один заказ поставщику включает в себя кучу заказов покупателей, нужен опт.
На схеме этого не видно, потому что мы уходим от конкретики (заказ #35, заказ #42) к абстрактному "заказ клиента", "заказ поставщику". На схеме же есть четкая связь между документами клиента и поставщика. В жизни получается разделение. У людей ломается мозг.
Как косячат:
- Нет ясности, когда формировать заказ поставщику
- Менеджеры долбят закупщика регламентом в лицо и говорят, что он тормозит процесс, когда закупщик пытается набрать партию на закупку (вместо отправки на завод каждого отдельного заказа клиента)
- После закупки, даже если в ней клиентский заказ должен был поступить только частично, процесс на радостях двигают дальше. Клиент, заказавший стол, получает только ножки и массу впечатлений.
Как решить:
1. Разделите этот процесс на два: заказ клиента и закупка у поставщика. Причем заказ клиента - это не разрубленный по середине наш старый процесс. На самом деле, от старого процесса его отличает только замена блоков "заказ поставщику - прием поставки" на "ожидание поступления заказа". Пускай в заказе покупателя меняются статусы: ожидает, в закупке, поступил частично, поступил полностью. Так вы разобьете нечеткую связь между заказом клиента и закупкой у поставщика. В то же время процесс будет максимально соответствовать жизни без этих вот "а тут на самом деле нужно так...".
2. Введите правила запуска процесса "заказ поставщику" - раз в неделю, по заполнению объема и т.д. Ваши закупщики должны руководствоваться правилами, а не "силой земли" и напором продаванов. Так вы снимаете конфликт между отделами продаж и закупок, убираете импульсивные решения о старте второго процесса.
Итого:
Если в жизни несколько сущностей сливаются в одну (или наоборот), то в схеме часто этим пренебрегают для наглядности. Сотрудники тоже потом пренебрегают такой схемой, в ней ведь чушь. Зачастую оправданно разделять такие процессы на части, выделяя из одного новый процесс, а в месте замены на схеме ставить - "ожидание свершения действия".
Не забудьте подписаться на наш канал, чтобы не пропустить статьи об автоматизации процессов, а также другой наш опыт.