Комплексная регламентация бизнес процессов организации

В статье рассмотрен один из возможных подходов к структурированию процессов управления, выполняемых руководителями организации. Представлен пример системы процессов управления Транспортным отделом торговой компании, схемы процессов управления в Business Studio. К статье прилагается xml-файл с шаблоном отчета, позволяющим выгружать из Business Studio регламент процесса управления на 3-х уровнях (контур управления — процесс управления — операции процесса управления).

Введение

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

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

В данной статье рассмотрен один из возможных методических подходов к структурированию и описанию процессов управления, а так же пример описания процессов управления в среде Business Studio.

Структурирование процессов управления

Опробованным на практике и удобным способом структурирования процессов управления, выполняемых конкретным руководителем подразделения, является определение этих процессов в привязке к контурам управления. Можно выделить следующие контуры управления:

1. Годовой;
2. Квартальный;
3. Месячный;
4. Недельный;
5. Ежедневный.

Для руководителей верхнего уровня, отвечающих за принятие решений стратегического характера, дополнительно можно определить 3-летний или 5-летний контур управления.

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

Структурирование процессов внутри контура управления выполняется следующим образом:

1. Проводится интервью с руководителем, в рамках которого обсуждается его деятельность (например, выполняемая ежегодно в рамках годового планирования или отчетности);
2. Бизнес-аналитик формирует перечень процессов в рамках контура управления; определяется примерный состав участников и результат каждого процесса управления;
3. Руководитель согласует полученный перечень процессов управления в рамках контура; бизнес-аналитик вносит необходимые корректировки.

Далее бизнес-аналитик проводит дополнительные интервью с руководителем по сбору информации для детального описания процессов управления внутри каждого контура. В результате получается следующая 3-уровневая структура:

1. Контур управления:
   1. Процесс управления:
      1. Операция;
      2. Операция;
      3. …
   2. Процесс управления:
      1. Операция;
      2. Операция;
      3. …
   3. Процесс управления
      1. …

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

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

• Неукомплектованный штат организации (руководитель вынужден выполнять часть работы за отсутствующих сотрудников);
• Неумение руководителя делегировать полномочия и организовывать работу подчиненных;
• Желание руководителя путем личного «встраивания» в операционные процессы всё держать под контролем, быть «незаменимым» и т. п.

Пример. Руководитель некоторой компании проанализировал существующие подходы к структурированию управленческой деятельности и предложил использовать следующий перечень типовых действий по управлению:

1. Сбор и анализ информации для выработки решения:
   1. Определение состава собираемой информации;
   2. Определение форм отчетности.
2. Выработка решения:
   1. Анализ альтернатив;
   2. Подготовка вариантов решения;
   3. Принятие решения;
   4. Выработка критериев оценки достижения результата.
3. Реализация решения:
   1. Планирование;
   2. Организация исполнения плана;
   3. Мотивация персонала;
   4. Координация.
4. Учет результатов реализации решения:
   1. Учет результатов;
   2. Сравнение по принятым критериям.
5. Оценка и контроль результатов реализации решения;
6. Анализ и выявление существенных факторов, повлиявших на решение и результаты его реализации:
   1. Анализ дополнительной информации;
   2. Диагностика возможных причин отклонений.
7. Регулирование существенных факторов доступными инструментами:
   1. Регулирование на уровне реализации (возврат к п. 3);
   2. Регулирование на уровне выработки решения (возврат к п. 1, 2).

Данный перечень можно использовать для:

• Анализа полноты и качества выполнения конкретных процессов управления, осуществляемых руководителем;
• Разработке предложений по оптимизации процессов управления.

Описание процессов управления в среде Business Studio

На Рис. 1. показана структура процессов управления, разработанная в рамках проекта, участником которого являлся автор статьи.

Рассмотрен процесс управления Транспортным отделом торговой компании «Оптима»*, г. Ижевск. Описание процессов выполнено в среде моделирования Business Studio 3.5. На рисунке слева видно дерево процессов, в котором процессы управления структурированы по соответствующим контурам.

Для описания объекта модели «Управление ТО» и контуров управления использована нотация «Процесс». Это наиболее простая нотация в Business Studio, но в рамках рассматриваемой задачи ее использование вполне адекватно.

