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