В статье рассматривается возможность применения для оценки любого процесса организации технологии, представленной в стандарте ГОСТ Р ИСО/МЭК 15504-2. Материал может быть интересен специалистам, использующим (разрабатывающим) собственную методику оценки уровня зрелости как отдельных процессов, так и системы процессов организации в целом.

Введение

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

Существуют различные подходы к оценке зрелости процессов. Среди них есть подход, который проработан в области информационных технологий в стандартах серии ГОСТ Р ИСО/МЭК 15504. В данной статье сделана попытка интерпретировать стандарт ГОСТ Р ИСО/МЭК 15504-2 так, чтобы можно было проводить оценку зрелости любых процессов организации. В самом стандарте сказано, что документ: «… распространяется на оценку процессов и ее применение для улучшения и определения возможностей процесса. Настоящий стандарт устанавливает минимальный набор требований к проведению оценки, соблюдение которых обеспечит объективность, беспристрастность, непротиворечивость, повторяемость результатов оценки, представляющих оцениваемый процесс».

В документе вводятся понятия «Оценка» и «Возможность». Замечу, что в рассматриваемом стандарте ни разу не используется термин «Зрелость». Тем не менее, далее в статье я буду пользоваться термином «зрелость процесса».
Отмечу, что Стандарт разрешает использовать его материалы: «…пользователи настоящего стандарта могут свободно воспроизводить соответствующие материалы как часть любой модели оценки процесса…». Модель оценки процесса, в том виде, в каком я хочу представить читателю (таблица критериев и уровней) в тексте ГОСТ Р ИСО/МЭК 15504-2 отсутствует. Методика описана там текстом, что не очень удобно для восприятия и использования.

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

По итогам внимательного чтения документов ГОСТ Р ИСО/МЭК 15504-1-2009 и ГОСТ Р ИСО/МЭК 15504-2 я сделал для себя вывод, что процессы желательно оценивать по следующим четырем аспектам:

1. Возможности достижения целей организации.
2. Текущий потенциал процесса (например, производительность).
3. Возможности (потенциал) улучшения процесса.
4. Культура непрерывного улучшения процесса.

На рис. 1 представлен пример, в шутливой форме поясняющий эти аспекты.

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

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

Каким же образом измерить возможности процесса? Хотя в Стандартах серии 15504 можно выделить указанные выше аспекты, измерять предлагается набор так называемых атрибутов (критериев), по которым определяется уровень возможностей процесса. Т.е. все четыре аспекта свернуты в линейный список критериев. Итак, давайте рассмотрим собственно критерии и уровни оценки возможностей процесса.

Критерии и уровни оценки зрелости процесса

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

Для каждого уровня от «0» до «5» в ГОСТ Р ИСО/МЭК 15504-2 описаны критерии, по которым нужно проводить оценку возможностей процесса. Критерии сгруппированы по нескольким аспектам. После сведения всех этих критериев в таблицу, получается следующая картина.

Надписи на рис. 2. весьма мелкие, поэтому зарегистрированным пользователям портала можно скачать файл MS Excel.

Как видно из таблицы, атрибуты (критерии) оценки процесса сгруппированы по следующим разделам:

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

Таким образом, нужно для каждого атрибута оценить уровень достижения. Далее определяется уровень возможностей (зрелости) процесса в целом при помощи следующей таблицы, которую предлагает использовать Стандарт ГОСТ Р ИСО/МЭК 15504-2:

В таблице MS Excel (рис.2.) приведен пример оценки критериев для некоторого условного процесса. Видно, что при такой оценке процесс находится между уровнями «1» и «2».

Интерпретация структуры критериев оценки возможностей процесса

Считаю важным обсудить некоторые вопросы по структуре и содержанию критериев (атрибутов).

Осуществление процесса

Здесь все понятно. Если процесс выполняется и мы получаем приемлемый результат, то зрелось процесса соответствует Уровню 1.
Можно определить и использовать несколько критериев второго уровня декомпозиции, которые реально измерить, например:
• План/факт по объему производства (например, при отклонении более минус 25% значение критерия равно «0» и т.п.);
• План/факт по уровню брака;
• План/факт по срокам поставки;
• …

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

Управление осуществлением

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

Управление рабочим продуктом

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

Определение процесса

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

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

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

Измерение процесса

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

Контроль процесса

Судя по смыслу представленных критериев, данный раздел правильнее было бы назвать «Управление вариациями процесса». Представленные критерии вполне можно оцифровать.

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

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

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

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

Резюме

Мы рассмотрели системы критериев и уровней оценки возможностей процесса, рекомендуемые стандартом ГОСТ Р ИСО/МЭК 15504-2. На мой взгляд, подход, сформулированный в стандартах, можно использовать для оценки зрелости любого процесса, не только в области информационных технологий. Читатель может творчески переосмыслить представленный материал и создать (изменить) методику оценки зрелости процессов для своей компании. Эта методика может быть использована в рамках проекта внедрения процессного управления и последующей деятельности по постоянному совершенствованию процессов компании.

В.В. Репин, к.т.н., доцент, тренер, консультант по управлению.

Январь 2017 г.

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

Введение

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

Но процессное управление – это не создание регламентов. В первую очередь, это оперативное управление бизнес-процессами. Цель небольшого исследования, которое я провел, состоит в анализе возможностей Business Studio в комплекте с BS Portal для поддержки оперативного управления бизнес-процессами компании.

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

