Михаил Гордеев, директор по технологиям ЗАО «Евроменеджмент» Андрей Борисов, эксперт направления «Регламентация деятельности и описание бизнес-процессов» «Невской консалтинговой компании» Наталья Коршак, руководитель направления «Регламентация деятельности и описание бизнес-процессов» «Невской консалтинговой компании» Источник: http://www.e-xecutive.ru
При внесении изменений в деятельность компании руководитель вынужден балансировать между двумя крайностями. С одной стороны, есть опасность сломать непродуманным решением налаженные и описанные бизнес-процессы компании. С другой стороны, есть желание повысить эффективность максимальным образом, то есть разрушить все «до основанья, а затем…» построить что-то кардинально новое. Именно на второй парадигме основывался активно пропагандируемый ещё несколько лет назад реинжиниринг бизнес-процессов.
В учебниках по описанию бизнес-процессов приводились замечательные примеры многократного улучшения эффективности деятельности крупных международных компаний. Например, как IBM в разы ускорило процесс рассмотрения заявки на предоставление персональных компьютеров в кредит.
Члены правления корпорации IBM заинтересовались, почему средний срок рассмотрения заявки на предоставление кредита для приобретения персонального компьютера составляет чуть ли не полтора месяца. За это время большинство потребителей успевают приобрести такую «мелочь» (одну-две тысячи долларов) где-либо еще. Чтобы проверить описанный бизнес-процесс компании, члены правления решили провести эксперимент: тут же на заседании заполнили по заявке и попросили отнестись к этим документам со всем вниманием. Разумеется, на следующий день они получили уведомление о предоставлении кредита. «Значит, умеем, когда надо», — решили члены правления и распорядились провести в компании описание и анализ бизнес-процессов.
В результате они узнали, что каждую заявку проверяет несколько отделов, каждый из которых рассматривает определенный ее аспект (кредитную историю, задолженности, имущество и т. п.). Причем, согласно утверждённому описанию, бизнес-процесс рассмотрения каждым отделом компании осуществляется последовательно.
Новые заявки поступают в очередной отдел, эксперт проводит анализ и делает определенные выводы: «Все ясно, можно предоставить компьютер в кредит. Все ясно, нужно отказать. Так, интересный случай, надо разобраться…» И пока он рассматривает одну заявку, со всеми остальными, в том числе и с теми, решение по которым уже было принято, никто не работает, они просто лежат у него в кабинете. И в каждом отделе описанный выше бизнес-процесс повторяется!
Решение, принятое членами совета директоров компании, было простым по сути и реинжиниринговым по реализации. Каждый отдел сформулировал ряд четких критериев, по которым можно было четко понять, что необходимо сделать с каждой заявкой: предоставлять компьютер в кредит, отказать или же провести более детальный анализ. Затем специалисты компании описали новый бизнес-процесс и разработали многотерминальную экспертную систему, за терминалы посадили операционисток (естественно, обучив их по специально разработанной программе). В результате бизнес-процесс стал таким: заявка поступает к операционистке, которая вводит данные в экспертную систему, определяющую — предоставить компьютер в кредит; отказать на следующих основаниях (текст отказа прилагается); направить заявку на дальнейшее рассмотрение в следующие отделы (перечень отделов).
В итоге выполнения описанного бизнес-процесса в течение нескольких дней клиентам компании сообщали, будет или нет удовлетворена их просьба, или о том, что им придется подождать еще несколько дней. Сокращение сроков рассмотрения заявок привело к росту продаж, экономии затрат на экспертов, которые начали выполнять более квалифицированную работу.
В примере налицо кардинальное изменение описания бизнес-процесса и повышение эффективности в разы. Самое интересное, что почти все руководители много раз действовали аналогичным образом тогда, когда можно было четко сформулировать критерии принятия итогового решения (таких , например, как критерии предоставления скидок: если доставка осуществляется за пять дней, предоставляется трехпроцентная скидка, если же доставка занимает десять дней, предоставляется пятипроцентная скидка). Как только эти критерии сформулированы, принятие решения делегируется вниз, что приводит к экономии, улучшению описанных бизнес-процессов, повышению качества… Причем реализация изменений бизнес-процессов обычно проходит проще, чем в компании IBM, поскольку при этом не требуется экспертная система и сокращение специалистов, — но и не приводит к подобному повышению эффективности.
Подобная работа является одним из результатов оптимизации бизнес-процессов — кропотливой работы по постоянному улучшению деятельности компании.
Отличием оптимизации от реинжиниринга в данном случае является скорость получения результата, объем работ и суть изменений. Если не вдаваться в подробности, при оптимизации одно правило быстро доводится до исполнителя и корректируется «на ходу». Когда осуществляется реинжиниринг, долго и тщательно разрабатывается определенная система описаний бизнес-процессов, которая затем проверяется, а после реализуется, и часто при ее реализации разрабатываются и внедряются различные формы автоматизации.
В табл. 1 представлены различия между реинжинирингом и оптимизацией (усовершенствованием) бизнес-процессов, выделенные Томом Давенпортом , гуру в области описания бизнес-процессов.
Таблица 1. Различия между реинжинирингом и оптимизацией бизнес-процессов
Источник: piter-consult.ru
Процессная иерархия. Какой должна быть глубина декомпозиции?
При описании бизнес-процессов часто сталкиваешься с ситуацией, когда нужно определить, до какого уровня копать? Некоторые процессы интуитивно понятны и просты, а некоторые являются сложными комплексными. Как понять, где остановиться?
Один из примеров процессной иерархии приведен в BPM CBOK:
Уровень 1: Процесс
Уровень 2: Подпроцесс
Уровень 3: Бизнес-функция
Уровень 4: Поток работ
Уровень 5: Задачи и сценарии
Цель декомпозиции процессов и процессной иерархии — не только показать, что куда входит, но и иметь возможность создавать схемы и описание процессов, действий, работ по каждому блоку отдельно, не теряя целостность картины, понимая место конкретных действий.
Полная схема всех процессов в рамках одного дерева, скорее всего, будет нечитаемой. Гораздо удобнее сначала создать схему 1го — 2го уровней, а затем на отдельных схемах показать их декомпозицию на бизнес-функции, работы, действия.
Всегда ли нужны все пять уровней? Думаю, что не обязательно. Работа не должна быть ради работы, если уже на 3 уровне будет ясно и понятно, что делать, то на нем можно остановиться, отложив более глубокую проработку на будущее, и приступить к более приоритетным задачам.
Как понять, где остановиться в декомпозиции процессов?
Можно ответить на него так: описывать нужно до такого уровня детализации, когда каждому в процессе ясно:
- Что (конкретное действие),
- Кто (ответственный),
- Когда (в какой момент времени, когда начинать, сколько времени выполнять),
- Как (конкретный алгоритм, инструкция),
- Где (рабочее место, ПО),
- Чем (инструментарий)
- С чем (активы/пассивы, информация,…) делает.
Т.е. ключевой параметр – понятность и однозначность.
Например, есть процесс «Продажи».
В чем он заключается: Менеджер по продажам находит клиента, договаривается, заключает сделку, выполняет условия сделки, предоставляя объект сделки покупателю и получая от покупателя определенные в сделке активы.
Вроде бы, всё понятно, но чего-то не хватает.
Если мы торгуем на рынке в розницу «с колес» за наличный расчет (купил-продал) по фиксированным ценам, то, возможно, продавцу будет понятно: видишь человека, предлагай ему товар, бери деньги, отдавай товар. Всё.
Но, что делать, если условия чуть сложнее и выбор вариантов чуть больше? Например, продать можно за наличные или по безналу, в рассрочку или в кредит? Если покупатель просит скидку? Если на рынке есть ограничения? Если рынок высококонкурентный, а покупателей найти не просто? Если можно использовать различные методы привлечения клиента, какой выбрать?
И т.д.
В этом случае процесс необходимо детализировать до подпроцессов:
Например, описать отдельно поиск клиента (первый подпроцесс), заключение сделки (второй подпроцесс) и т.д.
А что, если какой-то из подпроцессов выполняется несколькими подразделениями, для каждого из которых также существует несколько вариантов действий?
В этом случае стоит описать функции каждого подразделения, его задачи, конкретные работы и действия.
Т.е. остановиться стоит тогда, когда исполнитель понимает: «делать только так» — простая понятная цепочка действий. В итоге не должно остаться развилок, алгоритм которых не описан. Если есть в процессах или функциях участок, где у исполнителя есть выбор, делать/не делать/делать так или иначе, эти ситуации должны быть описаны.
Источник: shikov-as.ru
Как определить границы бизнес-процесса: 3 совета для начинающих аналитиков
Описать бизнес-процесс невозможно без определения его границ. Поэтому сегодня рассмотрим, что такое границы бизнес-процесса, зачем их определять и как это сделать максимально просто и эффективно. Рекомендации начинающим аналитикам, на что обратить внимание при описании бизнес-процесса и разработке целостной системы иерархически связанных процессных блоков, чтобы комплексно описать всю деятельность предприятия.
Что границы бизнес-процесса и зачем они нужны
Границы бизнес-процесса отделяют его содержимое (функции, события, участники, данные и прочие объекты) от внешней среды. Например, входы бизнес-процесса поступают в него извне и находятся за его границами. Аналогично, выходы, которые являются результатом его выполнения, идут во внешнюю среду, выходя за границы самого бизнес-процесса.
Определяя границы бизнес-процесса как рамки, отделяющие его от других процессов, аналитик структурирует деятельность, представляя ее в виде связанных друг с другом блоков. Лучше всего эту идею демонстрирует структурный подход нотации IDEF0, рассматривая каждый бизнес-процесс как черный ящик, за границами которого находятся идущие к нему входы, механизмы, сигналы управления и исходящие выходы. В процессно-событийных нотациях, таких как UML activity, BPMN и EPC, содержимое бизнес-процесса находится между начальным событием, которое запускает его подобно триггеру, и конечным событием, выступающим в роли финишной точки.
Таким образом, независимо от нотации моделирования, определение границ очень важно, т.к. позволяет ограничить контекст описываемой деятельности. Также это позволяет избежать так называемого creep – распознания с попытками «объять необъятное» в одной схеме. К примеру, изменение данных в личном кабинете пользователя находится за границами процесса «Регистрация пользователя», несмотря на то, что в обоих процессах могут повторяться отдельные бизнес-функции, а также возможно участие одних и тех же субъектов, объектов и данных.
Источник: babok-school.ru