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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Резюме

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

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

Ноябрь 2013 г.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Резюме

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

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

Сентябрь 2013 г.

С какой эффективностью работает Ваш отдел Организационного развития (ООР)? Насколько он близок к реальному бизнесу? Помогают ли бизнес-аналитики (БА) руководителям подразделений оптимизировать процессы или только записывают с их слов и оформляют схемы процессов? В статье В.В. Репина обсуждаются два аспекта развития ООР: используемые технологии работы и требуемые компетенции бизнес-аналитиков.

Технологии и компетенции ООР

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

1. технология планирования и учета деятельности ООР, в том числе нормирование работы БА;
2. технология описания (моделирования) и регламентации бизнес-процессов;
3. технология работы со средой моделирования процессов;
4. технология оптимизации бизнес-процессов (реинжиниринга);
5. технология обучения сотрудников компании.

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

Планирование и учет деятельности ООР

Технология планирования и учета деятельности ООР должна включать такие аспекты, как формирование плана работы ООР на месяц, формирование еженедельных отчетов БА, формирование отчета по выполнению плана ООР на месяц.
План работы ООР не может быть самодостаточным или, другими словами, оторванным от других планов компании. Он должен базироваться на общем плане описания, анализа, оптимизации и аудита бизнес-процессов организации. Это может быть один план или комплект планов. Такой план может отличаться от плана работы ООР в том случае, если в бизнес-единицах (далее — БЕ) компании есть свои бизнес-аналитики, которые административно подчиняются руководителям БЕ. Если компания относительно небольшая и БЕ не выделены, отдельного подразделения внутреннего аудита нет, то план работы ООР может совпадать с общим планом описания, анализа, оптимизации и аудита бизнес-процессов организации.
План работы ООР должен быть в достаточной степени напряженным (т.е. не должно быть простоя ресурсов), но в тоже время практически реализуемым. Формирование такого плана – всегда поиск некоторого компромисса между целями топ-менеджера и возможностями ООР.

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

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

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

Технология описания (моделирования) и регламентации бизнес-процессов

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

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

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

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

В современной компании неразумно описывать бизнес-процессы «на коленке», т.е. используя такие инструменты, как MS Word, MS Excel, MS Visio или Power Point. Целесообразно создать электронный репозиторий или, другими словами, базу знаний компании по бизнес-процессам. Для этого используются инструментальные средства моделирования, например Business Studio 4.0 или iGrafx 2013.
Описание процессов в современной среде моделирования предполагает выбор и использование стандартной нотации, например «Процедура» Business Studio, BPMN, eEPC.
Для эффективной работы со средой моделирования ООР необходимы, как минимум, два нормативных документа:

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

1. ОБЩИЕ ПОЛОЖЕНИЯ
   1.1.Назначение и область действия
   1.2.Используемые сокращения
   1.3.Термины и определения
   1.4.Нормативные ссылки
   2.ВЕДЕНИЕ СПРАВОЧНИКОВ В «BUSINEES STUDIO»
   2.1.Справочник «Процессы»
   2.2.Справочник «Субъекты»
   2.3.Справочник «Объекты деятельности»
   2.4.Справочник «Управление»
   3.ОПИСАНИЕ ПРОЦЕССОВ В «BUSINEES STUDIO»
   3.1.Элементы нотации «Процедура» «Business Studio»
   3.2.Описание операций процесса
   3.3.Использование стрелок типа «связь предшествования»
   3.4.Использование стрелок типа «поток документов»
   3.5.Использование событий
   3.6.Использование блока «Решение»
   3.7.Использование междиаграммных ссылок
   3.8.Использование сносок
   4.СХЕМЫ ОРГАНИЗАЦИОННОЙ СТРУКТУРЫ В «BUSINEES STUDIO»
   4.1.Используемые графические элементы
2. ЗАПОЛНЕНИЕ АТРИБУТОВ ОБЪЕКТОВ МОДЕЛИ
   5.1.Заполнение атрибутов процесса
   5.2.Заполнение атрибутов операции процесса
   5.3.Заполнение атрибутов стрелок
   5.4.Заполнение атрибутов субъекта деятельности
   5.5.Заполнение атрибутов объекта деятельности
   5.6.Заполнение атрибутов целей и показателей

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