Предполагаю так же, что читатель уже имеет минимальный набор знаний об архитектуре Business Studio и видел в работе BS Portal (см. http://www.businessstudio.ru/load/portal/).

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

Функционал для регулярного оперативного управления бизнес-процессами – что в него должно входить? Какие инструменты может использовать владелец процесса (руководитель структурного подразделения)? Другими словами, нужен методически грамотный ответ на вопрос: «Что есть оперативное управления бизнес-процессами»? Ответ на этот вопрос не так прост, как может показаться на первый взгляд.

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

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

1. Оперативное планирование процесса (деятельности подразделения).
2. Мониторинг и контроль процессов по показателям;
3. Анализ причин отклонений в процессе и принятие решений (выбор — коррекция или корректирующее действие);
4. Оформление, выдача и контроль исполнения разовых задач по процессу (в т.ч. коррекций).
5. Планирование, организация и контроль исполнения корректирующих действий по процессу.
6. Оперативный контроль исполнения требований нормативно-методических документов (регламентов).
7. Анализ процесса в целом (в т.ч. на основе статистики), планирование, организация и контроль исполнения внутренних проектов развития (PDCA).
8. Оперативный контроль экземпляров бизнес-процессов.

Хотел бы обратить внимание, что автоматизация задач 1-3 во многих компаниях до сих пор отсутствует. Руководители используют подручные средства для хранения и анализа информации: свою голову, ежедневник, файлы MS Excel и т.п. В более продвинутых компаниях применяют BI-системы, автоматизируют работу с поручениями, внедряют документооборот, BPMS и проч.

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

Посмотрим, насколько Business Studio и, в особенности, BS Portal смогут помочь нам в поддержке указанных выше задач.

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

Итак, заходим на портал Business Studio. В рассматриваемой компании (демо-базе) я назначил себя на должность Коммерческого директора (на Генерального – скромность не позволила).

Для входа на портал нужно ввести свой логин и пароль. Кстати, я поменял логотип производителя на логотип моего портала www.bpm3.ru (там можно купить Business Studio и заказать консалтинг, извините за продакт плейсмент).

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

Для настройки пиктограмм разделов нужно разместить новые файлы в системной папке BS Portal. Через интерфейс Business Studio сделать это не получится. А уж если говорить о настройке стилей, то придется редактировать файл css.

Разделы «Показатели», «Цели» и «Документы» формируются по умолчанию, хотя их можно отключить. Но я оставил – их вполне можно использовать. Было создано несколько новых разделов, внутри которых используются так называемые разделители. Например, есть раздел «Мои процессы и НСД». В нем первый разделитель – «Управление процессами». Внутри некоторых разделов в виде гиперссылок показаны названия отчетов, в некоторых – «Коммерческий директор». Дело в том, что движок Business Studio работает следующим образом. Для отчетов, сформированных по классу физические лица, он выводит название самого отчета. Для отчетов по классу «Субъекты» — название должности. Если бы я занимал две должности в рамках данной модели (например, был бы еще Директором ООО «СбытПромЗакупка» — дочерней компании), то кроме «Коммерческого директора» была бы видна должность «Директор». Дело в том, что разработчики считаю, что в компаниях физические лица часто занимают несколько должностей.

Кстати, функционал настройки персональной страницы в Business Studio выполнен весьма сложно – нужно провалиться вниз на 9 уровней различных меню (если я не сбился со счета), чтобы сделать все необходимые настройки. Чтобы их проверить – снова на 7 уровней вниз и т.п. Понятие «Предпросмотр» web-страницы отсутствует и проч. Нужно запустить портал на формирование, и только потом смотреть результат.

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

Контроль процесса по показателям

Давайте зайдем в раздел «Мои показатели» на персональной странице, выберем один из показателей и посмотрим, что покажет система как результат работы стандартного отчета. Результаты представлены на рис. 4.

Мы видим довольно унылый (с точки зрения дизайна) график изменения значений показателя. Но это даже неважно. В Business Studio нельзя:
• сделать график интерактивным;
• поменять тип диаграммы или цвета;
• гибко поменять видимую часть графика (подвигать шкалу времени), изменить масштаб;
• сравнить с другими показателями (на одном графике), посмотреть тренды;
• использовать диаграммы разного типа.

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

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

Таким образом, если вы хотите контролировать показатели на BS Portal будьте готовы перемещаться между разными web-страницами с разными показателями (через Персональную страницу или Навигатор), с простейшей графикой и почти полным отсутствием интерактива. Можно сказать, что в BS Portal нет и 5% от функционала не самой дорогой BI-системы. Возможно, за свои деньги (1200 рублей за одну лицензию портала) это вполне адекватный функционал. Кроме того, хочу еще раз напомнить, что основное назначение системы – моделирование и регламентация деятельности организации. BS Portal нужен для вывода информации о моделях процессов и регламентов в интерактивном, гипертекстовом виде. Если эта задача для вас основная, то лучшего инструмента вы сегодня на рынке не найдете.

Мои процессы и НСД

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

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

Возможность создания такого рода отчетов – «плюс» как самой Business Studio, так и BS Portal. Легкость доступа к разработанным моделям процессов очень важна. Часто, причем даже в крупных компаниях, процессная модель остается «военной тайной» подразделения организационного развития и не доводится до линейных руководителей. Но ведь именно они являются потребителями этой информации! BS Portal в такой ситуации может оказаться реальным решением проблемы информирования широких масс сотрудников о процессных наработках.

Следующий отчет – «Процессы, в которых я участвую». Его задача – показать все операции, которые выполняет сотрудник, занимающий данную должность. Важно быстро находить требования к работе, которую нужно выполнить. Перелистывать десятки (если не сотник) бумажных регламентов невозможно. Поэтому BS Portal дает отличную возможность доступа к информации регламентирующего характера. Результат работы отчета представлен на рис. 6. Хочу заметить, что вид таблицы определяется пользователем – можно вывести всё, что необходимо руководителю (например, требования к срокам, периодичность выполнения, даты и т.п.).

Пойдем далее. Отчет после разделителя «Мои НСД» выводит таблицу с перечнем нормативно-методических и справочных документов по всем процессам, в которых участвует сотрудник. При нажатии соответствующих гиперссылок можно перейти на стандартный отчет по документу и потом открыть его на просмотр – см. Рис. 7.

Вернемся к разделу «Мои процессы и НСД». Последний отчет в данном разделе подготовлен для демонстрации возможности вывода фотографий. В данном случае я создал справочник оборудования, используемого в процессе. Добавил (через Meta Edit) поле для закачки фотографий и сделал соответствующий отчет – см. рис. 8.

Естественно, кроме названия и фото можно добавить всё, что угодно – описание, технические характеристики, порядок подготовки к работе и проч.

Мои страт. карты

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

Оперативный контроль

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

Первый отчет – «Оперативный контроль процессов». Результат его работы показан на рис. 10. Фактически, представленная таблица – это электронный ежедневник владельца процесса, в котором он осуществляет фиксацию отклонений процесса от нормального хода. Делается это на основании контроля значений показателей (через тот же BS Portal). Почему не хватает только отчетов с показателями? Попытайтесь ответить на простой вопрос: «Как убедиться в том, что руководитель регулярно мониторил процесс, фиксировал отклонения и разбирался с ними?!» Всё в голове или ежедневнике… Если вы сторонник неконтролируемого, субъективного ручного управления, то для вас этот вопрос покажется надуманным.

Вернется к отчету. Он включает: дату проверки, показатель, суть отклонения, формулировку причины отклонения, выбор реакции (коррекция или корректирующее действие), описание коррекции (оперативной разовой задачи в рамках процесса, необходимой для устранения отклонения), плановую и фактическую даты и т.п. Возможна дополнительная аналитика, классификатор отклонений и т.п. В правой части таблицы (на рисунке не видна) указан ответственный исполнитель и статус («Выполнено», «Не выполнено»). В крайней правой ячейке – ссылка на так называемое «Сообщение о несоответствии», созданное владельцем процесса по факту выявления отклонения и принятия решения о выполнении корректирующего действия. Почему так? Дело в том, что в Business Studio создать корректирующее мероприятие можно путем создания «Сообщения о несоответствии» (функционал СМК), для которого нужно указать список мероприятий. Кроме того, мероприятия можно создать для объектов «Несоответствия» и «Причина». Кстати, посмотреть нужные мероприятия в системе можно, но это неудобно. Замечу, что при настройке отчетов я старался максимально использовать штатную структуру данных Business Studio, а не громоздить новые классы и объекты через Meta Edit.

Теперь хотел бы обратить внимание читателя на простой, но ключевой аспект – все указанные выше данные можно внести только через интерфейс Business Studio. Через BS Portal это сделать невозможно (как, впрочем, и редактировать регламенты в гипертекстовом виде – это моя мечта). Напомню, что одна лицензия Business Studio стоит 76 800 рублей. Т.е. если владелец процесса хочет вести ежедневник контроля отклонений в BS, ему нужно будет потратит эту сумму. Хотя, стоит отметить, что сообщения о несоответствиях можно вводить через модуль Cockpit, который стоит 980 рублей.

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

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

Пример работы отчета представлен на рис. 11.

Как видно на рис. 11, в таблице есть такие столбцы, как: дата проверки, процесс, регламент (кстати по ссылке можно его открыть), пункт НМД (который проверялся), описание несоответствия и сообщение о несоответствии.

Следующий отчет – «КД, которые я контролирую». Расшифровка КД – корректирующие действия. Владелец процесса должен иметь оперативную информацию о статусе этих корректирующих действий. Иначе опять голова, ежедневник или Excel… Чуть не забыл 1С. Но в нем такие настройки есть далеко не во всех компаниях. Пример работы отчета представлен на рис. 12.

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

Последний отчет в рассматриваемом разделе – «Мои проекты» — см. рис. 13. При помощи этого отчета владелец процесса получает информацию по проектам внутреннего развития (PDCA), для которых он является контролирующим лицом. Опять же – приведена простейшая форма отчета. При желании можно вывести любые данные по проекту — даже График Ганта со статусом исполнения. Для этого можно присоединить соответствующий файл MS Project. При просмотре портала в MS Internet Explorer можно будет открывать этот файл на редактирование. На крайний случай, просто приложите скрин-шот из MS Project.

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

Другие разделы персональной страницы

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

Для прикола добавлен раздел «Мои фото», где сотрудник может что-то опубликовать. Однако механизм занесения фото в Business Studio таков – через текстовое поле формата rtf (тип атрибута «Изображение» хотя и есть в Meta Edit, но не поддерживается системой). Более правильный путь – создание специальных справочников через Meta Edit. В этом случае можно делать ссылки на файлы прямо из списка, доступного для каждой должности (процесса и т.п.).

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

Какие еще разделы можно добавить? Например, «Бенчмаркинг» или «Отзывы клиентов» и т.п. Важно помнить, для кого создается персональная страница. В этом контексте стоит обратить внимание на следующий момент. В BS Portal – внешний вид и структура персональной страницы (в т.ч. состав отчетов) не могут изменяться в зависимости от категории должности сотрудника. Например, для специалиста структура персональной страницы должна быть совершенно другой. Ему не нужны разделы по управлению процессом, аудитам и т.п. Но он увидит ту же страницу (как для «Коммерческого директора»), но большинство отчетов будут пустыми.

Резюме

Итак, подведем итоги. Что может Business Studio Portal в части поддержки оперативного управления бизнес-процессами:

Итог – соответствие функционала BS Portal задачам оперативного управления бизнес-процессами – всего 14%. Понятно, что моя оценка субъективна.

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

В.В. Репин, к.т.н., доцент, тренер, консультант по управлению.

Октябрь 2016 г.

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

Введение

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

Контролируете ли Вы исполнение требований вашими подчиненными?

Для начала давайте обсудим простую ситуацию. Вы – руководитель, управляющий несколькими сотрудниками, которые выполняют определенную работу. Есть утвержденные регламентирующие документы, по которым эта работа должна выполняться. Однако Вы не можете постоянно находиться в помещении (и не только), где выполняется работа. Вы можете контролировать работу раз в день, неделю, месяц. Чем реже Вы будете контролировать ситуацию, тем больше вероятность того, что к концу срока работа не будет выполнена надлежащим образом. Это не аксиома, конечно. Факторов влияния много: уровень руководителя (чем ниже – тем чаще контроль), сложность выполняемой работы, профессионализм, ответственность и этические качества сотрудников, корпоративная культура и проч.
Было бы наивно полагать, что можно набрать идеальных сотрудников, которые добросовестно будут исполнять свою работу даже при отсутствии контроля. Ничего идеального не бывает. В реальности постоянно возникают отклонения, которые нужно оперативно выявлять и корректировать. Проблема состоит в том, что руководитель не всегда видит, не имеет представления о том, как именно создается результата процесса. Чаще всего менеджеры стимулируют сотрудников на получение результата процесса, но при этом не обращают внимание на то, как именно был получен этот результат. При отсутствии контроля процессы начинают «деградировать». Последствия могут быть критическими не только для клиентов, но и для самой организации.
Давайте рассмотрим простой пример – Вы заказали строительство летнего домика некоторой компании. Заключили договор, оплатили аванс. Приехала бригада. Выполнила работу. Через 1,5 месяца вы принимаете готовый дом и оплачиваете оставшуюся сумму. Во время строительства Вас на участке не было, а жена не могла (или не хотела) брать на себе ответственность за контроль над процессом. В результате, через некоторое время после приемки Вы начинаете обнаруживать скрытые дефекты. А вот их количество и степень важности зависят от компании-подрядчика: технология строительства, уровень культуры, подбор и стимулирование бригады, система контроля и т.п.
Если руководитель оперативно не контролирует процесс, то сотрудники могут начать выполнять работу не так, как требуется регламентом (т.е. технологией выполнения процесса), а так, как им выгодно и/или удобно. Например, им может быть выгодно сделать больший объем работы для получения премии (деньгами, свободным временем). Они могут попытаться сэкономить материал и использовать его в личных целях (продать, например) и т.п. Кроме того, они могут нарушать требования просто по халатности, лени или незнанию. Но до тех пор, пока руководителя интересует только конечный результат, сама работа, приводящая к этому результату, будет выполняться не так, как требуется регламентами, а так как удобнее, выгоднее, быстрее для исполнителей.

К чему ведет отсутствие оперативного контроля исполнения требований регламентов?

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

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

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

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

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

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

Методы контроля
• визуальный контроль;
• контроль по документам;
• контроль по показателям;
• контроль экземпляров процесса;
• неформальный контроль;
• внутренний аудит;
• прочие.

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

Информация для оперативного контроля исполнения технологии процесса

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

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

Анализировать ситуацию будем с точки зрения владельца процесса (руководителя подразделения, отвечающего за выполнение процесса).
На рис. 1 представлена несколько видоизмененная структурная модель, которую я всегда использую для объяснения модели работы любого процесса. На данной схеме показана деятельность по преобразованию входов в выходы (результаты процесса), а так же ресурсы, необходимые для выполнения процесса: регламенты, оборудование, среда, персонал. Эти элементы процесса тоже нужно контролировать оперативно. Очевидно, что они влияют на возможность работать по стандартам. Но пока я хотел бы сделать акцент именно на оперативный контроль самой технологии (алгоритма) выполнения работы сотрудниками. Информация и методы, которые мы будем обсуждать, по большей части годятся и для оперативного контроля состояния ресурсов.
Так же, я не буду подробно останавливаться на контроле входов и выходов процесса. Дело в том, что методы контроля, например, сырья или готовой продукции давно разработаны и применяются на практике. Сплошной или выборочный контроль, разрушающий и неразрушающий контроль, и другие моменты подробно проработаны в рамках методов контроля и управления качеством. А вот оперативный контроль исполнения процесса – объект более интересный и важный для обсуждения.
Итак, обратимся к рис. 1 – цифрами показаны различные виды информации, которые могут быть использованы владельцем процесса для контроля исполнения технологии (алгоритма) выполнения процесса.

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

Таблица 1. Информация для контроля исполнения требований технологии выполнения процесса

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

Оперативный контроль при помощи системы Business Studio

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

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

Выводы

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

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

В.В. Репин, к.т.н., доцент, тренер, консультант по управлению.

Сентябрь 2016 г.

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

Краткое введение

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

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

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

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

Функционально-целевая модель ССБП

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

Как видно на рис. 1, основной результат или цель функционирования ССБП в целом – это «Возможность ведения прозрачного, управляемого и эффективного бизнеса» для собственников и топ-менеджмента. Не думаю, что для кого-то из собственников это не важно.
Надеюсь, вы обратили внимание на термин «Возможность» в формулировке результата. Честно говоря, я не люблю (на то имеются конкретные основания), когда используют термин «Обеспечение» при формулировке целей. Термин «возможность» — довольно близкий. Но в данном контексте понятные, корректные и актуальные регламенты – это действительно ВОЗМОЖНОСТЬ для руководителей — возможность эффективного контроля и управления процессами. А вот воспользуются ли они этой возможностью – это другой вопрос. Это другая часть системы управления, которую я в данной статье не рассматриваю.
Надеюсь, что представленная модель будет иметь для вас ценность. После осмысления схемы рис. 1, вы сможете четко обосновать для собственника компании ценность ССБП и суть каждого процесса в системе.

Рассмотрим кратко каждый процесс, представленный на схеме рис. 1.

1. Управление системой стандартизации бизнес-процессов

Основной результат: возможность функционирования и развития системы стандартизации бизнес-процессов.
Описание: ССБП, как любая система, требует управления. Предоставленная себе самой она будет деградировать. К сожалению, такая ситуация наблюдается довольно часто.
Основной результат подпроцесса управления, на мой взгляд, — возможность ССБП выполнять свое функциональное назначение (как части более сложной системы), а так же ее развитие, синхронизированное с изменениями организации в целом. Уровень развития ССБП должен соответствовать уровню развития организации в целом. За управление ССБП должен отвечать конкретный руководитель организации, например Директор по организационному развитию.

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

Основной результат: Глубокое и адекватное понимание процессов бизнеса. Понимание возможностей оптимизации процессов
Описание: Первый результат дает возможность регламентации процессов. Если мы глубоко и адекватно понимаем выполняемые процессы, знаем важные практически нюансы, мы способны создавать регламенты, основанные на 100% понимании процессов. Это – одно из важнейших условий эффективной работы по регламентам.
Второй результат заключается в возможности инициации и выполнения внутренних проектов организационного развития, которые изменяют процессы организации. Точки старта – это понимание проблем в процессах и путей их устранения.

3.Разработка НДМ

Основной результат: Возможность внедрения эффективных стандартов для бизнеса.
Описание: Основной результат процесса разработки – это регламенты (шире – НМД в целом). Но не просто регламенты. Это: а) документы, которые можно реально внедрить; б) документы, внедрение которых означает результативное и эффективное выполнение процессов на практике. Регламенты – регламентам рознь. Процесс разработки должен выдавать качественный результат с точки зрения возможности практической работы.

