Уровни бизнес процессов: Стандартизация бизнес-процессов: уровни развития системы – Что такое бизнес-процесс и описание бизнес процесса / Trinion corporate blog / Habr

Структура модели бизнес-процессов [BS Docs 4]

Модель бизнес-процессов, согласно методологии SADT, создается на основе принципа декомпозиции: «…декомпозиция заключается в начальном разделении объекта на более мелкие части и последующем соединении их в более детальное описание объекта». На верхнем уровне модели рассматриваемая система представляется в виде одного процесса, например, «Деятельность по производству и продаже оборудования», далее он декомпозируется на совокупность бизнес-процессов верхнего уровня (см. Основные элементы системы управления). Каждый из бизнес-процессов верхнего уровня декомпозируется на ряд подпроцессов. В качестве критерия выделения подпроцессов второго уровня можно использовать промежуточные состояния объекта управления. Например, процесс «Продвижение и продажи» может быть декомпозирован на подпроцессы:

1. Продвижение продуктов

2. Выяснение потребности клиента

3. Заключение договора с потребителем

4. Прием текущих заказов

5. Производственное планирование

6. Организация выполнения заказа клиента

7. Организация удовлетворения претензий клиентов

8. Анализ удовлетворенности клиентов

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

Business Studio позволяет создавать графические модели бизнес-процессов с помощью диаграмм, выполненных в той или иной нотации моделирования. Поддерживается пять типов нотаций графического моделирования — IDEF0, Процесс и Процедура, BPMN, EPC. Для создания модели бизнес-процессов можно использовать любую из этих нотаций или их комбинации. Рекомендуется в зависимости от уровня процесса в модели для его описания использовать нотации, приведенные в Таблице 1.

Уровень модели	Используемая нотация	Комментарий
0	IDEF0 (контекстная диаграмма)	Модель, выполненная в нотации IDEF0, имеет контекстную диаграмму верхнего уровня А-0, на которой объект моделирования представлен единственным блоком с граничными стрелками. Стрелки на этой диаграмме отображают связи объекта моделирования с окружающей средой. Диаграмма A-0 устанавливает область моделирования и ее границу.
1	IDEF0	1 уровень содержит процессы верхнего уровня модели.
2	IDEF0	2 уровень содержит декомпозицию процессов верхнего уровня. Например, процесс второго уровня «Продвижение продуктов» может быть декомпозирован на подпроцессы 3 уровня: 1. Группировка клиентов и анализ клиентской базы 2. Разработка программы удержания клиентов 3. Определение потребности по привлечению новых клиентов 4. Разработка комплекса продвижения продуктов на целевые рынки 5. Проведение мероприятий комплекса продвижения
3 и далее	Процесс, Процедура, BPMN, EPC	На 3 уровне происходит смена нотации моделирования. 3 уровень при корректной декомпозиции будет представлять собой работы — наименьшие возможные процессы, создающие минимальный отделимый результат, за отдельные действия внутри работы будут отвечать конкретные должностные лица.

Таблица 1. Уровни модели нотации IDEF0

Если в модели используются метапроцессы, то уровни сдвигаются, начиная с 1.

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

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

Элементарные правила описания процессов

Правила описания процессов, которые я здесь привожу, в первую очередь, предназначены для тех, кто не использует специализированное программное обеспечение. Если для описания процессов вы пользуетесь стандартными офисными программами наподобие MS Office и MS Visio, то эта статья будет вам очень полезна.

1. Карта процессов верхнего уровня отражает не более 22 – 25 процессов, включающих в себя основные процессы, вспомогательные и процессы управления.
2. На карте верхнего уровня необходимо отображать взаимосвязи процессов. Взаимосвязь – это то, что производит один процесс и использует другой. Производитель – клиент. Таким образом, вы связываете основные процессы в цепочку добавленной ценности.

3. Вспомогательные процессы, как правило, поставляют свои продукты во все остальные бизнес процессы. Например, процесс «Управление персоналом» поставляет свой продукт “персонал” во все остальные процессы. В таком случае укажите на карте факт выхода процесса, но не связывайте его с другими процессами.