1.ОБЩИЕ ПОЛОЖЕНИЯ
1.1. Назначение и область действия
1.2. Используемые сокращения
1.3. Термины и определения
1.4. Нормативные ссылки

2. ОБЩЕЕ ОПИСАНИЕ ПРОЦЕССА
   2.1. Общее описание процесса
   2.2. Графическая схема процесса
   2.3. Цели и показатели
   2.4.Методы контроля исполнения процесса
3. ОПИСАНИЕ ПОДПРОЦЕССОВ
   3.1.Регулярная проверка и актуализация справочников
   3.2.Внесение изменений в справочник процессов
   3.3.Внесение изменений в справочник «Субъекты»
   3.4.Внесение изменений в справочники «Объекты деятельности» и «Управление»
   3.5.Управление правами пользователей
   3.6.Импорт/экспорт данных из BS в формате xml
   3.7.Внесение изменений в мета-модель и применение к БД
   3.8. Внесение изменений в шаблоны отчетов
   3.9.Переход с версии на версию
   3.10. Обслуживание базы данных
4. ПРИЛОЖЕНИЯ Данный регламент используется БА, ответственными за поддержание электронного репозитория бизнес-процессов компании.

Технология оптимизации бизнес-процессов (реинжиниринга)

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

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

Технология обучения сотрудников компании

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

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

Компетенции бизнес-аналитиков

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

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

Практический пример

Рассмотрим пример внедрения указанных выше технологий в ООР конкретной торгово-производственной компании численностью несколько тысяч человек.
В таб. 2 показаны некоторые изменения, которые произошли в компании в период с начала декабря 2012 года по начало мая 2013 года.

Таблица 2. Изменения в деятельности ООР.

На следующих рисунках показано сравнение ситуации в компании в 2012 и 2013 годах по четырем аспектам:
• мнение руководителей о существующей системе процессов;
• мнение руководителей о графических схемах процессов;
• оценка степени актуальности базы регламентирующих документов компании;
• оценка руководителями существующей системы управления ЖЦ НМД.

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

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

На рис. 2 видно, что в 2012 году руководители весьма низко оценивали графические схемы процессов, разрабатываемые БА ООР. В 2013 году ситуация радикально изменилась. Более половины руководителей считают графические схемы наглядными и понятными, используют их в работе.

Ситуация с актуальностью НМД (см. диаграммы на рис. 3) сложнее. Видно, что актуальность НМД в 2013 году выше, чем в 2012. Но она все еще продолжает оставаться относительно низкой. Нужно определенное время, чтобы база НМД компании качественно поменялась.

Анализ диаграмм рис. 4 показывает, что необходимо продолжать работу по совершенствованию технологии управления ЖЦ НМД. Например, можно пойти по пути создания web-портала для внедрения безбумажной технологии регламентации бизнес-процессов компании (например, используя Business Studio Portal).

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

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

Резюме

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

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

Август 2013 г.

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

В статье В.В. Репина предлагается структура «Карточки бизнес-процесса» и метод автоматизации работы с карточкой при помощи инструментальной среды моделирования процессов Business Studio 4.0.

Управление процессами – основа эффективности и выживания компаний в будущем

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

Графическая схема или управляемый бизнес-процесс?

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

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

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

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

Карточка бизнес-процесса

Предлагаемая вниманию читателя «карточка бизнес-процесса» содержит 10 разделов:

1. Владелец процесса.
2. Выходы и потребители процесса.
3. Входы и поставщики процесса.
4. События.
5. Цели и показатели по процессу.
6. Ограничения.
7. Технология выполнения процесса.
8. Ресурсы процесса.
9. Риски.
10. Графические схемы процесса.

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

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