Для описания процессов управления внутри контуров управления использована нотация «Процедура» (более подробно об этой нотации можно прочитать в статье «ARIS eEPC или „Процедура“ Business Studio?»). На Рис. 1. показана кросс-функциональная схема процесса «Корректировка потребности в а/транспорте на месяц/квартал». В рамках данной модели все процессы управления были описаны в виде подобных схем.

Для каждого процесса управления и для каждой операции процессы были заполнены текстовые атрибуты:

1. Содержание деятельности;
2. Начало процесса;
3. Результат процесса.

Этих атрибутов вполне хватает для достаточно полного описания деятельности. При необходимости, можно использовать и другие атрибуты (в т. ч. создавать новые, необходимые бизнес-аналитику).

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

Рис. 1. Структура процессов управления Транспортным отделом

Формирование отчета для выгрузки информации из Business Studio

Для выгрузки описания процессов управления из Business Studio был разработан специальный отчет, который включает информацию о процессах на 3-х уровнях:

1. Описание контура управления;
2. Описание процесса в контуре управления;
3. Описание операций процесса (в табличной форме) и схему процесса.

На Рис. 2. показана работа мастера отчетов среды моделирования Business Studio. При помощи системы так называемых «привязок» была сформирована необходимая структура отчета. Далее был создан и отредактирован (под формат, принятый в компании) шаблон отчета — регламент процесса управления на 3-х уровнях. После этого готовый отчет был сохранен в папке пользовательских отчетов среды моделирования Business Studio и запущен на исполнение для объекта «Управление ТО» (см. Рис. 3).

Рис. 2. Мастер отчетов Business Studio. Разработка регламента управления на 3-х уровнях

Рис. 3. Запуск отчета для объекта «Управление ТО»

Регламент процесса управления для 3-х уровней

Отчет, запущенный для объекта модели «Управление ТО» сгенерировал документ в MS Word и вывел всю информацию о контурах и процессах управления в нужном формате. Автоматически было получено содержание документа (см. Рис. 4.).

Рис. 4. Содержание регламента процесса управления, полученное автоматически в результате запуска отчета в среде моделирования Business Studio

На Рис. 5. в качестве примера показан вывод информации о контуре управления в отчете. Показано текстовое описание контура и состав процессов управления, которые в него входят (в виде таблицы).

Заметим, что формат вывода описания контура управления можно сделать любым удобным для пользователя. В данном случае специально был выбран самый простой способ отображения информации, а детальное текстовое описание контура не делалось.

Рис. 5. Вывод информации о контуре управления в отчете

На Рис. 6. показан формат вывода информации для каждого процесса управления. Он включает в себя таблицу и графическую схему процесса, размещенную на листе А4.

Рис. 6. Вывод информации о процессе управления в табличной и графической форме

На Рис. 6 видно, что описание операций процесса выводится в виде таблицы, содержащей следующие столбцы:

1. Номер операции;
2. Наименование операции;
3. Исполнитель;
4. Инициирующие события;
5. Входящие документы;
6. Описание операции;
7. Завершающие события;
8. Исходящие документы.

Графическая схема процесса представлена в кросс-функциональном виде.

Объем регламента процесса управления в целом составил для процесса «Управления ТО» около 70 страниц в MS Word, что немного для такого значительного количества процессов.

Заключение

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

Вопрос целесообразности вывода всей информации о процессе управления в одном документе или формирования пакета инструкций по отдельным подпроцессам мы оставляем вне рамок данной статьи. Это технический аспект работы со средствами моделирования.

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

* Компания «Оптима» — это сеть современных удобных и доступных каждому магазинов в формате «дрогери», т. е. «магазин самообслуживания у дома». На сегодня «Оптима» — крупнейшая сеть магазинов непродовольственной группы в Удмуртии. Также компания представлена в Перми и Пермском крае, Республиках Башкортостан и Татарстан. В данный момент компания «Оптима» насчитывает более 60 магазинов и продолжает уверенно и динамично развиваться.

Шаблон отчета в формате XML для загрузки в систему Business Studio

Сентябрь 2010 г.

Рекомендуемые материалы по тематике

Глоссарий. Регламент процесса

Методика описания бизнес-процессов банка. Версия 2.0

Как сделать незаменимой систему управления бизнес-процессами в банке

Карточка бизнес-процесса — инструмент руководителя

Что такое бизнес-процесс? 

Существует много разных определений понятия «бизнес-процесс». Вот, некоторые из них:

Процесс – преобразование объекта труда, добавляющее его стоимость.  Э. Деминг