4. Помимо прочего на карте процессов верхнего уровня должны быть отображены:

• Продукты
• Категории клиентов
• Требования к продуктам

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

Подробнее о подготовке карты процессов верхнего уровня:

6. Если вы не используете ПО для моделирования бизнес процессов и намереваетесь в дальнейшем использовать распечатанные описания процессов, настоятельно рекомендую нумеровать / кодировать процессы. Это поможет не только в соединении уровней описания, но и облегчит поиск связей в документах.

Пример кодировки процессов

В нашей компании мы используем следующие принципы определения кода процесса:

• Карта процессов верхнего уровня всегда имеет код А1.
• Каждый бизнес процесс на карте верхнего уровня имеет свой номер и буквенное обозначение:
• Основные процессы обозначаются буквой B (Business)
• Вспомогательные процессы имеют букву C (Costs)
• Процессы управления начинаются с буквы D(Driver)
• После буквы идет порядковый номер процесса
• Нумерация процессов сквозная, то есть не зависит от буквы процесса, нумерация идет по порядку. Так что набор процессов может быть таким: B2, B3, B4, C5, C6, D7 и т.д.
• Подпроцессы следующего уровня используют многоуровневую нумерацию. Например, подпроцессы процесса B2 будут начинаться с B2.2, B2.3 и т.д.
• После кода процесса всегда следует его название. Например, B2 Производство. А его подпроцесс «Настройка оборудования» будет иметь код B2.2

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

8. Деление процессов на уровни называется декомпозицией. Чем больше процесс декомпозирован, тем детальнее он описан.

9. Жестких правил по декомпозиции процессов по уровням нет. Тем не менее мы в своей работе выделяем 3 уровня описания бизнес процессов.

Уровни описания процессов

10. Разные уровни описания процесса размещаются на разных схемах. 1 схема = 1 лист описания. См. Правила моделирования бизнес- процессов

11. Правила описания процессов говорят о том, что разные процессы могут иметь разное количество уровней описания.

12. Если нас интересует содержание подпроцесса, а не его взаимодействия с другими, то это описание представляет из себя одну схему уровня.

13. Тем не менее связи схемы на листе должны быть понятны. Должны быть обязательные пометки о том, к какому процессу и уровню относится данная схема. Частично эта проблема решается с помощью нумерации и кодификации, однако можно сделать еще удобнее. Для этого можно использовать отображение «пути» декомпозиции. Как это делается на интернет страницах.

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

15. Наименование страницы со схемой должно соответствовать системе кодирования и названия процессов.

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

17. Если есть возможность делать активные ссылки внутри документов, чтобы при нажатии на нее происходил переход на указанное место, то это желательно сделать. Это экономит время и удобно.

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

19. В общем мы рекомендуем следующую структуру документов по описанию процессов:

Структура документации

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

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

22. Обязательно ведите историю изменений документа. История должна быть неотъемлемой частью документа.

23. Скрупулезно проверяйте изменения и названия в документе. Не должно быть такого, что в одном месте название объекта изменили, а в другом нет.

Таковы базовые правила описания процессов.

Управление автоматизацией на разных уровнях развития процессов

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

Очень часто к нам обращаются компании, которые думают с помощью автоматизации махом решить все свои проблемы. К сожалению для них, автоматизация представляет собой своеобразное возведение в квадрат: если в бизнесе был порядок, его станет еще больше; если царил хаос, — последствия будут чудовищны: необученные использованию процесса сотрудники, столкнувшись с ИТ-решением, не смогут корректно его использовать, а потому оно превратится в «самокат», который едет только пока ты его толкаешь. 

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

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

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

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

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

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

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

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

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

Уровень 4. Определяемый. Регламент бизнес-процесса выведен и единообразно выполняется в рамках всей компании. Бизнес-процесс построен и контролируется по всей длине цепочки на основе какой-то конкретной и всеми разделяемой в компании методологии (например, BPM). Проекты выполняются качественно и без потерь времени. Бизнес-процессы начинают походить на конвейер — минимизируется корректирующее вмешательство со стороны собственника.

