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

К числу методов, которыми вы должны владеть в этой области, можно отнести:

  • 1) нотации для описания бизнес-процессов на верхнем уровне (например, IDEF0 или ARIS VAD) и метод их применения в компании;
  • 2) нотации для описания бизнес-процессов на операционном уровне (например, CFFC, ARIS еЕРС или BPMN).
  • 3) метод работы со средой моделирования процессов (внесения информации в систему) — «Соглашение по моделированию»;
  • 4) метод организации работ по описанию процессов;
  • 5) метод проведения моделирующих сессий;
  • 6) метод контроля качества графических схем процессов;
  • 7) метод валидации моделей процессов;
  • 8) метод имитационного моделирования процессов;
  • 9) метод выполнения проекта реинжиниринга (оптимизации) бизнес-процесса;
  • 10) прочие.

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

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

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

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

В общем, призываю отнестись к построению модели компании очень серьезно.

Второй пункт списка — нотации для описания бизнес-процессов на операционном уровне. К ним относятся: CFFC (Cross Functional Flow Chart), eEPC (Extended Event-driven Process Chain), BPMN (Business Process Model and Notation) и другие.

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

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

Нотации могут быть использованы только в конкретном программном продукте. Это как знание языка. Вы им владеете, но написать письмо можете как на бумаге, так и при помощи MS Word. Та же самая ситуация с нотациями моделирования. Можно описывать процессы в нотации, но «на коленке» (например, в том же MS Word1), а можно использовать специализированный программный продукт.

Но в современной компании неразумно описывать бизнес-процессы «на коленке», используя такие инструменты, как MS Word, MS Excel, MS Visio или Power Point. Целесообразно создать электронный репозиторий или, другими словами, базу знаний компании по бизнес-процессам. Для этого используются инструментальные средства моделирования.

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

Для эффективной работы со средой моделирования в компании необходимы, как минимум, две методики:

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

  • • методика работы со средой моделирования (так называемое «Соглашение о моделировании»);
  • • методика внесения изменений в базу знаний по бизнес-процессам.

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

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

В целом методика работы со средой моделирования в большей степени касается технических вопросов: требований нотаций, поддерживаемых средой моделирования, функционала системы, методов проверки качества моделей процессов и т.п. Говоря простым языком, методика показывает, как технически правильно описывать процессы с использованием конкретного инструмента. Но она не говорит, какие именно процессы, в какой последовательности и кто будет описывать. Это уже другая, но тоже исключительно важная, тема. Еще важно отметить, что никакое «Соглашение по моделированию» не заменит тщательного обучения, выполнения практических заданий и аттестации на умение моделировать реальные процессы. Сотрудников нужно научить видеть процессы и грамотно их описывать при помощи графических схем. Тогда этот инструмент будет работать. Любой ваш сотрудник может прочесть накладную или приказ. Значит, и схему процесса он тоже в состоянии прочитать и понять.

Методика описания процессов определяет кто, как и когда будет описывать и анализировать процессы в вашей компании. Речь идет о том, что при наличии инструмента моделирования (например, Business Studio) и «Соглашения по моделированию», нужно организовать работу по описанию процессов в компании.

В табл. 4.2 показаны важнейшие аспекты данной методики и возможные варианты их реализации. Вы можете обвести карандашом либо «Да», либо «Нет», либо нужный вариант. Но всегда думайте о последствиях вашего выбора.

Структура методики описания процессов. Варианты

Аспект методики

Возможные варианты реализации

Планирование описания процессов

Да / Нет

Использование нормативов трудоемкости работы по описанию процессов

Да / Нет

Выполнение работы по описанию и анализу процессов

А. Только бизнес-аналитики. Б. Только сотрудники отделов.

В. Сотрудники отделов совместно с бизнес-аналитиками

Проведение моделирующих сессий

Да / Нет

Проведение еженедельных совещаний по обсуждению графических схем процессов

Да / Нет

Проведение презентации (защиты) моделей процессов для владельца процесса (собственника бизнеса)

Да / Нет

Валидация моделей процессов

Да / Нет

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

Да / Нет

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

Да / Нет

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

Пример.

Аспект методики

Возможные варианты реализации

Планирование описания процессов

Нет

Использование нормативов трудоемкости работы по описанию процессов

Нет

Выполнение работы по описанию и анализу процессов

А. Только бизнес-аналитики

Проведение моделирующих сессий

Нет

Проведение еженедельных совещаний по обсуждению графических схем процессов

Нет

Проведение презентации (защиты) моделей процессов для владельца процесса (собственника бизнеса)

Нет

Валидация моделей процессов

Нет

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

Нет

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

Нет

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

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

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

В план стоит заложить резерв времени в размере 10% на увеличение трудоемкости и разовые, непредвиденные и срочные работы.

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

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

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

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

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

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

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

Моделирующая сессия (МС) — это специальное совещание, которое проводится по определенной технологии. Цель МС — вовлечь сотрудников в работу по описанию и анализу процессов, «привить» им культуру процессного взгляда на организацию деятельности, получить за короткое время детальную информацию по процессу.

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

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

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

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

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

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

А) провести «натурный эксперимент» — тестовую эксплуатацию, т.е. выполнить в реальности несколько экземпляров процесса в соответствии с разработанной схемой;

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

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

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

Еще одним важным методом является метод выполнения проекта оптимизации бизнес-процесса. Кратко перечислю ключевые аспекты данного метода:

  • 1) формируется модель процесса на верхнем уровне (эскизная модель процесса), определяются границы и участники процесса;
  • 2) определяются цели и показатели по процессу с точки зрения бизнес-заказчика (топ-менеджеров, собственника бизнеса);
  • 3) измеряются показатели по процессу «как есть»;
  • 4) разрабатывается и утверждается методика оценки эффекта от оптимизации (реинжиниринга) процесса (в случае, если эффект измерить сложно или невозможно, определяются качественные показатели удовлетворенности бизнес-заказчика результатами оптимизации процесса);
  • 5) определяются целевые значения показателей с точки зрения бизнес -заказчика;
  • 6) проводится цикл работ по описанию и анализу процесса (анализ ограничений, поиск узких мест и т.п.);
  • 7) разрабатывается, презентуется и утверждается план проекта оптимизации (реинжиниринга) процесса, назначается руководитель проекта;
  • 8) выполняется проект оптимизации (реинжиниринга) процесса;
  • 9) разрабатывается и проходит валидацию регламент оптимизированного процесса;
  • 10) внедряется регламент оптимизированного процесса;
  • 11) после выполнения достаточного количества циклов (экземпляров) процесса рассчитываются показатели оптимизированного процесса;
  • 12) осуществляется расчет экономического эффекта и выплата премии команде проекта.

Пункты 9—10 выполняются по методикам, которые целесообразно описать подробнее и отдельно в рамках системы стандартизации. Мы рассмотрим их ниже.

 
Посмотреть оригинал
< Пред   СОДЕРЖАНИЕ   ОРИГИНАЛ     След >