4. Ввод НМД в действие

Основной результат: Возможность ведения бизнеса по эффективным стандартам.
Описание: Написанный стандарт и внедренный стандарт – это две большие разницы. Основной результат процесса состоит в том, что сотрудники: а) досконально знают требования НМД; б) имеют правильные навыки выполнения работы; в) понимают важность выполнения работы в соответствии с требованиями. При этом стоит отметить, что процесс НЕ включает в себя оперативное управление или контроль исполнения регламентов.

5. Поддержка базы знаний и web-портала

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

6. Хранение НМД и выдача копий НМД

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

7. Контроль необходимости актуализации НМД

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

8. Инвентаризация НМД

Основной результат: Соответствие стандартов требованиям бизнеса.
Описание: Цель процесса практически повторяет цель процесса № 7, но методы выполнения этих процессов разные. Инвентаризация НМД проводится раз в полгода (год) более сложным методом. Выявляется реальное состояние каждого НМД с точки зрения актуальности и практической полезности для бизнеса.

9. Отмена НМД

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

10. Анализ использования НМД и оценка эффекта для бизнеса

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

11. Внутренний аудит

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

12. Обучение и аттестация по НМД

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

Модель потоков

На рис. 2 так же показана модель ССБП, но вместо описания ценности (главного результата), создаваемой каждый процессом, представлены потоки документов (информации).

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