Процесс — это совокупность взаимосвязанных или взаимодействующих видов деятельности, которая преобразует входы в выходы. ИСО 9001

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

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

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

Функциональный и процессный подход

Процессный подход часто противопоставляется функциональному. В чем разница?

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

 

Рис. 1 Линейно-функциональная иерархическая структура.

 Такое структурирование организации помогает, когда нужно стратегические цели компании каскадировать вниз по иерархии на отделы.  Разрабатывать целевые показатели, планы, бюджеты также же проще по функциональным единицам.  А в чем недостаток такой структуры? Дело в том, что подразделения выполняют свои функции не в вакууме, они взаимодействуют между собой.  В компании есть такие процессы, где клиент взаимодействует, когда с двумя, а когда и с пятью подразделениями. Подразделения являются друг другу   внутренними клиентами, передают друг другу информацию и результаты каких-то выполненных действий (процедур). Вот на таких стыках между подразделениями чаще всего и возникают проблемы, в результате которых  терпит прямые или косвенные убытки организация.

Рис. 2. Красными линиями обозначены фактические взаимодействия сотрудников при выполнении бизнес-процесса.

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

 

 Рис. 3 Синие пунктирные линии – решение проблем через руководителя.

А что же процессный подход?

В процессном подходе взаимодействующие сотрудники – договариваются между собой. У процесса появляется свой горизонтальный «руководитель» (его ещё называют Владельцем процесса).

В результате применения процессного подхода, мы получаем:

— оптимизированные процессы

— сформулированные и согласованные всеми участниками процессов требования к качеству процессов и процедур.

— комплект нормативных документов, который:  определяет зоны ответственности сотрудников при выполнении работ,  содержит требования к результатам  и содержанию работ и своевременно адаптируется к меняющимся условиям деятельности.

Категории Бизнес-процессов

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

Основные процессы — сквозные, как правило кросс-функциональные процессы, непосредственно создающие ценность для потребителя. Например, в ресторане -процесс обслуживания клиента от входа в ресторан, до выхода из ресторана.

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

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

Описание бизнес-процессов

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

 При описании бизнес-процессов важно соблюсти следующие принципы:

1. Описанию подлежат те процессы, которые уже сложились(сформировались).

2. Описание процессов начинается с моделирования схем.

3. Моделировать процессы следует в соответствии с уровнями детализации.

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

