Бизнес-процесс менеджмент. Часть 3 - Проектирование процессов..
Продолжаю описание Системы управления бизнес-процессами ПАРД.
1 часть - Ввводная ТУТ
2 часть - Карта процессов ТУТ
Проектирование процессов.
Для того что бы процесс начал работать именно так как нужно, и наиболее оптимальным способом, для достижения результатов его нужно спроектировать или по другому запрограммировать.
В моей системе для этого есть несложный алгоритм из 6 шагов. Я его постоянно совершенствую. Еще недавно, в своем посте я описывал 10 шагов.
Для описания процессов я использую различные инструменты, которые тут и привожу.
Используемый язык:
BPMN (англ. Business Process Model and Notation, нотация и модель бизнес-процессов) - система условных обозначений (нотация) для моделирования бизнес-процессов. Разработана Business Process Management Initiative (BPMI) и поддерживается Object Management Group,
Программы, которые использую я:
- www.gliffy.com - онлайн-сервис, который позволяет рисовать любые диаграммы в том числе содержит обозначения BPMN.
- GoogleDoks - можно рисовать, но только в простых обозначениях. Удобно расшаривать, сохранять как рисунок и вставлять в корп-портал. Не удобно из-за примитивного "инструментария".
- iGrafx - десктопная прога, содержит в себе BPMN. Имеет наиболее широкий и удобный функционал для програмирования процессов. Есть настройки по времени и может проигрывать процессы. Наиболее продвинутые функции сложны для малых предприятий. Хороша тем, что при росте вашей компании, ее функционало хватит на долгое развитие вашей системы управления бизнес-процессами.
- CRM-Mawisoft. Очень удобно отслеживать некоторые процессы. Например: Выполнение заказа, Обработка претензии. Существует специализированный софт, который позволяет отслеживать процессы, но он нужен предприятиям на которых как минимум есть отдельный процес-менеджер или даже отдел.
- OmniGraffe - Великолепная программа для рисования диаграм на IPad. Практически полностью удовлетворяет потребности в функционале и позволяет работать над процессами в дороге или в кафе. Маст Хев(как грится).
Алгоритм проектирования процесса(для новых процессов):
1. Определить цель процесса.
-Определяем событие старта прцесса.
-Определяем конечный продукт(результат) процесса.
-Определяем событие завершения процесса.
2. Составить перечень задач, которые по первоначальному мнению, необходимы для выполнения процесса.Накидывайте в список, все задачи, которые по вашему мнению необходимы для достижения результатов процесса. Например - в процессе выполения заказа, ни как не обойтись без задачи - отправка товара. Или в процессе снабжения, ни как не обойтись без задачи - постановка товара на приход.
Выкинуть задачи, которые добавляют ценности меньше чем требуют на их исполнение.Этот этап нужно выполнять несколько раз в течении всего проектирования процесса и по мере выявления таких задачь.
Например - контроль за дебиторкой возможно стоит дороже чем потерянная дебиторка. Это бывает, когда заказы небольшие и не являются разовыми, заказы делают постоянные клиенты, рейтинг платежеспособности которых легко выявить.
3. Выстроить задачи в цепочку последовательно.Выстраивать так как будто все задачи процесса будет выполнять один человек.
4. Распределить задачи между сотрудниками в соответствии с компетенциями.Например - в процессе выполнения заказа, могут быть задействованы разные компетенции. От умения расценять заказ, до умения упаковывать товар.
- Определить, возможно опытным путем, количество времени необходимого для выполнения каждой задачи один раз.
- Выявить перегруженность или недозагруженность того или иного участника процесса. Устранить выявленные дисбалансы.Взять самую долгую по времени задачу и посчитать сколько раз эту задачу сможет выполнить назначенный сотрудник.
Понять, остальные сотрудники сколько времени потратят на выполение такого же количества задач.
Этот анализ выявит дисбалансы в распределении задач.
Возможно один из сотрудников не сможет выполнить нужное количество задач в день, что бы процесс мог пройти нужное количество раз в день.
Или наоборот- какой то сотрудник будет недозагружен, так как сможет выполнить нужное количество раз свою задачу меньше чем за день.
5. Сведение задач из последовательной цепочки в параллельные цепочки субьектов.
- Выявить возможность выполнения задач параллельно разными сотрудниками.
6. Привязать(по возможности) выполнение задач ко времени, это будет первым шагом к регламентированию работы ваших сотрудников.
Рассмотрим все написанное на конкретном примере:
Мы хотим спроектировать процесс обработки претензий. Так и назовем - Обработка претензий. Я буду рассматривать на примере компании, которая продает запчати для грузовых автомобилей. Оптом по России, корпоративным клиентам.(Есть у меня такой проект в планах)
У нас есть Конечный Внутренний Продукт (КВП) -Лояльный клиент, одним из составляющих этого Продукта мы выявили подпродукт - Решенные претензии клиента, снятый негатив от претензии.
И вот мы решили спроектировать бизнес-процесс для создания этого КВП. Тут по пути появился Отдел Лояльности, который отвечает за этот КВП.
1. Определяем цель процесса:
Цель процесса: Решенная претензия клиента, снятый негатив от претензии.
Событие старта процесса: Клиент обратился с претензией
Результат процесса: Решенная претензия клиента
Конечное событие процесса: Следующий заказ клиента.
2. Составляем перечень задачь:
- регистрация претензии
- рассмотрение справедливости претензии
- выявление причины возникновения брака в работе или детали
- устранение ошибки в процессах, которая привела к возникновению брака
- замена бракованного товара
-созвониться с клиентом и убедиться, что клиент удовлетворен
- исправлением брака.
- компенсация клиенту неудобства полученного в результате брака в работе.
- Проверить продолжил ли сотрудничество клиент с компанией.
Мы накидали перечень задач "на вскидку" , пока нам кажется что этого
достаточно, мы еще не рассмотрели вариативность на некоторых этапах и
не выявили подпроцессы. Для начала проектирования этого вполне
достаточно.
3. Начинаем выстраивать задачи в цепочку:
РИС.1
Вот что у нас получилось. Во первых - у нас появились дополнительные
задачи, которые мы первоначально не смогли предусмотреть.
Во вторых - у нас появилась вариативность в некоторых местах.
В третьих - мы выявили подпроцессы и другие необходимые процессы,
которые нужно тут же занести в Карту процессов.
Выстраиваем и добавляем задачи исходя из идеологии компании и здравого смысла. Что значит исходя из идиологии? Это значит, что действуем в соответствии с ценностями компании и целями.
Например: У меня есть ценность - открытость. В соответствии с этой ценностью я выставил задачи: Связаться с клиентом и сообщить о устранении ошибки.,Связаться с клиентом
(Подпроцесс-Скрипт 1),Связаться с клиентом и сообщить что деталь была не бракованной,Связаться с клиентом, сообщить о результатах экспертизы и мерах по предотвращению подобных случаев.
Да да, именно так идеология проникает в бизнес-процессы. Ото один из маленьких примеров.
4. Распределяем задачи между подразделениями или сотрудниками:
РИС.2
Вот что получилось в результате.
Дальше:
-Определить количество времени необходимого для выполнения каждой
задачи один раз.
В данном случае не нужно считать время всех задач. Не стоит считать
сколько времени потребуется на звоки клиенту. А вот посчитать примерно
время подпроцессов нужно обязательно.
- Выявить перегруженность или недозагруженность того или иного участника процесса. УСтранить выявленные дисбалансы.
Тут, даже на вскидку, видно что задачи распределены равномерно. Перезагруженность того или иного участника процессов можно выявить только заглянув в Карту процессов и Регламент сотрудника и увидет степень загруженности специалиста.
5. Сведение задачь из последовательной цепочки в параллельные цепочки субьектов:
- Выявить возможность выполнения задачь параллельно разными сотрудниками.
В нашеп процессе не так то и много задачь, которые можно делать параллельно.
Но во время это работы, у меня процесс разбился на два самостоятельных.
РИС.3
Так же, я разделил весь процесс на этапы. Это важно будет на этапе работы процессов. Если вы используете прграмму для отслеждивания работы процесса, тоо вы сможете видеть на каком этапе находиться процесс.
Применительно к нашему прцессу - Регистрация процесса будет происходить в виде сделкив нашей CRM. Будут присваивать этапы и сотрудник ответственный за процесс будет всегда держать руку на пульсе. И сами сотрудники не будут паутаться в претензиях. Их может быть не мало, если продаж очень много и они не крупные.
6.Привязать выполнение задач ко времению:
Нужна подумать и решить, какие задачи мы можем привязать ко времени. Например обработка претензий в нашем случае может быть привязана ко времени. Можно установить что обработка претензий будет начинаться раз в неделю, по понедельникам, в 10.00. Соответственно, инспектор по качеству будет открывать в понедельник в 10.00 все зарегестрированные претензии и начинать с ними работу. Ему не нужно будет ничего напоминать, он со временем привыкнет начинать неделю с этой работы.
Вот как это будет выглядеть в ОБП.
РИС.4
----------------------------------------------
Этот процесс я взял практически с потолка и спроектировал прямо сегодня, в ходе написания этой главы. Тут много до чего можно и нужно докопаться. Я немного упростил, так как цель была-продемонстрировать проектирование конкретного процесса по моей системе.
Что бы было понятно, что я тут не теоретезирую, а делюсь конкретными практическими наработками.
-----
Естесственно, процесс будет дорабатываться после этапа тестирования( это будет описано в следующей части посвященной внедрению). По прошествии месяцев он может измениться до неузнаваемости и заблестеть новыми красками. К процессу появятся коментарии, он обрастет подпроцессами и другими документами. Только тогда, это станет настоящим бизнес-процессом, который нестыдно будет считать важным активом предприятия.
-----
Я взял вариант, когда мы проектируем процесс с нуля, а это гораздо проще, чем если мы хотим взять уже действующий процесс и описать его. Обьясню - когда компания уже давно работает и привыкла идти по определенной колее, пусть и не правильной, ломать по живому очень сложно. Нужно учитывать много факторов. Нужно работать в ситуации, когда люди не могут остановить работу ни на день. И делать реинжиниринг процессов в таком случае не просто.
------
Еще нужно сказать, что при рисовании бизнес-процесса, я несколько отступил от стандартов BPMN. Но считаю, что те упрощения, которые я допустил, являются необходимыми.
Не бойтесь проектировать и описывать процессы. Пусть вначале это будет совсем на примитивном уровне. В любом случае это будет лучше, чем отсутствие какой бы то ни было работы с бизнес-процессами. Дорогу осилит идущий.
-----
Я понимаю, что гуру BPM или какие нибудь модные консалтеры по проектированию бизнес-процессов, загрузят меня разными терминами, типа - BPA, BPMs, Process Intelligence, Process Mining, iBPM, ACM и т.д.
Я создавал систему максимально простой, что бы любой не подготовленный человек взялся и делал. А потом можно дойти и до PBMS и до Gamification.
----
Из за упрощения, я за рамками описания проектирования оставляю работу с ограничениями системы. При проектировании процессов, необходимо учитывать ограничения, которые накладывает на вас среда, и проектировать с учетом этого. Но это отдельная тема, за рамками Бизнес-процесс менеджмента.
-----
В следующей части будет очень важный раздел - Внедрение и поддержание процессов.---
ЗЫ: Извиняюсь за ужасное форматирование текста. Копировал с Корп-портала и почему то теперь не могу отформатировать нормально.
1 часть - Ввводная ТУТ
2 часть - Карта процессов ТУТ
Проектирование процессов.
Для того что бы процесс начал работать именно так как нужно, и наиболее оптимальным способом, для достижения результатов его нужно спроектировать или по другому запрограммировать.
В моей системе для этого есть несложный алгоритм из 6 шагов. Я его постоянно совершенствую. Еще недавно, в своем посте я описывал 10 шагов.
Для описания процессов я использую различные инструменты, которые тут и привожу.
Используемый язык:
BPMN (англ. Business Process Model and Notation, нотация и модель бизнес-процессов) - система условных обозначений (нотация) для моделирования бизнес-процессов. Разработана Business Process Management Initiative (BPMI) и поддерживается Object Management Group,
Программы, которые использую я:
- www.gliffy.com - онлайн-сервис, который позволяет рисовать любые диаграммы в том числе содержит обозначения BPMN.
- GoogleDoks - можно рисовать, но только в простых обозначениях. Удобно расшаривать, сохранять как рисунок и вставлять в корп-портал. Не удобно из-за примитивного "инструментария".
- iGrafx - десктопная прога, содержит в себе BPMN. Имеет наиболее широкий и удобный функционал для програмирования процессов. Есть настройки по времени и может проигрывать процессы. Наиболее продвинутые функции сложны для малых предприятий. Хороша тем, что при росте вашей компании, ее функционало хватит на долгое развитие вашей системы управления бизнес-процессами.
- CRM-Mawisoft. Очень удобно отслеживать некоторые процессы. Например: Выполнение заказа, Обработка претензии. Существует специализированный софт, который позволяет отслеживать процессы, но он нужен предприятиям на которых как минимум есть отдельный процес-менеджер или даже отдел.
- OmniGraffe - Великолепная программа для рисования диаграм на IPad. Практически полностью удовлетворяет потребности в функционале и позволяет работать над процессами в дороге или в кафе. Маст Хев(как грится).
Алгоритм проектирования процесса(для новых процессов):
1. Определить цель процесса.
-Определяем событие старта прцесса.
-Определяем конечный продукт(результат) процесса.
-Определяем событие завершения процесса.
2. Составить перечень задач, которые по первоначальному мнению, необходимы для выполнения процесса.Накидывайте в список, все задачи, которые по вашему мнению необходимы для достижения результатов процесса. Например - в процессе выполения заказа, ни как не обойтись без задачи - отправка товара. Или в процессе снабжения, ни как не обойтись без задачи - постановка товара на приход.
Выкинуть задачи, которые добавляют ценности меньше чем требуют на их исполнение.Этот этап нужно выполнять несколько раз в течении всего проектирования процесса и по мере выявления таких задачь.
Например - контроль за дебиторкой возможно стоит дороже чем потерянная дебиторка. Это бывает, когда заказы небольшие и не являются разовыми, заказы делают постоянные клиенты, рейтинг платежеспособности которых легко выявить.
3. Выстроить задачи в цепочку последовательно.Выстраивать так как будто все задачи процесса будет выполнять один человек.
4. Распределить задачи между сотрудниками в соответствии с компетенциями.Например - в процессе выполнения заказа, могут быть задействованы разные компетенции. От умения расценять заказ, до умения упаковывать товар.
- Определить, возможно опытным путем, количество времени необходимого для выполнения каждой задачи один раз.
- Выявить перегруженность или недозагруженность того или иного участника процесса. Устранить выявленные дисбалансы.Взять самую долгую по времени задачу и посчитать сколько раз эту задачу сможет выполнить назначенный сотрудник.
Понять, остальные сотрудники сколько времени потратят на выполение такого же количества задач.
Этот анализ выявит дисбалансы в распределении задач.
Возможно один из сотрудников не сможет выполнить нужное количество задач в день, что бы процесс мог пройти нужное количество раз в день.
Или наоборот- какой то сотрудник будет недозагружен, так как сможет выполнить нужное количество раз свою задачу меньше чем за день.
5. Сведение задач из последовательной цепочки в параллельные цепочки субьектов.
- Выявить возможность выполнения задач параллельно разными сотрудниками.
6. Привязать(по возможности) выполнение задач ко времени, это будет первым шагом к регламентированию работы ваших сотрудников.
Рассмотрим все написанное на конкретном примере:
Мы хотим спроектировать процесс обработки претензий. Так и назовем - Обработка претензий. Я буду рассматривать на примере компании, которая продает запчати для грузовых автомобилей. Оптом по России, корпоративным клиентам.(Есть у меня такой проект в планах)
У нас есть Конечный Внутренний Продукт (КВП) -Лояльный клиент, одним из составляющих этого Продукта мы выявили подпродукт - Решенные претензии клиента, снятый негатив от претензии.
И вот мы решили спроектировать бизнес-процесс для создания этого КВП. Тут по пути появился Отдел Лояльности, который отвечает за этот КВП.
1. Определяем цель процесса:
Цель процесса: Решенная претензия клиента, снятый негатив от претензии.
Событие старта процесса: Клиент обратился с претензией
Результат процесса: Решенная претензия клиента
Конечное событие процесса: Следующий заказ клиента.
2. Составляем перечень задачь:
- регистрация претензии
- рассмотрение справедливости претензии
- выявление причины возникновения брака в работе или детали
- устранение ошибки в процессах, которая привела к возникновению брака
- замена бракованного товара
-созвониться с клиентом и убедиться, что клиент удовлетворен
- исправлением брака.
- компенсация клиенту неудобства полученного в результате брака в работе.
- Проверить продолжил ли сотрудничество клиент с компанией.
Мы накидали перечень задач "на вскидку" , пока нам кажется что этого
достаточно, мы еще не рассмотрели вариативность на некоторых этапах и
не выявили подпроцессы. Для начала проектирования этого вполне
достаточно.
3. Начинаем выстраивать задачи в цепочку:
РИС.1
Вот что у нас получилось. Во первых - у нас появились дополнительные
задачи, которые мы первоначально не смогли предусмотреть.
Во вторых - у нас появилась вариативность в некоторых местах.
В третьих - мы выявили подпроцессы и другие необходимые процессы,
которые нужно тут же занести в Карту процессов.
Выстраиваем и добавляем задачи исходя из идеологии компании и здравого смысла. Что значит исходя из идиологии? Это значит, что действуем в соответствии с ценностями компании и целями.
Например: У меня есть ценность - открытость. В соответствии с этой ценностью я выставил задачи: Связаться с клиентом и сообщить о устранении ошибки.,Связаться с клиентом
(Подпроцесс-Скрипт 1),Связаться с клиентом и сообщить что деталь была не бракованной,Связаться с клиентом, сообщить о результатах экспертизы и мерах по предотвращению подобных случаев.
Да да, именно так идеология проникает в бизнес-процессы. Ото один из маленьких примеров.
4. Распределяем задачи между подразделениями или сотрудниками:
РИС.2
Вот что получилось в результате.
Дальше:
-Определить количество времени необходимого для выполнения каждой
задачи один раз.
В данном случае не нужно считать время всех задач. Не стоит считать
сколько времени потребуется на звоки клиенту. А вот посчитать примерно
время подпроцессов нужно обязательно.
- Выявить перегруженность или недозагруженность того или иного участника процесса. УСтранить выявленные дисбалансы.
Тут, даже на вскидку, видно что задачи распределены равномерно. Перезагруженность того или иного участника процессов можно выявить только заглянув в Карту процессов и Регламент сотрудника и увидет степень загруженности специалиста.
5. Сведение задачь из последовательной цепочки в параллельные цепочки субьектов:
- Выявить возможность выполнения задачь параллельно разными сотрудниками.
В нашеп процессе не так то и много задачь, которые можно делать параллельно.
Но во время это работы, у меня процесс разбился на два самостоятельных.
РИС.3
Так же, я разделил весь процесс на этапы. Это важно будет на этапе работы процессов. Если вы используете прграмму для отслеждивания работы процесса, тоо вы сможете видеть на каком этапе находиться процесс.
Применительно к нашему прцессу - Регистрация процесса будет происходить в виде сделкив нашей CRM. Будут присваивать этапы и сотрудник ответственный за процесс будет всегда держать руку на пульсе. И сами сотрудники не будут паутаться в претензиях. Их может быть не мало, если продаж очень много и они не крупные.
6.Привязать выполнение задач ко времению:
Нужна подумать и решить, какие задачи мы можем привязать ко времени. Например обработка претензий в нашем случае может быть привязана ко времени. Можно установить что обработка претензий будет начинаться раз в неделю, по понедельникам, в 10.00. Соответственно, инспектор по качеству будет открывать в понедельник в 10.00 все зарегестрированные претензии и начинать с ними работу. Ему не нужно будет ничего напоминать, он со временем привыкнет начинать неделю с этой работы.
Вот как это будет выглядеть в ОБП.
РИС.4
----------------------------------------------
Этот процесс я взял практически с потолка и спроектировал прямо сегодня, в ходе написания этой главы. Тут много до чего можно и нужно докопаться. Я немного упростил, так как цель была-продемонстрировать проектирование конкретного процесса по моей системе.
Что бы было понятно, что я тут не теоретезирую, а делюсь конкретными практическими наработками.
-----
Естесственно, процесс будет дорабатываться после этапа тестирования( это будет описано в следующей части посвященной внедрению). По прошествии месяцев он может измениться до неузнаваемости и заблестеть новыми красками. К процессу появятся коментарии, он обрастет подпроцессами и другими документами. Только тогда, это станет настоящим бизнес-процессом, который нестыдно будет считать важным активом предприятия.
-----
Я взял вариант, когда мы проектируем процесс с нуля, а это гораздо проще, чем если мы хотим взять уже действующий процесс и описать его. Обьясню - когда компания уже давно работает и привыкла идти по определенной колее, пусть и не правильной, ломать по живому очень сложно. Нужно учитывать много факторов. Нужно работать в ситуации, когда люди не могут остановить работу ни на день. И делать реинжиниринг процессов в таком случае не просто.
------
Еще нужно сказать, что при рисовании бизнес-процесса, я несколько отступил от стандартов BPMN. Но считаю, что те упрощения, которые я допустил, являются необходимыми.
Не бойтесь проектировать и описывать процессы. Пусть вначале это будет совсем на примитивном уровне. В любом случае это будет лучше, чем отсутствие какой бы то ни было работы с бизнес-процессами. Дорогу осилит идущий.
-----
Я понимаю, что гуру BPM или какие нибудь модные консалтеры по проектированию бизнес-процессов, загрузят меня разными терминами, типа - BPA, BPMs, Process Intelligence, Process Mining, iBPM, ACM и т.д.
Я создавал систему максимально простой, что бы любой не подготовленный человек взялся и делал. А потом можно дойти и до PBMS и до Gamification.
----
Из за упрощения, я за рамками описания проектирования оставляю работу с ограничениями системы. При проектировании процессов, необходимо учитывать ограничения, которые накладывает на вас среда, и проектировать с учетом этого. Но это отдельная тема, за рамками Бизнес-процесс менеджмента.
-----
В следующей части будет очень важный раздел - Внедрение и поддержание процессов.---
ЗЫ: Извиняюсь за ужасное форматирование текста. Копировал с Корп-портала и почему то теперь не могу отформатировать нормально.