Вполне вероятно, что читателю данная схема будет более понятна. Она вполне подходит для дальнейшей декомпозиции каждого подпроцесса, например, в нотации CFFC, BPMN или eEPC.
Хотел бы привести небольшую практическую рекомендацию по выполнению такой работы. Прежде чем начать формировать модели подпроцессов ССБП (т.е. выполнять декомпозицию), рабочей группе проекта внедрения ССБП целесообразно заполнить таблицу, содержащую следующие столбцы:
• №.
• Наименование процесса.
• Главная цель процесса.
• Входы (информация, документы).
• Выходы (информация, документы).
• Участники.
• Ответственный.

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

Резюме

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

В.В. Репин,
к.т.н., доцент, тренер, консультант по управлению.

Февраль 2016 г.

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

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

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

5.1….
5.2. Приемка ткани
5.2.1. Разгрузка а/м.
5.2.2. Визуальный контроль и проверка ткани по количеству.
5.2.3. Формирование и подписание акта приемки ткани.
5.2.4. Печать этикеток со штрих кодами.
5.2.5. Приклеивание этикеток (для ткани от поставщиков).
5.2.6. Сканирование этикеток.
5.2.7. Сверка и перемещение в 1С на склад приемки.
5.3. Приемка возврата
5.3.1. Получение информации о возврате.
5.3.2. Доставка возврата со склада клиента (в Москве) или из ТК.
5.3.3. Доставка возврата клиентом (самостоятельно).
5.3.4. Разгрузка а/м.
5.3.5. Проверка правильности оформления документов и наличия ткани.
5.3.6. Перемещение возврата и документов в зону ОТК .
5.4….

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

