Читать книгу "Бизнес-процессы. Моделирование, внедрение, управление - Владимир Репин"

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

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

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

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

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

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

• номер операции;

• наименование операции;

• исполнитель;

• инициирующие события;

• входящие документы;

• описание операции;

• завершающие события;

• исходящие документы.

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

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

• регламенты выполнения процессов;

• положения о подразделениях;

• должностные инструкции (на должности и роли).

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

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

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

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

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

Рис. 4.9.1. Выход за границы процессов

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

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

Рис. 4.9.2. Конфликты на границах процессов

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

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

Если схема процесса все-таки получилась слишком длинной (более 12–15 операций), следует внимательно ее проанализировать.

Возможно, что:

• на схеме представлено несколько процессов, а не один;

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

• в процессе появилась «грыжа» (см. ниже);

• прочее.

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

Рис. 4.9.3. Чрезмерно длинные процессы

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

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