Подписаться
Рубрикатор
Полный список
Развитие организации
Управление процессами
Моделирование процессов
Регламентация процессов
Автоматизация процессов
Бережливое производство
Менеджмент качества
Управление проектами

Облако терминов
12-процессная модель 4PL ACM Activity diagram AQPC ARIS ARIS 9 ARIS eEPC Balanced Scorecard Big Data & Analytic BMPN BPA BPEL BPM BPM accelerator BPM-система BPM-системы BPMN BPMS BPR BPWin BS Portal BSC Business Intelligence Business Performance Management Business Performance Management (BPM) Business Process Management Business Process Management Systems Business Process Manager Business Rules Business Studio Business Studio 3.6 Business Studio 4 Business Studio 4.0 Business Studio Portal CA ERwin Data Modeler Case Management Casewise Casewise Corporate Modeler CFFC Corporate Modeler CPM CRM Decision Management DFD Directum ECM eEPC

Группа FineXpert.ru на facebook
Опрос

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

Библиотека

06.02.2011 10:37
  от автора
  Репин

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

Оценки за материал: 4.45 (20)

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

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

Корректное определение границ процесса

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






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

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






Декомпозиция – слишком «длинные» процессы

Неопытные бизнес-аналитики часто «рисуют» слишком длинные схемы процессов. Так получается, если начать задавать вопросы сотруднику и ту же пытаться формировать схему. Лучше сначала выслушать описание деятельности в целом, делая пометки в блокноте. Затем обдумать ситуацию, структурировать описание деятельности «в голове» , выделяя процессы и предварительно определяя состав их операций. Только после этого приступать к формированию графических схем. Кстати, велика вероятность, что при структурировании информации, полученной от сотрудников, окажется, что целесообразно выделить и описать не один, а несколько процессов.
Если схема процесса все-таки получилась слишком длинной (более 12-15 операций), следует внимательно ее проанализировать. Возможно, что:
• на схеме представлено несколько процессов, а не один;
• операции процесса сильно неоднородны (по длительности выполнения, по требуемым ресурсами т.п.);
• в процессе появилась «грыжа» (см. ниже);
• прочее.

В любом случае, схему процесса стоит переделать. Исключения составляют ситуации, когда схемы специально рисуют на бумаге формата А3, чтобы отразить все детальные шаги и взаимодействия. Но увлекаться увеличением формата листов для схем процессов не стоит. А3 – это максимально допустимый размер. «Рисовать» и потом печатать схемы процессов на А2 или на А1 категорически не рекомендуется.






«Процесс в процессе» или процессная «грыжа»

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






«Примитивизация» - рисование процесса по «хвостам»


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






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






Связи между процессами, «оборванные» входы/выходы

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






Нарушение нотации моделирования

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






Проверка на здравый смысл

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






Использование типовых процессов

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






В.В. Репин, к.т.н., доцент, Исполнительный директор ООО «BPM Консалтинг Групп», зав. кафедрой Управления бизнес-процессами НОУ ВПО «ИЭФ «Синергия», основатель портала www.FineXpert.ru

Февраль 2011 г.

Комментарии

Оценки: 3/
06.02.2011 18:33
  от автора
  Богиня
Владимир, описанные ситуации знакомы,имеют место и сейчас к сожалению.У нас нет штатного бизнес-аналитика, спасибо за тест - проверка на здравый смысл, будем проверять себя сами. Как у нас всё-таки любят всё усложнять.Ведь всё сложное познаётся через простое. У нас всё наоборот .
Оценки: 1/
06.02.2011 18:38
  от автора
  Репин
Привет, Богиня! Спасибо! М.б. что-то еще добавите из своего опыта?
Оценки: /
07.02.2011 08:55
  от автора
  Богиня
Владимир! К сожалению наш опыт наверное не самый лучший, а скорее наоборот Я попробую при наличии времени добавить что-то.
Оценки: /
07.02.2011 12:22
  от автора
  04011984
День добрый!
Весьма полезная статья...спасибо
Учтем, ибо описанные ошибки имеются
Оценки: /
07.02.2011 13:55
  от автора
  Дмитрий Пинаев