Теперь давайте обсудим форму этого регламента. Рекомендую использовать следующие разделы.

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

Титульный лист

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

Паспорт регламента

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

Содержание

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

Общие положения

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

Общее описание процесса

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

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

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

• инициирующие и завершающие процесс события;
• входы и выходы процесса.

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

Графическая схема процесса

Графическая схема обычно занимает в регламенте один лист формата А4. Довольно редко компании используют формат А3, но это неудобно в случае использования регламента в бумажном виде.

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

Описание операций процесса

Невозможно всю информацию о процессе показать на графической схеме – она станет слишком сложной и плохо воспринимаемой пользователем. Мне периодически попадаются схемы, нарисованные «на коленке» (без использования среды моделирования) и в нестандартной нотации. Как правило, понять такие схемы без интерпретатора (автора) почти невозможно. Поэтому я предполагаю, что вы будете использовать среду моделирования и какую-то стандартную нотацию (CFFC, eEPC, BPMN – выбор не такой уж широкий).
В связи с этим возникает необходимость в дополнительных разделах регламента, которые раскрывают необходимую для исполнителя информацию.
Прежде всего, это раздел по описанию операций процесса. Он может быть выполнен текстом или в виде таблицы. Структура, представленная в п. 7 таблицы является довольно сложной. В результате, получается длинная таблица с весьма узкими столбцами, что не только выглядит неэстетично, но и неудобно в использовании.

Как можно сделать по-другому? Например, разбить таблицу на две: а) собственно описание операций; б) описание инициирующих и завершающих событий и входов/выходов. Решение – за вами.
Что писать в текстовом описании каждой операции? На мой взгляд, необходимо кратко изложить ключевые особенности выполнения операции для исполнителя. Не нужно «разжевывать» ему всё. Мы предполагаем, что исполнитель является квалифицированным и опытным сотрудником, который знает свой процесс. Но на нюансы выполнения деятельности нужно обратить внимание! Очевидно, что если разработчик регламента сам никогда не выполнял процесс (причем результативно и за отведенное нормативное время), он не сможет написать что-то осмысленное и полезное в документ.
Периодически встречаются ситуации, когда в текстовом описании операции дублируют ее название. Ну, это просто халтура со стороны разработчика документа… Иногда приводят слишком подробное описание. В этом случае стоит критически его проанализировать и подумать об использовании формы 2-уровневого регламента.
Довольно мило, когда количество операций на схеме и в тексте не соответствует друг другу. Этот факт указывает на то, что: а) графическая схема не рассматривается разработчиком как реальный практический инструмент понимания и регламентации процесса; б) регламент представляет собой документ «ручной сборки» (что плохо).
В общем, создание текстовой части описания действий исполнителей в регламенте является важным, ответственным и творческим делом.

Действия в случае отклонений

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

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

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

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

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

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

Ресурсы, необходимые для выполнения процесса

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

Контрольные процедуры (методы контроля)

Методы контроля или, другими словами, контрольные процедуры целесообразно продумать на стадии разработки регламента. Для чего они нужны? Это инструмент оперативного (час, день, неделя) контроля со стороны непосредственного руководителя.
В каждом процессе есть места, где у исполнителя есть:

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

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

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

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

Цели и показатели

Формулировка целей процесса является тяжким трудом для многих руководителей. Гораздо проще просто написать, например, что задачей процесса является получение маркетинговой информации или обслуживание оборудования. Но это «ни о чём». Нужно учиться формулировать четкие цели, причем увязанные с общей системой целей организации.
Я считаю раздел «Цели и показатели» обязательным для регламента. Процессом нужно управлять, а без показателей это невозможно делать целенаправленно. Нецеленаправленная деятельность – это хаос, имитация управленческой деятельности. Поэтому цели и показатели нужно включать в регламент обязательно.

Приложения

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

«Редкие звери» или нечасто используемые разделы регламента

Кратко хочу сказать про разделы, которые встречаются в регламенте процесса редко. Например, это раздел «Ответственность исполнителей». Его оформляют в виде таблицы. Как правило, везде одна и та же фраза – «Несет ответственность в соответствии с УК РФ…» или «Устное/письменное замечание руководителя/ Дисциплинарное взыскание». Если вам нечего написать в таком разделе, кроме одной и той же общей фразы, то лучше вообще убрать раздел из регламента.
Кроме «Ответственности исполнителей» в регламенте могут показывать информацию по проведенным аудитам. Это удобно для электронной версии, но неудобно для бумажной.
Иногда в регламентах можно увидеть такие разделы, как «Документирование и архивирование» или «Порядок внесения изменений». Но в них чаще всего пишут общие фразы типа: «Порядок документирования и архивирования в рамках настоящего регламента определен внутренними нормативными документами компании «» и « Настоящий Регламент пересматривается на соответствие в установленные в компании «_» сроки. Порядок пересмотра настоящего регламента определен внутренними нормативными документами компании «___». Зачем включать такие пустые, формальные фразы в регламент?! Не понимаю…

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