В разделе 5 необходимо описать существующие цели и показатели для управления процессом. В соответствии с методическим подходом (см. статью «Процессное управление: границы применимости») показатели могут быть следующего вида:
• общие показатели;
• показатели выхода процесса;
• показатели выполнения процесса;
• показатели входа процесса;
• показатели ресурсов процесса.
Классификация показателей по указанным видам не является обязательной, но она полезна при выполнении анализа процесса со всех важных точек зрения.
Последние три столбца таблицы заполняются следующим образом – ставится либо «ДА», либо «Нет». Если в подразделении (компании) существует (в какой либо форме) документ, в котором сформулированы правила (методика) расчета показателя, в то в столбце «Наличие метода расчета» ставится «Да». Если для расчета показателя есть фактические данные, то в следующем столбце «Наличие данных» так же ставится «Да». Последний столбец — «Наличие интерфейса» — показывает, можно ли автоматически сформировать отчет по показателю в какой-либо программе (кроме MS Excel). Если показатели рассчитываются вручную в данном столбце ставится «Нет».

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

Раздел 7 служит для «ревизии» технологии выполнения процесса. В первую очередь необходимо определить состав внутренних нормативно-методических документов, которые регламентируют процесс. Затем нужно определить внешние НМД. Далее необходимо обратить отдельное внимание на нормативные документы, которые устанавливают требования к продуктам/услуга процесса со стороны потребителей («стандарты качества потребителей»). Это важно для понимания требований, предъявляемых потребителями.
Далее в таблице разделе 7 представлены четыре вида учета. Если определенный вид учета реализован при выполнении процесса, то в первом столбце ставится «Да». Во втором столбце приводится краткое текстовое описание существующей системы учета.
Учет операций означает, что мы учитываем все операции, выполняемые по ходу процесса. Если выполнение какой-то части или вида операций не учитывается, то в первый столбец ставим «НЕТ». Это означает, что технология выполнения процесса (а значит, и сам процесс) не полностью находится под нашим контролем. В зависимости от требований ГД, данный критерий может более или менее жестким. Например, можно считать, что учета операций нет, если в одном из подпроцессов процесса отсутствует учет 10% выполняемых операций. «Жесткость» критерия зависит от требовательности руководителя. В принципе, все операции всех подпроцессов процесса должны учитываться (т.е. учет операций должен быть на всех уровнях).
Учет очередей означает, что фиксируется размер очереди обрабатываемых объектов перед каждой операцией процесса. Наличие очереди перед операцией означает, что выполняющий эту операцию ресурс загружен (не простаивает). Учет очередей необходим для понимания узких мест при выполнении процесса и возможности его последующей оптимизации (как, впрочем, и учет операций).
Учет расхода ресурсов дает нам возможность анализировать затраты ресурсов, связанные с выполнением процесса и рассчитывать различные показатели эффективности.
Учет производительности необходим для понимания и анализа результатов выполнения процесса.
Корректное заполнение раздела 7 является очень важным для понимания текущего уровня управляемости процесса.

В разделе 8 следует представить информацию о ресурсах, которые необходимы для выполнения процесса. К ним относятся: персонал, оборудование, ИТ-инфраструктура, среда, измерительный инструмент. При заполнении таблицы указывается тип ресурса, количество, приводится список НМД, устанавливающих требования к данному ресурсу.

В разделе 9 описываются риски, связанные с выполнением процесса. Как и в Разделе 6, здесь представлено три вида рисков: в зоне контроля, в зоне влияния, во внешней среде (вне зоны нашего влияния).

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

Реализация карточки процесса в Business Studio и вывод информации в web через BS Portal

Работу по заполнению карточки процесса (паспорта процесса) можно автоматизировать. Удобно это сделать в специализированной среде моделирования процессов Business Studio 4.0. Фактически, при помощи Business Studio можно построить базу знаний компании по бизнес-процессам.
Рассмотрим пример настройки карточки процесса на условном примере. Схема процесса, для которой была создана карточка, представлена на рис. 8.

Для того, чтобы можно было занести необходимые данные по процессу в Business Studio, необходимо создать ряд новых атрибутов для процесса. Для этого были выполнены определенные доработки модели данных при помощи инструмента Meta Edit (входит в комплект поставки Business Studio в версии Enterprise). Например, был создан новый класс для описания ограничений процесса – см. рис. 9.

