Удобная и доступная методика описания бизнес-процессов.

Система управления бизнес-процессами. Что это такое, как это работает, когда не работает и другие общие вопросы.
September 10, 2014
Показатели бизнес-процессов.
September 10, 2014
Показать все

Удобная и доступная методика описания бизнес-процессов.

Удобная и доступная методика описания бизнес-процессов.

В данной статье изложена методика, содержащая простой алгоритм описания бизнес-процессов. Он не соответствует ни одно официальной нотации, но позволяет выявить главное: суть и логику процесса, найти его слабые места, недостающие промежуточные входы-выходы, сбои в передаче информации и т.д. После чего, при необходимости, процесс можно «перевести» на язык любой нотации, описывающей рабочие потоки. Похожий подход излагает Михаил Рыбаков (http://www.mrybakov.ru/) в своей книге «Как навести порядок в своем бизнесе», которую всем рекомендую для прочтения, как минимум для наведения порядка в своем видении бизнеса.

Для начала нам надо задать общие параметры процесса, а именно:

  • Название. Правильно выбранное название четко задает наше понимание процесса. Удобно, когда название состоит из «отглагольного существительного» (то есть образованного от глагола) и некоторых уточнений, например, «Обслуживание клиента в ресторане».
  • Первый и последний шаги. Они сразу задают единое понимание границ процесса. Для СТО это может быть звонок или визит клиента (первый шаг) и возврат отремонтированного автомобиля клиенту (последний шаг). Но возможны и другие варианты. Например, окончание процесса после процедуры оплаты или сбора отзывов и мнения об обслуживании. В зависимости от того, как будут установлены границы, определяется и логика процесса и его название. Возможно, такое название как «Осуществление ремонта автомобиля от обращения клиента до оплаты» звучит чуть более тяжеловесно, зато четко. В будущем это сильно облегчит нам работу.

Определяя первый и последний шаги, мы определяем границы процесса, а так же инициирующие и завершающие события. В качестве события могут быть: информация на входе или выходе (обращение, письмо, отчет и т.д.), материальный ресурс на входе или выходе (автомобиль в зоне приемки), таймер (по пятницам в 15-00), условие (в зоне приемки автомобилей нет места, все подъемники заняты и т.д.).

  • Цели процесса. Опять же, отслеживайте точность формулировок. Помните, что цель, определяет то, что измеряется и контролируется (ну крайней мере, так обычно задумывается), а то что контролируется, то и в наибольшей степени исполняется. Т.е. если заложить цель «Получение максимальной прибыли при ремонте автомобиля» и затем ежедневно доходность ремонтных работ, то скорее всего с каждого отдельного ремонта будет извлечена максимально возможная доходность, только скорее всего количество обращений клиентов со временем начнем катастрофически снижаться. Другой пример: «Обеспечить максимальное удовлетворение клиента и его желание многократно пользоваться нашими услугами в будущем, максимальную текущую и долгосрочную прибыль СТО от обслуживания клиента» звучит уже более адекватно. Однако, при этом возникает вопрос приоритетов, так все таки обеспечивать долгосрочную или текущую прибыль? Уделять больше внимания удовлетворению клиентов или получению прибыли? Обозначить и расставить приоритеты должна помочь стратегия компании, ее культура, видение бизнеса собственниками и топ-менеджерами. Сомнительно, что можно придумать один подходящий для всех вариантов, намного важнее чтобы отдельные части: стратегия, видение, название процесса, сам процесс, его границы, показатели процесса друг другу соответствовали.
  • Менеджер (синонимы: владелец, хозяин, собственник) процесса. Это тот, кто отвечает за весь процесс в целом: от первого шага до последнего и за его конечные результаты. О том, что за зверь такой – владелец процесса, мы поговорим в отдельной статье, здесь же только отмечу, что владелец процесса не только несет ответственность, но и обладает всеми необходимыми ресурсами для управления процессом, в том числе и сквозным, т.е. проходящим через несколько подразделений организации. Если по какой-то причине выделение таких ресурсов и полномочий невозможно (речь о реальном выделении, а не формальном), то стоит или пересмотреть кандидатуру владельца процесса, или, как это не резковато звучит, отказаться от использования данной технологии управления и подобрать другую, которая бы более соответствовала культуре управления в данной компании.

Задаем общую логику процесса.

Теперь мы можем определить общую схему выполнения процесса. Ее удобно представлять как последовательность операций, которые обычно записывают в прямоугольниках и соединяют стрелками. На схеме процесс, как правило, вдет слева направо или сверху вниз, в зависимости от расположения листа бумаги.

Ключевой момент: процесс не зависит от организационной структуры и может проходить через несколько подразделений, пересекать их границы. Такие процессы называют сквозными.

В примере с СТО встречей клиента занимается администратор, оформлением ремонта — мастер, а непосредственно ремонтом — один или несколько ремонтных участков (цехов).

Клиента редко интересует, какие именно подразделения выполняют для него работу, как они взаимодействуют и т.д. Клиенту важно получить свой товар (услугу) надлежащего качества, в установленные сроки и с минимальными сопутствующими затратами. Процессный подход дает возможность управлять этими важными для клиента параметрами работы вашего бизнеса, способствуя его (ну и вашему) процветанию.

сто

На данном этапе описания придерживайтесь нескольких простых правил:

  1. Описывайте стандартный нормальный ход процесса. В ходе любого процесса возможны ветвления, исключения, нештатные ситуации и т.д. Но вы займетесь ими позже, после того как будет описан основной ход процесса. Допустим, ваша компания выполняет заказы клиентов, причем заказы различных типов. В этом случае назовите шаг «выполнение заказа клиента», а для разных типов вы опишете несколько различных подпроцессов.
  1. Не описывайте процесс сверхподробно, но и не ограничивайтесь слишком высоким уровнем абстракции. Если реальность вынуждает сделать процесс длинным, подумайте о том, чтобы разбить его на подпроцессы. Так проще и описывать его, и контролировать в дальнейшем.
  2. Придерживайтесь выбранного уровня детализации (точности описания) для всех процессов, на сколько это возможно. Иногда, появляется желание расписать какой-нибудь процесс сверхподробно, так как по нему много информации. Не стоит поддаваться. Не ломайте систему. Лучше напишите операционную инструкцию по выполнению того или иного шага процесса в рамках одного исполнителя (подразделения), и сделайте на нее ссылку в описании процесса.
  3. Определите для себя, как вы будете описывать процесс: «как есть» или «как надо». Для чего перед проектированием процессов определите для себя ответы на следующие вопросы, а затем постоянно ориентируйтесь на них по ходу описания,:
    • какие операции будут выполняться;
    • будут ли они выполняться и при каких условиях;
    • кто будет их выполнять;
    • когда и где это будет выполняться;
    • насколько точно они будут выполняться;
    • какая информация будет при этом выполняться.

Описываем процесс.

Возьмем чистый документ: лист бумаги побольше или новый документ в подходящей компьютерной программе (MS Visio, например).

Гордо напишем название процесса. В нашем случае: «Обслуживание клиента в СТО от записи клиента до оплаты работ».

Под ним равномерно распределите по горизонтали слова:

  • Поставщик
  • Вход
  • Шаг
  • Выход
  • Клиент

Получится примерно следующее:

2_2

Переходим к первому шагу процесса: «Запись клиента» Сейчас мы детально проанализируем первый шаг процесса.  Это «Встреча и размещение клиента».

  1. Записываем посередине, обводим прямоугольником, проставляем номер шага.

2_3

Рисуем компактно, место нам еще понадобиться. Причем, как показала практика, часто его нужно больше, чем планировалось первоначально.

Дальше необходимо определить (и записать) ответственного за данный шаг. Именно ответственного, а не фактического исполнителя, хотя часто – это может одно и тоже лицо. Предположим на нашем СТО есть два администратора и один старший администратор стола заказа. Ответственным лицом будет – старший администратор, хотя общаться с клиентом может и администратор, но отвечает за результат именно он. Записываем ответственного за шаг и исполнителей (если это один и тот же человек, то записываем один раз). Роли можно выделить шрифтом.

2_42. Теперь нам надо определить «выходы» данного шага. Выходом может быть информация, а также нечто материальное. Более подробно входы и выходы рассмотрены в конце статьи.

Далее будет определяем выходы данного шага. Т.е. не только процесс в целом имеет свои выходы, но и каждый отдельный шаг. Выходом может быть:

  • что-то материальное, может быть материальное изменившее свое состояние в ходе шага;
  • может быть информация: новый бумажный или электронный документ, документ изменивший свой статус, документ, в который внесли какие-нибудь изменения, и т.д.
  • в редких случаях это может человек, над которым произведено какое-либо действие: пострижены волосы, сделан маникюр, проведена операция и т.д.
  • Выходов может быть несколько, при этом они могут дополнять друг друга и быть связаны между собой, например, отремонтированный телефон, акт-выполненных работ и счет на оплату ремонта.

Старайтесь избегать абстрактных, не проверяемых и не фиксируемых выходов, особенно это касается информации. С ними неудобно работать, их трудно контролировать, а такие процессы плохо поддаются автоматизации. Т.е. какая-то устная информация, удовлетворённый клиент и т.д. – не совсем подходят в качестве выхода. Устное распоряжение – можно внести в журнал распоряжений, и тогда выходом шага процесса будет – запись в журнале. С удовлетворённого клиента можно взять анкету-отзыв или просто подпись об отсутствии претензий, тогда выходами соответственно будут анкета и документ с подписью клиента.

Каждый шаг выполняется ради своих выходов. То есть, если нет выходов, шаг не имеет смысла и, скорее всего, не нужен. Поэтому выходы надо определить максимально точно.

Что будет выходом нашего шага? Предположим на нашем СТО действует электронная система учета записей клиентов. Тогда соответственно и выходом будет новая запись в журнале. То есть информация о клиенте, его автомобиле, предварительной неисправности, времени передачи автомобиля в ремонт и т.д.

2_53. Процессы имеют своих клиентов, но и выходы каждого шага предназначены кому-то конкретному. Хотя возможны и такие ситуации, когда клиентами, т.е. получателями выходов, будут, в том числе, и их отправители, если выход будет использован на следующем шаге процесса, а ответственным за него является тот же ответственный, что и за предыдущий шаг. Кроме того клиентами может быть широкая группа людей, например, клиенты компании (для информационной рассылки о новой услуге) или весь персонала компании (для приказа директора об изменении трудового распорядка).

Кто же будет получателем информации о заказе в нашем случае? Во-первых, конечно, начальник участка ремонта автомобилей, во-вторых, возможно, охранник на въезде, чтобы пропустить автомобиль. Можно еще предположить, что получателями могут быть начальник отдела запчастей, чтобы сделать предварительную проверку наличия запчасти, или получатель будет еще и сам клиент, например, ему придёт СМС-подтверждение. Но мы не будем уходить в такую степень детализации и фантазии, чтобы не усложнять пример. Но в реальных бизнес-процессах, такие «плюшки» могут значительно ускорить и сам процесс и удовлетворенность клиента.


2_6

В данном случае старший начальник участка ремонта и охранник являются внутренними клиентами (потребителями) данного шага 1. То есть теми, кому нужен выход данного шага, кто предъявляет к нему требования. Задача исполнителя данного шага — удовлетворить своего клиента: внутреннего или внешнего. Дать то, что ему нужно, и в той форме, в которой это ему нужно. Исполнитель шага является поставщиком для своих клиентов.

Внешний клиент — это клиент компании. Внутренний клиент — тот сотрудник вашей компании, который использует результаты данного шага.

По поводу требований в выходу шага. В данной статье мы не станем подробно обсуждать эту тему, но вообще при описании процессов регламентируется не только ход процесса, но и форматы и стандарты входов и выходов. Это делается для того, чтобы выход был не просто на усмотрение его исполнителями, а был именно тем, что необходимо клиенту. Т.е. если это отчет для бухгалтерии, то это не отчет вообще, а отчет по определённой форме, содержащий определенную информацию, отправленный установленным порядком к назначенному времени.

4.Для того чтобы полноценно выполнить любой шаг, его исполнителям тоже необходимо на что-то получить. Это что-то можно получать из предыдущего шага, из внешних источников (информацию от клиента, сырье от поставщика) или из неких баз данных компании (различные базы нормативных и методологических документов, базы данных работников компании, учетные системы, журналы заказов клиентов и т.д.), то есть коллекторов различной информации предприятия, к которым могут обращаться работники по мере необходимости. Вообще-то в некоторых нотациях описания бизнес-процессов такие базы данных не всегда являются отдельными входами, но в нашем примере это будет именно входы. Тут, как и в некоторых других случаев, более принципиальным является не то, чем мы считаем базу данных: отдельным входом или нормативным документом для выполнения процесса, — а последовательность применение этого принципа для всех процессов.

Теперь посмотрим, а что нужно администратору стола заказов СТО, чтобы создать новую запись в журнале ремонтов? Например:

  • информация и пожелания клиента;
  • стандарты СТО по работе с клиентами;
  • информация об имеющихся заказах и текущих ремонтах.

Это — входы данного шага. Нарисуем их слева от шага 1:

2_7


Обратите внимание, на внешний вид «Журнала ремонтов». Напомню, что у нас журнал электронный. Мы договорились, что это будет отдельный вход, но я выделил внешне, как базу данных. Стандарты работы СТО, тоже могут быть частью базы данных нормативно-методологической информации компании, но мы предположили, что это просто отдельный документ. Что касается информации от клиента, при описании требований к входу процесса (шага) можно (и нужно) уточнить, как именно эта информация предоставляется: форма на сайте, бумажный бланк, форма, заполняемая в электронном журнале администратором стола заказов со слов клиента. И опять повторюсь – все эти особенности и принципы должны одинаково применяться ко всем процессам и быть понятны всем, кто работает с регламентами.

5. Далее необходимо определиться, кто предоставляет нам входы для выполнения шага. А от кого официант может получить всю эту информацию? Смотря какую.

  • Пожелания клиента — от самого клиента.
  • Стандарты по работе с клиентами — от директора СТО.
  • Информацию о текущих и запланированных ремонтах из журнала ремонта (а ведь для расчета времени записи еще необходима информация о имеющихся производственных силах и мощностях, но предположим, что она тоже есть в нашем журнале) — от начальника ремонтного участка. Обратите внимание, что работать с журналом ремонтов могут самые разные работники и подразделения СТО, но ответственным за ведение журнала у нас является именно начальник ремонтного участка.

2_8

Последовательность, в которой мы анализировали шаг процесса.

  1. Шаг: название, ответственный, исполнители.
  2. Выход(ы) шага.
  3. Клиент(ы), которому нужны эти выходы и который предъявляет к ним свои требования (отдельно по каждому выходу).
  4. Вход(ы) этого шага.
  5. Поставщик(и) по каждому входу. К ним ответственный за данный шаг предъявляет свои требования.

 

После того как мы полностью описали один шаг, переходим к следующему. В процессе такого глубокого анализа исходный состав и последовательность шагов могут измениться.  Какие-то шаги могут быть поменяны местами, какие-то поглощены, какие-то добавлены. Но и обойтись без начальной последовательности, как правило, не получается.

Далее переходим к следующему шагу:

2_9

После того, как все шаги описаны, можно закладывать в логику процесса ветвления и исключения. Для их описания использовать различные логические операторы.

Операторы логики бывают трех типов: логическое «И», логическое «исключающее ИЛИ», логическое «неисключающее ИЛИ».

2_10

«How Is» или «To Be»?

При описании структуры бизнес-процессов и разработке регламентов возможны три варианта относительно изменения бизнес-процессов:

  • оставить процессы «как есть» и вносить улучшения в процессе непрерывного улучшения бизнес-процессов
  • внести относительно небольшие изменения для повышения эффективности и упрощения автоматизации процессов
  • провести кардинальный реинжиниринг процессов.

Об плюсах и минусах этих вариантов смотрите в статье о том, что такое СУБП. 

Оформление результатов описания процесса.

Можно выделить шесть основных объектов, используемых для описания процессов:

  1. События.
  2. Операторы логики (по-другому их называют: блоки решения, ветвления/развилки, шлюзы/гейтвеи).
  3. Операции процесса.
  4. Стрелки типа «Связь предшествования».
  5. Стрелки типа «Поток объектов».

2_11

6. Объекты входов/выходов: базы данных, документы, материальные объекты и т.д. Символы для их обозначения зафиксированы в нотациях, но вы можете выбрать и те символы, которые вам больше нравятся, например, в библиотеке символов MS Visio:

1

 

Вот, что может получится:

Нотация «Процедура» среды моделирования Business Studio:

2_12

Или в нотации ARIS (почти):

2_13

В нотации IDEF3:

2_14

Описание нотаций: BPMN 2.0 (или кратко BPMN 2.0 (постер)), IDEF0IDEF3 (EN). Информацию о нотациях вы без труда найдете в интернете, я не ставлю своей целью «конипаст» из стандартов.

Вы можете выбрать для себя вариант сами: строго придерживаться какой-либо официальной нотации, тогда ее надо будет изучить и придерживаться ее для описания процессов. Либо вы можете взять какую-либо нотацию за основу, определить правила описания процессов в вашей компании, утвердить их и довести до сотрудников. В этом месте на меня сторонники официальных документов и международно принятых нотаций могут наброситься с каменюками, и, возможно, с некоторой точки зрения будут правы. Но лично я придерживаюсь мнения, что нотация — это вторично, а логика и качество описания процесса — первично. В конце концов, все учили в школе русский язык (а если точнее правила русского языка), даже сдавали экзамены, но много ли людей, которые на самом деле умеют этим языком пользоваться, да еще и так, чтобы этим умением прямо или косвенно приносить прибыль и себе, работодателю? Аналогия немного спорная, но тем не менее. Если у вас есть процесс великолепно описанный в нотации IDEF3, с соблюдением всех требований нотации, но при этом в самой логике процесса заложены ошибки, некорректно определены границы процесса и т.д. Будет ли польза от такого описания?

Поэтому решайте сами, но мне кажется, что в первую очередь правила описания должны быть просты и удобны для тех, кто читает и описывает процессы. Определите эти правила, графические элементы для описания (пример смотрите выше) и начинайте работать над описанием процессам в графической форме.

Все люди разные, и для некоторых графическая форма описания процесса — неудобна. Не страшно добавить в регламент табличную форму описания, и краткое текстовое описание.

Что еще может и должно быть указанно в регламенте процесса:

  • описание целей процесса;
  • показатели процесса (смотрите отдельную статью по этому вопросу);
  • порядок управления процессом и внесения изменения в регламент;
  • матрицу ответственности (разбейте процесс на основные этапы, и назначьте роли для участников процесса для каждого этапа):
Наименование работы (этап процесса) Участник 1 Участник 2 Участник 3 Участник 4
Этап 1 И  И, О, КР П УЧ
 Этап 2 И И, О И С
 Этап 3 С И, О К УЧ
 Этап 4 И,О ИН К
  • П- Планирует, собирает информацию, готовит решение.
  • С- Согласовывает решение(визирует документ).
  • Р- Принимает решение (утверждает документ).
  • О- Отвечает за организацию и результат.
  • И- Исполняет.
  • УЧ — Участвует в исполнении.
  • КР- Контролирует.
  • ИН- Получает информацию о ходе и результатах процесса.
  • К- Консультирует (предоставляет информацию).

Примечание: на практике количество ролей лучше сократить до 4-5.

— термины и определения, используемые в регламенте;

  • — перечень внутренних и внешних нормативных и методических документов, которые используется при выполнении процесса, при необходимости, они могут быть включены в регламент процесса в качестве приложений.

Для работы можете использовать такой шаблон регламента (Положение о СУБП и Шаблон БП), а также обязательно введите в действие приказом по предприятию Положении о СУБП (процессном подходе). Данное Положение — не готовый документ, это только основа. В свою редакцию внесите свои соглашения о моделировании, особенности своего подхода к СУБП, структурные и управленческие особенности своей компании.

Входы и выходы бизнес-процессов. Несколько рабочих «фишек».

Иногда входов и выходов становится слишком много, это затрудняет «чтение» процесса. Использование различных баз данных и журналов помогает систематизировать работу с данными. Например, база данных персонала, которая содержит всю необходимую информацию о работниках (не только персональные учетные данные, но и данные об обучении, отзывах от коллег, нарушениях, поощрениях, освоенных специальностях, возможных вертикальных и горизонтальных перемещениях и т.д.) может использоваться как общая база данных для многих кадровых процессов. Так выходом процесса обучения будет информация, вносимая в эту базу, о результатах обучения и освоенной специальности. После проведения аттестации также можно внести соответствующую информацию в эту же базу. Тогда выходом определенных операций будет, например, заполненная строка (форма) в базе данных, а выходом всего процесса – изменённая база данных. Примерно такая же ситуация с циклом выполнения какого либо заказа клиента. Так строка о заявке на доставку будет содержать различные поля: адрес, желаемые плановые сроки, реальные плановые сроки, объем доставки, отметка о переносе доставки, отметка о выполнении доставки, реальное время выполнения и т.д. Причем соответствующие поля заполняют различные ответственные лица.  Тогда основу процесса будет составлять работа с этой записью в журнале заказов на доставку: создание записи, ее заполнение, изменение, закрытие. По итогу же выполнения заказа вы будете иметь полную его историю, которую можно использовать для заказа. Входом  процесса будет первоначальная информация для заявки от клиента, а выходом – отчет о выполнении заказа, составленный (или полностью состоящий) из соответствующей строки в журнале заказов.

В регламенте процесса обязательно прописывайте стандарты и требования к входам и выходам (и не забывайте, что они должны быть согласованы с поставщиками и клиентами процессов):

  • Формат передачи данных: размер файлов, тип и структура данных, линии передачи информации (основные и дублирующие) и т.д. ;
  • Упаковка и маркировка для материальных объектов;
  • Время, сроки, каналы материальных объектов;
  • Требования к размерам и состоянию материальных объектов;
  • Дополнительные требования получателя;
  • Система уведомления о нарушении соответствия входов и выходов стандартам.

© Сагалович Александр.

Минск. Сентябрь 2014.

Добавить комментарий