Отличная статья! А иллюстрации просто шикарные - креативно и со смыслом!
Оценки: /
09.02.2011 22:15
  от автора
  kaloshina
Чувствуется огромный накопленный опыт, очень наглядно, здорово вообще!
Оценки: /
10.02.2011 20:42
  от автора
  Klimchuk_AA
Статья понравилась своей лаконичностью
От себя добавлю еще одну типичную проблему - увлечение описания информационных потоков.
В результате появляется сложная паутина, гораздо полезнее рисовать только движение документов.
Логика такая: если информация важна - давайте оформим ее документом (электронным или бумажным), иначе - не стоит терять время на описание.
Оценки: /
12.02.2011 22:44
  от автора
  Елиферов Виталий
Спасибо, Володя!
Мне очень понравилось. Скопировал себе и дам прочитать своим сотрудникам.
С уважением Виталий.
Оценки: /
13.02.2011 18:31
  от автора
  Репин
Привет, Виталий!
Спасибо за отзыв! Кстати, если будут новые статьи, материалы - размещай, обсудим.
С уважением
Владимир
Оценки: /
17.02.2011 16:01
  от автора
  stas.mikhail
Спасибо, Владимир. Отличная статья. Почитал и сразу увидел в своих процессах кучу ошибок, не смотря на то что от нотации стараюсь не отклоняться, и правила описания соблюдать, все же свежий взгляд находит косяки. А себе для постоянного напоминания распечатал рисунки из статьи и повесил рядом с рабочим местом. Отличная вещь, помогает помнить про возможные косяки и рисовать более вдумчиво.
Оценки: /
17.02.2011 21:10
  от автора
  Репин
Спасибо! Рад, что рисунки оказались полезными
Оценки: /
21.02.2011 10:05
  от автора
  Репин
Коллеги!
Формулирую ещё один аспект формирования графической схемы бизнес-процесса: "Какую бы схему мы не рисовали, она должна быть красивой!"
Уродливые схемы не вызывают эстетического удовольствия у пользователя. Наоборот, они его отталкивают, вызывают ненужное раздражения. Для бизнес-аналитиков очень важно, чтобы руководители и специалисты были лояльны к их работе и ее результатам.
Оценки: /
21.02.2011 23:36
  от автора
  bell
Есть другое мнение: "все схемы процессов неправильны, но некоторые из них полезны".
Оценки: /
24.02.2011 11:24
  от автора
  ivanilovai
спасибо!
Оценки: /
25.02.2011 00:28
  от автора
  BusinessSet
Владимир, добрый день.
Спасибо за статью!
PS: в аспекте "Однородность процесса" небольшая опечатка "...по формированию паркета документов..."
Оценки: /
26.02.2011 15:31
  от автора
  Yury.Radchenko
Владимир, как Вы думаете, можно ли автоматизировать проверку построенных схем процессов по выше изложенным рекомендациям? Т.е. вывести их в некий алгоритм проверки? Возможно не все из приведенного, а часть?

В Business Studio, например, сейчас каждая нотация имеет проверку на правильность построения. Проверка идет, как я бы сказал, на "орфографию". А в статье скорей "грамматика".
Оценки: /
26.02.2011 15:49
  от автора
  Репин
Привет, Юрий! Спасибо за вопрос.
Думаю, что такого рода проверки почти не реально реализовать в системе. Система - это инструмент. Она может использоваться совершенно по-разному в зависимости от выбранной методики и квалификации бизнес-аналитиков. Реально можно проверять:
1)количество объектов на диаграмме. Если, например, на схеме появилось более 12 операций, то может загораться "желтая лампочка". Если более 15 - "красная лампочка" и т.п. Пока этого нет в BS.
2) "Оборванные" входы/выходы. Можно сделать в BS, используя существующие возможности.

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

Комментировать материалы могут только зарегистрированные пользователи. Вы можете зарегистрироваться здесь.
©  2010-2014 В.В. Репин. Сайт основан 3 февраля 2001 г.

Все права защищены. Частичное или полное копирование информации данного ресурса возможно только с разрешения владельца.

Регистрация
О Портале
Правила
Контакты
Новости
Библиотека
Энциклопедия
Литература и сайты
Группы
Мои страницы
Тесты
Форум
Доска объявлений