Уровень 5. Измеряемый. Дальнейшим рычагом совершенствования процесса становятся выставленные KPI. Теперь каждая операция на постоянной основе проходит мониторинг и оценку. Отсутствуют затраты дополнительного времени и ресурсов на исполнение. Фактически отсутствует риск срыва бизнес-процесса. Обратите внимание, какой долгий и тернистый путь проделывает процесс для того, чтобы стать проверяемым на уровне конкретных цифр! А теперь сравните с тем путем, который в компаниях зачастую проходит внедрение системы KPI для сотрудников. Как видно из описания выше, прежде чем переходить к полноценной системе оплат по KPI (не путать со сдельной оплатой за выполнение определенных показателей, здесь под KPI мы имеем в виду именно каскадированные вниз параметры стратегии), необходимо преодолеть задачи постановки повторяемого в масштабах всей компании процесса.

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

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

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

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

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

Понятие бизнес-процесса [BS Docs 4]

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

Бизнес-процесс — последовательность действий (подпроцессов), направленная на получение заданного результата, ценного для организации.

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

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

Ключевыми понятиями процессного подхода являются:

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

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

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

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

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

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

Антон Тимохин

Руководитель проектов дирекции по развитию НПО «ЭЛСИБ»

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

Начало начал

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

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

• Выполнение ненужных (не добавляющих ценность) работ, большая вариабельность циклов работ;
• Отсутствие стандартизации и унификации бизнес-процессов, произвольная структура бизнес-процессов, отсутствие документации, регламентирующей их выполнение;
• Неэффективная архитектура информационных потоков (сбор, анализ, хранение данных), недостаточный уровень автоматизации;
• Избыточное число подразделений и департаментов, дублирование функций, неэффективное взаимодействие между ними;
• Размытие зон ответственности, отсутствие ответственного за бизнес-процесс и его результат в целом;
• Концентрация всех полномочий на высшем уровне иерархии, отсутствие практики делегирования полномочий;
• Излишние трудозатраты на контрольно-отчетную деятельность, существенные потери времени на согласованиях;
• Мистема оценки труда не мотивирует сотрудников к снижению затрат и повышению качества, мотивационные показатели подконтрольны мотивируемому.

Список можно продолжить.

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

• Слепая вера топ-менеджмента компании в то, что внедрение новой программной системы (ERP, CRM, MRP и др.), которая (по заверению ее разработчиков) после внедрения и использования лучших практик, заложенных в референтных моделях, совершит чудо и бизнес сам начнет изменяться в положительную сторону…;
• Сложившийся факт, что описание бизнес-процессов многими рассматривается как универсальный инструмент решения проблем. Но на практике это далеко не так — описание может помочь в устранении проблемных зон, но не само по себе, а в рамках комплексного подхода, одним из компонентов которого может быть как раз формализация бизнес-процессов компании;
• Отсутствие бизнес-задачи. Компания работает, приносит некоторую прибыль. Да, при этом есть некоторые сложности в коммуникациях, но не более чем «рабочие моменты». Зачем менять сложившуюся практику выполнения работ, тем более, что описание бизнес-процессов потребует инвестиций в программное обеспечение, обучение специалистов, отвлечение сотрудников от рабочего процесса? Снижение эффективности компании и увеличение издержек неизбежно, если в цели проекта не входит увеличение бизнес-показателей.

Несколько слов об оптимизации

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

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

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

Про инструменты и методологии

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

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

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

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

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

Что можно получить в итоге

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

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

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

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

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

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

Лучшие практики

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

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

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

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

Этап первый — инициация проекта

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

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

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

Этап второй — бизнес-задача

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

Диагностика может проводиться классическим способом (интервьюирование, стратегическая сессия, анализ показателей эффективности) или с применением онлайн-системы BIZDIAGNOSTICS. Система BIZDIAGNOSTICS — управленческий инструмент, который позволяет быстро и с минимальными ресурсными затратами провести внутренний аудит компании и получить достоверную и объективную информацию о качестве системы управления компании, идентифицировать проблемные зоны и получить рекомендации по их устранению. Результаты организационной диагностики являются основой для формулирования бизнес-задачи на проект.

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

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

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

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

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

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

Этап третий — программное обеспечение

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

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

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

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