Дополнение структуры данных в Meta Edit и формирование необходимого для вывода карточки отчета заняло около 2-х рабочих дней.
После того, как все необходимые доработки были сделаны, мы заполнили соответствующие поля для тестового процесса (примеры представлены на рис. 9 и 10).

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

Каждый руководитель подразделения может заполнить карточки для своих процессов прямо в Business Studio. Информация фактически сразу будет доступна всем заинтересованным руководителям и сотрудникам через web-портал. Например, Генеральный директор может оперативно посмотреть, как идет заполнение карточек, правильно ли определены клиенты, ограничения и риски, насколько хорошо поставлен учет по процессу, определены ли показатели для управления и т.п.

Выводы

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

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

Август 2013 г.

В настоящее время в большинстве российских компаний регламентирующие документы принято утверждать и хранить в бумажной форме. При таком подходе к регламентации исключительно сложно оперативно поддерживать актуальность регламентной базы, вносить изменения в связанные между собой документы, уведомлять пользователей об изменениях. Бумажная гора становится все больше. Регламенты быстро устаревают. Сотрудники не исполняют требования и т.п. Использование систем электронного документооборота (СЭД) улучшает ситуацию, но не кардинально. Хранение скан-копий регламентов в виде pdf-файлов не решает задачи быстрой актуализации множества связанных между собой документов.
Если ли выход из данной ситуации? Какие возможности предоставляют современные программные продукты? Что ждет нас в будущем? В статье Владимира Репина предпринята попытка ответить на эти вопросы. Основная идея статьи – использование web-решения в рамках средства моделирования для создания базы знаний по бизнес-процессам в масштабах компании.

Бумажные горы

«Какова трудоемкость описания и регламентации одного бизнес-процесса»? Этот вполне конкретный вопрос часто задают руководители, отвечающие за организационное развитие. Им нужно знать, сколько бизнес-аналитиков привлечь. Очевидно, что нужен какой-то норматив для обоснования численности сотрудников.
Для определения трудоемкости удобно ввести понятие «нормо-процесса». Такой нормо-процесс представляет собой схему на листе формата А4, содержащую от 8 до 12 операций (иногда – больше). Графическое описание нормо-процесса, ввод нужных данных в систему моделирования (текстовое описание операций, описание входов/выходов и событий, формы документов, цели и показатели, методы контроля и т.п.) плюс время на согласование вместе составляют около 4-5 полных рабочих дней работы одного бизнес-аналитика.
Представим себе, что нам нужно полностью регламентировать процессы сбыта крупной компании (3000 человек). Потребуется описать, как минимум, 60-80 нормо-процессов. Такая работа потребует около 400 рабочих дней. Один бизнес-аналитик будет выполнять ее почти 2 года. Очевидно, что нужно выделить больший ресурс. Так обычно и поступают руководители компаний, которые поверили в регламентацию процессов и предприняли активные действия по ихразработке и внедрению. В отдел орг. развития приглашают 4-5 специалистов. Пять специалистов смогут детально описать и регламентировать весь сбыт примерно за 4 месяца. Будет создано большое количество регламентов, которые после утверждения будут доведены до сотрудников сбыта.
Но жизнь не стоит на месте. Внутри и вне компании постоянно все меняется. Необходимо вносить изменения в регламенты, которые уже созданы. Причем изменения в одном регламенте (процессе), как правило, затрагивают и многие другие. Так же возникают изменения в структурных нормативных документах: в должностных инструкциях, положениях о подразделениях. Для поддержки уже существующей регламентной базы необходимо взять еще 2-3 бизнес-аналитиков.Растет бумажная гора регламентов. Растет численность штата бизнес-аналитиков. Растут расходы, а эффективность бизнес-процессов не повышается.
В чем же причина данной проблемы? Что является узким местом? Если бы узким местом было количество бизнес-аналитиков, работающих в компании, то простым увеличением их числа проблема была бы решена. Но это не так. Массив информации по бизнес-процессам становится настолько сложным, что даже 10 человек не могут быстро и эффективно вносить в него изменения. Что же делать? Отказаться от описания и регламентации совсем?! Нет. Надо искать причины проблем в используемой в компании технологии работы с регламентирующими документами. Рассмотрим 3 существующих технологических подхода к регламентации, представленные в следующей таблице.