• Операция — минимальная часть дейтяльеости. Выполняется «автоматически» (переключить скорость в автомобиле, скопировать в Word и т.п.)
• Действие — несколько последовательно выполняемых операций, требующие осознанного контроля (доехать из пункта А в пункт B, написать текст и т.п.)
• Процедура — несколько последовательно выполняемых действий. У процедуры всегда есть результат (устное сообщение
• Бизнес-процесс базового уровня — последовательность взаимосвязанных процедур, выполняемых несколькими исполнителями, приводящая к значимому для организации результату.
• Направление деятельности — укрупнённая часть деятельности компании, состоящая из нескольких групп бизнес-процессов базового уровня

Процессы описываются на уровне Процедур, бизнес-процессов базового уровня и направлений деятельности.

Текстовые описания самих процедур, рационально возложить на самих исполнителей процессов.  Здесь могут возникать определённые проблемы.  Для того, чтобы описанные процедуры в регламентах получились понятными, необходимо уметь писать инструкции. Навыком писать инструкции обладают далеко не все. Кроме того, сотрудники не всегда замотивированы на эту работу.  Часто руководителю необходимо проявить решительность, чтобы довести дело до конца, а консультанту проявлять дипломатичность,  умение доносить смысл этой работы и навыки убеждения. 

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

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

Зачем моделировать и регламентировать процессы? Всем ли это нужно?

 Всем ли подходит Процессный подход? Процессный подход полезен практически для любй компании с устоявшимися процессами. Но есть категория, для которых возврат на вложенные ресурсы будет максимальный.  Это такие компании с достаточно большим количеством управленческих воздействий. По опыту консультантов, регламентация деятельности приносит наибольшую пользу там, где количество постоянных управленческих воздействий превышает 1000.  Где Управленческие воздействия (УВ) = правила х исполнители. 

 

Рис. 4  Регламентация деятельности  и управление по отклонениям.

Другими словами, в таких компаниях достаточно много исполнителей, и у них достаточно много различных правил. 

Язык описания бизнес-процессов. Нотации.

Нотаций описывающих процессы много. Самые популярные нотации процессов:  eEPC, BPMN, Cross Functional Flowchart (Процедура), Flowchart, IDEF0,.

Что такое нотация ?

Нотация — это «графический язык» описания бизнес-процессов. Подобно тому, как программист может создать одну и ту же программу на разных языках, также одни и те, же процессы могут быть описаны в разных нотациях.

Как правило при описании процесса отражают, как минимум четыре сущности процесса:

• вход процедуры (процесса)
• исполнитель процедуры
• сама процедура (текстовое обозначение- отглагольное существительное)
• выход процедуры (результат процедуры/процесса)

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

 Каждая нотация имеет свои плюсы и минусы:

Диаграмма Cross-functional Flowchart  – не отображает исполнителей, EPC – наиболее подробная, но если процессы большие, то схема разрастётся до больших плохо читаемых размеров, BPMN – современная, наиболее развивающаяся нотация, но наиболее полезна, если в будущем вы планируете автоматизировать процессы.

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

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

Иногда целям проекта лучше соответствует не какая-то одна нотация, а комбинация нескольких. Например, самый верхний уровень модели процессов организации часто описывается в нотации IDEF0, а более детальные уровни бизнес-процессов в нотации BPMN или EPC.

Оптимизация процессов

Главный метод оптимизации – это решение задачи оптимизации в  малой группе, состоящей из участников процесса. Очень важно производить именно совместное командное обсуждение. Проектирование процесса в одиночку часто на практике приводит к ошибкам, слишком уж много практических рабочих нюансов необходимо предусмотреть.  Роль консультанта в этом процессе: фасилитатор, модератор и участник разработки.
Какие методы оптимизации бизнес-процессов существуют? Я выделяю две основные группы.

группа 1. Методы оптимизации «здравого смысла»:

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

  Примеры оптимизаций из первой группы : 
  При описании взаимодействия между отделом бронирования заказов и отделом продаж туристической компании было замечено, что 80% всех причин отказов в бронировании вызвано всего пятью причинами. Стандартизовав эти 5 причин, ИТ-специалисты сделали 5 кнопок во внутренней ERP-системе, что позволило значительно сократить объём переписки между отделами, ускорило и упорядочило информирование менеджеров продаж.

группа 2. Методы бережливого производства

Помимо «методик оптимизации здравого смысла» (убирать повторы, запараллеливать процессы, устранение явных неэффекивностей), для оптимизации бизнес-процессов, можно использовать Техники бережливого производства:

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

Метод согласования входов — выходов между на стыках процессов SIPOC.

Как я писал ранее, большинство бизнес-процессов в компаниях сквозные, т.е. проходят «сквозь» подразделения. Большинство проблем, естественным образом появляются на стыках подразделений просто потому, что в линейно-функциональной иерархии — у каждого подразделения свои цели, KPI и свой руководитель. 

Для решения проблем на таких стыках разработана методика SIPOC. SIPOC — акроним  от слов supplier, input, process, output, customer (поставщик, вход, процесс, выход, клиент).

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

 
Рис. 5 Методика согласования требований «клиент-поставщик» SIPOC.

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

Революционный и эволюционный метод изменения процессов.
Есть методика революционных изменений процессов, которая разывается «реинжиниринг». Практика показала, что невозможно качественно изменить процессы революционным путём, произведя «реинжиниринг». А вот эволюция, групповая работа над изменением процессов, самих исполнителей процессов работает очень даже хорошо. Никто не знает работу лучше, чем человек который её выполняет. Консультант в данном случае выступает модератором и соучастником этой работы, его задача вовлечь людей, мотивировать на эту работу, а также привносить на обсуждение свои идеи, наравне с другими участниками.

Автоматизация бизнес-процессов

Лучшая оптимизация процессов — это автоматизация. Но автоматизация требует инвестиций, и бывает не всегда экономически оправдана. Кроме того, далеко не все операции можно автоматизировать. Следует прорабатывать возможности автоматизации во время оптимизационных мозговых штурмов. Полезно сразу же приглашать на такие штурмы ИТ-специалистов.

Нотация BPMN — нотация специально разработанная для автоматизации процессов, поэтому, если вы описываете процессы с прицелом, на возможную будущую автоматизацию, то это ещё один аргумент в пользу именно этой нотации.

Категории процессов

Процессы принято делить на :

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

Конечно, начать работу с процессами лучше с основных процессов. Основной процесс – это то, ради чего организация создавалась. Это тот процесс, который формирует основную ценность для клиента.  Например, в ресторане, это процесс обслуживания клиента от входа в ресторан, до его ухода. Для интернет-магазина, процесс от момента заказа, до момента отгрузки и оплаты.

Мифы и заблуждения

Чем подробнее вы опишете бизнес-процесс, тем лучше.
Подробность написания инструкции – плохой критерий качества описания процесса. Письменный текст должен быть кратким, информативным, легко читаемый. Немногие обладают навыком понятно выражать свои мысли. Идеалом может быть инструкция IKEA, текста там мало, где возможно, используются иллюстрации. Пользоваться такими регламентами легко.

Если уж начали описывать процессы, то описать надо полностью все процессы компании. Без этого модель не будет полной.
Описать все процессы в компании очень трудоёмко, да это и не нужно. Начать лучше с основного бизнес-процесса, и наиболее проблемных процессов. Главное в работе надо процессами не описать всё до последнего, а внедрить практику работы над процессами в системный менеджмент компании. Лучше оптимизировать и регламентировать процессы постепенно, получая выгоды от раза к разу. Пусть небольшие, но быстрые победы на этом пути лучше мотивируют команду.
Существует понятие процессной зрелости компании, когда компания переходит от хаотичных процессов, сначала к описанным и контроллируемым процессов, а потом к интегрированным и проактивным. И этот путь требует инвестиций времени и усилий.

P.S.  Если вас интересует повышение конкурентноспособности вашей организации через повышение операционной эффективности и процессный подход — мы готовы вам в этом помочь. Имеем большой опыт проектов в разных отраслях от промышленных производств до интернет-платформ. Подробнее..

Больше полезных материалов в моем Instagram

Алгоритм разработки

Мне не раз приходилось писать регламенты «с нуля» и корректировать существующие. В конечном итоге, проанализировав накопившийся опыт, пришла к тому, что при написании любого регламента необходимо пройти 7 шагов.

ШАГ № 1: Найти проблему

ШАГ № 2: Определить «вход» и «выход» процесса

Наш процесс: Василий планирует…

Любое использование материалов медиапортала РШУ возможно только с разрешения

редакции.

Регламентация бизнес-процессов предполагает описание процессов взаимодействия разных сотрудников предприятия.

Важно отличать регламентацию бизнес-процессов от инструкции, которая касается в большинстве случаев только одного конкретного исполнителя.

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

Регламентация бизнес-процессов является необходимым этапом для того, чтобы затем провести цифровую трансформацию бизнеса с использованием BPMS или иных систем.

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

Цель регламентации бизнес-процессов

В большинстве случаев регламентация преследует следующие цели:

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

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

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

Поэтому регламентация бизнес-процессов совершенно необходима для любого бизнеса.

Как проводится регламентация бизнес-процессов

Чтобы регламентация бизнес-процессов была выполнена правильно, потребуется определить для каждого из процессов несколько параметров.

• Владелец процесса (лицо, которое им управляет).
• Входы и выходы процесса («вход» – событие, инициирующее бизнес-процесс, «выход» – событие, завершающее его).
• Участники бизнес-процесса.
• Используемые технологии и ресурсы.

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

Ещё важно сразу продумать:

• Систему контроля с использованием показателей.
• Систему внесения изменений и модернизации.

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

Современные системы BPM, позволяющие собирать обширную статистику, уже одним этим дают большое пространство для будущего роста и развития.

Типичные ошибки при регламентации бизнес-процессов

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

Также приходится сталкиваться с тем, что:

• Не выстроена система целей и задач.
• Бизнес-процессы разных уровней смешиваются друг с другом.
• Отсутствует полноценное понимание границ разных процессов.
• Нечётко определены входы и выходы.
• Регламентация проводится поспешно и бессистемно.
• Созданный регламент слишком субъективен и отражает точку зрения своего автора, но с ним могут не согласиться другие сотрудники.

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

После того, как регламентация бизнес-процессов выполнена, можно приступать к их формализации с помощью систем класса BPM или Low-code. Системы Low-code, например, платформа Comindware Business Application Platform, имеют столь же большое количество возможностей, как и BPMS, и смещают центр тяжести усилий по разработке бизнес-приложений и дальнейшей их адаптации к новым требованиям бизнеса с программистов на аналитиков. Цифровая трансформация с их помощью позволяет перейти на новые принципы работы более плавно и принести хорошие результаты – но только если регламентация была проведена грамотно и с учётом всех нюансов.

Елена Гайдукова, маркетолог-аналитик. Работает в сфере BPM и автоматизации процессов с 2014 года. В настоящее время является бренд-менеджером решений на базе Comindware Business Application Platform.

Для чего предприятия регламентируют свои бизнес-процессы? Приводит ли это к заметному росту эффективности?

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

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

1. Понятие регламентации

В данном разделе речь пойдет о регламентации в рамках внедрения процессного подхода.

Для соответствующего выполнения бизнес-процессов разрабатывают регламенты и инструкции.

Регламентация – это установление подробных правил, определяющих порядок деятельности государственного органа, учреждения, организации и др. (Большая советская энциклопедия. — М.: Советская энциклопедия. 1969—1978)

Введем общие понятия регламента и инструкции.

Регламенты описывают процессы взаимодействия исполнителей, инструкции – порядок действий отдельных исполнителей при реализации бизнес-процессов.

2. Цели регламентации

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

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

•    Стандартизации деятельности, обеспечения четкой повторяемости процессов и возможности управления ими;

•    Тиражирования опыта в другие организации (филиалы, новые предприятия);

•    Накопления знаний и передачи их новым сотрудникам (при обучении, приеме на работу)

•    Для проведения внутренних аудитов.

3. Проблемы регламентации

В российских компаниях вопрос регламентации решается часто формально. Сказывается отсутствие понимания целей и задач регламентации, адекватных методик и опыта, подготовленных специалистов.
Часто отсутствует предварительно построенная системы процессов (рис.1), четко фиксирующая на всех уровнях рассмотрения взаимодействия и взаимозависимости регламентируемого бизнес-процесса.

 

Рис.1 Области регламентации при наличии системы бизнес-процессов

Без предварительно построенной системы процессов традиционны следующие ошибки:

•    смешиваются процессы разных уровней;

•    неправильно определены границ процессов;

•    регламентация проводится бессистемно, под влиянием возникшей потребности. Регламентируются хаотично выхваченные куски цепочек работ (см. рис. 2);

•    управление процессами (деятельность по управлению) в регламентах либо не рассматривается совсем, либо о нем упоминается поверхностно;

•    о входах и выходах в регламентах либо не говорится, либо они перечислены не полностью;

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

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

4. Типовая структура регламента бизнеса-процесса

При регламентации бизнес-процесса в рамках внедрения процессного подхода обязательно следует учитывать основные элементы бизнес-процесса, то есть в регламенте должны быть  отражены следующие моменты:

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

•    входы процесса, в том числе требования к входам; события, инициирующие начало процесса;

•    выходы процесса, в том числе требования к выходам (результатам); события, завершающие процесс;

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

•    ресурсы, необходимые для выполнения процесса (персонал, инфраструктура, оборудование, информация, прочее).

Под регламентацией бизнес-процессов (процессов) верхних уровней понимается разработка, согласование, утверждение нормативно-методических  документов, частично или полностью устанавливающих:
      1. Порядок управления бизнес-процессом;
      2. Порядок выполнения бизнес-процесса (входы, технология, выходы);
      3. Требования к ресурсам, необходимым для его выполнения.

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

5. Особенности регламентации бизнес-процессов верхнего уровня

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

•    Ответственность и полномочия руководителей;

•    Технология управления бизнес-процессом (планирование, организация, контроль, мотивация, принятие решений по процессу);

•    Систему показателей, используемых для управления процессом и отчетности перед вышестоящим руководством.

Управление невозможно без системы показателей, по которой мы оцениваем процессы. Для управления процессами не обязательно детально описывать технологии их выполнения. Технология выполнения бизнес-процесса верхнего уровня показывается в виде крупных блоков деятельности. Основная задача в данном случае состоит в том, чтобы отобразить структуру подпроцессов и распределение ответственности за них между руководителями более низкого уровня.

Важно:

•    Создать систему процессов;

•    Закрепить ответственность руководителя за их выполнение;

<<Содержание регламента бизнес-процессов верхних уровней (шаблон)

6. Особенности регламентации бизнес-процессов операционного уровня

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

<<Содержание регламента бизнес-процессов операционного уровня (шаблон)