После анализа рынка систем бизнес-моделирования было принято решение об использовании в нашем проекте системы Business Studio, наиболее полно соответствующей установленным критериям.

Этап четвертый — методология

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

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

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

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

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

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

Этап пятый — бизнес-модель, рабочие группы

Дальнейшая схема выполнения проекта подробно представлена на рисунке 1.

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

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

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

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

В рамках проекта владельцы бизнес-процессов отвечают за обеспечение выполнения работ по:

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

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

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

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

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

Этап шестой — моделирование, оптимизация

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

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

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

Чтобы исключить дублирование информации в справочниках системы, на данном этапе в группах по описанию и оптимизации бизнес-процессов назначаются ответственные. Они осуществляют ввод данных в справочники на основании запросов участников группы.
Также в целях повышения эффективности работы групп, структурирования информации в базе данных системы, минимизации временных затрат на поиск информации в системе при вводе данных в справочники группы «Объекты деятельности» рекомендуется создавать структуру каталогов (например так, как это описано в статье «Организация работы с документами на платформе Business Studio»).

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

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

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

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

Этап седьмой — внедрение

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

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

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

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

Вместо заключения

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

Опубликовано по материалам:
Журнал E-xecutive.ru

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

Расчет себестоимости бизнес-процессов на примере проекта «Национального расчетного депозитария»

Глоссарий. Организационная структура управления

«Business Studio + DIRECTUM» — новая формула эффективного управления бизнес-процессами

Презентация доклада «Проектирование системы управления предприятием» c форума «Промышленный салон-2005»

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

Елена Савосина

Руководитель портфеля проектов ПАО «АК БАРС» БАНК

Доклад Елены Савосиной на первой отраслевой кейс-конференции «Бизнес-процессы банка: оптимизация и инновации», прошедшей 16 февраля 2018.

Ключевые тезисы выступления:

Внедряемые в Банке технологии (Agile, Scrum, Lean) призваны обеспечить возможность быстрых изменений внутренней среды. Какое место при этом уделяется изменениям внутренней нормативной базы? Как создать такую структуру НРД, которая способна поддерживать гибкую «перестройку» бизнес-системы банка?

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

Именно поэтому в настоящее время все больше внимания уделяется новым технологиям управления, позволяющим обеспечивать необходимые скорости изменения продуктов, технологий и компаний в целом. Многие организации сейчас занимаются внедрением и развитием технологий управления, получивших название «гибких» — таких как Agile, Scrum, Kanban, Lean.

Меняется и само восприятие компании. Модели, где организация воспринимается как единый механизм, где каждый сотрудник служит винтиком большой системы, постепенно уступают место восприятию организации как семьи с едиными ценностями и даже как живого организма, где каждый сотрудник — значимый элемент. Именно такие организации назвал «бирюзовыми» Федерик Лалу в своей книге «Открывая организации будущего». Эффективность и конкурентоспособность такой модели доказали уже многие компании с мировыми именами. Их основой является самоорганизация, при которой для осуществления каких-либо изменений нет необходимости проходить десятки инстанций и согласований, а нужно просто начать по-новому вести свою деятельность.

Результаты опроса были ожидаемыми

Организационную платформу для реализации «бирюзовой» идеологии как раз и дает внедрение гибких технологий, предполагающих командную работу, самоорганизацию и т. п. И здесь возникает вопрос: как все это будет выглядеть на практике?

Представим ситуацию. В какой-то понедельник руководство вашей организации объявляет: «С сегодняшнего дня мы — „бирюзовая“ организация и будем жить по-новому!» И как теперь будет выглядеть ваш понедельник? А другие дни недели? Скорее всего, они будут такими же, какими были и до этого, так как от одних слов вряд ли что-то изменится в вашей работе.

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

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

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

Недавно проведенный нами опрос содержал всего два вопроса: «Что Вы делаете, когда у вас возникают трудности в понимании процесса?» и «Как можно улучшить регламенты процессов?».