Резюме

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

В.В. Репин,
к.т.н., доцент, тренер, консультант.

Июль 2015 г.

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

Структура чек-листа

Качественная графическая схема бизнес-процесса является основой для:
• выполнения анализа процесса и разработки мероприятий по его оптимизации;
• формирования понятного и практически полезного регламента (стандарта).

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

Ниже представлены название разделов чек-листа и их краткие характеристики.

Тип модели процесса

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

Соответствие стандартной нотации моделирования

Необходимо проверить соответствие схемы общепринятым нотациям моделирования. Вариантов не много: IDEF0, eECP, CFFC, BPMN.

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

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

Корректность формулировок названий объектов на схеме

Объекты схемы это: документы, информация, операции процесса, субъекты (должности, роли), логические операторы (шлюзы) и проч.

Следует обратить внимание на соответствие названий Стандарту моделирования. Если в нем нет требований в части названий объектов, то стоит их внести.

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

Корректность описания входов/выходов

Входы/выходы могут быть информационные и материальные.

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

Корректность описания событий

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

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

Отсутствие логических и содержательных ошибок

Это самый важный раздел в чек-листе.

В первую очередь, здесь нужно указать логические ошибки. Например, некорректное использование в паре логических операторов «И» и «ИЛИ».

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

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

Аккуратность исполнения схемы. Визуальная наглядность

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

Отсутствие физической нереализуемости

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

Отсутствие возвратов (переделок работы)

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

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

Поэтому надо определить правила, когда рисовать возвраты, а когда – нет.

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

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

Отсутствие дублирования операций (прямое или косвенное)

Как это ни странно, иногда на схеме процесса можно увидеть дублирование операций.

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

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

Отсутствуют пропущенные важные операции

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

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

Отсутствует чрезмерный контроль

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

Отсутствуют узкие места («бутылочные горлышки»)

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

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

Иногда визуально выявить узкое место сложно. Нужен содержательный анализ на основе конкретных данных.

Отсутствуют возвраты в прошлое

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

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

Отсутствие смешения единичного потока и накопления (объектов обработки)

Это довольно тонкая, но очень распространенная ошибка.

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

Отсутствие «процессной грыжи»

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

Например, в процессе получения информации об оплате счета, возникает операция «Ведение бухгалтерского учета».

Отсутствие неоднородности масштаба операций

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

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

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

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

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

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

Рекомендую сначала попробовать найти несоответствия в схеме самостоятельно, а уже потом посмотреть мой вариант чек-листа.

Заполненный чек-лист

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

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

После данной тренировки попробуйте проверить качество моделей процессов Вашей компании.

В.В. Репин,
к.т.н., доцент, тренер, консультант.

Март 2015 г.

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

Введение

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

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

Введем следующее определение:

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

Можно сформулировать несколько целей создания и поддержания ССБП в компании:

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

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

1. Методы.
2. Инструменты.
3. Ресурсы.
4. Процессы.

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

Структура процессов системы

На следующем рис. 1. представлена структура процессов ССБП – первый, верхний уровень.

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

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

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

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

В таблице 1 представлена характеристика каждого уровня развития ССБП. Цветом показано состояние процессов системы. Оранжевый цвет – процесса нет, цифра «0». Желтый цвет – процесс есть, но работает недостаточно эффективно, оценка «0,5». Зеленый цвет – процесс есть, эффективная работа, оценка «1».
Красным цветом выделены процессы, на которые стоит обратить особое внимание. Именно они позволяют замкнуть контуры управления и делают систему управляемой.
Читатель статьи может зарегистрироваться на портале www.finexpert.ru, войти под своим логином и скачать файл MS Excel, в котором представлена данная таблица. В ней можно оценить состояние системы стандартизации бизнес-процессов вашей компании.

Таблица. 1. Уровни развития системы стандартизации бизнес-процессов.

Ключевая проблема системы

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

К числу процессов, «замыкающих» обратные связи (а без них нет управления) относятся:

1. планирование и контроль описания и регламентации процессов;
2. проведение моделирующих сессий;
3. контроль качества моделей процессов;
4. валидация моделей процессов;
5. разработка оперативных методов контроля исполнения НМД;
6. контроль качества проектов НМД;
7. валидация проектов НМД;
8. обучение и аттестация сотрудников на знание НМД;
9. контроль исполнения НМД и поддержка сотрудников во время переходного периода;
10. проведение инвентаризации НМД;
11. периодический оперативный контроль исполнения НМД линейным руководителем;
12. прочие.

Пример компании V-ого уровня

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

«…По особенностям описания бизнес-процессов в компании можно сказать, что система построена на основе сертифицированной ИСМ путем расширения на всю деятельность организации. Была выстроена структура НМД, охватывающая около 80% подразделений и процессов. Составлены требования к процессу разработки и внедрения регламентирующей документации. Все БП взаимосвязаны между собой, от общих стандартов до конкретных инструкций. Специалисты и руководители подразделений в группе с отделом развития принимают непосредственное участие в описании своих и смежных БП, являются инициаторами оптимизации БП и соответствующей регламентации.
Система управления выстроена в обязательном порядке с учетом культуры и ценностей компании. Разработан и развивается комплекс мероприятий по мотивации персонала. Ежегодно проводятся внутренние мероприятия по обучению и развитию персонала, и формированию кадрового резерва. Это и плановые внешние или внутренние семинары с последующим контролем применения полученных знаний, и различного рода номинации по крупным индивидуальным и групповым проектам, перспективным техническим решениям и др.
Оценка знаний и использования действующей НМД включена в общую аттестацию сотрудников, проводится при плановых и внеплановых аудитах подразделений, а также составляется непосредственным руководителем по результатам работы. Вся НМД размещена и актуализируется на внутреннем портале, к которому имеют соответствующий доступ все сотрудники компании, ее филиалов, представительств и дочерних организаций.
В части автоматизации БП предстоит немало работ, частично реализованных и также запланированных на ближайшее будущее. На данный момент практически всё построено в ручном режиме и во многом держится на исполнительности, ответственности и вовлеченности персонала, поэтому смело можно сказать, что коллектив компании — это действительно её капитал…