Технология I. Традиционное решение
Традиционное решение (I) предполагает использование среды моделирования только для описания процессов и выгрузки регламентирующих документов. Выгруженный в файл MS Word регламент может быть отправлен нескольким сотрудникам по e-mail для получения замечаний. Полученные замечания вносятся в среду моделирования. Затем выгружается следующая версия файла с регламентом и так далее. После внесения всех замечаний, распечатывается бумажная версия регламента. Далее на бумажном документе собирают согласующие подписи (т.е. в каком-то смысле дублируют при этом предыдущую работу по согласованию). Обратим внимание на тот факт, что сбор подписей на бумажных оригиналах нормативно-методических документов является неотъемлемой чертой корпоративной культуры большинства российских компаний. Далее документ утверждается и в бумажной форме помещается в архив нормативно-методических документов компании.

Технология II. Использование СЭД
При использовании СЭД ситуация очень похожа на предыдущую. Разница в том, что согласование проектов регламентов осуществляется в электронной форме в рамках СЭД (система электронного документооборота). Утверждается регламент так же в СЭД, в т.ч. с использованием ЭЦП (электронная цифровая подпись). Далее регламент в электронном виде помещается, например, в защищенное файловое хранилище. Естественно, на каждый регламент есть своя регистрационно-контрольная карточка, показывающая его историю (в т.ч. версии, дату утверждения и проч.). За счет наличия в СЭД развитых средств поиска сотрудники могут достаточно быстро находить нужные им регламенты. Однако, проблема быстрого изменения связанной группы нормативно-методических документов остается неизменной, то есть внедрение СЭД не позволят решить эту проблему.

Технология III. Web-портал
При использовании web-портала среды моделирования ситуация радикально меняется. Во-первых, нет необходимости формировать какие-либо регламентирующие документы в виде файлов MS Word. Вся информация о процессе представлена на web-портале, причем в интерактивном виде: графическая схема, ответственные сотрудники, требования к выполнению процесса, описание используемых ресурсов, цели и показатели и т.п. Все процессы связаны между собой – можно легко перемещаться от одного процесса к другому, просматривать требования к ресурсам и т.д. Согласование требований к процессу может осуществляться прямо на web-портале, причем с использованием ЭЦП (без необходимости установки СЭД).

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

Последнее утверждение в корне меняет подход к регламентации бизнес-процессов в компании. Зачем создавать горы бумажных или электронных (в файловых хранилищах СЭД) регламентов? У каждого сотрудника сегодня есть РС, планшет или смартфон. При необходимости, он обращается к web-порталу компании и практически мгновенно находит нужную ему информацию нормативно-методического характера. Такой подход является в достаточной степени революционным. Для его внедрения нужно твердое желание руководства компании. Кроме того, ограничивающим фактором являются возможности среды моделирования. В следующем разделе мы рассмотрим, какие возможности предлагают современные системы моделирования в области создания и использования web-портала.

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

Для сравнения мы выбрали лучшие среды моделирования бизнес-процессов: Business Studio 4.0, ARIS 9, Casewise и iGrafx 2013. В следующей таблице 2 представлены их функциональные характеристики с точки зрения работы web-портала.

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

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

Как видно из таблицы 2, современные среды моделирования очень похожи с точки зрения возможностей представления и работы с информацией на web-портале. Однако, есть и различия, которые могут сыграть свою роль при выборе соответствующей системы. Если руководством компании принято решение сделать ставку на безбумажную технологию регламентации процессов на web-портале, то нужно выбирать систему, обеспечивающую наиболее легкую и удобную работу сотрудников организации именно с web-порталом.
Ключевыми требованиями при выборе web-решения могут быть:
• простота и скорость размещения информации на web-портале;
• возможность автоматического обновления информации;
• возможность автоматической интеграции с другими базами данных (учетные системы, ERP) для автоматического вывода на портал информации по плановым и фактическим значениям показателей по бизнес-процессам;
• возможность согласования контента на web-портале с использованием ЭЦП.

Выводы

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

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

Июнь 2013 г.