Результаты опроса были ожидаемыми. Большинство сотрудников банка (44%) при возникновении трудностей обращаются к коллегам или руководителю, а значит, отвлекают их от их работы. Лишь 29% сотрудников обращаются к регламентам процессов. При ответе на вопрос, как улучшить регламенты, мнения разошлись, но в целом можно сделать вывод, что имеющаяся версия документов требует изменений. Наглядно результаты опроса приведены на рис. 1.

Рис. 1. Результаты опроса сотрудников

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

Создание иерархии процессов

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

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

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

Рис. 2. Иерархия бизнес-процессов

Моделирование процессов производим в системе Business Studio, поэтому практический пример рассмотрим на ее основе (рис. 3).

Рис. 3. Пример иерархии процесса

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

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

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

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

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

А с кем теперь нужно согласовать изменения в действиях одной функциональной роли в рамках выполнения одного этапа сквозного бизнес-процесса? Если вносимые изменения не меняют выход этапа, т. е. меняется работа лишь внутри этапа, то согласовывать данные изменения нужно только с владельцем этого этапа. Если же изменения затронут выход из этапа, то требуется согласование с владельцем следующего этапа (для него меняется вход!) и владельцем сквозного процесса. Согласитесь, согласование с владельцем одного этапа проще, чем с владельцами всех этапов сквозного процесса (а их может быть и 15, и 20, и при этом для них вносимые изменения не имеют никакого значения).

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

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

Моделирование процесса

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

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

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

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

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

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

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

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

Иерархия внутренних нормативных документов

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

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

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

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

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

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

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

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

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

Выводы

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

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

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

Рис. 5. Сокращение стоимости и сроков изменения процесса

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

Текст статьи опубликован по материалам журнала «Банковское дело» №4, 2018.

ПАО «АК БАРС» Банк — российский акционерный коммерческий банк. Головной офис расположен в Казани. На начало 2018 года «АК БАРС» Банк обслуживает более 3,1 млн частных лиц и свыше 67 тысяч корпоративных клиентов. Филиальная сеть на 1 марта 2018 года — 5 филиалов в крупных городах России, 142 дополнительных офиса, 22 операционные кассы, 88 операционных офисов.

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

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

Методика оптимизации бизнес-процессов банка (финансовой организации)

«Динамизация» банка или как сделать процесс оформления командировки незаметным

1. Бизнес-направления деятельности компании

2. Бизнес-процессы компании первого уровня

3. Организационная структура компании верхнего уровня

Оргструктура первого уровня Бизнес-процессы первого уровня	1. Генеральный директор	1.1. Коммерческий директор	1.2. Финансовый директор	1.3. Директор по развитию	1.4. Директор по персоналу	1.5. Директор по логистике	1.6. Директор по безопасности	1.7. Начальник юридического отдела
1. Основные бизнес-процессы
1.1. Закупка товара		X
1.2. Хранение и складирование товара						X
1.3. Продажа товара через филиалы		X
1.4. Продажа товара оптом		X
2. Обеспечивающие бизнес-процессы
2.1. Административно-хозяйственное обеспечение			X
2.2. ИТ-обеспечение и связь			X
2.3. Обеспечение безопасности							X
2.4. Юридическое обеспечение								X
3. Бизнес-процессы управления
3.1. Стратегическое управление				X
3.2. Управление финансами			X
3.3. Управление маркетингом		X
3.4. Управление процессами				X
3.5. Управление персоналом					X
3.6. Управление закупкой и транспортной логистикой						X

Структура бизнес-процесса «Продажа через филиалы»

I. Бизнес-процессы

1. Основные бизнес-процессы

1.1. Закупка товара

1.2. Хранение и складирование товара

1.3. Продажа товара через филиалы

1.3.1. Управление процессом

1.3.2. Формирование товарного запаса под продажи

1.3.3. Распределение плана продаж по сегментам

1.3.4. Работа с покупателем и получение заявки

1.3.5. Подготовка товара к отгрузке

1.3.6. Доставка товара покупателю

1.3.7. Передача товара покупателю

1.3.8. Возврат дебиторской задолженности

1.3.8.1. Контроль оплаты товара покупателем

1.3.8.2. Блокировка отгрузки товара

1.3.8.3. Разблокировка отгрузки товара

1.3.9. Возврат товара

2.1. Продажа товара оптом