Зернева Светлана Анатольевна
Специалист Отдел развития корпоративной системы менеджмента
ЗАО Фирма «Август»

Выводы

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

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

В.В. Репин,
к.т.н., доцент,
тренер, консультант,
Исполнительный директор и партнер ООО «BPM Консалтинг Групп»

Февраль 2015 г.

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

Введение

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

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

«Простой» процесс

На рис. 1. показан простейший бизнес-процесс. Он заключается в том, что три сотрудника, находящиеся на различных должностях, последовательно выполняют три операции по созданию документа для внешнего заказчика: находят нужную информацию, подготавливают и передают заказчику некоторый документ. Каждая операция (согласно хронометражу) длится 10 минут. Заявки от заказчиков поступают равномерно с интервалом в 5 минут (всего около 2000 заявок в месяц). Получится ли у нас рассчитать на пальцах, сколько сотрудников нужно для подготовки документов? Основным ограничением является срок подготовки документа – «в течение 1 рабочего дня с момента подачи заявки». Давайте попробуем. Полезное время работы сотрудника – 22860 минут = 10560 минут. Время, требуемое одному сотруднику для обработки заявки, составит 2000*10 минут = 20 000 минут. Очевидно, что нужно иметь двух сотрудников на должности А, чтобы обработать все заявки.

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

Результаты имитации процесса показывают (см. рис. 1), что в феврале 2015 года на вход процесса поступило 1920 заявок. Из них только 958 (почти 50%) было выполнено к концу месяца. На первой операции процесса возникла очередь длинной 6 дней 16 часов. Наши расчеты «на пальцах» подтвердились. Давайте посмотрим, что будет, если увеличить численность всех сотрудников вдвое. На рис. 2. показаны результаты соответствующей имитации.

На рис.2 видно, что практически все заявки были выполнены. Длина очереди почти нулевая. Это означает, что численность по два сотрудника на каждой должности является оптимальной численностью для получения результата данного процесса (документ выдается «в течение 1 рабочего дня с момента подачи заявки» и даже быстрее). При этом мы, конечно, не учитывали прогулы, пьянки и беременность.
Любой скажет, что такие расчеты легко сделать безо всякого описания и имитационного моделирования процесса. Безусловно, это можно сделать (в т.ч. учесть % неявки персонала на работу, беременность и другие факторы при помощи коэффициентов, как это делают опытные нормировщики). Но давайте посмотрим, можно ли будет так просто выполнить расчет в более реальной практической ситуации.

«Сложный» процесс

Усложним процесс следующим образом:

1. заявки поступают неравномерно в течение дня;
2. операции процесса выполняются не точно 10 минут, а их длительность имеет некоторое распределение (минимум – 6, максимум – 14 минут);
3. существует определенный уровень «брака» при подготовке документов – 5% (выявляется потребителями при получении документов).

На рисунках 3, 4 и 5 показаны распределения соответствующих параметров, используемых при имитации.

На рис. 3. видно, что пиковая нагрузка приходится на три часа дня.

В целом, распределения на рис. 3 и 4 подобраны так, чтобы общее количество заявок в месяц составляло около 2000, как и в предыдущем случае.

На рис. 5. показано распределение времени выполнения операций процессов. Видно, что матожидание времени выполнения составляет 10 минут.

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

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

На рис. 6 видно, что к сотруднику, выполняющему операцию «Находит нужную информацию» стоит очередь из заявок, длинна которой на конец месяца составляет немногим более 2 дней. Т.е. мы не выполняем требования «В течение 1 рабочего дня с момента подачи заявки». Попытаемся увеличить численность сотрудников до 9 человек. На рис. 7. показаны результаты соответствующей имитации.

На рис. 7 видно, что при численности 9 человек (3 человека на каждой должности), очереди заявок практически нет.

Давайте предположим, что нам удалось провести работы по улучшению процесса, которые обеспечили:
1) сокращение среднего времени выполнения каждой операции процесса на 30%;
2) сокращению уровня брака до 1%.

Результаты имитации оптимизированного процесса показаны на рис. 8.

На рис. 8. мы видим, что очереди вообще нет. В связи с этим возникает подозрение, что сотрудники недостаточно загружены работой. Действительно, если посмотреть график работы сотрудника, занимающего должность С (рис. 9) видно, что он недостаточно загружен в первой половине дня, т.е. до пиковой нагрузки. Возникают мысли, как организовать работу так, чтобы в первой половине дня выводить меньше сотрудников и устранить соответствующие потери. Но это уже совсем другая история…

Выводы

В данной статье мне хотелось обратить внимание читателя на следующие моменты:

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

В.В. Репин,
к.т.н., доцент,
тренер, консультант,
Исполнительный директор и партнер ООО «BPM Консалтинг Групп»

Январь 2015 г.

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

Введение

Многие компании в России и СНГ уже инициировали или планируют приступить к проектам внедрения процессного подхода. Причины запуска проекта могут быть разные, например:

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

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

«Розовые очки» или неоправданные ожидания руководства

Неоправданные ожидания руководства от проекта – явление вполне заурядное. Для успешных и очень занятых руководителей внедрение ПП — это как приобретение нового автомобиля. Если есть деньги, то купить его просто и быстро. Как говорится, «утром деньги, днем стулья. Днем деньги, вечером стулья…». Но системное внедрение процессного подхода в организации – не покупка автомобиля. Это даже не строительство склада. Изменения касаются принципов деятельности и управления, а главное – отношения сотрудников к своей повседневной деятельности. «Процессный» взгляд на работу и привычка «работать с процессами» не могут появиться у большого количества людей за несколько дней или даже месяцев.
Ситуацию с «Розовыми очками» можно диагностировать в случае, когда у руководителя есть убежденность в том, что:
• удастся избежать активного личного участие в проекте;
• внедрение– это вопрос чисто технологический, а не идеологический и психологический (и даже отчасти религиозный);
• всё можно сделать за несколько месяцев (например описать и регламентировать 30 ключевых сквозных процессов компании на 1 месяц) минимальными ресурсами за минимальные деньги;
• тотальное описание и регламентация процессов полезны для бизнеса;
• стоит издать приказ и определитьKPI для менеджеров, и проект пойдет как по маслу;
• всёчто нужно, можно купить у внешних провайдеров, причем, чем крупнее консалтинговая компания/системный интегратор, тем лучше.

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

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

Боязнь наказаний

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

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

Результат – созданные в соответствии с планом работ графические схемы никуда не годятся. А это есть профанация(от лат. profanatio — осквернение святыни; искажение, извращении ечего-либо невежеством; непочтительное отношение к достойному уважения, опошление (идеи, учения, произведений искусства и т.д.). Например, руководитель производства получил задание описать процесс планирования производства. К концу квартала была разработана схема, содержащая два квадрата: «сформировать план производства» и «утвердить план производства»… Комментарии, как говорится, излишни.
Если руководство не сможет вовремя выявить факты профанации, то будет наработана гора некачественных графических схем, которые невозможно использовать на практике. Это, с свою очередь, приведет к дискредитация процессного подхода в глазах сотрудников компании и, возможно, к провалу проекта в целом.

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

Боязнь дополнительной ответственности

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

По моим наблюдениям, в компаниях чаще всего считают результативность деятельности (т.е. план/факт). Что же касается эффективности (факт/затраченные ресурсы), то ее рассчитывают, в основном, финансовые службы. Руководителям других подразделений проще использовать показатели результативности, причем часть из них считается как «план/факт» по итогам исполнения ряда мероприятий. Выдал нужный объем продукции/услуг, выполнил все запланированные мероприятия – ты результативен. А поскольку KPI (показатели, по которым осуществляется материальное стимулирование) привязаны именно к результату, то руководители спокойно получают свои квартальные премии…
Как только в рамках проекта внедрения ПП речь заходит о создании показателей, по которым становится «прозрачной» деятельность менеджеров с точки зрения эффективности (интенсивного развития)бизнес-процессов, то возникает скрытое сопротивление руководителей подразделений. Они не хотят использовать эти показатели.
Часть руководителей боится, что после внедрения таких показателей станет очевидным факт, что интенсивного развития, совершенствования процессов просто нет, а оперативная работа сводится к латанию дыр/тушению пожаров.
Другая важнейшая психологическая причина состоит в том, что руководители боятся, что после ввода в действие показателей эффективности их премия будет зависеть от этих показателей — Генеральный директор изменит систему стимулирования, ориентируя ее на эффективность (а не только на результативность) деятельности. В этом случае возникает дополнительная нагрузка, проблемы, нервы и т.п. Естественно, что рядовой руководитель не хочет этого.
Чтобы избежать такого рода проблем необходимы:
• утверждение Концепции внедрения ПП – четкая декларация о намерениях измерять эффективность и совершенствовать процессы;
• личное участие топ-менеджера в работе по созданию и внедрению системы целей и показателей;
• проведение рабочих сессий по разработке целей и показателей для открытого, коллегиального обсуждения проблем и возможностей по измерению эффективности бизнес-процессов;
• последовательная позиция руководства и «амнистия» — отсутствие наказаний за неэффективные процессы на период разработки и внедрения ПП;
• качественное обучение руководителей методам разработки и использования целей и показателей;
• активная методическая помощь и разъяснительная работа Главного методолога.

Стыд и боязнь проявить некомпетентность

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

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

Обиды и демотивация

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

Резюме

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

В.В. Репин, к.т.н., доцент, консультант по управлению.

Ноябрь 2013 г.

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

История вопроса

В декабре 2012 года на конференции «ПРОЦЕССНОЕ УПРАВЛЕНИЕ: сегодня и завтра» я прослушал весьма интересный доклад Наталии Самариной, Начальника отдела организационного развития ЗАО «ЮИТ Санкт-Петербург». В рамках доклада приводилась информация о методе описания процессов, используемом ООР в «ЮИТ». Это была так называемая «Моделирующая сессия» — совещание по структурированию процессов с привлечением руководителей и специалистов подразделений (см. рис. 1 – фото из опубликованного доклада).

Метод весьма заинтересовал, и я решил ознакомиться с ним ближе – съездил в Питер в компанию «ЮИТ». Наталия любезно разрешила присутствовать на одной из МС, которые регулярно проводятся в компании.

Моделирующая сессия

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

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

Каждая операция процесса подробно обсуждается. Определяются входы/выходы и события. Информация аккуратно фиксируется на липких бумажках и помещается на стенд.
После завершения сессии результаты работы фотографируются. Кроме того, бизнес-аналитики забирают бумагу с собой в ООР. Далее они используют полученный материал уже для профессионального описания процесса в Business Studio. Разработанные в нотации «Процедура» Business Studio схемы процессов согласуются с участниками МС. Далее эти схемы используются для регламентации соответствующих процессов.
Особенности реализованного в «ЮИТ» подхода, на мой взгляд, следующие:
• сотрудники компании активно вовлекаются в деятельность по структурированию процессов;
• по ходу МС фактически осуществляется обучение сотрудников методу описания;
• бизнес-аналитики получают информацию достаточно высокого качества, что существенно ускоряет последующую работу по формированию графических схем процессов;
• участие сотрудников в описании процессов делает более простым последующее согласование графических схем.

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

Алгоритм проведения сессии

Используя знания о методе проведения МС в «ЮИТ» мы разработали свою версию данного подхода. На рис. 3. Показана схема процесса проведения МС. При проведении МС мы дополнительно используем проектор, который выводит на большой экран таблицу MS Excel, содержащую список операций рассматриваемого процесса («домашняя заготовка» бизнес-аналитиков).

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

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

Преимущества и недостатки МС

Стоит обсудить преимущества МС и риски, которые могут возникнуть при ее проведении в компании.

Преимущества МС:
• активное вовлечение сотрудников в деятельность по описанию процессов;
• возможность быстро получить качественную информацию для описания процесса;
• общий PR методов процессного управления.

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

Риски при проведении МС
• переход от продуктивного обсуждения к неуправляемому «базару»;
• нарушение технологии визуализации процесса и, как следствие, получение сырых результатов низкого качества;
• нехватка времени для описания процесса в целом;
• прочие.

Чтобы сессия прошла продуктивно, бизнес-аналитику очень важно уметь грамотно ее модерировать. Для этого нужны определенные навыки и некоторая доля харизмы. Поэтому проведение МС нужно поручать наиболее подготовленным, опытным бизнес-аналитикам.

Резюме

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

В.В. Репин, к.т.н., доцент, консультант по управлению.

Сентябрь 2013 г.