Читать онлайн Свод знаний по управлению бизнес-процессами: BPM CBOK 3.0 бесплатно

Свод знаний по управлению бизнес-процессами: BPM CBOK 3.0

Научные редакторы Белайчук А. А., Елифёров В. Г.

Руководитель проекта М. Шалунова

Корректоры Н. Витько, Е. Чудинова

Компьютерная верстка К. Свищёв

Дизайн обложки Ю. Буга

В оформлении обложки использованы изображения из фотобанка shutterstock.com


© ABPMP, 2013

© Издание на русском языке, перевод, оформление. ООО «Альпина Паблишер», 2016


Все права защищены. Произведение предназначено исключительно для частного использования. Никакая часть электронного экземпляра данной книги не может быть воспроизведена в какой бы то ни было форме и какими бы то ни было средствами, включая размещение в сети Интернет и в корпоративных сетях, для публичного или коллективного использования без письменного разрешения владельца авторских прав. За нарушение авторских прав законодательством предусмотрена выплата компенсации правообладателя в размере до 5 млн. рублей (ст. 49 ЗОАП), а также уголовная ответственность в виде лишения свободы на срок до 6 лет (ст. 146 УК РФ).

Вступительное слово: Конни Мур (Connie Moore), вице-президент и главный аналитик, Forrester Research

Я очень горжусь тем, что Ассоциация ABPMP[1] попросила меня написать предисловие к третьей версии Свода знаний ABPMP CBOK[2]. Почему? Потому что работа по сертификации, начатая ABPMP, является одной из наиболее важных инициатив в области BPM[3]. Мы в Forrester Research знаем, что подготовленных профессионалов в области BPM явно недостаточно для покрытия растущего спроса на квалифицированных и опытных специалистов, а отсутствие опытных профессионалов сдерживает дальнейшее использование BPM в преобразовании и совершенствовании процессов.

На фоне того, как количество рабочих мест в Европе и в Америке непрерывно сокращается, а безработица, неполная занятость и стагнирующие зарплаты приобретают хронический характер, дефицит специалистов со знаниями в области ВРМ – не просто хорошая, а отличная новость для людей, ищущих работу или стремящихся сделать карьеру в бизнесе или в IТ. Причем речь идет не только о тех, кто хочет изучить BPM для повышения собственной квалификации – компании не просто заполняют вакансии, но и планируют в ближайшее десятилетие расширить программы обучения, чтобы обеспечить персоналом программы BPM-трансформаций. Это означает, что предприятия и государственные учреждения должны вплотную заняться проблемой адекватной подготовки большого числа знающих BPM-профессионалов, а профессиональные организации – предоставить желающим возможности развивать и совершенствовать свои навыки.

И это еще не все. Недавно аналитики Forrester Research пришли к выводу, что процессно-ориентированный бизнес будущего потребует от организаций переноса центра тяжести BPM на Большие процессы[4]. Под этим мы понимаем следующее.

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

Мы пошли дальше и сформулировали пять принципов мышления, основанного на Больших процессах.

Принцип 1: Преобразовывать, а не просто улучшать процессы.

Принцип 2: Давать рычаги управления клиентам.

Принцип 3: Делать процессы глобальными, стандартизованными и «человечными».

Принцип 4: Использовать большие данные[5].

Принцип 5: Удвоить ставку на процессные компетенции.

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

Забавно: сегодня утром, собравшись поработать над этим предисловием, я открыла электронную почту и в первом же письме (полученном из Великобритании) увидела:

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

Мой ответ:

«Я рекомендую ознакомиться с программой сертификации Ассоциации BPM-профессионалов ABPMP. У них есть свод знаний CBOK, который можно скачать с сайта или купить в бумажном виде, а затем пройти тест для получения сертификата. Я думаю, это очень хороший первый шаг».

Это отличная иллюстрация того, что люди по всему миру хотят – просто жаждут – получить материалы BPM CBOK.

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

Процессные «острова» внутри организаций. Работая с крупными компаниями и государственными учреждениями, я сталкивалась с множеством отдельных групп с глубокими процессными познаниями и с опытом в таких методологиях, как бережливое производство, шесть сигм[6] и др. Обычно они относятся к бизнес-подразделениям, иногда – к IТ. И удивительно, как часто эти превосходные специалисты в области повышения эффективности и совершенствования процессов понятия не имеют о системах BPMS и о дисциплине BPM. На мой взгляд, использовать весь этот процессный интеллект и всю эту мощь на то, чтобы улучшать или преобразовать процессы без использования программного обеспечения, – это ошибка. Потому что тяжело на постоянной основе менять процессы, не отражая изменения в программном обеспечении, с помощью которого люди делают свою работу. BPM-профессионалы должны видеть и оборотную сторону медали – программное обеспечение для управления процессами.

Нишевые применения технологий BPM. Аналогичным образом, в изолированных областях внутри организации – обычно в IТ – можно найти специалистов по программному обеспечению BPM. Эти специалисты (а много их не бывает) понимают, как работает программное обеспечение BPM, и рассматривают его как часть платформы разработки приложений нового поколения, реализующих бизнес-процессы. Обычно у таких специалистов базовое образование – программирование. Они разбираются в технологических аспектах бизнес-правил, обработки событий, анализа, в социальных сетях и мобильных технологиях, и BPMS они воспринимают как еще одну технологию, которую надо освоить. Но хотя разработчики приложений и архитекторы могут быть знакомы с концепцией бережливого производства (воспринимая ее со стороны гибкой разработки)[7], им недостает знаний основных методологий дисциплины BPM. Они должны изучить и другую сторону медали – ту, которую видят эксперты по бережливому производству и шести сигмам.

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

Сейчас интересное время для тех, кто работает в области BPM. Много новых должностей на высшем уровне появляется уже сейчас, а дальше, по мере признания концепции Больших процессов и роста числа процессно-ориентированных компаний, их будет появляться еще больше. Подготовка людей на эти должности – это то, что сейчас нужно, это отличная перспектива, и это хорошо для экономики. И я воодушевлена тем, как ABРMP справляется с задачей.

Предисловие президента ABPMP

BPM – это быстро развивающаяся дисциплина, которая меняет взгляд бизнеса на управление процессами и на роль автоматизации в управлении процессами и потоками работ внутри и между предприятиями. Для многих из нас эта развивающаяся дисциплина в совокупности с автоматизацией стала революцией в реализации быстрых изменений и инновационной возможностью оптимизировать работу и взаимодействие с клиентами, поставщиками и сотрудниками. Методы и подходы BPM дают возможность достичь нового уровня в операционном менеджменте, в мониторинге и измерении эффективности на всех уровнях компании. У тех, кто осваивает эти подходы, методы и средства, меняется взгляд на окружение: новая парадигма, основанная на быстрых итерационных изменениях, заставляет по-новому смотреть на производительность и результативность бизнес-процессов. Сейчас BPM дорос до поддержки функций масштаба предприятия, позволяя управлять ими в рамках концепции постоянного совершенствования. Эта новая способность поддерживать быстрые изменения стимулирует новый уровень взаимодействия между бизнесом и IТ-профессионалами, которым необходимо понимать стратегический эффект внедряемых изменений.

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

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

В подобных книгах очень ценен опыт авторов и рецензентов. Она представляет собой результат совместных усилий множества авторов, рецензентов отдельных глав и книги в целом, каждый из которых является опытным практиком. Большинство из них являются сертифицированными BPM-профессионалами (CBPP®)[8]. Каждый из них день за днем проводит в окопах BPM.

Кроме того, все авторы – люди дела. На любом уровне, от стратегии до сервис-ориентированной архитектуры, они работают засучив рукава. Это определяет особую точку зрения: CBOK®– не компиляция того, что автор почерпнул из общения с другими людьми, и не изложение частного опыта, а практическое, докапывающееся до глубин обсуждение широкого круга вопросов BPM.

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

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

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

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

От имени ABPMP я благодарю вас за интерес к этому исследованию BPM. Присоединяйтесь к нам в качестве члена и делитесь опытом с другими на мероприятиях отделений ABPMP[9]. Я думаю, вы получите удовольствие от подобных обсуждений с коллегами.

Тони Бенедикт (Tony Benedict), CBPP Президент ABPMP International

Об этой книге
История написания версии 3 CBOK®

Проект написания новой версии ABPMP CBOK® стартовал в конце 2010 года. На первом шаге были изучены комментарии читателей второй версии, к которым добавились комментарии и предложения европейских и бразильских членов ассоциации. В конце 2011 года было принято решение полностью переписать CBOK, поскольку отрасль BPM/BPMS изменилась настолько сильно, что просто добавлять информацию признали нецелесообразным.

Проект переписывания CBOK® возглавил Дэн Моррис (Dan Morris). Вся работа была разделена на три подпроекта: написание глав, рецензирование глав, комплексное рецензирование CBOK®. В завершение текст прошел профессиональную редактуру на предмет грамматических и орфографических ошибок.

Подпроект написания глав возглавил Раджу Саксена (Raju Saxena) – он тот, кто не давал этой работе остановиться. Рецензирование глав самоотверженно возглавил Оуэн Кроули (Owen Crowley). Комплексное рецензирование и работу с комментариями также возглавил Дэн Моррис. Тони Бенедикт (Tony Benedict) руководил окончательной редактурой текстов и иллюстраций.

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

Руководящие принципы

Совет директоров ABPMP рекомендовал авторам и рецензентам руководствоваться следующими принципами.

• Ориентироваться на практиков бизнеса.

• Способствовать единому пониманию BPM.

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

• Содействовать единообразному применению языка BPM/BPMS.

• Добиваться, чтобы текст был легко читаемым, основательным и глубоким.

• Давать ссылки на смежные дисциплины (например, шесть сигм, бережливое производство и т. д.).

• Содержать общепринятые методы.

• Быть нейтральным по отношению к вендорам и методологиям.

• Служить руководством, а не инструкцией.

• Охватывать современные концепции.

Содержание

В каждой главе CBOK® рассматривается отдельная тема в рамках BPM, и каждую главу можно изучать независимо. Между главами нет сквозной нити повествования, читателям рекомендуется использовать CBOK® как руководство. В нем обстоятельно рассматриваются темы, в совокупности дающие широкое представление о BPM, BPMS, трансформации и изменении бизнеса.

CBOK® включает следующие главы.


Версия 3 CBOK® и ABPMP CBPP™

Этот перечень тем перекликается с сертификационными тестами ABPMP CBPP™[10]. Однако следует отметить, что экзамен CBPP™ основан не только на CBOK®, а ключевым требованием сертификации является наличие практического опыта.

Авторы

Авторы CBOK® набирались исходя из профессионального опыта, подтвержденного мероприятиями ABPMP, отзывами коллег, работой в комитетах ABPMP, публикациями, выступлениями и авторитетом в отрасли. Все авторы являются сертифицированными BPM-профессионалами (CBPP).



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

Вступления к главам

Комитету CBOK® удалось привлечь к написанию вступительных слов известных экспертов в области BPM. Они поделились своим видением того, как в будущем могут развиваться те или иные аспекты BPM, и тем самым повысили ценность соответствующих глав.


ABPMP CBOK® и качество

Качество оставалось главной заботой на протяжении всего процесса написания CBOK®. В новой версии мы стремились обновить содержание, включив новые идеи, изменения восприятия BPM рынком и изменения в технологиях BPMS. Для этого ABPMP воспользовалась подходом, основанным на проверках и балансе.

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

Комитетом рецензентов руководил Оуэн Кроули (Owen Crowley), ему помогали Дэн Моррис (Dan Morris) и Габриэль Филд (Gabrielle Field). Благодаря Оуэну качество оставалось в центре внимания рецензентов на протяжении всех шести месяцев, пока длилась эта работа. Члены команды рецензентов указаны ниже.


Комплексная проверка качества CBOK®

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

Рецензенты итогового варианта версии 3 CBOK® перечислены ниже.


Завершение работы над CBOK®

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

Ссылки на производителей и поставщиков

Множество поставщиков и исследовательских фирм разработали референтные модели и применяют собственную терминологию в области BPM и BPMS. ABPMP не делает выбор в пользу какой-то определенной модели. Вместо этого мы используем множество моделей, чтобы познакомить читателя со всем спектром и показать, что выбор конкретной модели не столь важен. Что действительно важно для компании, так это выбрать конкретную модель и последовательно ее придерживаться. Или осознать, что в компании уже используется несколько моделей, и действовать в соответствии с этим.

Будущие версии CBOK®

Поскольку BPM и BPMS быстро развиваются, любой текст будет нуждаться в непрерывном пересмотре и обновлении. С этой целью ABPMP будет выпускать регулярные обновления, которые будут доступны на сайте ассоциации ABPMP ее членам и тем, кто приобрел годовую подписку на CBOK®.

Мы отдаем себе отчет, что, несмотря на все усилия, которые мы предприняли для выпуска качественного продукта, кто-то может захотеть расширить перечень тем или рассмотреть какие-то вопросы более глубоко. Таких читателей мы просим направлять свои пожелания и предложения на электронный адрес [email protected]

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

Комментарии

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

Предисловие
Определение профессионала управления бизнес-процессами

Следующий текст является выдержкой из статьи экс-президента ABPMP Бретта Чамплина (Brett Champlin) для BPM Strategies (www.bpmstrategy.com), октябрь 2006 года.

На нескольких конференциях BPM я задавал аудитории из нескольких сотен участников вопрос: «Кто здесь представляет IT?» Обычно поднималось 30–45 % рук. Следующий вопрос: «Кто представляет бизнес?» – еще 30–45 %. И, наконец: «Кто здесь, как я, находится где-то посередине?» Руки поднимала почти вся группа. Это показательно. Многие из нас, кто занимается управлением процессами, проектированием процессов, анализом эффективности процессов, автоматизацией процессов и т. д., находятся в замешательстве. Кто мы – бизнес-профессионалы, которые должны знать, как воспользоваться IТ для управления процессами, или IТ-профессионалы, которые должны разбираться в бизнесе, чтобы в полной мере использовать возможности новых IT-решений?

BPM – это одновременно и управленческая дисциплина, и программное обеспечение для управления процессами. Информационные технологии для управления потоками работ, интеграции корпоративных приложений (EAI)[11], управления документами и контентом, бизнес-правилами и эффективностью и другие были собраны воедино, чтобы обеспечить управление, основанное на процессном подходе. Несколько лет назад поставщики ПО BPM были нацелены на исполняемые процессы, сегодня они предлагают системы BPMS с полным набором функций и возможностей, необходимых процессным менеджерам, аналитикам и IТ-разработчикам.

Последние исследования подтверждают, что BPM быстро становится доминирующей парадигмой менеджмента XXI века. В апреле 2005 года исследование BPMG показало, что «…BPM приобрел значительное признание в качестве основного средства управления бизнесом…» и «…более 80 % ведущих международных организаций активно реализуют программы BPM, и многие из них делают это в глобальном масштабе». Бенчмаркинг, проведенный APQC в марте 2005 г., показал, что «BPM – это то, как ведут свой бизнес передовые организации». В этом исследовании также изучались стратегии, подходы, средства и методы (включая процессные фреймворки и модели процессной зрелости), проверенные на опыте процессно-ориентированных организаций мирового уровня, и был сделан вывод, что хотя «сами по себе информационные технологии не являются управлением бизнес-процессами, но значительная часть потенциала BPM-инициатив не может быть реализована без поддержки мощных, гибких и дружественных по отношению к пользователю IТ-решений».

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

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

Судя по всему, компаний, в которых движущей силой BPM является IТ-подразделение, столько же, сколько таких, в которых программу BPM двигают вперед основные бизнес-подразделения. Аналогичным образом, похоже, что есть два основных подхода: проектно-ориентированный и тот, в котором BPM рассматривается как непрерывные усилия по совершенствованию и трансформации. Эти различные модели порождают роли с разными названиями и наборами обязанностей, при том что все они нацелены на процессное управление.

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

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

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

Мы видим множество успешных моделей внедрения BPM, но все их объединяет одно: множество новых ролей и обязанностей. Эта новая группа профессионалов управления бизнес-процессами необходима бизнесу XXI века. Судя по членам ABPMP, как правило, это люди высокообразованные (67 % имеют степень бакалавра и выше) и с большим опытом работы (в среднем 9,9 года) в области совершенствования и реорганизации процессов.

Некоторые самые распространенные роли:

• процессный аналитик;

• процессный инженер;

• процессный архитектор;

• менеджер процесса;

• владелец процесса;

• консультант по процессам;

• бизнес-аналитик;

• системный аналитик;

• менеджер или директор программ повышения эффективности;

• менеджер или директор по процессным инновациям.


Этот перечень должностей вместе с производными от них охватывает большинство новых ролей в процессно-ориентированных организациях. Вне зависимости от названия и организационной структуры, в основном они отвечают за одни и те же виды деятельности: моделирование процессов, анализ процессов, проектирование процессов, изменение процессов и трансформацию, внедрение процессов, мониторинг и контроль процессов, повышение эффективности процессов. Некоторые могут входить в штат IТ, другие – относиться к бизнес-подразделениям. Многие организации создают кросс-дисциплинарные группы, объединяющие знания IТ и бизнеса, или подбирают в них людей с опытом работы и в IТ, и в бизнесе, чтобы сломать границы между традиционными областями знаний. Многие организации убедились в том, что успешной стратегией в области BPM является объединение в одной команде консультантов как людей, обладающих общими познаниями, с практиками, хорошо знающими специфику бизнеса.

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

Миссия Ассоциации BPM-профессионалов ABPMP и Европейской ассоциации EABPMP – популяризировать практику BPM, формировать Свод знаний (СВОК) и содействовать развитию профессионалов, работающих в данной области. Региональные отделения АВРМР и ЕАВРМР регулярно проводят мероприятия, посвященные отдельным темам в рамках BPM или разбору примеров внедрения, тем самым предоставляя своим членам недорогую программу непрерывного обучения. В ассоциации есть комитет по образованию, который занимается разработкой BPM СВОК. Вслед за этим мы планируем создать рекомендуемые учебные планы для учебных заведений и курсов переподготовки. Мы намерены разработать набор критериев для оценки учебных программ и процедуру официальной сертификации поставщиков образовательных услуг. Мы также подготовим программу сертификации профессионалов в области управления бизнес-процессами[12].

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

Об Ассоциации профессионалов управления бизнес-процессами (ABPMP)

Основная информация об ABPMP

Ассоциация BPM-профессионалов (ABPMP)[13] – это некоммерческая профессиональная организация, нацеленная на продвижение концепций и методов BPM.

У ABPMP есть отделения в нескольких регионах США, и новые отделения создаются в США и в мире. Тем, кто хотел бы принять участие в работе ABPMP, но у кого поблизости нет отделения ABPMP, мы советуем рассмотреть вопрос о создании местного отделения. Члены, не ассоциированные с действующим отделением, приписываются к отделению Members At Large, у которого есть собственное выборное руководство и которое участвует в деятельности ABPMP наравне с остальными отделениями[14].

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

ABPMP связан партнерскими отношениями с другими профессиональными организациями, в частности с Европейской ассоциацией управления бизнес-процессами (EABPM), которая поддерживает сертификацию и версии BPM CBOK® на французском и немецком языках.

За подробной информацией об ассоциациях ABPMP и EABPMP, пожалуйста, обращайтесь на сайты www.abpmp.org и www.eabpmp.org[15].

Миссия, ценности и деятельность

Ассоциация BPM-профессионалов (ABPMP) – это некоммерческая, независимая от поставщиков программных продуктов, профессиональная организация, нацеленная на продвижение и развитие концепций и методов BPM. ABPMP работает для практиков и под руководством практиков.

Концепция

Концепция Ассоциации BPM-профессионалов заключается в том, чтобы:

• быть центром объединения практиков управления бизнес-процессами;

• стать ведущим профессиональным сообществом для профессионалов управления бизнес-процессами;

• давать определения дисциплине и практике управления бизнес-процессами;

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

Миссия

Миссия ABPMP заключается в том, чтобы:

• участвовать в деятельности, способствующей продвижению опыта управления бизнес-процессами;

• развивать Свод знаний по BPM (CBOK);

• вносить свой вклад в продвижение и развитие навыков профессионалов, работающих в области ВРМ.

Деятельность

ABPMP проводит образовательные и общественные мероприятия для непрерывного обучения и распространения передовых методов, новых идей и опыта между своими членами – коллегами по профессии. Информацию о таких мероприятиях можно найти на сайте ассоциации www.abpmp.org[16].

Этический кодекс

Будучи приверженной самым высоким стандартам профессиональной этики, ABPMP считает, что профессионалы BPM обязаны:

• быть этичными в профессиональной деятельности и в личной жизни;

• признавать этический стандарт, основанный на честности, справедливости и вежливости, в качестве принципов, направляющих образ жизни и поведение;

• соглашаться с обязательством вести профессиональную деятельность в соответствии с настоящим этическим кодексом и стандартами поведения.

Каждый член ABPMP обязан принять и подписать этический кодекс и стандарт профессионального поведения, изложенные ниже.

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

Я согласен с тем, что:

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

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

• я имею обязанности перед другими членами ассоциации и коллегами по профессии. Поэтому я буду отстаивать высокие идеалы ABPMP, намеченные уставом ассоциации. Кроме того, я буду сотрудничать с другими членами ассоциации, неизменно относясь к ним честно и с уважением;

• я принимаю на себя эти обязательства и как личность, и как член ассоциации. Я буду активно исполнять эти обязательства, посвятив себя этой цели.

Стандарты поведения

Настоящие стандарты расширяют и подкрепляют Этический кодекс специфическими нормами поведения. Они определяют не цели, к которым надо стремиться, а правила, которые ни один профессионал не должен нарушать. Перечисленные ниже нормы определяют принципы профессии.

В знак признания моих профессиональных обязательств я должен:

• избегать конфликтов интересов и информировать о потенциальных конфликтах;

• защищать приватность и конфиденциальность любой доверяемой мне информации;

• принимать полную ответственность за выполняемую мною работу;

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

• поддерживать, уважать и соблюдать местное, национальное и международное законодательство;

• прилагать все усилия к тому, чтобы обладать самыми актуальными знаниями и опытом тогда, когда они могут понадобиться;

• делиться знаниями с другими и делать все возможное для предоставления объективной и основанной на фактах информации;

• во всех профессиональных контактах быть справедливым, честным и объективным;

• сотрудничать с другими для достижения понимания и для выявления проблем;

• всегда защищать законные интересы моего работодателя и моих клиентов;

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

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

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

• не извлекать выгоды из недостатка знаний или опыта у окружающих;

• не использовать и не ставить себе в заслугу чужую работу без явного подтверждения и разрешения;

• не злоупотреблять доверенной мне властью.

Контакты

Качество информации является нашей постоянной заботой, и мы приложили усилия к тому, чтобы каждая часть CBOK прошла проверку через рецензирование ведущими BPM-профессионалами. Просим вас направлять комментарии к этой версии CBOK в адрес ABPMP. Контактную информацию вы найдете на сайте www.abpmp.org.

Совет директоров ABPMP International

О русской версии CBOK

Данная книга является переводом англоязычного BPM CBOK версии 3.0, выполненным Ассоциацией профессионалов управления бизнес-процессами (АПУБП) – российским отделением (Russian Chapter) международной Association of Business Process Professionals (ABPMP).

Работа над русской версией CBOK была начата осенью 2013 года (практически сразу после выхода английской) и проходила в несколько стадий.

В первую очередь был переведен глоссарий, чтобы в дальнейшей работе придерживаться единой терминологии. В работе над глоссарием приняли участие:

• Белайчук Анатолий Анатольевич, евангелист BPM, Comindware Inc, к.т.н., CBPP;

• Вагнер Юлия Борисовна, к.э.н., директор по развитию BPM, ООО «Бизнес-Консоль»;

• Елифёров Виталий Геннадиевич, консультант по управлению, автор книг и статей по процессному подходу;

• Кузин Вадим Евгеньевич, начальник отдела комплексной автоматизации, HПК «Уралвагонзавод»;

• Михеев Андрей Геннадьевич, преподаватель МЭСИ, НИТУ МИСиС; бизнес-аналитик, Консалтинговая группа РУНА;

• Сорокин Александр Сергеевич, зам. директора департамента стратегического планирования и управления изменениями, «Маревен Фуд Сэнтрал», к.э.н., MBA, PMP;

• Федоров Игорь Григорьевич, к.т.н., профессор, МЭСИ.


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

Затем команда переводчиков перевела весь текст, разделившись по главам. В этой работе приняли участие:

• Арзуманян Максим Юрьевич, ассистент кафедры ИТЭ, СПбГУТ им. проф. М. А. Бонч-Бруевича (глава 10);

• Архипов Игорь Константинович, руководитель группы методологии поддержки и сервисов, ЗАО «Лаборатория Касперского», CBAP (главы 1, 3);

• Барсукова Валентина Александровна, бизнес-аналитик (глава 9);

• Белайчук Анатолий Анатольевич, евангелист BPM, Comindware Inc, к.т.н., CBPP (главы 2, 10);

• Бутыркин Вячеслав Алексеевич (глава 10);

• Вагнер Юлия Борисовна, к.э.н., директор по развитию BPM, ООО «Бизнес-Консоль» (глава 7);

• Громыко Алексей Николаевич, директор по развитию ООО «Бюро проектного менеджмента», CPM, DipFM (глава 6);

• Датский Игорь Алексеевич, ведущий бизнес-аналитик, Digital Design (введение);

• Дементьев Андрей Владимирович, к.т.н., MBA (глава 4);

• Елифёров Виталий Геннадиевич, консультант по управлению, автор книг и статей по процессному подходу (глава 9);

• Клычихина Олеся Васильевна, директор проектного офиса, ЗАО «Коминфо Консалтинг» (глава 5);

• Коптелов Андрей Константинович, директор департамента по оптимизации бизнес-процессов, Университет «СИНЕРГИЯ»; преподаватель ВШБИ НИУ ВШЭ (глава 8);

• Котиков Александр Эдуардович, архитектор IТ, ООО «Тойота Мотор»;

• Котов Денис Геннадьевич, технический директор, «Импелтех» (введение);

• Литун Виктория Валерьевна, директор по маркетингу, Концерн Р-Про (глава 4);

• Машков Илья Владимирович, директор практики «Метасоник», ООО «Логика ВРМ» (глава 8);

• Полуэктов Николай Евгеньевич, начальник управления, ОАО «Альфа-Банк», PMP (глава 8);

• Пранцузов Сергей Иванович, бизнес-аналитик, ООО «Санг» (глава 6);

• Рашевский Ярослав Игоревич, руководитель проектов, ЗАО «Сфера» (глава 5);

• Сорокин Александр Сергеевич, зам. директора департамента стратегического планирования и управления изменениями, «Маревен Фуд Сэнтрал», к.э.н., MBA, PMP (главы 3, 7);

• Сорокина Наталия Викторовна, бизнес-альянс-менеджер, Horus software GmbH (глава 10);

• Смирнова Юлия Викторовна, бизнес-аналитик, ООО «НЕОЛАНТ Запад» (глава 4);

• Стебельский Евгений Владимирович, инженер-аналитик, Сбербанк России (главы 3, 10);

• Юдин Михаил Юрьевич, финансовый директор, Донецкая фармацевтическая компания (глава 5).


Работу по редактированию взяли на себя Анатолий Белайчук и Виталий Елифёров.

Ряд ценных замечаний к тексту, прошедшему редактуру, дали:

• Томорадзе Илья Владимирович, директор программы Executive MBA ВШКУ РАНХиГС, к.э.н.;

• Федоров Игорь Григорьевич, к.т.н., профессор, МЭСИ.


Окончательное вычитывание всего текста выполнили:

• Вагнер Юлия Борисовна, к.э.н., директор по развитию BPM, ООО «Бизнес-Консоль»;

• Елифёров Виталий Геннадиевич, консультант по управлению, автор книг и статей по процессноиу подходу.


Вёрстка текста была выполнена Анатолием Белайчуком.

Вся работа была завершена в январе 2015 года.

Все участники проекта выполняли работу на некоммерческой основе, то есть бесплатно.

Отличия русской и английской версий

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

В ходе редактирования мы постарались сделать язык более простым и «человеческим». Там, где приходилось выбирать – следовать точно исходному тексту, рискуя при этом, что он останется непонятым, или отступить от «буквы», но сделать его более понятным читателю, мы шли по второму пути.

В ходе перевода были исправлены десятки опечаток и явных ошибок, обнаруженных в оригинальной версии CBOK. ABPMP International планирует внести эти исправления в версию 3.1.

Существенные исправления были внесены только в главу 10 «Технологии BPM», где часть текста была переписана, а часть – исключена. В частности, был исключен раздел, посвященный SOAP, как слишком технический по содержанию в контексте BPM.

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

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

Планы на будущее и обратная связь

Эта книга представляет собой третье издание BPM CBOK и первое, переведенное на русский язык. Поскольку работа над оригинальной английской версией была начата еще в 2012 году, то неизбежно к моменту публикации что-то устарело, а какие-то новые веяния не нашли отражения.

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

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

Со всеми комментариями и предложениями обращайтесь на сайт Ассоциации профессионалов управления бизнес-процессами (ABPMP Russian Chapter): abpmp.org.ru.

Предисловие к русской версии

Уважаемый читатель! Вы держите в руках не справочник, не учебник и не стандарт. Хотя что-то от всего перечисленного в этой книге есть, но все же это другой, отдельный жанр – «свод знаний».

В принципе жанр это известный – свои своды знаний есть, например, у бизнес-аналитиков (BABOK, Business Analysis Body of Knowledge) и у руководителей проектов (PMBOK, Process Management Body of Knowledge). Но все же во избежание недоразумений уточним, что эта книга:

• не дает ответы на все вопросы (как справочник);

• не излагает последовательно и исчерпывающе какую-то теорию (как учебник);

• не предписывает определенный порядок действий, конкретные средства или методы (как стандарт).


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

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

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

Про бизнес-процессы написано много книг, но BPM CBOK занимает среди них уникальное место.

1. Полнота. Профессионал превосходит дилетанта, пусть даже талантливого, поскольку уверен: в его подготовке нет «белых пятен». Пускай он многое успел забыть со времен учебы, но он знает, куда при необходимости можно заглянуть, чтобы вспомнить. У дилетанта же блестящие знания в одной области могут соседствовать с зияющими пробелами в других. Изучив CBOK, вы можете быть уверены, что в области BPM у вас таких пробелов нет.

2. Апробированность. ABPMP – организация, состоящая из практиков и ориентированная на практиков. Все авторы, принявшие участие в написании CBOK, опираются на собственный опыт управления бизнесом через процессы и управления самими бизнес-процессами. Здесь нет красивых, но неработающих теорий и методов. У каждого метода, разумеется, есть своя область применения, но все они проверены на практике.

3. Мейнстрим. Среди авторов CBOK – очень уважаемые в мире BPM имена и представители очень уважаемых организаций. И то, что все они смогли прийти к консенсусу и поставили свои имена под этой книгой, дорогого стоит! Не может быть науки без сложившегося «мейнстрима» – системы понятий и набора методов, признаваемых широким кругом специалистов, – иначе это не научная школа, а секта со своим гуру и его откровениями. CBOK является изложением мейнстрима BPM. Является ли этот мейнстрим чем-то раз и навсегда заданным? Разумеется, нет! Можно ли от него отступать? Разумеется, да! BPM был и остается живой, развивающейся дисциплиной. Но не в ваших интересах отступать от мейнстрима, не отдавая себе отчета, в чем он заключается и по каким причинам вы от него отступаете.

4. Беспристрастность. ABPMP – организация, в уставе которой прописана независимость от компаний – поставщиков программного обеспечения и услуг. Эта же политика дистанцирования от конкретных программных продуктов и фирменных методологий проводится и в CBOK. Да, авторы пристрастны в своей приверженности концепции BPM в целом, но здесь вам не будут неявно под видом идей «продавать» софт или услуги, как это случается с источниками информации, аффилированными с коммерческими компаниями.


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

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

Прямой смысл сверяться с CBOK есть при планировании инициатив в области процессного управления, при выборе программного обеспечения и при подборе специалистов. CBOK является основой сертификации специалистов по бизнес-процессам (Certified Business Process Professionals, CBPP), которую проводит ABPMP.

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

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

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

Смысл CBOK не в том, чтобы ввести единомыслие, – отнюдь нет. Идея заключается в том, чтобы дать некую общую для всех отправную точку. Чтобы можно было работать «по отклонениям» – здесь и здесь мы воспользуемся таким-то подходом из рекомендованных в CBOK, а вот здесь будем развивать свой собственный, так как стандартные нас не устраивают по таким-то и таким-то причинам…

BPM был и останется делом творческим и благодаря этому очень увлекательным для специалистов, которые в нем работают. Но, чтобы он получил по-настоящему широкое признание со стороны бизнеса, его надо сделать чуть более скучным – сформировать общую доктрину, или мейнстрим. И на основе его сформировать профессии: специалист по управлению бизнес-процессами, процессный архитектор и т. д. Что, собственно, и является миссией ABPMP.

Только тогда у заказчика появится ощущение надежности того, что он делает в области BPM. На основе CBOK он сможет сформировать обоснованную стратегию и перспективный план и следовать ему, привлекая специалистов с понятной квалификацией на понятные роли. И тогда в выигрыше будут все.

Русская терминология BPM

Хотя процессная дисциплина, развиваясь и расширяясь, насчитывает десятки лет, единства терминологии в ней не наблюдается; BPM был и остается «движущейся мишенью». Это относится и к английской терминологии, и в еще большей степени – к русской.

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

Как всегда в вопросах терминологии, изложенная ниже трактовка не является безусловной, и вы вполне можете придерживаться альтернативной. Но для понимания BPM CBOK настоящий раздел, без преувеличения, является ключевым – если вы не усвоите, какой смысл вкладывается в базовые термины, вопросы будут возникать на каждом шагу.

«Процессов» или «процессный»?

Трудности перевода BPM CBOK начинаются не с первых страниц и не с первых фраз, а с первых букв: BPM, Business Process Management. Оставим на время в стороне «business» – как перевести «process management»?

«Process» может быть и существительным, и тогда process management надо переводить как «управление процессами», и прилагательным – тогда получится «процессное управление».

Сложившееся в русском языке словоупотребление противоречиво: process management обычно переводят как «процессное управление», а business process management – как «управление бизнес-процессами».

Если вникнуть в предмет, то выяснится, что BPM – это «двухэтажное здание».

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

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

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


Получается, что двойственность английского словосочетания «process management» – это как раз то, что нужно: одновременно и «процессное управление», и «управление бизнес-процессом».

Русским же читателям надо принять это двуединство терминологии: говорим «процессное управление» – держим в уме «управление бизнес-процессами», и наоборот.

Идем дальше, смотрим названия глав CBOK:

• Process Modeling – Моделирование процессов;

• Process Analysis – Анализ процессов;

• Process Design – Проектирование процессов;

• Process Performance Management – Управление эффективностью процессов.


Но при этом:

• Process Transformation – Процессная трансформация;

• Process Organization – Процессная организация.


Почему такое расхождение? Потому что в главе 7 речь идет не о трансформации процессов как самоцели, а о трансформации бизнеса через трансформацию процессов. Опять-таки надо помнить: говорим «трансформация», подразумеваем «трансформация бизнеса». (Аналогично ставший модным в последнее время термин digital transformation означает «цифровую трансформацию» и тоже – бизнеса, который подразумевается.) И, конечно же, в главе 10 речь идет не об «организации процесса», а об организационных структурах, поддерживающих процессное управление.

«Бизнес» или «дело»

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

Из-за этого словосочетание «бизнес-процесс», например, в государственных учреждениях в России вызывает мгновенное отторжение: «У нас бизнеса нет!» Эта проблема не возникла бы, если бы мы переводили «business processes» как «деловые процессы», но сложившееся словоупотребление уже не изменить.

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

«Функция» и «кросс-функциональный процесс»

«Функция» – термин, регулярно вызывающий непонимание и споры.

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

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

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

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

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

«Сквозной процесс» (end-to-end process)

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

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

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

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

Предприятие (enterprise)

Enterprise на русский язык обычно переводят как «предприятие» или «компания». Оба варианта не вполне удачны: «предприятие» у некоторых ассоциируется с коммерческой инициативой (бизнес-проектом), у других – с заводом. «Компания» ассоциируется с юридическим лицом. Enterprise systems принято переводить как «корпоративные системы», подчеркивая тем самым масштаб.

В CBOK enterprise всюду переведен как «предприятие», под которым понимается хозяйствующий субъект (не обязательно промышленное предприятие).

«Ценность» (value), «стоимость» (cost) и «потребитель» (consumer)

О том, что такое ценность, что такое потребитель и что такое ценность для потребителя, можно написать отдельную книгу. Более того, такие книги написаны!

Грубое, но зато простое определение: ценность – это то, за что потребитель готов заплатить деньги (пусть потенциально). Соответственно, потребитель – это тот, кто в принципе готов заплатить деньги за вашу продукцию и услугу.

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

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

Допустимый альтернативный вариант перевода термина value – «потребительская стоимость».

С другой стороны, value в словосочетании value-added-tax (VAT) относится не к ценности, а к стоимости, и совершенно правильно его переводят как «налог на добавленную стоимость» (НДС).

Словосочетание value chain иногда переводят как «цепочка создания стоимости» – это грубая ошибка, только «ценности»!

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

«Производительность» (efficiency), «результативность» (effectiveness) и «эффективность» (performance)

В англоязычной литературе по менеджменту стандартной является дихотомия efficiency/effectiveness, идущая от Питера Друкера (Peter F. Drucker):

• efficiency is doing things right – «делать вещи правильно». Здесь речь идет об оценке процесса изнутри – насколько точно мы следуем установленным регламентам, насколько экономно распоряжаемся имеющимися ресурсами. В этой книге мы перевели этот термин как «производительность»;

• effectiveness is doing the right things – «делать правильные вещи». Здесь речь идет об оценке процесса извне – с точки зрения потребителя. В этой книге всюду переводится как «результативность».


Эти понятия на первый взгляд могут показаться близкими, но Друкер подчеркивает различие: «нет ничего более бесполезного, чем делать максимально производительно то, что не следует делать вовсе».

Там же, где речь идет о показателях процесса во всем их многообразии, без разделения на efficiency/effectiveness, в CBOK используется термин «performance», который в этой книге переводится как «эффективность».

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

Способность (capability)

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

Так что это – процесс, компетенция, ресурсы, средства? Если коротко – все из перечисленного, но на более высоком уровне абстракции.

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

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

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

Следует различать способность (capability) и возможность (opportunity). Возможность – это то, что нам предоставляет бизнес-окружение, способность – это то, что мы развиваем у себя в компании. Например, в ответ на открывшуюся возможность или предвидя новые возможности – такие как появление новых рынков или новых потребностей у заказчиков.

Адаптивный/маневренный (agile)

В IТ и, в частности, в разработке программного обеспечения термин agile широко используется больше 10 лет, и на русский язык agile development переводится как «гибкая разработка». Но при переводе CBOK мы решили отойти от этой традиции.

Во-первых, этот перевод неточен, ведь «гибкий» – это flexible, а не agile. Agility – это способность быстро реагировать и/или адаптироваться под изменяющиеся условия.

Во-вторых, хотя словосочетание agile development хорошо известно в IТ, но термин business agility является новым. Это дает возможность ввести в обращение более удачный вариант перевода.

В зависимости от контекста в CBOK используются два варианта перевода agile: «адаптивный» или «маневренный».

Регулирование (governance)

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

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

CBOK оперирует терминами «BPM governance», «BPMS governance», «SOA governance». Мы решили вместо «управления» в русской версии CBOK использовать термин «регулирование», а «governance body» переводить как «орган регулирования» или «регулятор». (Примерами такого органа являются процессный офис и центр компетенции BPM.)

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

Пример регулирования применительно к BPMS – формально закрепленный порядок утверждения и ввода в действие новой версии процесса или нового процесса.

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

Белайчук Анатолий Анатольевич, президент Ассоциации профессионалов управления бизнес-процессами (ABPMP Russian Chapter), к.т.н., CBPP

Глава 1
Введение в CBOK

1.0. Что такое BPM CBOK?

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

Собрать и опубликовать в одной книге все имеющиеся знания по BPM – идея, вряд ли реализуемая на практике. Поэтому цель BPM CBOK[18] – дать в помощь BPM-профессионалам всесторонний обзор передовых методов, дискуссионных тем и уроков, извлеченных ABPMP[19] и ассоциациями-партнерами. BPM – это непрерывно развивающаяся дисциплина. Версия 3 CBOK дает понимание методов BPM на базовом уровне, а также ссылки на сообщества BPM и другие полезные источники информации. Мы призываем BPM-профессионалов использовать данное руководство наряду с другими источниками информации, а также вступать в сообщество BPM, чтобы приобретать знания и делиться ими.

Термин «управление бизнес-процессами» (BPM) ниже будет встречаться очень часто, поэтому дадим его определение.

Управление бизнес-процессами (Business Process Management, BPM) – это концепция управления, увязывающая стратегию и цели организации с ожиданиями и потребностями клиентов путем соответствующей организации сквозных процессов. BPM сводит воедино стратегию, цели, культуру и организационную структуру, роли, политики, нормативы, методологии и программные средства для: а) анализа, проектирования, внедрения, управления и непрерывного улучшения сквозных процессов и б) регулирования отношений в области процессного управления.

1.1. Цели написания BPM CBOK

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

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

Помимо этого, CBOK дает представление о фундаментальных знаниях, необходимых BPM-профессионалу. Любая сертификация или профессиональная оценка в области BPM потребует от кандидата продемонстрировать понимание основных концепций и умение выполнять действия, рассматриваемые в CBOK. Экзаменационные вопросы сертификации CBPP[20] основаны на CBOK.

1.2. Обратная связь

По мере того как дисциплина BPM обогащается новыми знаниями и опытом, будет развиваться и CBOK. Версия 2.0 была опубликована на английском, немецком и португальском языках. Читатели версии 2 дали ценные отклики, которые были учтены при подготовке данной версии. Версия 3.0 была улучшена благодаря взаимодействию между ABPMP и EABPMP[21].

За развитие BPM отвечает Комитет по обучению ABPMP. Комитет приветствует любые отклики, направленные на улучшение CBOK, и направляет их на рассмотрение сообществу ВРМ-профессионалов.

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

1.3. Структура глав CBOK

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

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

Примечательно, что в CBOK нет отдельной главы, посвященной внедрению процессов, – аспекты, относящиеся к информационным технологиям, рассматриваются в главе «Технологии BPM», а организационные аспекты – в разделе «Управление изменениями» главы «Процессная трансформация».



Такие вопросы, как регулирование и стратегическое планирование, относящиеся к более широкому контексту взаимосвязи между BPM и другими аспектами организации, рассматриваются в главах «Процессная организация» и «Управление процессами предприятия».

1.4. Обзор глав

Глава 2. Управление бизнес-процессами

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

Глава 3. Моделирование процессов

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

Глава 4. Анализ процессов

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

Глава 5. Проектирование процессов

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

Глава 6. Управление эффективностью процессов

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

Глава 7. Процессная трансформация

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

Глава 8. Процессная организация

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

Глава 9. Управление процессами предприятия

Управление процессами на уровне предприятия[24] вытекает из необходимости достичь максимальной результативности процессов в контексте заданной бизнес-стратегии и функциональных целей, основанных на этой стратегии. Управление портфелем процессов обеспечивает соответствие корпоративной стратегии или стратегии бизнес-единицы и включает в себя методы оценки инициатив. Данный раздел BPM включает рассмотрение средств и методов оценки уровня процессной зрелости, а также областей деятельности, способствующих повышению этого уровня. Рассматриваются процессные фреймворки[25], а также интеграция процессов, понимаемая как взаимодействие различных процессов между собой и процессов с моделями, охватывающими эффективность, цели, системы, персонал и средства контроля (финансовые и операционные), бизнес-стратегию и показатели эффективности. Исследуются вопросы процессной архитектуры и передовых методов управления процессами предприятия.

Глава 10. Технологии BPM

BPM – это управленческая дисциплина, опирающаяся на информационные технологии. В данной главе рассматривается широкий спектр существующих технологий, обеспечивающих планирование, проектирование, анализ, исполнение и мониторинг бизнес-процессов. Сюда входят пакеты прикладных программ, средства разработки, инфраструктурные компоненты, хранилища данных и информации, обеспечивающие связанную с BPM деятельность. Рассматриваются интегрированные Системы управления бизнес-процессами (BPMS)[26] и процессные репозитарии, а также изолированные средства моделирования, анализа, проектирования, исполнения и мониторинга. Также рассказывается о стандартах, методологиях и новых трендах BPM.

1.5. Эффект BPM

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

1.5.1. Эффект для предприятия

Явная ответственность за непрерывное совершенствование

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

Гибкое управление на основе измерений эффективности

BPM ежедневно поставляет информацию для системы контроля эффективности. Организации с развитой практикой BPM способны быстрее реагировать на выявленные отклонения эффективности.


Таблица 1.1

Эффект BPM

Измерение эффективности положительно влияет на стоимость и качество

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

Мониторинг обеспечивает соответствие нормативным требованиям

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

Повышение гибкости управления за счет большей прозрачности и готовности к изменениям

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

Совершенствовать процессы проще благодаря наличию информации

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

Контроль над издержками и их снижение через оценку стоимости процессов

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

Целостность и достаточность компетенций

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

Документирование операций и сохранность знаний

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

1.5.2. Эффект для клиентов

Совершенствование процессов положительно влияет на удовлетворенность клиентов

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

Мобилизация персонала для реализации ожиданий заинтересованных сторон

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

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

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

1.5.3. Эффект для менеджмента

Уверенность в том, что все выполняемые в процессе действия добавляют ценность

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

Оптимизация эффективности на всем протяжении процесса

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

Улучшения планирования и прогнозирования

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

Устранение препятствий в виде границ между подразделениями

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

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

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

Система информирования об инцидентах и анализа последствий

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

1.5.4. Эффект для исполнителей

Уверенность в будущем и информированность

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

Лучшее понимание картины в целом

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

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

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

Точно определенный набор рекомендуемых средств

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

1.6. Обзор BPM

Методы BPM концентрируются как на результатах, так и на способах их достижения. Таблица 1.2 иллюстрирует три широкие области применения BPM.


Таблица 1.2

Три взгляда на BPM[27]


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

Усовершенствование бизнес-процессов (BPI) – это разовая инициатива или проект, направленный на более полное соответствие стратегии организации и ожиданий клиентов. BPI включает в себя выбор, анализ, проектирование и внедрение усовершенствованного процесса.

Также под BPM может пониматься целостная система, образовавшаяся в результате ряда инициатив и проектов. Такая система под названием управление процессами предприятия включает в себя стратегию, ценности и культуру, организационную структуру и роли, полный набор сквозных процессов со своими целями и показателями, информационные системы и людей. Степень достигнутого прогресса может оцениваться по шкале уровней зрелости процессного управления[28].

Управление процессами предприятия (EPM) – это применение принципов, методов и процессов BPM в конкретной организации. EPM: а) обеспечивает соответствие портфеля и архитектуры сквозных процессов стратегии и ресурсам организации и б) предоставляет модель регулирования для оценки и управления BPM-инициативами.

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

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

Библиография

BPMG «In Search of BPM Excellence: Straight from the Thought Leaders», Meghan-Kiffer Press, 2005

Champlin, B. «Business Process Management Professionals», BPM Strategies, 2006

Burlton, R.T. «Business Process Management: Profiting from Process» Sams, 2001

Morris, D.; Brandon, J. «Reengineering Your Business», McGraw-Hill Book Company, 1994

Davenport, T. «Process Innovation: Reengineering Work Through Information Technology», Harvard Business School Press, 1993

Dephi Group «BPM 2003 Market Milestone Report», Delphi Group Whitepaper, 2003

Dwyer, T. «BPM Institute's State of Business Process Management», Executive White Paper, www.BPMInstitute.org, 2004

Hammer, M.; Champy, J. «Reengineering the Corporation: A Manifesto for Business Revolution», Harper Business Books, 1993 (Русский перевод: Хаммер М., Чампи Д. Реинжиниринг корпорации. Манифест революции в бизнесе. М.: Манн, Иванов и Фербер, 2011.)

Harmon, P. «Evaluating an Organization's Business Process Maturity», Business Process Trends, March 2004, Vol. 2, No. 3

IIBA International Institute of Business Analysis (Ed.)«A Guide to the Business Analysis Body of Knowledge», 2009

Mahal, A. «How Work Gets Done: Business Process Management, Basics and Beyond», Technics Publications, 2010

Osterloh, М.; Frost, J. «Prozessmanagement als Kernkompetenz. Wie Sie business reengineering strategisch nutzen können», Gabler Verlag, 2006

Parker, B.G. «Data Management Maturity Model» MITRE Software Engineering Center, McLean, 1995

Porter, M. «Competitive Advantage», New York: Free Press, 1985 (Русский перевод: Портер М. Конкурентное преимущество. Как достичь высокого результата и обеспечить его устойчивость. М.: Альпина Паблишер, 2008.)

Rosemann, M.; deBruin., T. «Application of a Holistic Model for Determining BP maturity», Business Process Trends, 2005

Rummler, G.A. «Serious Performance Consulting: According to Rummler» ISPI and ASTD, 2004

Rummler-Brache Group «Business Process Management in U. S. Firms Today», A study commissioned by Rummler-Brache Group, 2004

Rummler, G.A.; Ramias, A.J.; Rummler, R.A. «White Space Revisited: Creating Value Through Process», Jossey-Bass, 2010

Ryan K.; Ko, L. «A computer scientist's introductory guide to business process management BPM», ACM Press, 2009

Scheer, A.W.; Abolhassan, F. et.al. (Editors) «Business Process Automation», Springer-Verlag, 2004

Sinur, J. «Leveraging the Three Phases of Process Evolution», Process World 2004, Gartner, Inc. Presentation, 2004

Spanyi, A. «More for Less: The Power of Process Management», Meghan-Kiffer Press, 2006

zur Muehlen, M. «Workflow-based Process Controlling. Foundation, Design, and Application of workflow-driven Process Information Systems», Logos, 2004

Vom Brocke, J.; Rosemann, M. «Handbook on Business Process Management: Strategic Alignment, Governance, People and Culture», Springer, 2010

Глава 2
Управление бизнес-процессами

Вступительное слово: Джанель Хилл (Janelle Hill), вице-президент, Gartner Inc.

Взгляд Gartner на BPM

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

В 2011 г. мы находимся в начале новой эры процессного мышления – периода, который, по мнению Gartner, будет характеризоваться процессами, адаптирующимися к меняющимся бизнес-условиям[29]. В представлении Gartner, операционное совершенство больше не должно измеряться только внутренними показателями, ориентированными на производительность. Вместо этого ключевые принципы BPM подчеркивают значимость прозрачности, подотчетности и способности адаптироваться как предпосылок непрерывной оптимизации и способов справляться с изменчивостью глобального бизнес-окружения.

Чтобы адекватно ответить на эти вызовы, организация должна развивать способность предвидеть меняющиеся потребности рынка и клиентов и реагировать на эти изменения. Учитывая частоту появления событий, оказывающих радикальное влияние на глобальную экономику, бизнес стремится стать более адаптивным. Но, несмотря на то что BPM использует мантру «адаптивность бизнеса»[30] уже 10 лет, лишь немногие организации действительно достигли этой цели. Хотя лидеры в области BPM восприняли культуру непрерывного усовершенствования и все чаще вносят изменения в свои процессы, все же их процессы проектируются без прицела на постоянные изменения. Внесение изменений по-прежнему остается делом сложным и зачастую требует глубоких технических познаний. Адаптивность процессов чаще определяется цикличностью развития IТ, а не темпом, задаваемым бизнесом.

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

• Что в нашей работе должно сигнализировать о необходимости вмешательства в операционные процессы? Как мы можем осуществлять мониторинг этих сигналов?

• Какие события (внутренние и инициируемые извне) должны побудить нас изменить порядок работы?

• Какие аспекты работы особенно нуждаются в пересмотре и насколько часто?

• Кто должен принять решение о целесообразности внесения изменений и о том, что конкретно надо изменить?

• Как мы можем оповестить о желательности изменений и убедиться, что они реализованы?

• Как мы узнаем, что внесение изменения достигло желаемых целей? И если цели не достигнуты, можем ли мы легко отменить внесенное изменение?


Далее наши исследования показали, что большинство организаций продолжает фокусироваться на небольших улучшениях структурированных процессов, в то время как возможности дифференциации процессов в большей степени кроются в деятельности работников умственного труда[31]. Эта деятельность в значительной степени не структурирована – она не является рутинной, и для нее не характерно последовательное и предсказуемое выполнение.

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

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

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

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

2.0. Введение

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

2.1. Что такое управление бизнес-процессами (BPM)?

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

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

• BPM – это управленческая дисциплина.

• Успешно внедренный BPM является ключевой способностью[32].

• BPM нацелен на создание ценности для потребителя.

• BPM нацелен на сквозные процессы и координацию[33] действий, относящихся к разным бизнес-функциям.

• BPM отвечает на вопросы, какая, где, когда, зачем и как выполняется работа и кто отвечает за ее выполнение.

• Способы описания и представления бизнес-процессов должны выбираться в соответствии с назначением и применением.

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

• Согласованное и проактивное управление бизнес-процессами требует существенных инвестиций в развитие способностей компании.

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

• Внедрение BPM влечет появление в организации новых ролей.

• BPM не предписывает какую-то определенную структуру, методологию или набор средств.

• Информационные технологии во внедрении BPM играют не основную, а обеспечивающую роль.

• Внедрение BPM является стратегическим решением и требует твердой поддержки со стороны высшего руководства.

2.2. BPM – это управленческая дисциплина

Слово «управление» (англ. management) происходит от французского menagement – «искусство руководства, управления» и латинского manu agere – «направлять рукой». Оно описывает действия по руководству организацией или ее частью путем развертывания человеческих, финансовых, материальных и интеллектуальных ресурсов для достижения заданных целей, в особенности для максимизации ценности для потребителя и, таким образом, возврата инвестиций учредителей.

«Дисциплина» есть объем знаний, отвечающий общепризнанным принципам и методам в специфической предметной области.

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

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

Обоснование определения BPM как управленческой дисциплины троякое.

• BPM – это не жестко заданный набор методов и средств, которые организация принимает в виде готового рецепта, а свод знаний, включающий принципы и передовые методы[34], помогающий организации выработать такой набор методов и средств.

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

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

2.3. Успешно внедренный BPM является ключевой способностью

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

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

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

1. Бизнес-процессы, поддерживающие управление бизнес-процессами. Например, у организации должны быть процессы, которые обеспечивают:

• описание и проектирование бизнес-процессов;

• разработку и внедрение бизнес-процессов;

• мониторинг и контроль исполнения бизнес-процессов;

• непрерывное и постоянное улучшение бизнес-процессов, несмотря на и в ответ на внутренние и внешние изменения.

2. Определенные роли (люди), вовлеченные в управление бизнес-процессами. Таковые включают (не ограничиваясь ими) следующие:

• архитектор процессов, который отвечает за описание и проектирование бизнес-процессов;

• процессный аналитик, который отвечает за построение, внедрение, мониторинг и оптимизацию бизнес-процессов;

• владелец процесса, который отвечает за исполнение бизнес-процесса от начала до конца, в соответствии с определенными целевыми показателями эффективности и в конечном итоге за создание ценности для потребителя.

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

• описание бизнес-процессов в контексте корпоративной архитектуры;

• проектирование бизнес-процессов с целью внедрения;

• исполнение бизнес-процессов в контексте операционной деятельности;

• мониторинг целевых показателей эффективности бизнес-процессов;

• анализ бизнес-процессов с целью выявления и оценки возможностей для улучшения;

• управление изменениями бизнес-процесса.

2.4. BPM нацелен на создание ценности для потребителя

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

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

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

Тем, кто впервые знакомится с BPM или, возможно, не до конца его понимает, утверждение «цели организации могут быть достигнуты путем целенаправленного управления бизнес-процессами» может показаться слишком смелым. Но если его тщательно разобрать и проанализировать, то прослеживается следующая логика.



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

• Следовательно, все цели организации должны сводиться к созданию ценности для потребителя.

• Бизнес-процесс – это «машина», которая создает продукцию и услуги и предоставляет их потребителю.

• BPM устанавливает средства, которыми управляются бизнес-процессы.

• Следовательно, BPM – это средство достижения целей организации.


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

• Потребителями производителя шин являются производители автомобилей и водители.

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


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

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




Еще один пример: IТ-подразделение фармацевтической компании оказывает услуги бизнес-подразделениям. Каждая такая услуга предоставляется посредством бизнес-процесса внутри IТ-подразделения. Связь поставщик – потребитель сервиса показана ниже (рис. 2.4).

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

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


2.5. BPM нацелен на сквозные процессы и на координацию действий, невзирая на границы между бизнес-функциями

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

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

Приведенная диаграмма (рис. 2.5) показывает, что:

• действия выполняются бизнес-функциями, обладающими специализированными компетенциями;

• бизнес-процесс координирует последовательность действий, относящихся к нескольким бизнес-функциям.



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

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

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

2.6. BPM отвечает на вопросы какая, где, когда, зачем и как выполняется работа и кто отвечает за ее выполнение

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

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



• Когда выполняется работа?

• Какие материалы или информация требуются на входе?

• Какая продукция или артефакты получаются на выходе?

• Где выполняется работа?

• Где хранятся произведенные продукция и артефакты?

• Зачем выполняется работа?

• Кому предназначен конечный результат?


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

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

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

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

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

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

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

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

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

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

• Функциональность информационных систем и то, как эта функциональность задействована в исполнении процесса.


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

2.7. Способы описания и представления бизнес-процессов должны выбираться в соответствии с назначением и применением

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

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

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

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

• Группа, отвечающая за непрерывность и восстановление бизнеса[35], нуждается в описании бизнес-процессов, чтобы понять критический уровень устойчивости бизнеса и составить список процессов и функций, которые должны быть восстановлены для обеспечения коммерческой жизнеспособности в случае катастрофического события.

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

• Главный технолог нуждается в описании бизнес-процессов для составления и обновления корпоративных планов технологического развития.

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

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

• Команда IТ-разработчиков нуждается в описании бизнес-процессов, чтобы понять, как требования к информационным системам и их проект поддерживают бизнес-функции.

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


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

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

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

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

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

Литература по BPM изобилует жизненными циклами бизнес-процессов, описывающими управление с обратной связью. Независимо от числа фаз цикла и присвоенных им названий подавляющее большинство можно свести к циклу «Планирование – действие – проверка – корректировка» (PDCA)[36], популяризированному доктором Эдвардсом Демингом (Dr. W. Edwards Deming) в 1950-е годы (рис. 2.7).



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

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

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

2.8.1. Стадия «Планирование»

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



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

• Потребитель процесса.

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

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

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

• Регулирующие положения – внешние или внутренние политики и правила, накладывающие ограничения на проектирование и исполнение процесса.

• Исходные значения показателей производительности и результативности (если речь идет о существующем бизнес-процессе).

• Целевые показатели производительности и результативности будущей версии процесса.


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

• Действия, составляющие бизнес-процесс.

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

• Организации, функции и роли, принимающие участие в выполнении процесса.

• Информационные системы, задействованные в выполнении процесса.

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

• Специфические события, влияющие на исполнение процесса.

• Бизнес-правила, ограничивающие исполнение процесса.

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

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

• Какие роли отвечают за исполнение каких действий.

• Какие действия производят какие результаты.

• Какие события какие действия запускают.

• Какие действия выполняются на каких местах.

• Какие результаты хранятся в каких местах.

• Какие информационные системы обеспечивают какие действия.

Успешное выполнение фазы «планирование» дает:

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

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

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

2.8.2. Стадия «Действие»

Назначение стадии «Действие» цикла PDCA – внедрить процесс в соответствии со спецификацией, разработанной на стадии «Планирование», и приступить к его эксплуатации.



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

• Создание новых ролей и полномочий или модификация существующих.

• Проектирование или реструктуризация функциональных подразделений.

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

• Разработка и внедрение вспомогательных средств, таких как стандарты на операционные процедуры, инструкции и руководства.

• Открытие новых каналов и точек взаимодействия с клиентами.

• Создание и внедрение средств мониторинга показателей эффективности процесса, панелей показателей для контроля эффективности, а также механизмов эскалации.


Стадия «Действие» цикла PDCA включает в себя также исполнение процесса с момента внедрения его в эксплуатацию. Другими словами,

• процесс запускается инициирующими событиями;

• процесс получает входы;

• выполняются действия;

• производятся промежуточные результаты;

• конечные результаты процесса производятся и передаются по назначению.

2.8.3. Стадия «Проверка»

Назначение стадии «Проверка» цикла PDCA – измерить показатели эффективности процесса и сравнить их с ожидаемой эффективностью.



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

Показатели эффективности, оцениваемые извне или с точки зрения потребителя, принято называть результативностью, они призваны отвечать на вопрос: «Делаем ли мы то, что надо?»[38] Эти показатели должны подтвердить, что мы систематически соответствуем потребностям и ожиданиям заказчика.

Секрет полезности метрик на стадии «Проверка» – правильная архитектура описания процесса на стадии «Планирование». Как показано на рис. 2.9, целевые показатели эффективности процесса определяются ожиданиями потребителя. Эти показатели эффективности самого верхнего уровня, в свою очередь, декомпозируются на нижележащие целевые показатели эффективности, которые могут устанавливаться на функциональном и операционном уровнях. В теории:

• если достигнуты все операционные целевые показатели, то функциональные показатели выдержаны;

• если достигнуты все функциональные показатели, то показатели эффективности процесса самого верхнего уровня выдержаны;

• если достигнуты все показатели эффективности процесса, то потребитель удовлетворен.


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

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




Традиционные категории показателей эффективности:

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

• качество продукции: например отсутствие дефектов, объем переделок, надежность продукции;

• качество услуги: например гибкость, добросовестность, надежность;

• стоимость: например трудозатраты, материальные затраты, накладные затраты, стоимость переделок;

• удовлетворенность потребителя: например соответствие восприятия продукции или услуги ожиданиям.

2.8.4. Стадия «Корректировка»

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



На основе данных об эффективности, собранных на стадии «Проверка», могут выполняться корректировки двух видов.

• Действия с отдельными экземплярами процессов (вмешательство в реальном или близком к реальному времени)

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


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

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

• В 45 % случаев подготовка рабочего места не была завершена за два дня до даты выхода сотрудника, что привело к эскалациям, которые увеличили затраты на один случай на $2000.

• 95 % специалистов отдела HR поставили отметки «неудовлетворительно» или «крайне неудовлетворительно» технологиям скрининга и отслеживания перед приемом на работу.

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

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


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

• Сбор и агрегирование данных и наблюдений, собранных на стадии «Проверка».

• Анализ этих данных и составление списка критичных замечаний, по которым должны быть приняты меры.

• Разработку рекомендаций по устранению замечаний из списка (то есть требования к проекту будущей версии процесса).

• Ранжирование и приоритизацию всех требований к будущей версии внутреннего устройства процесса, которые должны быть реализованы на следующей стадии «Планирование» цикла PDCA.

2.9. Согласованное и проактивное управление бизнес-процессами требует существенных инвестиций в развитие способностей компании

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

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

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

• Вспомогательные процессы предназначены для поддержки основных, обычно через управление ресурсами и/или инфраструктурой, необходимых основным процессам. Разница между основными и вспомогательными процессами в том, что вспомогательные процессы непосредственно не создают ценность для потребителя. Примеры вспомогательных процессов обычно относятся к ИТ, финансам, управлению персоналом. Хотя вспомогательные процессы зачастую тесно связаны с функциональными областями (например, процесс выдачи и отзыва разрешения на сетевой доступ), они могут пересекать функциональные границы и зачастую действительно их пересекают.

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

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

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

• возможности приобрести автомобиль;

• возможности получить кредит на приобретение автомобиля (при необходимости);

• возможности получить сервисное обслуживание автомобиля (при желании).


При взгляде извне потребитель видит выходы только трех бизнес-процессов:

• продажа автомобиля (потребитель выезжает на новых «колесах»);

• оплата покупки (потребитель получает по почте напоминание об очередном платеже);

• обслуживание автомобиля (потребитель регулярно пригоняет машину для замены масла и диагностики).


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

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

• доступ к капиталу для закупок у изготовителя и пополнения склада;

• оценка рынка с целью оптимизации соотношения подержанных и новых автомобилей и моделей автомобилей на складе;

• заказ автомобилей у производителя и оптовиков;

• поддержание выставочного зала и склада в чистом и презентабельном виде;

• ведение базы данных о потребителях и поставщиках;

• подбор и адаптация продавцов, финансовых менеджеров и сервисных специалистов;

• управление оплатой труда и экономической эффективностью;

• мониторинг процентных ставок, условий и опций кредитования у конкурентов;

• снабжение сервис-центра запчастями и инструментами.


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

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

• измерение удовлетворенности потребителей;

• измерение эффективности (время и стоимость) сервисного обслуживания;

• выявление возможностей изменения и улучшения процесса;

• сопоставление возможностей усовершенствования процессов со стратегическими целями и соответствующая приоритизация;

• реализация возможностей усовершенствования процессов в проекте будущей версии процесса, успешное и эффективное ее внедрение в эксплуатацию;

• измерение возврата от инвестиций во все вышеперечисленное.


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

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

Комплексное управление бизнес-процессами на стадии «Планирование» цикла PDCA требует способности осуществлять планирование и описание процессов.

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

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

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


Комплексное управление бизнес-процессами на стадии «Действие» цикла PDCA требует способности осуществлять детальное проектирование, разработку и внедрение процессов. Например:

• управление портфелем проектов для упорядочивания, инициирования и управления большими портфелями бизнес– и IТ-ориентированных инициатив, вытекающих из планирования трансформаций;

• управление проектами для управления отдельными бизнес– и IТ-ориентированными инициативами, входящими в портфель проектов;

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


Комплексное управление бизнес-процессами на стадии «Проверка» цикла PDCA требует способности осуществлять мониторинг и отчетность по эффективности. Например:

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

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


Совместное управление бизнес-процессами на стадии «Корректировка» цикла PDCA требует способности осуществлять реагирование на изменения и непрерывное совершенствование. Например:

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

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

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

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

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

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



Анализируя состояние своих бизнес-процессов по шкале Хаотичные – описанные – контролируемые – интегрированные – проактивно управляемые[39], организация может определить к какому уровню они относятся (поодиночке или в совокупности), и в соответствии с этим решить, на развитие каких собственных бизнес-способностей следует направить ресурсы.

2.10.1. Стадия хаотичных процессов

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


Таблица 2.1

2.10.2. Переход от хаотичных к описанным процессам

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

В области планирования и описания процессов (шаг «Планирование» цикла PDCA) обычно наблюдается следующее.

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

• Возросшее понимание того, как проекты усовершенствования бизнес-процессов и обеспечивающие их IТ-инициативы реализуют стратегию организации.

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

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

• Инвестиции в стандарты, методологию и средства анализа бизнеса и бизнес-процессов.

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


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

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

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

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

• Больший акцент на стабильности и повторяемости при разработке и внедрении бизнес-процессов; использование более структурированных (основанных на архитектуре) фреймворков и методов.


Как следует из приведенной табл. 2.1, организации, не инвестирующие в развитие способностей, обеспечивающих описание процессов, страдают из-за неспособности:

• выдержать перед клиентами обязательства по поставке продукции и предоставлению услуг;

• донести до персонала требования по эффективности;

• объяснить, что означает «действовать в соответствии с регламентом»;

• добиться устойчивости и повторяемости процесса;

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

2.10.3. Переход от описанных к контролируемым процессам

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

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

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

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

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

• Появление таких специализированных ролей, как владелец процесса и администратор[40] процесса. Эти роли участвуют в управлении сквозным бизнес-процессом, пересекающим границы функциональных подразделений, и отвечают за создание ценности для потребителя согласно четко определенным целевым показателям предоставления продукции и услуг.

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

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


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

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

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


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

2.10.4. Переход от контролируемых к интегрированным процессам

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

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

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

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

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

• Стратегическое планирование: дисциплина, имеющая дело с движущими силами бизнеса и базовыми ценностями для потребителя[41]. Более конкретно стратегическое планирование выделяет и увязывает такие компоненты, как видение и миссия, цели и стратегия, продукция и услуги, внутренние и внешние показатели жизнедеятельности, с тем чтобы оптимизировать и улучшать положение на рынке.

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

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

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

• Сервис-ориентированная архитектура: дисциплина, выявляющая и увязывающая информационные и технологические компоненты, собранные в ключевые бизнес-сервисы, реализованные с помощью IТ. Более конкретно, сервис-ориентированная архитектура призвана гарантировать, что веб-сервисы, веб-приложения, базы данных и технологическая инфраструктура обеспечивают доступность данных для использования в бизнес-процессах.

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

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

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

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

2.10.5. Переход от интегрированных к проактивно управляемым бизнес-процессам

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

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

• организация способна быстро, легко и адекватно реагировать на изменения во внешних регламентах и другие воздействия и угрозы. Например, по многим оценкам, суммарные затраты на решение проблемы-2000 и выполнение требований Закона Сарбейнса – Оксли[42] превысили триллион долларов США. Значительная часть этих затрат была связана с неэффективными средствами выявления воздействия этих угроз на операции и неэффективным проведением соответствующих изменений.

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



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

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

• Способности, обеспечивающие мониторинг и отчетность по эффективности (стадия «Проверка» цикла PDCA), гарантируют, что эффективность процесса последовательно и всесторонне измеряется и сопоставляется с нормативами, установленными на стадии планирования, и что информация об эффективности доступна и используется всеми заинтересованными сторонами.

• Способности, обеспечивающие преобразование и непрерывное совершенствование (стадия «Корректировка» цикла PDCA), гарантируют, что организация способна точно оценивать и адекватно реагировать на информацию, собранную на стадии «Проверка». Эти способности обеспечивают целостность процессов в условиях нестабильности и изменчивости окружения и являются катализатором непрерывного совершенствования процессов во времени.

• Новые стратегические, функциональные и операционные команды передаются со стадии «Корректировка» на стадию «Планирование» для описания и планирования, тем самым замыкая цикл системы управления.

2.11. Внедрение BPM требует введения в организации новых ролей

BPM – это управленческая дисциплина, которая имеет дело с принципами и практикой бизнес-администрирования и определяет способы и методы управления бизнес-ресурсами.

Концепция менеджмента подразумевает регулирование[43]. Вообще говоря, регулирование есть структурированный подход к принятию решений и их реализации. Применительно к бизнес-процессам под регулированием понимается:

• структурированное принятие решений о том, как организация функционирует с точки зрения создания ценности для потребителя;

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

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

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

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

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



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

• владелец процесса;

• процессный лидер;

• администратор процесса;

• процессный аналитик;

• процессный методолог[44].

2.11.1. Владелец процесса

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

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



Чтобы соответствовать предъявляемым к нему требованиям, владелец процесса обычно:

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

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

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

• добивается понимания того, как люди и системы участвуют в процессе;

• является активным заинтересованным лицом в бизнес– и IТ-инициативах, затрагивающих процесс;

• содействует принятию бизнес-процесса;

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

• предлагает корректирующие действия, если эффективность процесса не соответствует ожиданиям;

• эскалирует экземпляры важного процесса, требующие внимания из-за существенных отклонений эффективности;

• возглавляет команду по оценке, приоритизации и реализации запросов на изменение процесса;

• работает вместе с другими владельцами процессов, добиваясь координации.


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

Владелец процесса внутри функциональной иерархии

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

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

• Ответственность за процесс поручается нескольким владельцам процесса.



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

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

Владелец процесса вне функциональной иерархии

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



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

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

2.11.2. Процессный лидер

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



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

В связи с исполнением роли процессного лидера могут появляться следующие дополнительные обязанности:

• выработка концепции и стратегии BPM и спонсирование ее реализации;

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

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

2.11.3. Администратор процесса

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



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

• Накопление знаний и опыта в рамках функциональной области.

• Привлечение и удержание самых талантливых сотрудников.

• Структурирование и описание ролей в функциональной команде.

• Описание и поддержка процедур операционного уровня.


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

• Забота о том, чтобы процедуры операционного уровня соответствовали требованиям вышестоящего бизнес-процесса, обеспечиваемого функцией.

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

• Сбор и отправка владельцу процесса откликов и предложений по совершенствованию процесса.

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

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

2.11.4. Процессный аналитик

В небольших проектах BPM процессный аналитик может выполнять обязанности на всех стадиях цикла управления процессом. В более крупных проектах процессный аналитик может специализироваться на одном или двух ключевых аспектах дисциплины (рис. 2.18). Характерные примеры обязанностей:



• сквозное проектирование бизнес-процесса под руководством владельца процесса и на основании сведений, получаемых от экспертов в предметной области;

• ведение репозитория процессных моделей;

• диагностика проблем и выработка предложений по их решению совместно с владельцем и администраторами процесса;

• проведение анализа (например, анализа эффективности, анализа «что, если» и имитационного моделирования процесса) по запросу владельца и/или администраторов процесса;

• участие в работе команды, проводящей оценку и приоритизацию запросов на изменение процесса;

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

2.11.5. Процессный методолог

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

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



Обычно в обязанности процессного методолога входит:

• описание принципов, методов и стандартов BPM;

• забота о том, чтобы принципы, методы и стандарты BPM соответствовали текущему и будущему масштабу реализации BPM;

• консультирование, наставничество и обучение передовым методам и стандартам, проведение их в жизнь и контроль за соблюдением.

2.12. BPM не предписывает определенный фреймворк, методологию или набор средств

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

• Для описания организационного контекста бизнес-процессов и, в частности, их связи со стратегическими целями часто используют фреймворки и методологии корпоративной архитектуры[45], такие как матрица Захмана, TOGAF, DODAF, FEAF.

• Для оптимизации модели бизнес-процесса с точки зрения выполняемых действий, выходов и использования ресурсов – людей и информационных систем – часто используются такие фреймворки и методологии, как Раммлер – Брейч (Rummler – Brache) и бережливое производство.

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

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

• Аналогичным образом, существуют бесчисленные подходы, способные помочь в бизнес-анализе, – такие как шесть сигм, Монте-Карло и дискретное имитационное моделирование событий[47].

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

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

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

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

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


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

2.13. Информационные технологии во внедрении BPM играют не основную, а обеспечивающую роль

В последнее десятилетие мы наблюдаем невероятный прогресс программного обеспечения, предназначенного для поддержки таких составляющих дисциплины BPM, как:

• архитектура бизнес-процессов и моделирование бизнес-процессов в контексте вышестоящей корпоративной архитектуры;

• проектирование бизнес-процессов, включая обсуждение проекта с различными заинтересованными сторонами и загрузку в процессный движок;

• исполнение бизнес-процессов и оркестровка действий, выполняемых людьми и информационными системами;

• анализ бизнес-процессов и автоматизация таких методов, как функционально-временной анализ, функционально-стоимостной анализ и имитационное моделирование на основе сценариев[48];

• управление бизнес-правилами, в том числе независимо от бизнес-процессов для большей гибкости;

• разработка веб-сервисов, сервис-ориентированная архитектура и предоставление корпоративных данных по запросу в ходе исполнения процесса;

• обратная связь – использование показателей эффективности процессов для анализа и учета в будущей версии процесса.


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

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

• роль IТ-подразделения в BPM – помощника, а не лидера;

• внедрение BPM – это не IТ-проект, а согласованное изменение методов управления процессами, которое может быть поддержано информационными технологиями.


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

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

2.14. Внедрение BPM является стратегическим решением и требует твердой поддержки со стороны высшего руководства

Как было показано выше, полномасштабное (в масштабах корпорации или крупной организационной единицы) внедрение BPM зачастую требует появления и развития:

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

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

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


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

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

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

Глава 3
Моделирование процессов

Вступительное слово: Крэйг Ле Клер (Craig Le Clair), вице-президент и главный аналитик, Forester Research

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

Кроме того, по экспоненте растут объем и значение больших данных[49] – информации из социальных сетей, датчиков и мобильных устройств. Большие данные и основанная на них аналитика меняют процессы, и в соответствии с этим должны быстро меняться средства моделирования.

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

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

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

BPM годами тянет с выполнением обещания «замкнутого цикла»[50] – непрерывного циклического моделирования, проектирования, исполнения и улучшения бизнес-процессов. К сожалению, большинство BPM-решений почти полностью сконцентрировались на исполнении, а стратегии уделяют минимум внимания. В течение следующих нескольких лет благодаря прогрессу в моделировании баланс в системах BPMS[51] сместится от разработки и исполнения в сторону мониторинга и реализации процессной стратегии. Чтобы добиться сбалансированности, следующее поколение BPMS соединит бизнес-архитектуру – модели способностей, цепочки создания ценности и стратегические карты – с контролем исполнения процессов в реальном времени, что позволит высвечивать проблемы с производительностью процессов и вырабатывать рекомендации по оптимизации.

Проектирование от моделей должно улучшить коммуникации с заинтересованными лицами бизнеса

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

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

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

Для объединения в одной команде усилий экспертов по стратегии и по взаимодействию с заказчиками, гуру процессной трансформации и IТ-экспертов все шире будут использоваться средства коллективной работы

Как и изолированные процессы внутри организации, команды трансформации зачастую представляют собой изолированные друг от друга ячейки, разбросанные по предприятию. Мы сплошь и рядом видим, как команда совершенствования операционной деятельности применяет принципы бережливого производства или шести сигм, параллельно с этим специалисты по маркетингу осваивают новые принципы работы с клиентом, а IТ внедряет систему BPMS. Каждая из этих групп обладает внушительным багажом, но их усилия часто изолированы друг от друга. К 2015 году компании, освоившие совместное моделирование процессов, объединят сильные стороны всех команд в единых стратегических инициативах и соберут экспертов в центрах компетенции. Чтобы проводимые изменения становились глубокими и долгосрочными, в эти комбинированные команды включат также экспертов по стратегии и по управлению изменениями.

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

Программное обеспечение для бизнеса, включая корпоративные приложения, системы управления бизнес-процессами, динамический кейс-менеджмент[53], системы поддержки коллективной работы и мобильные приложения, становится существенно проще в использовании и управлении. Это достигается совершенствованием пользовательского интерфейса и интуитивно понятными средствами графического конфигурирования, скрывающими сложность технологий. По мере того как все больше поставщиков выпускает ПО, ориентированное на бизнес, его представители, кровно заинтересованные в процессах, все меньше зависят от IТ в том, что касается конфигурирования процессов и освоения новых возможностей.

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

3.0. Введение

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

3.1. Моделирование бизнес-процессов

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

3.1.1. Применение процессных моделей

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

• организационного планирования (структурирования);

• исследования (изучения);

• прогнозирования (предсказания);

• измерения (количественной оценки);

• объяснения (обучения, демонстрации);

• верификации (валидации);

• контроля (установления ограничений и целей).


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

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

• значки, наглядно изображающие элементы процесса;

• связи между значками;

• связи значков с окружением;

• поведение или действие значков.


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


Таблица 3.1

3.1.2. Статические и динамические модели

Статические модели отображают единственное, не меняющееся во времени состояние процесса. Статические модели:

• фиксируют исходное состояние;

• документируют промежуточные версии;

• изображают будущее состояние, основанное на предположениях о целях и рисках процесса;

• управляют изменениями;

• приводят процесс к более высокому уровню зрелости.


Модель может содержать элементы динамики, например предусматривать возможность взаимодействия с пользователем или показывать развитие во времени.

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

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

3.1.3. Компоненты процесса и программные средства

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

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

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


Таблица 3.2

Примеры компонент процесса, охватываемых моделью

3.1.4. Цели моделирования процессов

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

Процессные модели – это средства:

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

• анализа эффективности процесса;

• описания изменений.

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

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


Таблица 3.3

Побудительные причины моделирования процессов

3.2. Основные процессные нотации

Нотация – это стандартизованный набор символов плюс правила, определяющие, что они означают.

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

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

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

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

• Есть возможность импорта-экспорта моделей между различными программными средствами.

• Некоторые средства дают возможность перевести нотацию моделирования в исполняемый язык.

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

Рекомендации по выбору нотации моделирования

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

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


Таблица 3.4

Распространенные процессные нотации[54]

3.2.1. Нотация моделирования бизнес-процессов BPMN2.0

Стандарт business process model and notation (BPMN) первоначально был разработан Business Process Management Initiative, в настоящее время он поддерживается консорциумом Object Management Group (OMG). Растущая популярность BPMN в качестве стандарта привела к тому, что его стали поддерживать наиболее распространенные средства моделирования. Он предоставляет полноценный набор символов для моделирования различных аспектов бизнес-процесса. Как и большинство современных нотаций, символы BPMN описывают взаимосвязи, такие как последовательность выполнения работ.

Ключевые характеристики

• Версия 2 (BPMN2.0) показывает, что нотация является зрелой и устоявшейся.

• Более 100 символов сгруппированы в так называемые описательные и аналитические наборы[55] в соответствии с потребностями разных пользователей.

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

Для чего используется

• Чтобы представить модель процесса разным аудиториям.

• Для имитационного моделирования.

• Для исполнения процесса.

Преимущества

• Широко используется и легко воспринимается; многими рассматривается как стандарт «де-факто».

• Заметное использование в Министерстве обороны и других государственных ведомствах США.

• Одна из наиболее мощных и гибких нотаций для выявления ограничений процесса.

Недостатки

• Чтобы корректно использовать полный набор символов, необходимы обучение и опыт работы.

• Трудно увидеть взаимосвязи между различными уровнями процесса.

• Разные средства моделирования могут поддерживать разные подмножества нотации.

• В некоторых организациях люди бизнеса плохо воспринимают нотацию из-за ее IТ-корней.

Пример
Дополнительная информация

• Официальный сайт BPMN, принадлежащий OMG: www.bpmn.org.

3.2.2. Дорожки

«Плавательные дорожки» – это не отдельная нотация, а скорее, полезное дополнение к другим системам нотаций. Их часто включают в диаграммы BPMN, EPC, UML и блок-схемы, чтобы показать исполнителя, ответственного за выполнение определенного действия. Дорожки изображаются в виде длинных вертикальных или горизонтальных полос, напоминающих дорожки в плавательном бассейне. Упорядочивание потока действий по дорожкам делает наглядной передачу ответственности и работы между участниками процесса.

Ключевые характеристики

• Дорожки изображают исполнителей или группы исполнителей.

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

Для чего используется

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

• Чтобы заинтересованные стороны лучше понимали процесс.

Преимущества

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

• Четко определяет точки передачи ответственности в процессе.

• Может описывать последовательность операций, потоки материалов и сообщений.

Недостатки

• Сложно изобразить коллективную ответственность.

• В некоторых случаях может способствовать укоренению функционального мышления.

Пример

3.2.3. Блок-схемы

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

Ключевые особенности

• Используется как в сочетании с дорожками, так и без них.

• Множество вариантов для различных целей.

• В основе лежит простой набор легко узнаваемых символов.

• Является предшественником многих более современных нотаций.

Для чего используется

• Чтобы быстро описать процесс там, где не требуется детальное документирование.

• Чтобы начать проект моделирования в отсутствие средств для приобретения полнофункционального программного обеспечения.

• Чтобы разрабатывать диаграммы в ходе традиционного программирования.

Преимущества

• Хорошо воспринимается программистами и системными инженерами.

• Высокоуровневые блок-схемы помогают достичь консенсуса.

• Подходит для изображения «магистрального пути»[56] процесса.

• Не требует существенных затрат.

• Поддерживается недорогими программными средствами, в том числе универсальными программами для рисования.

Недостатки

• Помимо стандарта ANSI, существует множество вариантов нотации.

• Может не хватать точности при описании сложных бизнес-процессов.

• У элементов нет устоявшихся наборов атрибутов.

• Модели являются «плоскими», из-за чего приходится разрезать диаграмму на сегменты, соединенные коннекторами.

• По общему мнению, не является подходящим средством для описания сложных процессов.

Примеры

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

Дополнительная информация

• Стандарты ANSI.

• Вводные разделы учебников по программированию.



3.2.4. EPC

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

Основные характеристики

• Нотация EPC была разработана в начале 1990-х годов профессором Университета земли Саар Августом-Вильгельмом Шеером (August-Wilhelm Scheer) как часть методологии ARIS.

• EPC может использоваться для моделирования, анализа и перепроектирования бизнес-процессов.

• Может использоваться в сочетании с вертикальными или горизонтальными дорожками.

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

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

Для чего используется

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

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

Преимущества

• Широко используется и хорошо воспринимается в Германии и в других европейских странах, особенно в транснациональных компаниях.

• Существенное присутствие в Министерстве обороны США и других крупных организациях.

• Правильно спроектированный EPC может читаться как последовательность предложений обычного языка.

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

• Можно расширять модели дорожками или дополнительными типами элементов, описывающими исполнителей, системы, информацию.

• Некоторые средства моделирования все лучше и лучше позволяют преобразовывать EPC в BPMN.

• Одна из самых мощных и универсальных нотаций в части описания ограничений процесса.

Недостатки

• Менее распространен в США по сравнению с BPMN и блок-схемами.

• Чтобы не делать ошибок, команда должна пройти обучение нотации.

• Нотация полноценно реализована только в программных продуктах семейства ARIS.

Пример
Дополнительная информация

• www.ariscommunity.com.

3.2.5. UML

Унифицированный язык моделирования (UML) – это стандартизованный набор нотаций и методов моделирования, главным образом предназначенных для описания требований к информационным системам. Хотя в основном UML используется для системного анализа и проектирования, некоторые организации применяют диаграммы действий[57] из семейства UML, чтобы моделировать бизнес-процессы. UML поддерживает Object Management Group (OMG).

Основные характеристики

• Представляет собой набор из более чем десяти связанных друг с другом нотаций и методов моделирования.

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

• Набор символов разный в разных нотациях.

• SysML, подмножество UML, часто используют для описания систем и систем, состоящих из систем.

Для чего используется

• Для документирования сценариев использования[58].

• Для спецификации требований к информационным системам.

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

• Для описания и проектирования структур данных.

• Для описания низкоуровневых потоков работ.

Преимущества

• Широкое сообщество пользователей.

• Реализован в большинстве средств моделирования.

• Множество книг и онлайновых источников информации.

Недостатки

• Создан для моделирования ПО, моделирование бизнес-процессов – второстепенная задача.

• Разные средства моделирования могут реализовывать нотацию по-разному.

Пример[59]
Дополнительная информация

• Официальный сайт UML, принадлежащий OMG: www.uml.org.

• Файлы помощи программного обеспечения IBM Rational.

3.2.6. IDEF

IDEF[60] – семейство нотаций и методов моделирования, первоначально разработанных ВВС США как часть методологии описания рабочих процессов и информационных систем, в настоящее время в свободном доступе[61]. IDEF широко применяется в течение многих лет и реализован во многих средствах моделирования.

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

Основные характеристики

• Верхний уровень описывает контекст задачи.

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

• У шага процесса есть вход, выход, управление и механизм – они изображаются надписанными стрелками.

• Система числового кодирования отражает связь нижних уровней с верхними (например, B3.2 – второй подпроцесс процесса B3).

Для чего используется

• Для моделирования на любом уровне.

• В системах автоматизированного производства.

Преимущества

• Точное выражение понимания процесса аналитиком.

• Легко отлеживаемая логика декомпозиции от уровня к уровню.

• Исчерпывающая и общедоступная документация.

Недостатки

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

• Диаграммы с множеством прямоугольников и стрелок могут выглядеть запутанными и сложными.

Пример
Дополнительная информация

• Документация на сайте www.idef.com.

• Документация на программный продукт Computer Associates BPWin[62].

3.2.7. Карты потока создания ценности

Карты потока создания ценности – это один из методов бережливого производства. (Не путать с другой нотацией – цепочкой создания ценности.) Карта потока создания ценности изображает физическое окружение и потоки материалов и продукции в производстве. Оригинальное название этой нотации в корпорации Toyota, где ее придумали, – «Карта потоков материалов и информации». Она используется для того, чтобы привязать к процессу затраты ресурсов и времени и таким образом дать представление о производительности.

Основные характеристики

• Очень простой набор символов.

• Может включать диаграммы, сделанные в других нотациях.

Для чего используется

• Чтобы вовлечь в анализ процесса его исполнителей.

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

• Там, где не требуются полноценные средства моделирования.

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

Преимущества

• Простота и легкость применения.

Недостатки

• Плоские модели.

• Репозиторий не предусмотрен.

• Невозможно использовать для решения сложных задач.

Пример
Дополнительная информация

• Публикации, посвященные бережливому производству и методу шести сигм.

3.3. Специализированные подходы к моделированию процессов

Рассмотренные ниже подходы (табл. 3.5) могут применяться в проектах моделирования и усовершенствования. Они позволяют проанализировать процессы со стороны предприятия в целом.


Таблица 3.5

Специализированные подходы к моделированию процессов[63]

3.3.1. Цепочка создания ценности

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

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

Основные характеристики

В зависимости от средства моделирования:

• иногда реализуется в виде диаграммы цепочки создания ценности;

• на схему могут накладываться исполнители, финансы, время, системы или специфические данные;

• может использоваться в сочетании с дорожками.

Для чего используется

• Для декомпозиции фрагментов процессов, непосредственно вносящих вклад в создание ценности для клиентов.

• Для изображения процессов верхнего уровня.

Преимущества

• Легко читается и понимается.

• Минимум неоднозначности благодаря простым связям.

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

Недостатки

• Не видны точки принятия решений.

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

Пример
Дополнительная информация

• Референтная модель компании The Value Chain Group[64].

• Диаграмму цепочки создания ценностей поддерживает ПО ARIS компании Software AG.

3.3.2. SIPOC

Аббревиатура SIPOC расшифровывается как supplier (поставщик), input (вход), process (процесс), output (выход), и customer (потребитель). Это шаблон документирования процессов, принятый в методологии «шесть сигм». Какого-то стандарта или предпочтительной нотации не существует; в принципе достаточно простой таблицы с соответствующими заголовками. Модель SIPOC часто используют, чтобы достичь первичного консенсуса относительно того, какие области процесса являются предметом исследования.

Основные характеристики

• Простая запись в столбик (без дорожек).

• Для заполнения ячеек можно использовать текст или понятные графические элементы.

Для чего используется

• Интенсивно используется на старте проектов шести сигм и бережливого производства.

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

• Для достижения начального консенсуса о границах проекта моделирования.

Преимущества

• Быстро и просто.

• Требует только простого шаблона в виде таблицы.

Недостатки

• Мало возможностей для углубленного сбора информации, проектирования и анализа.

• Может затормозить применение более мощных средств.

Пример
Дополнительная информация

• www.isixsigma.com.

3.3.3. Системная динамика

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

Основные характеристики

• Диаграммы причинно-следственных связей и петель обратной связи.

• Динамичность – анимированная демонстрация хода выполнения процесса.

Для чего используется

• Для отображения деятельности организации на макроуровне и имитационного моделирования ее общей производительности.

• Для изучения воздействия изменения параметров на процесс или на организацию в целом.

Преимущества

• Дает живое, движущееся, изменчивое изображение процессов верхнего уровня.

• Более понятна, чем статичная модель или текстовое описание.

Недостатки

• Непригодна для анализа проблем на уровне исполнителей или информационных систем.

• Непригодна для анализа внешних воздействий на процесс.

Пример

Рисунок 3.10 представляет собой статический снимок анимированной модели освоения новой продукции из статьи Джона Стермана (John Sterman), 2001 год.


Дополнительная информация

• Сообщество «Системной динамики»: www.systemdynamics.org.

• Программа PhD в Школе менеджмента MIT Sloan[65].

3.4. Уровни процессных моделей

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

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

На рисунке 3.11 приведен пример процессной иерархии, начиная с верхнего уровня процессов предприятия и заканчивая бизнес-процессами и потоками работ.

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

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

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

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

Иерархия процессных моделей также рассматривается в разделе 5.3.

Рекомендуемый подход: стандарт моделирования

Формализованный стандарт моделирования должен задавать число и название уровней в моделях «как есть» и «как будет»[66]. В прошлом эти стандарты могли быть независимыми от каких-либо внешних стандартов или используемых средств, но сейчас всё меняется. Позаботьтесь о соответствии внутреннего стандарта возможностям и ограничениям используемых средств моделирования. Например, хотя BPMN2.0 не является единственным стандартом в моделировании, он становится таковым применительно к системам BPMS. Это может потребовать включения BPMN в качестве составляющей внутреннего стандарта моделирования. Качественный стандарт моделирования должен в той или иной степени охватывать все уровни, показанные на рис. 3.11.



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

Интегрированные процессные модели

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

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


3.4.1. Модель процессов предприятия

Точка зрения предприятия

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

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

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

Модель процессов предприятия играет роль высокоуровневого «чертежа» организации. Она может включать или не включать вспомогательные и управляющие процессы.

Дополнительные области применения модели процессов предприятия

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

• наложены на ключевые показатели эффективности (KPI) и стратегические цели;

• использованы для приоритизации проектов и планирования ресурсов;

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

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

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

Примеры процессных фреймворков:

• простые многоуровневые или пирамидальные модели;

• референтная модель процессов APQC;

• цепочка создания ценностей Портера;

• специализированные отраслевые референтные модели для энергетики, нефтегазовой промышленности, телекоммуникаций, страхования.

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

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

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

• Основные процессы в модели APQC – «разработка видения и стратегии» (1.0), «проектирование и разработка продукции и услуг» (2.0), «маркетинг и продажа продукции и услуг» (3.0), «поставка продукта и услуг» (4.0) и «управление обслуживанием клиентов» (5.0).

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

Референтные модели, процессные фреймворки и архитектуры рассматриваются также в разделах 3.8 и 9.1.4.

3.4.2. Модели бизнес-процессов

Взгляд со стороны владельца процесса

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

• бизнес-контекст;

• описание бизнес-процесса;

• границы бизнес-процесса, в рамках которых выполняется анализ и внедряются изменения.

Этот взгляд находит отражение в моделях сквозных[67] бизнес-процессов: основных, вспомогательных, управляющих.

Модели бизнес-процессов:

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

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

3.4.3. Модели потоков работ

Взгляд со стороны операционного менеджера

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

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

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

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

3.4.4. Шаги выполнения задачи

И это не предел – модель можно детализировать еще глубже. Основное правило – детализировать процесс до уровня, достаточного для:

• решения ваших задач и

• решения своих задач другими участниками на следующих фазах проекта.

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

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

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

• провести совещание с разработчиками, чтобы выяснить, какая информация им понадобится в ходе разработки и тестирования ПО;

• позаботиться о документировании соответствия между пунктами требований и компонентами программного продукта. Это позволит гарантировать соответствие ПО потребностям исполнителей процесса.

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

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

Взгляд со стороны исполнителя

Те, кто непосредственно выполняет работу, обычно концентрируются на своих задачах (обязанностях, действиях, процедурах) и на шагах, из которых состоит выполнение этих задач. Шаги определяют, как выполняется работа.

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

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

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

3.4.5. Моделирование снизу вверх и сверху вниз

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

Моделирование снизу вверх

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

Моделирование сверху вниз

Сегодня все чаще моделирование процессов используется для:

• совершенствования масштабных, сквозных и кросс-функциональных бизнес-процессов, а также для

• управления эффективностью таких бизнес-процессов.

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

Золотое правило моделирования

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

3.5. Сбор информации о процессе

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

• прямое наблюдение;

• интервью;

• опросы;

• модерируемые совещания;

• веб-конференции.

3.5.1. Прямое наблюдение

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

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

3.5.2. Интервью

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

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

3.5.3. Опрос и письменные ответы

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

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

3.5.4. Модерируемые совещания

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

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

3.5.5. Веб-конференции

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

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

3.5.6. Участники моделирования

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

В качестве экспертов предметной области могут выступать:

• менеджеры высшего звена, определяющие динамику бизнеса на верхнем уровне;

• менеджеры среднего звена, определяющие механизмы мониторинга и контроля;

• рядовые сотрудники, непосредственно выполняющие работу, описываемую моделью.

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

3.6. Фреймворки и референтные модели

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

3.6.1. Моделирование с использованием фреймворка

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

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

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

• архитектурный фреймворк федеральных ведомств США FEAF[71];

• архитектурный фреймворк Министерства обороны Великобритании MODAF[72];

• архитектурный фреймворк Министерства обороны США DoDAF[73];

• архитектурный фреймворк TOGAF[74].

Ценность этих фреймворков двоякая: во-первых, они помогают справиться с экстремальной сложностью подобных организаций, а во-вторых, служат базой для сравнения разных проектов внутри одного ведомства. TOGAF, последний фреймворк в приведенном списке, является универсальной версией комплексного фреймворка, поддерживаемого организацией The Open Group. Большинство этих внешне различных фреймворков являются либо производными фреймворка, предложенного Джоном Захманом (John Zachman) в 1987 году, либо разработаны под влиянием его идей.

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

3.6.2. Использование референтных моделей

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

SCOR® и DCORSM

Консорциум The Supply Chain Council (SCC) разработал референтную модель под названием SCOR[75] в помощь организациям, стремящимся структурировать свою цепочку поставок для целей анализа процессов, сравнения с конкурентами и оценки эффекта усовершенствований. Она задает общий словарь и структуру проекта моделирования цепочки поставок, в то же время оставляя свободу действий в том, что касается детализации процесса на нижних уровнях.

Референтная модель DCOR[76], также принадлежащая SCC, структурирует последовательность операций в исследованиях и разработке.

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

Референтные модели рассматриваются также в разделе 9.1.4.

3.7. Методы и средства моделирования

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

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

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

Распространенным сегодня стало также использование программ для рисования или моделирования в сочетании с проектором и большим экраном. У такого способа есть несколько преимуществ. Модель видна всем участникам и может редактироваться прямо в ходе обсуждения. Не требуется переносить модель в другое программное средство после завершения сессии; ее можно быстро и легко отправить по электронной почте.

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

Средства моделирования рассматриваются также в разделе 10.3.

3.8. Валидация и имитационное моделирование

3.8.1. Применение имитационного моделирования

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

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

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

• Определение факторов, сильнее всего влияющих на эффективность процесса.

• Сравнение эффективности различных вариантов процесса в одних и тех же условиях.

3.8.2. Средства имитационного моделирования

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

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

3.8.3. Технологии имитационного моделирования и анализа нагрузки

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

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

Имитационное моделирование рассматривается также в разделах 5.9 и 6.13.

3.9. Ключевые понятия

Модели процессов

• Являются упрощенным представлением действий.

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

• Применяются для описания, анализа и проектирования процессов.

• Полезны в качестве документа для целей обсуждения, обучения и координации; проектирования и составления требований; в качестве инструмента анализа.

• Могут отражать текущее («как есть») состояние процесса, одно или несколько предложений по изменению и финальное состояние «как будет».

• Могут требовать проверки правильности посредством имитационного моделирования.

Точки зрения

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

• Например, процессная модель может отражать точки зрения: организации в целом, бизнес-процесса, операции (потока работ).

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

Нотации

• Существует множество различных нотаций и методов моделирования.

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

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

• Иногда целям проекта лучше соответствует не какая-то одна нотация, а комбинация нескольких.

Фреймворки

• Если проект должен соответствовать определенному фреймворку, то определите требования в этой части на ранней стадии.

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

Сбор информации о процессе

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

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

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

Глава 4
Анализ процессов

Вступительное слово: Элис Олдинг (Elise Olding), Gartner Inc.

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

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

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

Анализ процессов – это средство достижения цели, но не сама цель! Итогом работы должно быть создание ценности для организации. Одна из самых распространенных ошибок – останавливаться на анализе «как есть» слишком надолго, документируя каждую подробность. Я сталкивалась с организациями, у которых модели процессов заполняли комнаты от пола до потолка, а их бизнес-партнеры не желали эти схемы рассматривать. И не удивительно! Их изучение заняло бы несколько недель; даже я была ошарашена объемом.

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

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

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

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

4.0. Введение

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

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

4.1. Что такое анализ процессов

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

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

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

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

Ключевые факторы, подлежащие рассмотрению:

• стратегия бизнеса;

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

• ключевые проблемы на пути к достижению целей;

• вклад процесса в общую цепочку создания ценности;

• организация и бизнес-роли, обеспечивающие процесс.

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

4.2. Зачем нужен анализ процессов

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

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

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

Мониторинг эффективности процесса с непрерывным отображением метрик на панели приборов позволяет обнаружить рост стоимости или падение производительности процесса. Анализ позволяет понять и измерить результативность и производительность процесса.

Полученная в результате анализа информация включает следующее:

• понимание стратегии, целей и задач организации;

• бизнес-среда и контекст процесса (ради чего процесс существует);

• место анализируемого процесса в рамках более широкого кросс-функционального процесса;

• входы и выходы процесса, в том числе внутренние и внешние поставщики и потребители;

• роли в процессе подразделений-участников и точки передачи ответственности между подразделениями;

• оценки масштабируемости и потребления ресурсов;

• бизнес-правила, управляющие процессом;

• подходящие для целей мониторинга показатели эффективности процесса;

• перечень выявленных возможностей повышения качества или производительности.

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

4.3. Когда проводить анализ

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

4.3.1. Непрерывный мониторинг

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

4.3.2. События, инициирующие анализ

Чаще всего анализ процесса инициируется событиями. Ниже рассматриваются некоторые примеры.

Стратегическое планирование

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

Проблемы эффективности

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

Новые технологии

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

Слияние / поглощение / выделение активов

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

Нормативные требования

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

4.4. Роли участников анализа процессов

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

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

4.4.1. Характеристики оптимальной команды

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

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

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

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

4.4.2. Роли и обязанности в ходе анализа

Ниже следует описание обязанностей каждой роли (табл. 4.1). Компетенции, которыми должна обладать организация, практикующая BPM, рассматриваются в главе 8 «Процессная организация».


Таблица 4.1

4.5. Подготовка к анализу процессов

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

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

4.5.1. Выбор процесса

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

• процессы, взаимодействующие с клиентом;

• процессы, оказывающие большое влияние на доходы;

• процессы, обеспечивающие процессы, представляющие большую ценность для бизнеса;

• кросс-функциональные процессы, нуждающиеся в координации.


Далее каждому из этих факторов можно присвоить шкалу и определять приоритетность процесса исходя из суммы баллов.

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

4.5.2. Рамки анализа

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

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

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

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

4.5.3. Выбор методологии

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

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

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

Прагматичный анализ основан на стандартной последовательности шагов «Планирование – действие – проверка – корректировка» (PDCA)[80]. Проанализируйте процесс с точки зрения внутренних стандартов качества и передовых методов, уделяя внимание таким аспектам, как минимизация числа передач ответственности между подразделениями, создаваемая каждым действием ценность, контроль данных и ресурсов ближе к их источнику. Проверьте, все ли исполнители следуют одной и той же процедуре. Изучение всех практикующихся исполнителями вариантов выполнения работы и выбор лучшего – это возможность значительно усовершенствовать процесс при минимальном риске. На будущее можно предусмотреть средства контроля и направления работы, которые обеспечат следование выбранному пути при минимуме вариаций, исключений и ошибок.

4.6. Проведение анализа

Существует ряд хорошо известных и опубликованных методологий анализа процессов. Некоторые из них рассматриваются в главе 3 «Моделирование процессов» и главе 6 «Измерение эффективности процессов». Общие действия, относящиеся к анализу процессов, рассмотрены ниже. Они применяются и к новым, и к существующим процессам.

4.6.1. Бизнес-контекст

Чтобы понять, зачем нужен процесс, ответьте на такие вопросы:

• Что процесс должен сделать?

• Почему он появился?

• Чем вызвана необходимость анализа?

• Какие системы обеспечивают процесс и будут ли они поддерживаться в будущем?

• Как процесс вписывается в цепочку создания ценности организации?

• Соответствует ли процесс стратегическим целям организации?

• Представляет ли процесс ценность для организации и если да, то насколько критичную?

• Насколько хорошо он функционирует в текущей бизнес-среде и насколько хорошо он способен приспосабливаться к ее изменениям?

• Каковы основные риски по отношению к процессу (внутренние, внешние, из окружающей среды) и насколько процесс способен адаптироваться, чтобы сохранить работоспособность в случае их наступления?

4.6.2. Организационный контекст (культура)

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

• Кто из руководителей организации отвечает за достижение процессом требуемых результатов? Насколько они привержены изменениям и насколько уверены в успешности усовершенствований?

• Как к предложенным изменениям и усовершенствованиям относятся влиятельные вспомогательные подразделения: служба персонала, контроля качества, управления рисками, финансы и т. д.?

• Что стимулирует получение качественных результатов процесса? Как результаты процесса учитываются в вознаграждении за выполненную работу? Входит ли успех процесса в число показателей качества?

• Как организация планирует проводить обучение управлению изменениями? Будет ли успешная реализация изменения включена в число целевых показателей?

• Как трактуют причины изменений те, кого процесс затрагивает, и те, кто за него отвечает? Рассматривает ли организация мастерство процессной работы в качестве ключевой компетенции? Какие отношения, методы или показатели эффективности могут приводить к противодействию сотрудничеству и изменениям?

4.6.3. Метрики эффективности

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

• Достигает ли процесс заданных целевых уровней эффективности?

• Какой уровень обслуживания считается для процесса приемлемым? Соответствует ли время цикла текущему целевому показателю?

• Как мы узнаем, что процесс улучшился? Например, если показателем процесса является время, можно ли игнорировать стоимость? Или если показателем является стоимость, можно ли игнорировать время?

• Как организован мониторинг бизнес-процесса? Каковы ключевые метрики и какая предусмотрена реакция на отклонения?

• Осуществляется ли контроль метрик эффективности или процессных панелей приборов постоянно и непрерывно?

4.6.4. Взаимодействие с заказчиком

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

• Кто является заказчиком? Почему заказчики обращаются к процессу, а не куда-нибудь еще?

• Какие предложения по улучшению процесса поступают от заказчиков?

• Сколько раз заказчик взаимодействует с процессом? Нет ли среди этих взаимодействий лишних?

• Насколько понятным для заказчика является процесс и то, как он использует полученную от заказчика информацию?

• Как измеряется удовлетворенность заказчика? Соответствуют ли показатели удовлетворенности целевым значениям?

• Чего ожидает от процесса заказчик и в чем его цель?

• Если процесс является внутренним, как он прямо или косвенно отражается на заказчике?

4.6.5. Передача ответственности

Любая точка в процессе, в которой работа или информация передается от одной системы, человека или группы другой, называется передачей ответственности[81]. Точки передачи ответственности очень чувствительны к разрывам процессной логики и должны тщательно анализироваться. При этом можно руководствоваться следующими вопросами:

• В каком месте передача ответственности, вероятнее всего, приведет к задержке процесса?

• Есть ли в потоке информации или работ узкие места, вызывающие задержки ниже по потоку?

• Нельзя ли избавиться от каких-то передач ответственности?

• В каких местах потоки информации сходятся и соблюдаются ли при этом последовательность и сроки?

• Какими способами при передаче ответственности контролируются последовательность, сроки и зависимости?

4.6.6. Бизнес-правила

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

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

• Нет ли в бизнес-правилах разрывов логики, неоднозначностей или противоречий?

• Нет ли расхождений между правилами, которые управляют взаимозависимыми процессами?

• Соответствуют ли бизнес-правила целям организации?

• Не создают ли существующие правила помех в виде излишних согласований или шагов, которые следует устранить?

• Когда и почему бизнес-правила возникли и как они были сформулированы?

• К чему бы привело устранение определенных правил?

• Какой процесс управляет изменениями бизнес-правил?

4.6.7. Производительность

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

• Масштабируем ли процесс в сторону увеличения? В какой момент процесс откажет при возрастании объема работы?

• Насколько хорошо процесс масштабируется в сторону уменьшения? Каковы затраты на процесс, если он работает вхолостую?

• Что происходит с процессом, когда требуемые материалы или ресурсы задерживаются или недоступны?

• Что происходит ниже по потоку работ, когда процесс ускоряется или замедляется?

4.6.8. Узкие места[82]

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

• Какие факторы приводят к появлению узкого места, являются ли они человеческими, системными или организационными?

• Не связано ли узкое место с множественными передачами ответственности между группами?

• Является ли узкое место следствием внутреннего или внешнего ограничения? Что является ограничением: доступные ресурсы, бизнес-правила, зависимость от других процессов?

• Не приводят ли к появлению узких мест лишние участники процесса или барьеры между подразделениями?

4.6.9. Вариации

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

• Какая степень вариации допустима?

• Являются ли вариации необходимыми или желательными?

• В каких точках вариации наиболее вероятны? Можно ли их устранить и если да, то как?

• Поможет ли автоматизация устранить вариации?

4.6.10. Затраты

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

• Какова полная стоимость процесса с учетом частоты и обстоятельств его выполнения?

• Соответствует ли стоимость лучшим отраслевым стандартам?

• Можно ли уменьшить затраты за счет автоматизации или технологических усовершенствований? Если да, то каким образом и насколько?

• Насколько каждая из имеющихся возможностей снизить затраты повлияет на реализацию и на операционную прибыль?

4.6.11. Вовлечение персонала

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

Эту важную часть анализа помогут направить в правильное русло следующие вопросы:

• Насколько большие вариации привносит человеческий фактор? Является ли вариация желательной? Допустимой? Можно ли действие автоматизировать? Что бы это дало процессу? Как бы это сказалось на сотруднике и на культуре организации?

• Насколько сложна задача? Какой требуется набор навыков? Насколько обучены для выполнения задачи исполнители?

• Как во время выполнения задачи исполнители реагируют на внешние события?

• Как исполнитель определяет, что задача выполнена хорошо? Какие механизмы обратной связи способны его направить? Что дает исполнителю эта обратная связь – что он может изменить, обладая этой информацией?

• Знает ли исполнитель место задачи в процессе и какое влияние она оказывает вниз по потоку работ? Знает ли он, что происходит до начала задачи? Как исполнитель справляется с вариациями на входе задачи?

• Каким объемом информации располагает исполнитель при выполнении задачи? Достаточно ли ее?

• Есть ли признаки того, что процессы не являются прозрачными, понятными и повторяющимися, а выполняются по обстоятельствам? Например, часто ли приходится прибегать к героизму или вмешательству, чтобы обеспечить выполнение важной работы? Бывает ли так, что люди, роли которых выглядят похоже, выполняют разную работу или выполняют схожую работу по-разному?

4.6.12. Контрольные точки процесса

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

• Есть ли какие-либо требования законодательства или регулятора, соответствие которым надо контролировать в данном процессе?

• Оказывает ли процесс воздействие на окружающую среду, и если да, то надо ли его контролировать?

• Каким правительственным органам или органам регулирования подотчетен процесс и нужно ли им сообщать об изменении процесса?

• Какие существуют компетенции и роли, относящиеся к контролю за процессом?

• Хорошо ли задокументированы и усвоены структуры и процедуры, относящиеся к контролю за процессом? Подкрепляется ли контроль за процессом обучением и сертификацией?

• Обеспечивает ли структура административной подчиненности независимость налаживания качественного контроля за процессом от выполнения процедур контроля?

4.6.13. Прочие факторы

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

4.7. Сбор информации

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

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

• Сравнение эффективности компании с ее конкурентами или с показателями смежных отраслей.

• Основания для проведения анализа процесса и кто его заказал.

• Место процесса в организации.

• Люди, которые должны участвовать в проекте анализа процесса.

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

• интервью с людьми, вовлеченными в процесс;

• изучение записей/транзакций процесса (эти данные могут как подтвердить информацию, полученную в ходе интервью, так и разойтись с ней);

• наблюдение за тем, как фактически выполняется процесс на всем его протяжении;

• аудиторские отчеты, показывающие существующие в организации точки контроля.

Интервьюирование

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

Наблюдение

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

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

Исследование

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

4.7.1. Анализ бизнес-среды

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

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

Бенчмаркинг

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

Другой тип бенчмаркинга – сравнение процессов организации с процессами ее прямых конкурентов и поиск конкурентных преимуществ. Такие исследования могут проводиться в рамках SWOT-анализа[84]. Источниками информации при этом служат открытые публикации, отраслевые ассоциации, веб-сайты, клиенты, обзоры консалтинговых фирм. Основные характеристики процессов организации сопоставляются с таковыми у конкурентов.

И последний тип бенчмаркинга – поиск процессов, являющихся лучшими образцами[85] в других отраслях и схожих с анализируемым процессом. Например, компания онлайновой розничной торговли хочет реорганизовать обработку заказов, взяв на вооружение передовой опыт. Компания анализирует практику обработки заказов в других отраслях, чтобы позаимствовать для себя новые идеи. Это позволяет аналитикам избежать распространенной ловушки «группового мышления», когда организация смотрит только на себя или на свою отрасль. Подобный бенчмаркинг может инициировать изменения масштаба трансформации бизнеса.

Бенчмаркинг помогает оценить потенциал увеличения эффективности процесса и препятствия на пути его реализации.

4.7.2. Анализ информационных систем

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

Ниже рассматриваются некоторые распространенные методы анализа.

Анализ потоков данных

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

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

Бизнес-правила

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

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

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

Документация и перспективы дальнейшего использования

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

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

4.7.3. Анализ процесса

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

Моделирование

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

Анализ затрат по действиям

Анализ затрат по действиям (ABC)[86] – это просто список затрат, отнесенных на действия процесса. В сумме они дают стоимость процесса. Бизнес часто использует этот метод для оценки истинных затрат, связанных с продукцией или услугой. Он часто применяется в сочетании с другими методами из этого раздела.

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

Анализ корневых причин

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

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

Анализ чувствительности

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

• Чувствительность процесса. Это измерение того, насколько хорошо процесс выдерживает изменения различных параметров процесса, таких как увеличение/уменьшение некоторых входов или увеличение/уменьшение времени поступления некоторых входов. Это позволяет для любой комбинации параметров спрогнозировать, как быстро будет протекать процесс, с каким объемом работы он сможет справиться и где будет узкое место.

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

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

Анализ рисков

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

4.7.4. Анализ взаимодействия с человеком

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

Прямое наблюдение

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

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

Что следует выяснить в ходе такого анализа?

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

• Знает ли исполнитель, что представляет собой общий процесс, или он просто выполняет определенный регламент.

• По каким критериям исполнитель определяет, что очередная работа выполнена им удовлетворительно.

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

Работник может переключаться с рутинной, транзакционной работы на интеллектуальную[87]. В этом случае может понадобиться задать дополнительные вопросы, чтобы составить описание такой работы. Интеллектуальную работу следует также проанализировать на предмет наличия в ней бизнес-правил, которые потенциально возможно автоматизировать.

Ученичество

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

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

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

Имитация действий

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

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

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

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

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

Анализ организации рабочих мест

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

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

Анализ использования ресурсов

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

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

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

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

Анализ системы мотивации и вознаграждения

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

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

4.8. Отчет по результатам анализа

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

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

• Обзор текущей бизнес-среды.

• Назначение процесса (ради чего он существует).

• Модель процесса (что и как делается, входы и выходы).

• Потенциал повышения эффективности процесса.

• Внешние и глубинные причины неэффективности процесса.

• Избыточные действия, которые можно устранить, и ожидаемая экономия.

• Рекомендуемые решения и прочие рекомендации.

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

4.9. Рекомендации

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

4.9.1. Поддержка высшего руководства

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

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

4.9.2. Процессная зрелость организации

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

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



Оценка зрелости процессов помогает оценить потенциал процессной трансформации и вносит важный вклад в составление перспективных планов процессных изменений и инвестиций в IТ. Модели процессной зрелости рассматриваются в главе 9 «Управление процессами предприятия».

4.9.3. Не проектируйте решение на этапе анализа

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

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

4.9.4. Аналитический паралич

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

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

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

4.9.5. Выделение времени и ресурсов

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

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

4.9.6. Ориентация на заказчика

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

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

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

4.9.7. Понимание культуры организации

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

4.9.8. Опора на факты

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

4.9.9. Возможное сопротивление

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

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

Ключ к успешному преодолению сопротивления – вовлечение в анализ владельца процесса.

4.10. Заключение

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

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

4.11. Ключевые понятия

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

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

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

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

• клиентские процессы;

• процессы, оказывающие большое влияние на доходы;

• процессы, обеспечивающие процессы, представляющие большую ценность для бизнеса;

• кросс-функциональные процессы, нуждающиеся в координации.

Анализ должен показать связь процесса с бизнесом и выявить все имеющиеся нестыковки, как то:

• не достигаются целевые показатели эффективности;

• не оправдываются ожидания клиентов;

• передача ответственности приводит к разрывам;

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

• узкие места.

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

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

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

Глава 5
Проектирование процессов

Вступительное слово: Джим Сайнур (Jim Sinur), вице-президент, Gartner

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

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

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

Моделирование бизнес-процессов заранее

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

Проектирование через пользовательские интерфейсы

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

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

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

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

5.0. Введение

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

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

Проектирование процесса представляет собой проект, которым, как и любым другим проектом, необходимо управлять. Но, несмотря на критическую важность формального проектного управления, в этой главе оно не рассматривается, так как это отдельная и самостоятельная компетенция. Читателям, интересующимся этой темой, мы предлагаем обратиться к материалам Института проектного управления (PMI)[91].

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


5.1. Что такое проектирование процесса

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

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

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

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

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

5.1.1. Проектирование процесса

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

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

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



Всюду ниже мы будем принимать изображенную на рис. 5.2 структуру «процесс – подразделение – поток работ» как данность и для краткости называть ее просто «процесс». А работу внутри подразделения мы будем обозначать термином «поток работ».

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

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

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

5.1.2. Зачем нужно проектировать процессы

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

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

Это признают даже в тех компаниях, которые практиковали моделирование процессов. Факт тот, что большинство компаний лишь в общих чертах понимают, как организована работа на уровнях выше уровня отдельных подразделений. Конечно, исключения встречаются, но большинство компаний не может похвастаться детальным знанием своих процессов – включая даже те, которые используют для моделирования интегрированные системы управления бизнес-процессами (BPMS)[93]. Причина в том, что в большинстве компаний проекты в области BPM и бизнес-анализа тяготеют к тактическому уровню. Но ситуация постепенно меняется, и некоторые организации успешно связывают бизнес-архитектуру с процессной архитектурой и процессными моделями, тем самым делая более прозрачными бизнес-операции и их связь со стратегией.

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

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

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

5.2. Основы проектирования процессов

В этой главе мы рассмотрим: 1) описание процессов; 2) декомпозицию на подпроцессы; 3) бизнес-функции; 4) потоки работ на уровне бизнес-подразделений и 5) сценарии операций. Модель нового процесса должна рассматривать действия вне зависимости от того, какие подразделений их выполняют – это следствие кросс-функциональной природы процесса. Рассмотрение верхнего уровня процесса продолжается на уровне подпроцесса, где работа распределяется по бизнес-функциям и подразделениям. На уровне подразделения действия, относящиеся к данному процессу, объединяются с действиями в рамках других процессов, образуя поток работ. Полноценное перепроектирование должно принимать во внимание изменения на всех этих уровнях, в противном случае возможен негативный эффект в более широком контексте или прямой ущерб работе, выполняемой ниже по потоку.

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

Существует множество методов и подходов, позволяющих решать специфические проблемы и итерационно проектировать процессы: бережливое производство, шесть сигм, бережливые шесть сигм, функционально-стоимостной анализ затрат (ABC), SIPOC, анализ цепочки создания ценности, кайдзен, анализ видов и последствий отказов (FMEA), соглашения об уровнях обслуживания (SLA) и т. д.[94] У каждого свои возможности, которые необходимо сопоставлять с потребностями – любой инструмент должен использоваться по назначению. Там, где применяется BPMS, мы будем говорить о единой среде BPM, поддерживаемой BPMS.

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

5.2.1. Модель процесса не является моделью бизнес-архитектуры

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

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

Сочетание моделей этих двух видов дает перекрестный взгляд. Любая работа должна быть обеспечена определенной бизнес-способностью – это вопрос результативности[95]. Затем можно проследить последовательность выполнения работ и усовершенствовать управление. Исключая ненужную работу и автоматизируя все, что возможно, проектировщик добивается максимальной производительности[96].

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

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

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

5.2.2. Отправная точка

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

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

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

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

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

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

5.2.3. Стандарты сбора информации

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

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

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

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

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

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

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

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

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

Кроме того, многие проекты страдают от терминологической путаницы. Использование относящихся к BPM и процессной трансформации терминов и акронимов различается от компании к компании, от проекта к проекту и от одной проектной команды к другой. Частично это объясняется тем, что многие термины не имеют общепризнанных определений. Это, конечно, плохо, но гораздо хуже расхождение в терминах и определениях между разными подразделениями одной организации. Как показывает опыт, во избежание расхождений между подразделениями и между бизнесом и IТ необходимо давать определения даже вещам из разряда «это всем известно». Чтобы все друг друга понимали, определения должны быть согласованы с бизнес-руководителями, с IТ и бизнес-партнерами. Но тут возникает культурно-политическая проблема: чье определение будет признано истинным и выбрано для всеобщего употребления? Реальность такова, что выработка общего словаря является непростой задачей.

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

5.2.4. Управление проектированием процессов

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

Так как формальные подходы к BPM пока не получили широкого распространения, сегодня рабочие группы в основном сами определяют, какой подход они будут использовать. Это приводит к тому, что в большинстве компаний каждый проект BPM выполняется по-своему. Можно ожидать, что у каждого подхода окажутся свои сильные и слабые стороны, в зависимости от компании, ее культуры и поддержки со стороны IТ. Компания может воспользоваться этим опытом, чтобы проанализировать прошлые проекты и выработать на основе этих уроков собственную методологию, аккумулирующую удачные решения и обеспечивающую точность, качество и итоговый успех. Тот, кто стремится развивать более стратегический подход, получит также гарантию, что информация будет собираться не только для нужд конкретного проекта, но будет объединяться с информацией из других проектов, формируя модели сквозных процессов масштаба предприятия.

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

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

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

5.3. Выявление процесса – «как есть» или «текущее состояние»

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

5.3.1. Закладка прочного фундамента под изменения

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

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

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

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

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

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

5.3.2. Организация информации о процессе

Когда информация собрана и проанализирована, перед командой встает задача организации и консолидации огромного объема данных. Для организации общего репозитория сегодня используются либо популярные средства моделирования, такие как Visio, либо более функциональные, такие как Casewise, либо компоненты, входящие в состав BPMS. Эти средства позволяют перевести собранную информацию в формат графических диаграмм с несколькими уровнями детализации (процессная декомпозиция) – подпроцессов, действий, задач. Но хотя они и позволяют изобразить потоки работ в понятном виде, их возможности в части проектирования новой схемы бизнеса ограничены.

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

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

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

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

5.3.3. Уровни модели

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

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

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


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

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

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

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

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

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

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

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

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

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

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

Подробнее о том, как разрабатываются модели процессов, см. в главе 3 «Моделирование процессов».

5.3.4. Выявление процесса и потока работ

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

5.3.5. Как на самом деле устроен процесс

Многие задаются вопросом: почему я должен беспокоиться о модели «как есть»? Я изменяю компанию, почему просто не сосредоточиться на будущем состоянии? Ответ прост: потому что, прежде чем менять процесс, необходимо его понять. Вы не сможете просто создать концептуальную будущую модель бизнеса и рассчитывать на ее реализацию, не обеспечив возможность перехода от текущего состояния к будущему.

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

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

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

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

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

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

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

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

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

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

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

• Для процессов – подпроцессы и их взаимодействие.

• Для подпроцессов – бизнес-функции/сценарии и подразделения, которые их выполняют.

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

Примечание: эти уровни декомпозиции модели составляют процессную иерархию.

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

• Возможности для усовершенствования и ожидаемый эффект в привязке к части бизнеса, к которой они относятся.

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

• Используемые IТ-приложения и где они используются.

• Основная функциональность каждого IТ-приложения.

• Данные – где хранятся, как вводятся и как используются.

• Правила – писаные и неписаные.

• Процедуры принятия решений с вероятностями исходов.

• Нормативы качества/продолжительности/производительности и т. п.

• Политика внутреннего аудита и прочие требования.

• Требования к измерению эффективности.

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

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

5.4. Стратегические изменения бизнеса

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

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

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

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

5.5. Процессный анализ – достичь понимания бизнеса

Всё подвергайте сомнению. Не пренебрегайте ничем в поисках возможностей совершенствования.

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

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

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

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

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



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



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

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

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

Более подробное изложение процессного анализа см. в главе 4 «Процессный анализ».

5.6. Проектирование процессов и потоков работ – модель «как будет»

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



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

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

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

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

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

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

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

Группа, отвечающая за проектирование бизнеса, должна иметь представление о технических аспектах проектирования, создания и внедрения бизнес-усовершенствований. Аналогично группа от IТ должна иметь представление о подходах к трансформации бизнеса. Ограничения и доступные варианты будут сильно различаться в зависимости от того, опирается ли проектирование процесса на генерацию BPMS-приложений, на разработку информационной системы на. NET или на унаследованную систему на языке COBOL. Так как эти ограничения скажутся на проектировании новых бизнес-моделей и поддерживающих их приложений, их необходимо выявить и описать в начале проектирования.

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

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

• Проектирование нового процесса на соответствующую глубину детализации (согласно процессной иерархии).

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

• Описание сценариев процессной работы и выделение модулей на основе этих сценариев.

• Описание потребностей в данных.

• Описание бизнес-правил.

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

• Определение показателей успешности изменения и эффекта с точки зрения потребителя.

• Определение целевых уровней показателей нового процесса.

• Определение и проектирование бизнес-отчетности и отчетности по эффективности.

• Оценка величины разрыва между текущим и желаемым положением дел.

• Разработка требований и спецификаций изменения бизнеса и информационных систем.

• Проектирование на физическом уровне.

• Анализ и проектирование IТ-инфраструктуры.

• Имитационное моделирование, тестирование и приемка.

• Автоматическая генерация или разработка IТ-приложений.

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

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

• Разработка и реализация плана внедрения.


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

5.6.1. Эволюционный менеджмент: управление эволюцией бизнеса через изменения

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

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

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

При этом подход к реализации каждой версии на этом эволюционном пути – такой же, как и к изменению, нацеленному на конкретное усовершенствование.

5.6.2. Проектирование нового процесса

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

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

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

С появлением BPMS многие из этих традиционных проблем, ограничивающих возможность компании оптимизировать свои операции, становятся менее актуальными или даже полностью исчезают. Ключевые компоненты BPMS – моделирование процессов, управление правилами, генерация приложений, доступ к данным (SOA) и передовые средства измерения и мониторинга эффективности. Способность поддерживать очень быстрые изменения – самое большое преимущество BPMS. Как сказано в главе 10 «Технологии BPM», системы BPMS создают новую, интегрированную IТ– и бизнес-среду. Система BPMS и приложения, которые она генерирует из моделей процессов, моделей данных и правил, управляют выполнением задач. За изменением любой модели или правила следует повторная генерация приложения – это открывает возможность очень быстрого прототипирования и имитационного моделирования, позволяющего убедиться, что новая версия процесса работает как ожидается. Перенос приложения в промышленную эксплуатацию выполняется в один клик. Как результат, в среде BPM на основе BPMS изменения на любом уровне процессной иерархии (см. рис. 5.3) можно осуществлять в требуемом темпе.

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

Обсуждение всех относящихся к моделированию программных продуктов, действий и методологий выходит за рамки CBOK. У каждого есть свои сильные и слабые стороны, и оптимальный выбор определяется целями проекта, культурой организации, необходимостью генерировать приложения и существующей IТ-инфраструктурой.

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

5.6.2.1. Проектирование процесса «как будет»

На первом шаге проектирования рассматриваются изменения на уровне процесса в целом. Будут ли какие-то компоненты верхнего уровня (подпроцессы) добавлены или ликвидированы? Изменения на этом уровне добавляют или удаляют большие области работы.

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



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

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

• В чем цель этого процесса, подпроцесса, потока работ или действия?

• Не является ли он избыточными или похожим на уже имеющийся?

• Какие здесь есть проблемы, какие возникают вопросы к качеству и к контролю и почему они возникают?

• Почему необходим этот шаг?

• Какова его цель?

• Где он должен выполняться?

• Когда он должен выполняться?

• Кто лучше всех подходит для его выполнения?

• Адекватен ли уровень автоматизации?

• В чем основные проблемы?

• Как их можно устранить?

• Как сделать процесс максимально результативным (делать только то, что нужно)?

• Как сделать процесс максимально производительным (устранить лишние действия)?

• Как можно устранить выявленные лишние действия?

• Каким стандартам необходимо соответствовать?

• Как осуществляется мониторинг и контролируется достижение целевых показателей эффективности?

• Какие факторы ограничивают возможности изменения процесса, подпроцесса, потока работ, действия или сценария?

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

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

Если создаваемая ценность определена, значит, работа вносит свой вклад в продуктивную деятельность – «делает то, что надо»[98]. Таким способом мы избавляемся от работы, которая стала ненужной, но о производительности здесь речи не идет.

На этом первоначальном этапе создается фундамент новой модели. Если используется система BPMS, то на этом этапе в ней появляется новая модель.



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

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

5.6.2.2. Определение действий в рамках нового процесса

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

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

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

5.6.2.3. Проектирование изменений уровня задач и сценариев

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

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

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

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

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

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

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

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

Но модель процесса все еще может содержать разрывы, поэтому команда должна обратить внимание на потоки и на развилки и, по возможности, их упростить. Одновременно следует постараться избавиться от ручной работы везде, где возможно. Если используется BPMS, «белые пятна» можно заменить сгенерированными BPMS-приложениями. Если проектирование ведется с использованием традиционного ПО для моделирования процессов, необходимо обсудить с IТ возможности автоматизации и реалистичные сроки.

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

Мы рекомендуем параллельно вести проектирование нескольких версий модели «как будет» и обкатывать на них весь спектр идей от скромных усовершенствований до фундаментальных преобразований. Полученные результаты следует тщательно рассмотреть и включить лучшие находки в новую модель.

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

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

В случае использования BPMS списки задач, назначение исполнителей, учет графиков рабочего времени, отчетность и т. п. встраиваются в приложения, которые генерирует BPMS, и таким образом обеспечиваются автоматизированный контроль и мониторинг эффективности, см. главу 10 «Технологии BPM». Если BPMS отсутствует, необходимо совместно с IТ решить, что можно предпринять в этой области. Модель должна соответствовать имеющимся IТ-средствам.

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

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

Наконец проектирование завершено.

• Вся не добавляющая ценность работа исключена.

• Все проблемы рассмотрены.

• Все возможности усовершенствования бизнеса рассмотрены.

• Правила обоснованы и нормализованы.

• Ручная, неавтоматизированная работа устранена.

• Бизнес-сценарии упорядочены.

• Проанализировано возможное влияние изменений на всех уровнях процессной иерархии.

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

• Специфицированы потребности в автоматизации.

• Произведена оценка показателей новой модели по сравнению с исходной «как есть».

• Спроектирована система контроля для новой бизнес-модели и для проекта внедрения.

• Спроектирована система контроля эффективности, предупреждения о проблемах и другой отчетности.


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

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

5.6.2.4. Бизнес-правила – непрерывный поиск возможностей усовершенствования

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

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

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

Многие организации тяготеют к усложнению бизнес-правил. Отчасти это связано со стремлением сократить их число – многие стремятся представить все дерево принятия решения в виде одного правила, вместо того чтобы разбить его на отдельные решения и затем объединить их в набор правил. Помимо того что переусложненные правила труднее тестировать и использовать, они усложняют процесс. А чем сложнее процесс, тем выше вероятность сбоя. Вот почему важно ориентироваться на наборы правил и вырабатывать такие стандарты, которые позволят сохранять правила настолько простыми, насколько возможно.

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

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

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

5.7. Управление изменениями

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

О корпоративной культуре и управлении изменениями написана масса книг. Некоторые компании решают проблему одобрения изменений персоналом через создание формальных групп управления изменениями и выработку стандартов внедрения изменений в бизнесе и в IТ. Другие требуют, чтобы проект включал в себя человеческую составляющую и чтобы в нем уделялось внимание донесению до персонала причин изменений, намерений и планов.

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

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

5.8. Анализ и проектирование IТ-инфраструктуры

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

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

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

Вот некоторые вопросы, которые встанут перед IТ.

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

• Накладывает ли текущая инфраструктура ограничения на возможную модель бизнеса?

• Возможно ли быстро внедрить новую модель бизнеса?

• Как изменения в IТ влияют на организацию?

• Можно ли прибегнуть к поэтапному подходу?

• Каковы затраты на внедрение новой модели (включая обучение, программное обеспечение и т. д.)?

• Могут ли поставщики программного обеспечения помочь с внедрением?


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

5.9. Имитационное моделирование

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

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

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

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

5.10. Выводы

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

5.11. Ключевые понятия

Проектирование процесса заключается в разработке новой процессной модели, обеспечивающей соответствие операций бизнес-стратегии.

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

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

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

• Проектировать от действий, добавляющих ценность.

• Выполнять работу там, где это наиболее оправдано.

• Предоставлять потребителю единую точку контакта с процессом.

• Объединять процессы в кластеры.

• Уменьшать число передач ответственности между подразделениями.

• Уменьшать размер пакетной обработки.

• Предоставлять доступ к информации там, где она больше всего нужна.

• Вводить информацию один раз и давать к ней доступ везде.

• Перепроектировать процесс, прежде чем переходить к автоматизации.

• Проектировать исходя из желаемых показателей эффективности.

• Стандартизировать процессы.

• Рассматривать возможность перехода к удаленной совместной работе и аутсорсингу.


Проектирование процессов включает следующие действия.

• Моделирование с помощью специального программного обеспечения.

• Определение действий, составляющих процесс.

• Определение правил, диктующих ход процесса.

• Определение точек передачи ответственности.

• Определение метрик.

• Сравнение и бенчмаркинг.

• Имитационное моделирование и тестирование.

• Разработка плана внедрения.


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

Глава 6
Управление эффективностью процессов

Вступительное слово: Дэвид МакКой (David McCoy), управляющий вице-президент и почетный аналитик, Gartner
(© Gartner, Inc. 2012.)

Где-то между 2000 и 2001 годами, когда мы с Роем Шултом (Roy Schulte) руководили командой, представившей миру его концепцию мониторинга бизнес-действий (Business Activity Monitoring, BAM), мы обнаружили, что идея мониторинга «бизнес-действий» в реальном времени с помощью обработки событий, применения фильтров и аналитики вызывает большой интерес. Мне запомнилась одна наша презентация – первая в истории полномасштабная презентация BAM. Мы выступали совместно на одной из наших конференций, и аудитория была сильно ориентирована на технологии – вплоть до того, что несколько участников представляли компании, занимающиеся автоматизацией производственных процессов. Мы пытались донести мысль, что если что-то работает в производственном цеху, то это может сработать и в бизнесе. Сейчас, спустя 10 с лишним лет, мы видим, что BAM стал у BPM-экспертов дежурной темой и продать организации идею мониторинга эффективности процессов в реальном времени не так уж сложно. Однако, хотя BAM и завоевал место под солнцем, для многих концепция управления эффективностью бизнес-процессов в целом остается загадкой, и то, как эта деятельность осуществляется в большинстве компаний, оставляет желать лучшего.

Попросту говоря, легко измерять эффективность процессов и управлять ею в теории, но, когда требуется осязаемый результат, мы зачастую терпим неудачу. Иногда неудача обусловлена используемыми технологиями: плохо интегрированные системы, устаревшая инфраструктура, негибкие программные продукты, невозможность обработки событий – все это ведет к неудаче. Но я думаю, что основная сложность – это триединая проблема контекста, ценности и угла зрения[99]. Другими словами, обращаясь к управлению эффективностью процессов, мы обнаруживаем, что можем измерять что угодно. И чаще всего мы именно этим и занимаемся: измеряем все, что движется, но при этом упускаем из виду вещи более сложные, не лежащие на поверхности нашего «процессного мира».

Проблема контекста

Рассмотрим пример, который я описал в своем блоге[100]. В течение года мне часто приходится путешествовать вверх и вниз по горе Блад в штате Джорджия (США). Когда я еду вверх, то показатель «мили на галлон» резко падает. Но когда я еду вниз, позволяя силе тяжести на крутом уклоне делать свое дело, то показатель мгновенного расхода «мили на галлон» зашкаливает. В последней поездке мне удалось загнать этот показатель на отметку 99, упершись в предел, который программисты считали нереальным для автомобиля со средним расходом 25 миль/галлон. Это иллюстрация классического провала в управлении эффективностью процессов: ограниченность поля зрения.

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

Проблема ценности

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

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

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

Проблема угла зрения

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

Послушайте меня: все процессы отталкиваются от угла зрения. Угол зрения может отражать взгляд архитектора, бизнес-направления, IТ-отдела, консультанта, заказчика, поставщика и т. д. Идею угла зрения передает одно из моих любимых грандиозных слов: Weltanschauung. Когда-то в аспирантуре мне повезло изучать методологию проектирования вместе с экспертами мирового уровня, и мы почему-то постоянно возвращались к этому термину. Weltanschauung по-немецки означает «мировоззрение», я рассказывал об этом в своем блоге, если вас интересуют подробности. Идея заключается в том, что ваше мировоззрение – Weltanschauung – влияет на ваш угол зрения. Можно даже сказать, что это и есть ваш угол зрения. То, как вы воспринимаете реальность, накладывает отпечаток на то, как вы проектируете ваши процессы.

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

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

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

6.0. Введение

Управление эффективностью процессов включает в себя как понимание того, что измерять, так и понимание того, как измерять. По этой причине данная глава разделена на две части: что измерять и как измерять эффективность.

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

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

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

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

Управление эффективностью процессов. Раздел I

6.1. Что такое управление эффективностью процесса?

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

Это определение применяется по-разному на уровне процесса и на уровне потока работ: при переходе от одного к другому меняются контекст и уровень мониторинга.

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

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

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

В предположении, что процесс идентифицирован и описан корректно, мы должны спросить: результативен ли он, соответствует ли он ожиданиям? Уместно задаться вопросом, не выполняются ли необязательные подпроцессы или действия? В ходе такой оценки мы также должны, забыв о прошлом, задуматься, содержит ли процесс все необходимое для получения желаемого результата. Все должно оцениваться с точки зрения вклада в конечную продукцию или услугу. Для такой оценки хорошо подходят техники «бережливого производства». Целью является доведение до совершенства того, что следует делать, а не просто того, что мы делаем сейчас.

Избегайте допущения, что все в порядке и можно приступать к работе, – вы должны все проверить и обосновать. Задайтесь такими вопросами:

• Почему мы занимаемся теми бизнесами, которыми занимаемся? Не исключают ли они друг друга?

• На каких рынках мы работаем и с какими вызовами мы сталкиваемся на этих рынках?

• Что конкуренты делают лучше, чем мы?

• Кто является нашими целевыми заказчиками и чего они хотят?

• Даем ли мы им то, что они хотят? Что они о нас думают?

• Что нам следует делать, чтобы поддержать наш бизнес?

• Соответствует ли сегодняшний бизнес-процесс стратегической цели?

• С какими самыми большими проблемами мы сталкиваемся?

• Какие проблемы необходимо решить в первую очередь?

• Что нам требуется для их решения?


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

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

6.1.1. Привязка процессов к организации

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

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

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

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

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

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

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

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

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

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

6.1.2. Выбор того, что имеет смысл измерять, определяется зрелостью процессов

Приступая к управлению эффективностью процессов, компания должна реалистично оценивать свои возможности, исходя из достигнутого уровня процессной зрелости.

Процессная зрелость: характеристики и способности, которые определяют текущее состояние компании на пути к пониманию и управлению процессами.

Модель процессной зрелости – это путь от чисто функционального взгляда на работу к процессному. На этом пути компания, как правило, будет проходить определенные уровни или стадии зрелости, определяемые ее способностью осознавать свои процессы и управлять ими. Способность компании измерять эффективность работы на любом из уровней (отдельная задача, поток работ или процесс) связана с процессной зрелостью, поскольку на каждом уровне зрелости компания понимает процессы немного по-разному и обладает соответствующей данному уровню инфраструктурой поддержки процессов. Например, если компания находится в начале своего пути к управлению процессами, она не в полной мере будет понимать, что такое процесс и как ее процессы взаимодействуют между собой. Также не будет понимания того, как фрагменты работы связываются в единое целое и как их следует измерять. На данном уровне измерение эффективности процессов попросту невозможно. То же самое справедливо для данных. Если компания не способна с легкостью извлекать данные из обслуживающих процесс приложений, то определенные типы измерений и бизнес-аналитика ей окажутся недоступны. Таким образом, место компании на процессном пути (в соответствии с моделью процессной зрелости) способно помочь сформировать правильные ожидания от измерения эффективности и указать ясный путь к усовершенствованию мониторинга, измерения и отчетности.

Примечание: в этой главе мы используем термин «процесс» в трактовке ABPMP. Вкратце процесс – это все действия, необходимые для создания конечного продукта или услуги, и увязывание всей необходимой для этого работы, невзирая на границы внутри организации.

Зачастую желание управлять эффективностью и получать отчетность невозможно удовлетворить из-за разрыва между тем, что компания способна измерить, и тем, что требуется руководству. Поэтому, приступая к измерению эффективности процессов, необходимо оценить свой уровень процессной зрелости. Это непростая задача, учитывая, что многие компании плохо понимают, что такое процесс, что процессы могут в себя включать и как они взаимодействуют.

Следующая проблема заключается в том, что лишь немногие готовы услышать, что им нужно изменить свой взгляд на организацию или что они должны переосмыслить кажущиеся им стандартными термины и определения. Убедить людей изменить себя и свой взгляд на вещи даже сложнее, чем убедить измениться компанию. Компании сопротивляются переменам – это не новость. Но люди ненавидят перемены и иногда не ограничиваются просто сопротивлением, а активно с ними борются. Борьба может быть коварной и принимать разнообразные формы: приходилось вам встречать людей, которые брали на себя обязательства, а потом о них не вспоминали? Модель процессной зрелости здесь оказывается полезной, так как она создает фреймворк, который люди могут понять и на который они могут опереться. Она также помогает им принять решение: отправиться в путь или остаться там, где они находятся сейчас. В любом случае она помогает определить будущую стратегию и подход к управлению процессами, а следовательно, к измерению их эффективности.

Если модель процессной зрелости принимается, она становится руководством для определения и проработки плана процессной эволюции. Этот план покажет, в какой точке на пути процессной зрелости, по мнению компании, она находится и что нужно сделать, чтобы перейти на следующий уровень. В дальнейшем на этой основе определяются проекты и средства, а также формируются ожидания от процессных измерений.

Мы настоятельно рекомендуем использовать общепринятые, формальные модели процессной зрелости. Самостоятельно разработанная модель будет учитывать особенности компании, но не будет столь же хорошо продумана, как стандартные отраслевые модели, и поэтому заведомо окажется слабее.

Важно также отметить, что внутри компании различные рабочие группы, подразделения, бизнес-направления, дочерние предприятия и т. д. могут находиться на разных уровнях зрелости. Это же справедливо в отношении отдельных процессов: некоторые могут быть описаны, а некоторые даже не выявлены. Модель зрелости является частью формализованной стратегии управления процессами – дорожной картой, которая показывает текущий уровень понимания процессов и процессного управления и план его внедрения.

Существует много формальных моделей на выбор. Фокус в том, чтобы выбрать ту модель, которая будет воспринята большинством руководства компании. Адаптировав выбранную модель, вы получите дорожную карту повышения зрелости процессного управления и, опираясь на нее, будете развивать способности измерения процессов. Нужно только позаботиться о том, чтобы выбрать модель, основанную на бизнесе, а не на IТ. Технологии обеспечивают процессы и их измерение. Они не описывают их, если только вы не обладаете зрелой операционной средой BPM на основе BPMS, которая хранит модели и бизнес-правила всей компании. Дополнительную информацию см. в главе 9 «Управление процессами предприятия».

Для данной главы мы выбрали фреймворк из модели процессной зрелости Forrester Research. Однако, как уже было сказано, у Gartner и у многих других тоже есть хорошие модели процессной зрелости, и вам следует их изучить, чтобы выбрать наиболее подходящую для вашей компании.

Forrester Research делит процессную зрелость на пять стадий, или уровней, как показано в табл. 6.1.


Таблица 6.1

Модель процессной зрелости Forrester[103]


Опросы показывают, что большинство компаний находятся на уровне модели процессной зрелости 0, 1 или 2. Хотя многие пытаются стать процессно-ориентированными, то есть перейти на более высокий уровень процессной зрелости, выполнить такой переход удается немногим. Если применить эту модель к управлению эффективностью процессов, то мы увидим, что способности измерения эффективности можно привязать к уровням модели процессной зрелости.

Одно из оснований для такой привязки – тот факт, что даже в наиболее сложных видах IТ– и бизнес-операций измерение связано с пониманием. Если компания не осознает процесс, то она не может увидеть его целиком, как кросс-функциональный, и все, на что она способна, – это измерять эффективность внутри обособленных бизнес-подразделений. Она не способна связать эту информацию воедино, чтобы увидеть процесс как совокупность взаимосвязанных работ. Это сказывается на измерении эффективности, контроле качества, учете затрат, решении проблем и т. д.

Изучив модель процессной зрелости Forrester, мы увидим, что измерение эффективности принимает разные формы на разных уровнях зрелости. Эти формы вырабатываются при переходе с уровня на уровень по мере добавления новых возможностей мониторинга, измерения и отчетности. Они также предполагают наличие IТ– и бизнес-окружения, способных обеспечить автоматизированные мониторинг, измерение и отчетность. На начальных стадиях процессной зрелости многие компании делают выбор в пользу составляемых ручных отчетов и проверок качества продукции.


Таблица 6.2

Уровни процессной зрелости и показатели эффективности


Ориентируясь на перечисленные уровни, компания может проложить свой путь совершенствования измерения эффективности, в котором глубина понимания процессов коррелирует с измерениями и со способностью реализовывать серьезные программы автоматизированного измерения. Дальнейшее обсуждение в этой главе также ссылается на уровни зрелости модели Forrester. Далее мы представим список того, чем можно воспользоваться для развития способности измерения и мониторинга эффективности.

6.1.3. Развитие способности измерения процессной эффективности

Примечание: в таблицах ниже (табл. 6.3) первая строка взята из модели процессной зрелости Forrester Research. Вторая строка – комментарии ABPMP относительно измерения эффективности для соответствующего уровня зрелости.


Таблица 6.3

Описание процессной зрелости для уровня 0


Как было сказано выше, очень многие компании мыслят строго функционально и пока не задумываются о процессах. Другие осознают существование процессов, но смотрят на них как на последовательность из нескольких шагов в рамках подразделения. Эти компании находятся в начале своего пути к BPM.

На этой стадии развития руководство компании может ожидать множества различных мнений о том, что такое процесс и как его нужно измерять. Некоторые группы попробуют использовать метод «шесть сигм», но широкого применения в процессах он не получит, и результат окажется ограниченным.

Мониторинг эффективности останется практически неизвестным. Возможности компании в части мониторинга работ, измерения улучшений или соответствия стандартам или KPI, а также оценки эффективности будут очень ограничены. Измерения на данной стадии процессного развития компании будут находиться в зачаточном состоянии, с преобладанием узконаправленной отчетности постфактум.

Так как компании на данном уровне процессной зрелости не понимают свои процессы и то, из каких работ они состоят, измерение эффективности процессов для них недоступно. Измерение эффективности на данном уровне зрелости фокусируется на событиях, потоках работ или локальных проблемах. Возможности отчетности, как правило, ограничены, и способность объединять данные из разных источников остается делом будущего (табл. 6.4).


Таблица 6.4

Описание процессной зрелости для уровня 1


По мере осознания необходимости видеть свои процессы компании также осознают, что отсутствие понимания процессов является сдерживающим фактором. За возросшим пониманием следует признание того, что процессы в компании непоследовательны и дают изменчивые результаты. В этот момент многие компании в более широком масштабе начинают внедрять шесть сигм, бережливое производство и другие подходы к улучшению, и это приносит некоторую пользу. Но эти усилия сосредоточены, как правило, на передовых бизнес-направлениях и ключевых процессах.

Измерение эффективности, как правило, сосредоточено на соответствии заданному уровню качества или на снижении затрат отдела – обычно путем сокращения штата. Измерение эффективности становится целью многих (но не всех) руководителей. Некоторые руководители также пытаются определить кросс-функциональные процессы и построить их модели. Модели процессов, как правило, просты и не обеспечивают мониторинг и отчетность по эффективности.

Однако, если определение процессов не поддерживается высшим руководством, усилия по измерению эффективности процессов часто остаются некоординированными и ограничиваются фрагментами процесса в рамках подразделения, то есть потоками работ. Отчетность не охватывает процессы целиком, только некоторые фрагменты рассматриваются как взаимосвязанные. Невозможно встроить измерение эффективности в то, что еще целиком не осознанно, то есть в процесс. Измерения по-прежнему нацелены на немногие отдельные задачи потока работ, а более масштабные измерения остаются недостижимыми. Измерение эффективности в более широком масштабе, как правило, недостижимо из-за того, что только часть руководителей подразделений готова к измерению своей работы в контексте процесса (табл. 6.5).


Таблица 6.5

Описание процессной зрелости для уровня 2


Растущее осознание процессов проявляется в попытках достичь сквозного взгляда на какие-то выделенные процессы. На этом этапе некоторые руководители пытаются улучшить работу процессов с помощью назначения KPI. Появляется понимание важности бизнес-правил. Однако процессы все еще полностью не выявлены, и лишь немногие (в лучшем случае) точно описаны. Простые средства моделирования процессов могут применяться, но модели разнятся по содержанию и качеству, и лишь немногие поддерживаются в актуальном состоянии. К тому же эти первые процессные модели оторваны от повседневной работы.

Все измерения по-прежнему сводятся к локальным инициативам шесть сигм, ручному анализу потоков работ в рамках контроля качества и ручным подсчетам выполненных элементов работы. Данные информационных систем по-прежнему разделены, и получить обобщенную информацию из различных систем и баз данных без дополнительного программирования затруднительно. Тем не менее отчетность улучшается по мере того, как руководители начинают осознавать процессы и свою роль в них.

Вследствие возросшего понимания процессов руководители могут инициировать ручной сбор информации для измерения эффективности. Измерение эффективности описанных процессов все еще остается на базовом уровне и не обладает гибкостью. Оно также требует значительных усилий по дополнительному программированию (табл. 6.6).


Таблица 6.6

Описание процессной зрелости для уровня 3


Тем временем большинство процессов уже определены и описаны. Внедрена BPMS, и значительная часть деятельности осуществляется в операционной среде BPM с использованием BPMS. Процессы полностью обозримы, включая все взаимодействия с другими процессами и внешними партнерами. Руководство понимает процессы и использует формальные кросс-организационные модели процессов. Процессы декомпозированы на подпроцессы и разбиты на действия и потоки работ в привязке к подразделениям компании. Использование информационных систем теперь можно отследить.

Унаследованные и приобретенные/арендованные информационные системы интегрированы с BPMS и используются для тех операций, которые не поддерживаются BPMS. Данные из BPMS и унаследованных систем в основном доступны для отчетности. Но формализованное измерение эффективности еще не получило широкого распространения и по-прежнему нуждается в определении и развитии, чтобы соответствовать растущей потребности в оперативной информации (табл. 6.7).


Таблица 6.7

Описание процессной зрелости для уровня 4


Этот уровень характеризуется полным внедрением операционной среды BPM с использованием BPMS. В таких компаниях процессы хорошо описаны и управление ими формализовано. Такое управление обычно представляет собой дополнительную структуру, наложенную на организацию. Эффективность процессов и потоков работ измеряется: 1) в близком к реальному времени, что позволяет оперативно вмешиваться при возникновении проблем, и 2) для нужд бизнес-аналитики и улучшенной отчетности. Обычные операционные метрики и метрики шести сигм измеряются и используются в управлении компанией.

Измерение эффективности теперь интегрировано в текущую деятельность. Панели приборов в близком к реальному времени информируют о резервах, проблемах и выдают рекомендации с помощью машин логического вывода, опирающихся на события и ситуативные бизнес-правила. Измерение эффективности находится в процессе перехода от отчетности постфактум к управлению эффективностью в реальном времени.

На этом уровне возможно реализовать непрерывное улучшение (табл. 6.8). Происходящие в компании операционные изменения быстро отражаются в процессах, поддерживающих их системах и данных. Законодательные предписания быстро выполняются. Основанные на измерении эффективности (с помощью таких техник, как шесть сигм) изменения могут быть спроектированы, протестированы и внедрены в течение недель. Такая среда позволяет внедрять изменения достаточно быстро, чтобы реагировать на каждую возможность для улучшений. Сначала выполняется начальная оптимизация текущей деятельности, а затем оптимизация продолжается по мере обнаружения проблем и определения требуемых изменений.


Таблица 6.8

Описание процессной зрелости для уровня 5


Измерение эффективности теперь встроено в процессы с помощью BPMS и внешней отчетности. Для обнаружения проблем и быстрой реализации мер по их исправлению используются как традиционная отчетность по управлению эффективностью, так и бизнес-аналитика.

6.1.4. Подготовка почвы

Мы рассмотрели финальную точку эволюции процессного управления и измерения эффективности. Здесь они соединяются воедино – измерение становится основой управления. У большинства компаний этот путь занимает годы и подразумевает долгосрочную стратегическую приверженность высшего руководства.

Но, прежде чем всерьез заниматься измерением эффективности, рекомендуется честно оценить, в какой точке пути к управлению процессами компания находится в настоящий момент и каковы ее возможности в части реализации каких-либо измерений или подходов.

6.1.5. Решение не той проблемы

При создании любой системы измерения эффективности вы должны позаботиться, чтобы в фокусе ее внимания оказались правильные вопросы и правильные фрагменты процесса. Чтобы определить, что нуждается в измерении, обратите внимание на законодательные требования предоставления отчетности, требования финансовой отчетности, сравнение текущей эффективности с KPI и контрольными точками в работе, сравнение невыполненных заказов и объемов со стандартами, сравнение качества и стандартов, отходы, брак и т. д.

Помимо этих привычных измерений эффективности, следует также принять во внимание суждения, предпочтения и удовлетворенность различных внешних и внутренних заказчиков, так как выходы одного подпроцесса (подразделений) являются входами для другого.

Не все сказанное выше пригодно для каждой компании; не существует единого списка, применимого для любой ситуации.

6.2. Что такое эффективность процесса?

Простой вопрос, на который нелегко ответить. Сложность в том, что все зависит от обстоятельств.

Компании, находящиеся на разных уровнях понимания эффективности и обладающие очень разными техническими возможностями получения отчетности, приходят к разным ответам.

Эффективность процесса: измерение определенных операционных характеристик, заданных KPI, стандартами, трудовыми соглашениями, финансистами, передовым отраслевым опытом, ISO и т. д. В ходе измерения компания анализирует один или несколько процессов и взаимодействие между ними и сравнивает их эффективность с заданными критериями.

Некоторые вопросы, помогающие выяснить, что означает эффективность процесса.

• О какой характеристике эффективности идет речь? – Например, затраты? По сравнению с чем? – Качество? Качество чего? Как оно определяется? – Время цикла на единицу продукции?

• С чем измерения сравниваются и что они включают? Например, речь идет только о скорости или о скорости при заданном качестве?


То есть в действительности ответ не очевиден. Он зависит от того, как вы определяете и как выполняете измерения, и от того, с чем сопоставляете результаты. К тому же измеряемые показатели варьируются в зависимости от отрасли, направления бизнеса, подразделения и руководителя. Вот почему любое измерение эффективности должно начинаться с определения того, что вы будете измерять, зачем вы будете это измерять и с какими значениями будете сравнивать. Без этого вы запросто можете начать измерять не то, не так и сравнивать полученные результаты с произвольными нормативами.

Чтобы с этим разобраться, рекомендуется организовать рабочую группу по измерению эффективности. Это вопрос определений, и возможны различные интерпретации. Тут необходим контроль – невозможно выиграть в игре, результаты которой интерпретируются произвольным образом.

Итак, для начала должен быть список того, что нужно измерять и почему. Важно, чтобы все ключевые руководители вошли в рабочую группу. Если они не станут участвовать, то они не будут вовлечены. Это означает, что любой показатель может стать предметом дебатов и кое-кто может отказаться принять результаты. Правда в том, что, если руководители не принимают участия в работе рабочей группы, измерение эффективности обречено на неудачу. В случае возникновения проблем следует обеспечить обязательное участие с помощью вышестоящего руководителя. Если сопротивление исходит от самого руководителя, то неизбежен провал – оценка эффективности будет спущена на более низкий уровень потока работ или задачи. В такой ситуации необходима поддержка со стороны первого лица.

Протокол рабочей группы по измерению эффективности.



Когда все согласились с перечнем того, что нужно измерять, необходимо определиться со способом измерения. К перечню того, что будет измеряться, надо добавить процесс, подпроцесс или поток работ.



Затем участники рабочей группы должны определить, какие показатели необходимо измерять, чтобы получить обоснованные результаты.



И наконец, участники рабочей группы должны определить, как следует выполнять каждое измерение (формула, счетчик и т. п. и с чем сравнивать – KPI, стандарт и т. п.).



Если назначен сотрудник или группа, ответственные за измерение и точность/качество, то они также должны быть указаны.



При желании сюда можно добавить уточняющую информацию. Как и со всем, что мы рекомендуем, эта таблица может адаптироваться под нужды компании. Объект измерения не столь важен, ведь он может меняться по мере приобретения руководителями опыта в использовании этой информации и по мере продвижения компании к более высоким уровням зрелости управления процессной эффективностью. Что действительно важно, так это то, чтобы менеджеры, ответственные за результаты измерения, участвовали в выработке как подхода к измерению, так и формул для измерения.

6.2.1. Реальность

Хотя вся эта деятельность замечательно выглядит в теории, на практике все обстоит по-другому. Прежде всего, во многих компаниях она не формализована. Компании вроде UPS, у которых процессы хорошо описаны и которые измеряют все, что можно, следует рассматривать как исключения, так как в них имеется зрелое, процессно-ориентированное руководство. Другие компании, такие как Sloan Valve и Raymond James Financial, находятся на пути к процессно-ориентированному взгляду. Если они совершат этот переход, то управление процессной эффективностью не заставит себя долго ждать.

На пути к управлению эффективностью процессов важно понимать, что то, что менеджмент считает важными индикатором вначале, долго не продержится: он будет меняться с появлением доступа ко все новым данным и с повышением гибкости манипулирования ими. Вероятно, эти изменения будут связаны с повышением уровня процессной зрелости компании. Хотя потребность в отчетности в точности предсказать невозможно, можно быть уверенными, что с течением времени, по мере роста возможностей и поиска и доступа к данным, использование информации будет становиться все более изощренным.

Сегодня для большинства компаний достаточно новым является сам процессный взгляд, а измерение эффективности процесса будет еще большей новизной. Поэтому очень важно в этой ситуации управлять ожиданиями. Легко пообещать слишком много и не оправдать ожидания – это серьезно подорвет доверие. Поэтому, прежде чем давать обещания, убедитесь в способности их сдержать, основываясь на реалистичной оценке способности компании обеспечивать измерения.

6.2.2. Чем измерение эффективности процессов отличается от измерения эффективности потоков работ?

Как отмечалось выше в CBOK и в этой главе, мы обнаружили, что очень многие компании определяют процесс и управление им как работу, совершаемую в рамках отдельного подразделения. ABPMP официально не согласно с таким определением, но для многих компаний это реальность, и потому этому вопросу следует уделить внимание.

На практике эффективность потока работ может быть измерена примерно так же, как и эффективность процесса, за исключением того, что поток работ относится к действиям в рамках подразделения и его компьютерных систем, правил, баз данных, веб-сервисов, веб-порталов, интерфейсов, унаследованных приложений. Это – часть процесса, и, чтобы составить процесс, эта информация должна быть консолидирована с информацией о связанной работе других подразделений.

Однако в зависимости от того, в какой точке находится компания на пути к процессной зрелости, она может не обладать чем-то большим, чем измерение эффективности потока работ, или не видеть необходимости в этом. Также весьма возможно, что независимо от уровня процессной зрелости улучшения будут нацелены на потоки работ подразделений или даже на задачи. Это особенно характерно для многих проектов улучшения потребительского опыта взаимодействия. В таких проектах эффективность измеряется через призму улучшений в рамках данного проекта. Это может потребовать особого внимания при проектировании решения и встраивании измерения эффективности в поток работ.

Согласно определению ABPMP, «процесс» является кросс-организационным и включает в себя все работы, необходимые для создания и предоставления продукции или услуги. При этом процесс может быть разбит на подпроцессы, которые выполняются подразделениями как последовательность взаимосвязанных и последовательных действий – на потоки работ. После того как эта структура определена, можно организовать мониторинг процесса путем объединения информации на уровне потоков работ, включая передачу ответственности между подразделениями.

Если в наличии имеется операционная среда BPM с использованием BPMS, то такое измерение делается достаточно просто на основе информации из BPMS и связанной с ней базы данных. Но, если работа подразделения обеспечивается традиционной компьютерной системой, сбор информации для мониторинга и измерений потребует дополнительного программирования и переработки программных интерфейсов к данным унаследованных приложений (всех систем, используемых подразделениями, участвующими в измеряемом процессе).

Вопросы, которые мы сможем задавать, будут зависеть от того, на какой уровень мы их будем адресовать: процесса или потока работ. На уровне потока работ внимание должно быть сосредоточено на перемещении результатов работы от одного действия к другому и на участках, где возникают проблемы с качеством или какие-нибудь еще. На уровне процесса внимание сосредоточено на передаче результатов работы между отделами и на качестве результата, передаваемого следующему подразделению в рамках процесса. При этом измеряемые величины на обоих уровнях будут практически одними и теми же: время цикла, качество, точность принятия решений и т. д. Отличие, таким образом, заключается в контексте и в том, как эту информацию можно использовать для улучшения деятельности.

6.3. Что можно получить от измерения эффективности процессов?

В значительной степени это зависит от обстоятельств. Это определяется несколькими факторами, в том числе такими:

• насколько гибко можно извлекать данные из нескольких компьютерных систем;

• понимание процессов – уровень процессной зрелости;

• изощренность поднимаемых вопросов эффективности и измерений действий, качества и т. д.;

• соглашение о том, что измерять и как измерять;

• способность IТ создать гибкую систему измерения эффективности;

• представление отчетности и возможность углубления в данные;

• одобрение измерений эффективности теми, чьи показатели будут измерять.

Примечание: порядок пунктов в этом списке не отражает их важность, сложность и т. п.

Эта информация станет основой для разовых и для непрерывных усовершенствований.

У любой компании способность измерять эффективность процесса напрямую связана со способностями, перечисленными в моделях процессной зрелости. Следовательно, для того чтобы сформировать ожидания и создать план развития измерений, необходимо сопоставить эти модели с возможностями компании по измерению и предоставлению отчетности. Это позволит компании нарастить базовые способности, необходимые для любых измерений. В результате руководство сможет определить, какая информация ему необходима, а затем понять, что требуется для сбора этой информации и для формирования отчетности.

Для многих руководителей сбор этой информации направлен на поддержку таких подходов, как шесть сигм или ABC. Другие ориентированы на более стратегические подходы: бизнес-аналитику с возможностью углубления в данные и имитационным моделированием[104]. В любом случае измерение эффективности может обеспечить всесторонний взгляд на текущую деятельность с любым уровнем детализации: процесс, поток работ или задача. Кое-что из того, что можно измерять, рассматривается ниже в этой главе.

На практике использование компаниями отчетности по эффективности процессов будет эволюционировать. На первом этапе могут измеряться не те показатели, и, как следствие, информация может быть неполной, частично некорректной, или ее полезность будет ограничена. По мере роста понимания руководством информации и того, как ее можно использовать, содержание информации и способ ее представления будут изменяться. Скорость этой эволюции определяется реальным использованием информации об эффективности: чем больше она используется, тем лучше руководство понимает реальную потребность в отчетности и способы использования информации. И как это всегда бывает с хорошими вещами, чем больше пользы мы от них получаем, тем быстрее растет наша потребность в них.

Однако, чтобы добиться такой востребованности, необходимы время и усердие. Руководителям придется начать с низкой точки и довести программу измерения эффективности до высокого уровня совершенства. Мы это упоминаем, чтобы помочь сформировать правильные ожидания.

6.3.1. Измерение эффективности процессов двигает вперед процессное управление

Повторим еще раз: очень мало компаний смотрят на управление эффективностью с процессной точки зрения. Многие пытаются управлять компанией с помощью финансовых показателей, которые предлагают достаточно грубые оценки эффективности и методы ее улучшения. Другие внедряют программы повышения качества и пытаются влиять на эффективность, опираясь на статистические отклонения от отраслевых или каких-то других стандартов. Оба варианта являются неплохими отправными точками и основательными подходами к повышению эффективности, но этим и практически всем остальным подходам недостает фреймворка, дающего возможность понять, какие данные действительно нужны руководству и какие действия надо предпринять, чтобы более эффективно использовать информацию. Оба подхода успешно сигнализируют, когда что-то происходит, но они не отвечают на вопросы, почему и как это происходит. Что еще хуже, только немногие организации способны всерьез анализировать свою деятельность, перестраивать участки с целью изменения показателей эффективности и затем создавать или модифицировать компьютерные системы, необходимые для реализации этих изменений.

Таким образом, хотя измерения и производятся, отсутствует фреймворк, позволяющий понять, что означают данные, и затем действовать. Как следствие, даже если информация правильно интерпретируется, мало что можно сделать и мало что можно быстро изменить.

Признавая, что любое измерение эффективности и действия на его основе – это хороший старт для компании, находящейся на низком уровне процессной зрелости, мы еще раз напоминаем о ключевом значении управления ожиданиями в соответствии с реальностью.

По мере эволюции к более высоким уровням процессной зрелости, а следовательно, и зрелости измерения процессов будет происходить эволюция используемых средств BPM, которая приведет к широкомасштабному, стратегическому использованию в компании технологий BPMS. BPM, а в особенности операционный BPM на основе BPMS, использующий для интеграции приложений и данных SOA и веб-сервисы, позволяет уложить полученные в результате измерения эффективности данные в целостную систему (см. главу 10 «Технологии BPM»). Такая система, или фреймворк, задает необходимый для интерпретации данных контекст.

Если такой фреймворк наличествует, становится возможным работать с информацией об эффективности, отталкиваясь от контекста. В этом случае ясно видны предшествующее и последующее действия и можно найти причину проблемы. В ходе выработки решений, направленных на повышение объемов, на качество, на взаимодействие с потребителем, появляется возможность лучше их проанализировать, лучше смоделировать, проверить результаты с помощью имитационного моделирования, а затем полностью реализовать эти решения, обеспечив доступ к унаследованным приложениям, бизнес-правилам, измерениям эффективности и т. д.

Показатели качества, показатели эффективности, финансовые показатели теперь можно приложить к процессу или потоку работ, вместе или по отдельности. Каждый из этих подходов дает уникальную информацию с точки зрения стороны, заинтересованной в конкретном показателе. Будучи объединена, эта информация может рассказать намного больше – целое больше, чем сумма частей. По этой причине рекомендуется ежеквартально сопоставлять данные измерений по трем перечисленным направлениям (а также по другим, если таковые имеются), делая это в рамках рабочей группы, включающей экспертов по каждому из направлений. Это даст глубину понимания, которая в противном случае может оказаться недостижимой.

6.3.2. Как управление эффективностью процессов соотносится с отчетностью и бизнес-аналитикой?

Бизнес-аналитика[105]: компьютерная технология сбора и анализа информации о функционировании бизнеса. Она включает в себя статистический анализ, анализ трендов, анализ доходов и расходов и другие. Она также включает в себя средства предупреждения о превышении пороговых значений и системы логического вывода, которые обеспечивают оперативное реагирование и инициируют долгосрочные стратегические изменения.

Полученная в ходе измерения эффективности информация может дополнять бизнес-аналитику, полученную из разнообразных внешних и внутренних источников. Кроме того, используя движок бизнес-правил BPMS, эту информацию можно пропустить через фильтры логических выводов и решений и получить на выходе отчетность и рекомендуемые меры.

Для многих компаний информация по эффективности, полученная из операционной среды BPM с использованием BPMS, станет новым видом бизнес-аналитики. Это даст руководству новые источники информации (затраты, объемы, качество на уровне процесса и потока работ) и позволит задавать новые вопросы по операционной эффективности – текущей и за прошедшие периоды. Чтобы придать импульс такой бизнес-аналитике, следует учитывать ее потребности при определении состава и источников измеряемых данных (список возможных показателей см. в разделе 6.4.1).

Когда информация об эффективности становится частью бизнес-аналитики, руководство получает возможность встроить ее в качестве обратной связи в систему повышения эффективности. Руководство может использовать обратную связь для контроля за действиями в ответ на предупредительные уведомления, а также для корректировки пороговых значений по мере улучшения операционной деятельности. Это встраивает бизнес-аналитику в цикл непрерывного совершенствования и позволяет руководству регулировать бизнес-параметры (штат, объемы, IТ-поддержка и т. п.) и измерять результат изменений. В результате бизнес-аналитика становится приводным ремнем программы непрерывного усовершенствования.

6.4. Измерение и управление

Измерение эффективности – это просто получение данных. Они формируют картину, но эта картина должна быть интерпретирована. Интерпретация зависит от позиции человека или группы людей, которые анализируют данные и окружающий контекст, и разные исходные позиции являются причиной того, что одни и те же данные разными группами интерпретируются по-разному. Например, внешние и внутренние потребители могут иметь очень разные взгляды на эффективность и очень по-разному смотреть на данные, формируемые в процессе ее измерения. Некоторые из факторов, определяющих различия в исходной позиции, таковы.

• Бизнес-цели – различные ответы на вопрос, зачем мы что-то измеряем.

• Влияние на ценность – событие/результат; ценность для потребителя; значимость.

• KPI – целевое значение для сравнения и смысл этой величины.

• Определение метрик и способа измерения – пороговые значения и их значение для измерения эффективности.


Эти и многие другие факторы формируют основу мнения и позиции, но проблематика измерений выходит за рамки мнений – она включает также выбор способа измерения: формулы, которая будет использоваться, и того, как будет обеспечиваться качество данных и вычислений. Приведенный выше перечень дает примеры источников расхождений во мнениях относительно того, что должно измеряться и с чем должны сравниваться результаты, но настоящей проблемой является способ измерений. Это то, из-за чего отказываются признавать измерения и отвергают отчеты по измерениям. Поэтому критически важно, чтобы все заинтересованные лица согласились со способом измерения и чтобы это решение подтверждалось на регулярной основе, дабы гарантировать непрерывную во времени согласованность.

6.4.1. Что необходимо измерять?

Ниже перечислены рекомендуемые к рассмотрению категории измерения эффективности и качества. Это не исчерпывающий список, а информация к размышлению. То, какие процессы или действия будут измеряться, будет варьироваться в зависимости от компании, ее процессов, уровня зрелости и требований регулятора.

Операционная эффективность

Уровень процесса:

• объем транзакции;

• время реакции на событие;

• очередь ожидания по подпроцессам;

• время обработки реакции на событие;

• количество ошибок обработки;

• количество отклонений от нормальной обработки;

• потери – время, ресурсы;

• проблемы с торговыми партнерами и соисполнителями.


Уровень потока работ:

• объем транзакций;

• очередь ожидания по действиям – узкие места;

• количество ошибок по действиям и по людям;

• количество отклонений от нормальной обработки;

• количество и местонахождение точек принятия решений и других источников задержек (точек выхода и точек возврата);

• проблемы с внешней рабочей силой – продавцами (агентами), оценщиками, аутсорсерами.

Финансы

Уровень процесса:

• стоимость каждого подпроцесса – персонал, сырье, возвратные платежи, общие и административные расходы;

• стоимость реализованной продукции – процесс, включающий стоимость внешней работы, – работа, переданная другому процессу и возвращенная назад;

• отходы;

• экономия от внедрения нового решения.


Уровень потока работ:

• учет затрат по действиям[106];

• экономия от внедрения нового решения – на данном уровне или на уровне процесса.

Законодательство

Уровень процесса:

• соответствие законодательству;

• предоставление отчетности – своевременно и в полном объеме.


Уровень потока работ:

• следование условиям соглашения с профсоюзом;

• соответствие законодательству – например, SOX, HIPAA, Dodd/Frank[107];

• измерения для нужд обязательной отчетности на процессном уровне.

Выявление проблем

Уровень процесса:

• проблемы передачи ответственности;

• качество базы данных – дубликаты записей и т. п.;

• результаты проверок и аудитов – ручная проверка полуфабрикатов и конечной продукции;

• простой из-за ожидания дополнительной информации.


Уровень потока работ:

• качество передачи ответственности;

• ввод данных – классификация сбоев по причинам;

• выявление некорректных правил.

Потребительский опыт взаимодействия

Уровень процесса:

• удовлетворенность клиента от взаимодействия с компанией через отдел продаж, веб-портал, телефон.


Уровень потока работ:

• ошибки в заказах и т. п.;

• решение проблем – получение данных или корректной информации от заказчика посредством телефона, электронной почты, факса и т. д.

Качество

Уровень процесса:

• мониторинг качества с использованием шести сигм, TQM и т. п.;

• проверка/аудит сборочных узлов продукции или компонент услуг;

• проверка/аудит конечного продукта – ошибки и брак.


Результатом мониторинга работ и измерения эффективности являются отчеты, которые либо служат руководством к действию, либо информируют. Содержание таких отчетов варьируется в зависимости от того, что они пытаются оценивать; измерение эффективности должно соответствовать потребностям. В то же время может возникнуть необходимость проанализировать все потребности управления эффективностью в комплексе и идентифицировать все необходимые для этого данные и источники их получения. Сбор и хранение таких данных – задача IТ-специалистов, но для обеспечения гибкости и возможности детализации вглубь желательно хранить все необходимые данные в одном месте.

6.4.2. Ежедневный мониторинг: панели приборов

Данные могут отображаться по-разному. Иногда в развернутом виде, иногда в обобщенном. Оптимальное представление определяется назначением. Что касается обобщенной отчетности в режиме, близком к реальному времени, то потребность руководства в непрерывной картине текущей деятельности обеспечивается панелями приборов, на которых отображаются постоянно обновляемые результаты измерений. Если приборная панель снабжена логическим анализом на основе правил, то она способна сигнализировать о возникающих проблемах и рекомендовать корректирующие воздействия.

Любая приборная панель должна быть спроектирована так, чтобы дать четкое представление о конкретной составляющей деятельности. В центре внимания может быть компания в целом, процесс, поток работ или любая другая часть бизнеса. Отображение информации будет эволюционировать по мере того, как руководство будет отказываться от менее значимой информации в пользу более значимой для данного момента времени. Приборные панели необходимо делать максимально гибкими и легко изменяемыми в части содержания и способа представления.

Приборная панель обеспечивает начальный взгляд на эффективность и возможность погружения в данные. Детализация может быть реализована в программном коде, который обеспечивает определенный набор взаимосвязанных запросов (ограниченная гибкость), или быть произвольной – давать руководителю возможность выбирать любое направление детализации по своему усмотрению.

Как это обычно имеет место с отчетностью по эффективности, потребности руководства будут варьироваться в зависимости от уровня зрелости управления процессами и измерения эффективности. Но в любом случае приборные панели, собирающие и отображающие информацию в режиме, близком к реальному времени, остаются незаменимым средством измерения и управления операционной деятельностью на уровне процесса и потока работ.

6.4.3. Сравнение с KPI и эталонными значениями: производительность

Эффективность подразумевает соблюдение или превышение эталонных показателей, стандартов или KPI. Эти наперед заданные показатели формируют своего рода фреймворк для определения того, насколько хорошо функционирует какая-то часть процесса, потока работ или подразделение в целом. Ранее в этой главе мы представили перечень областей, на которые стоит обратить внимание при измерении эффективности. Это самая легкая часть. Определение того, как проводить измерение, сопряжено с политическими сложностями. Но самое тяжелое – решить, с чем сопоставлять результаты (если только цели не определяются просто наугад или на основании ручных измерений на протяжении определенного интервала времени).

Для любого измерения должен быть задан контекст, иначе это просто необработанные цифры. Контекст – это критерии оценки: KPI, стандарт, эталон и т. п. Можно использовать любой разумный контекст. Он должен определяться спецификой компании, процесса или потока работ. Ключевой аспект при определении контекста – он должен эволюционировать по мере эволюции программы непрерывного совершенствования в компании. (Мы ведь должны рассчитывать на то, что улучшения будут непрерывно происходить.) Когда это происходит, контекст измерений должен приводиться в соответствие с новыми, более жесткими требованиями или пороговыми значениями.

Для компаний, чей опыт измерения эффективности ограничен, или тех, кто хочет вывести измерения на новый уровень понимания, выбор целевых значений должен начинаться с изучения текущего состояния: ручных измерений и допустимых значений. Нужно изучить, что следует измерять, а также стандарты или KPI, с которыми нужно сопоставлять. Основательный подход к измерению эффективности подразумевает, что рамки контекста и целевые значения показателей должны определяться с участием тех сотрудников, чья эффективность будет измеряться, а рекомендованные целевые значения окажутся согласованы с менеджерами, показатели которых станут измерять, и с руководством бизнес-направления.

6.4.4. Машины логических выводов в управлении эффективностью

Мониторинг эффективности в реальном или близком к реальному времени может осуществляться с помощью BPMS. Такой мониторинг обеспечивает непрерывный поток данных из различных источников. Если эти данные используются для целей измерения, они дают результаты, привязанные к событиям или сценариям. Это позволяет автоматически анализировать данные сквозь призму предопределенных ключевых факторов. А если так, то BPMS может определить правила, которые из ситуации и значений данных будут выводить заключения о действиях, то есть рекомендовать, что делать.

Такой подход также полезен в ситуациях с высокой неопределенностью, быстрыми изменениями, в критических или сложных ситуациях, когда надо на основании данных и сложившейся ситуации быстро дать рекомендацию к действию. В некоторых случаях руководство может получить более точные рекомендации, обратившись за дополнительной информацией к машине логического вывода[108].

6.4.5. Анализ трендов и другие виды анализа

Как только появились данные и технический фреймворк для их извлечения, возникает возможность проводить анализ трендов, множество видов финансового и прочего анализа. Деятельность по измерению эффективности должна учитывать потребности руководителей различного уровня, чтобы они могли анализировать эффективность под своим личным углом зрения. Эти углы зрения должны быть определены и описаны на основе сопоставления текущей деятельности по измерению эффективности с потребностями в анализе и отчетности в рамках программы BPM. В конечном итоге должны быть учтены потребности в отчетности по эффективности по всем бизнес-направлениям и всем процессам, чтобы создать всестороннюю и гибкую среду, обеспечивающую управление процессами.

Чтобы выявить эти требования к отчетности, BPM-специалисту рекомендуется встретиться с IТ-руководителями, отвечающими за поддержку бизнес-направлений и за бизнес-аналитику. Результатом станет список текущих и отложенных потребностей в части отчетности. После этого BPM-специалисту следует встретиться с руководителями, отвечающими за участок работы (руководители бизнес-направлений и владельцы процессов), а также с теми руководителями, кто запрашивал дополнительную или особую отчетность. Такие встречи сформируют картину текущих и перспективных потребностей в отчетности по текущей деятельности и стратегическому развитию. На этих встречах будут определены потребности в анализе трендов и других видах долгосрочного анализа.

Следует стремиться к максимальному охвату различных углов зрения, определяя для каждого источники данных, способ анализа информации и пересечения с другими видами отчетности по эффективности. Результатом должен являться список потребностей в управленческой отчетности по эффективности и в бизнес-аналитике с указанием источника для каждого элемента данных – базы данных или системы.

Таким способом мы сможем удовлетворить максимально широкий спектр выявленных потребностей в отчетности по эффективности. Это улучшит соотношение эффект/затраты и для рассматриваемой работы, и для создания операционной среды BPM c использованием BPMS.

6.4.6. Удовлетворенность: оценка потребительского опыта взаимодействия (положительного и не очень)

Измерять удовлетворенность заказчика сложно, но критически необходимо. В современную эпоху мгновенной передачи информации любой опыт – позитивный и негативный – быстро распространяется по всему миру. Это влияет на поведение заказчиков, и они голосуют кошельком и ногами – просто отправляются за покупкой куда-нибудь еще. Вследствие этого прогрессивные компании берутся за составление карты всех точек взаимодействия с заказчиком и ищут способы предвосхитить его ожидания и управлять потребительским опытом взаимодействия. Такой подход остается относительно новым; то, что начиналось как новый подход под названием CRM[109], включавший в себя всего несколько инструментов для сканирования Интернета и реагирования на размещенные там сообщения, теперь развилось в более системные подходы под названием потребительский опыт взаимодействия, голос клиента[110] и т. п., которые проактивно подходят к описанию и измерению интегрального потребительского опыта взаимодействия.

Такой подход приобретает особое значение, когда компании приходят к пониманию того, что заказчика интересует цена, но не в ущерб качеству и хорошему обслуживанию. Это новое понимание, или даже новое восприятие заказчика, заставляет компании вырабатывать целостный взгляд на заказчика и на то, как заслужить его лояльность. Это заставляет переосмыслить использование заграничных колл-центров, веб-порталов, организацию клиентской поддержки (которая вынуждает персонал обращаться к множеству приложений, чтобы решить даже простую проблему – если она вообще решается) и т. д. Целью является устранение всех препятствий на пути к качественному взаимодействию с заказчиком. Но измерить это трудно, так как в основе лежит субъективное мнение. Чтобы достичь в этой области улучшения, необходим более комплексный, всесторонний взгляд на заказчика, учитывающий уровень его технической грамотности и соответствующий его ожиданиям того, что действия (например, возврат или корректировка счета) будут простыми, предсказуемыми и принимающими во внимание его интересы.

Такая отчетность уже на подходе, и ее следует принимать во внимание, рассматривая эффективность и способы ее измерения.

6.5. В поисках способа измерения эффективности

Мы разобрались с тем, что можно измерить и как определить источники информации. Теперь пришло время посмотреть на то, как мы можем измерить эффективность. Многим компаниям, которые не имеют возможности получать показатели эффективности из BPMS, придется комбинировать ручные подсчеты и информацию из унаследованных приложений. Такая отчетность не будет обеспечивать мониторинг и измерения в реальном или близком к реальному времени – в отличие от BPMS, в которой такая возможность является составляющей обеспечения операционной деятельности. Совершенствование отчетности по эффективности в более традиционной операционной деятельности будет определяться возможностью департамента IТ выделять время и ресурсы, необходимые для создания системы всестороннего мониторинга и оценки. Если ресурсов нет, то анализ и проектирование, о которых шла речь выше, не будут доведены до практической реализации.

В оставшейся части главы предполагается, что некоторые, если не все, части процесса реализованы в BPMS и что специалист по BPM в любом проекте обеспечен IТ-поддержкой в части программирования, управления данными и т. п. с приоритетом, обеспечивающим своевременное выполнение и сдачу работ. Повторяем: если этого нет, то надо либо добиться поддержки в этой части, либо скорректировать сроки с учетом минимальной поддержки IТ.

Помимо потребностей в автоматизации сбора данных, необходимо проанализировать потребности в отчетности и определить, где – в каких точках процесса и/или потока работ – эффективность может быть измерена. В каждой точке будет осуществляться мониторинг и сбор информации, и для каждой должны быть определены исходные данные, формула и вид предоставления отчетности. Такой сбор данных будет обеспечивать отчетность на всех уровнях для более широкого охвата бизнеса.

Помощь в определении способа измерения и типа собираемой информации могут оказать такие подходы к измерению и мониторингу, как шесть сигм и ABC. Они применимы на любом уровне: от процесса к потокам работ и к задачам.

Самое главное, чтобы подходы, на основе которых BPM-профессионал выстраивает мониторинг и измерения, были поняты в компании и поддержаны руководством.

6.5.1. Проектирование процесса управления эффективностью

Процесс управления эффективностью выстраивается, отталкиваясь от потребностей различных руководителей в информации о процессе или потоке работ, в зависимости от уровня отчетности. Он также напрямую связан с уровнем процессной зрелости компании. Измерить можно только то, что понятно менеджерам и обеспечено управленческими методами и данными.

Реалистическая оценка таких способностей – основа и мониторинга, и измерений. Но всегда надо с чего-то начать. Важно отдавать себе отчет, что компаниям или руководителям, для которых тема измерения эффективности и продвинутых измерений является новой, придется пройти собственный путь эволюции по мере приобретения знаний о том, что является возможным и что – самым необходимым. Зачастую этот путь познания начинается с большого объема бесполезных измерений и мониторинга. Это становится очевидным со временем, когда руководители отказываются от одних измерений и сосредотачиваются на других, действительно полезных.

Формируя ожидания и проектируя процесс измерения эффективности, важно понимать, что он неизбежно будет меняться по мере того, как руководители будут больше узнавать об измерении эффективности процессов и потоков работ, о доступной информации и имеющихся способах предоставления отчетности. Критически важно, чтобы наши способности измерения и отчетности на всем пути оставались гибкими; никто не должен с самого начала ожидать от них точности или оптимальности. Успех в этой деятельности, таким образом, достигается методом проб и ошибок. Это важно и с точки зрения формирования ожиданий, и для оценки затрат на переход к измерению и оценке эффективности.

Поэтому реальный процесс измерение – отчетность – оценка – реакция (то есть управление эффективностью) будет в значительной степени уникальным для каждого процесса и потока работ. Важно оказать поддержку потребностям руководства на всех уровнях компании. После интервью с руководителями компании, рассмотренным выше, BPM-специалист должен разработать подход к управлению эффективностью, содержащий начальные точки измерения, формулы расчета, KPI. Затем они встраиваются в операционную деятельность с помощью дополнений к основанной на BPMS операционной среде BPM или интеграционных модулей, интерфейсов и т. п. с унаследованными и новыми компьютерными системами.

Практическое использование покажет, какие надо произвести изменения в измерениях, и таким образом запустит эволюцию.

Способность компании обеспечить мониторинг/измерение/оценку эффективности напрямую зависит от способности получить (в близком к реальному времени) качественные данные как из процесса или потока работ, так и из унаследованных приложений, обеспечивающих бизнес. В некоторых ситуациях по-прежнему потребуется ручной аудит и подсчет, особенно если отсутствует фундамент операционной деятельности в виде BPMS. Из-за этого отчетность по эффективности может быть ограниченной и состоять из комбинации ручных и автоматических отчетов. Как уже было сказано, это зависит от уровня процессной зрелости и от поддержки со стороны автоматизированных систем, а также от способности компании извлекать и передавать информацию из различных источников и предоставлять ее в удобном для восприятия виде. Поэтому ограничения, которые накладывают на измерения возможности IТ, должны быть выявлены как можно раньше, в начале пути к управлению эффективностью. Это поможет определить истинное положение дел и разработать дорожную карту развития мониторинга/измерения/оценки как составную часть программы непрерывного совершенствования.

6.5.2. Выбор KPI и стандартов для сопоставления

Вначале стандарты, KPI и прочие целевые показатели будут основаны на текущих ориентирах, если таковые имеются. Если таковые отсутствуют, нужно обратиться к руководителям бизнес-направлений, внутреннему аудиту, юридической службе и другим, чтобы определить потребности и возможные источники ориентиров. Таковые могут включать коллективный договор, ручные подсчеты на статистически значимых отрезках времени, отраслевые стандарты и т. п.

Если у менеджера процесса или потока работ есть целевые значения, необходимо выяснить, чем они обоснованы. Если руководитель затрудняется с целевым значением или c его обоснованием, такое значение должно быть временно отложено в сторону, пока менеджер не сможет обосновать его необходимость. Вновь предлагаемые целевые значения должны трактоваться как «экспериментальные», и сравнение с ним должно производиться на временной основе до тех пор, пока использование отчетности по ним не продемонстрирует ценность производимых измерений и установленных пороговых значений.

Следует отметить, что после реализации инициатив по повышению эффективности целевые значения должны пересматриваться, чтобы отражать улучшения в операционной деятельности. По мере приближения деятельности к оптимальной целевые значения будут ужесточаться.

Области измерения, их KPI и стандарты формируют программу развития, долговечность которой определяется ценностью и использованием. Если ценность какой-то области измерений невелика, то она должна быть либо скорректирована, чтобы ценность измерений и целевых значений повысилась, либо отброшена. Такой подход к программе мониторинга и измерений заставляет постоянно пересматривать показатели и целевые значения с точки зрения их полезности для компании. При таком подходе области измерения и целевые показатели постоянно приносят пользу, эволюционируя вместе с бизнесом.

Постоянная переоценка системы измерения эффективности (операций, подходов к измерению, формул вычисления, целевых значений) должна быть формализована, оценка всех областей измерения и значений должна проводиться на заседаниях рабочих групп, на которых все руководители, использующие отчеты по эффективности, имеют возможность высказаться по использованию показателя и по изменению его целевого значения. Такой формальный процесс изменений поможет гарантировать, что мы измеряем то, что надо, и что программа измерения эффективности обеспечивает нужную информацию в нужное время в нужном месте.

6.5.3. Выбор формул и подходов к измерению

Насколько важно определиться с тем, что измерять, когда измерять и с чем сравнивать, настолько же важно решить, как выполнять измерение. Измерение может быть простым ручным подсчетом и формулой, по которой результаты группируются в соответствии со значениями X, Y или Z в заданном поле. Или это может быть проверка цифр в каждой 10-й транзакции. Перечень направлений измерения (формул измерения) бесконечен и будет уникальным для каждой компании, подразделения, процесса или потока работ. Сама формула будет меняться со временем, и суть данной главы не в ней. Суть в том, чтобы для каждого измерения существовала формула, прошедшая формализованную процедуру согласования.

Без этого результаты любых измерений являются предметом дискуссий и возражений. Единственный способ этого избежать – формально согласовать и утвердить области измерения, целевые показатели, подходы к измерению и формулы с теми, кто ими будет пользоваться.

Как и с остальными аспектами измерения эффективности, к формулам следует относиться как к чему-то преходящему и меняющемуся вместе с изменениями, происходящими в бизнесе. Но такие изменения должны быть формализованы и происходить только в рамках рабочих групп по измерению эффективности.

6.6. Развитие способности измерять эффективность

Самое сложное в наращивании способностей в области измерения эффективности – это политика. Мало кто из руководителей хочет, чтобы его оценивали, – сопротивление будет сильным, и можно ожидать разногласий по тому, что и как будет измеряться. Об этом надо позаботиться, так как руководителю достаточно легко найти возражения или сослаться на нехватку времени для каких бы то ни было измерений. Критически важна поддержка со стороны высшего руководства. Она должна быть активной (участие в совещаниях, в переписке и т. п.), постоянной и видимой. Это то, что обеспечивает вовлеченность.

Второй серьезный барьер – это способность компании обеспечить измерение эффективности процессов. В производственных и бизнес-подразделениях многих компаний не понимают, что такое процесс. Очень немногие компании действительно знают все свои процессы, то, как они взаимодействуют друг с другом (внутренние и внешние действия) и как работа распределяется между бизнес-подразделениями. Такое понимание важно с точки зрения развития способностей измерять эффективность с пользой.

Порой это второе препятствие становится непреодолимой преградой. Ожидания не должны быть слишком высокими или слишком низкими. Они должны быть реалистичными – особенно в компаниях, где негативно оценивают поддержку со стороны IТ. Если IТ-подразделение не может или не хочет обеспечить необходимый уровень поддержки, то вера в такую инициативу пропадет, и она заглохнет.

По этой, а также по другим причинам важно отнестись к измерению эффективности как к путешествию и спланировать это путешествие. Координация и управление таким путешествием должны официально осуществляться комитетом руководителей, чьи интересы затрагиваются в каждом из процессов. Компании следует рассмотреть возможность создания органа-регулятора, который определял бы подход к управлению измерением эффективности в рабочих группах и контролировал бы следование ему. Регулирующий орган будет отвечать за выбор способа измерения эффективности (особенно там, где текущая деятельность поддерживается BPMS), определять, как будет осуществляться контроль качества измерений и как измерение эффективности будет эволюционировать (например, формализованное одобрение рабочими группами). Этот орган должен выполнять функции центрального интерфейса между бизнесом и IТ, помогать планировать деятельность IТ и избегать конфликтов. Он может входить в состав Центра компетенций BPM[111].

6.6.1. Роль технологии BPMS

Операционная среда BPM с использованием BPMS способна обеспечить широкий спектр отчетности по эффективности как в режиме, близком к реальному времени, так и постфактум. Однако такая отчетность требует настройки BPMS, а также интегрированных с ней внешних систем. Это также относится к системам анализа потока информации, таким как системы мониторинга шести сигм, и соответствующим программным средствам.

6.6.2. Унаследованные приложения и бизнес-отчетность

Маловероятно, что IТ будет готово поддержать измерение и отчетность эффективности процессов. Автоматизированные системы и отчетность по эффективности обычно изолированы друг от друга: хотя системы предоставляют интерфейсы для бизнеса, это не те интерфейсы, которые требуются для задач отчетности.

6.6.3. Создание новой отчетности – это путь

Ведь это требует совместной работы IТ, юристов, финансистов, высшего руководства и руководителей бизнес-подразделений, в которых выполняются потоки работ.

Управление эффективностью процессов. Раздел II

Введение

Управление эффективностью процессов включает в себя как понимание того, что измерять, так и понимание того, как измерять. По этой причине данная глава разделена на две части: что измерять и как измерять эффективность. В настоящей второй части главы 6 мы сфокусируемся на том, как на основе BPM можно измерять эффективность.


Управление эффективностью процессов играет ключевую роль в достижении соответствия между целями организации и ожиданиями клиентов посредством стабильных и предсказуемых процессов. Ни один процесс не обходится без вариаций качества, продолжительности, доставки и стоимости. Понимание вариаций, контроль и управление ими – это ключ к тому, чтобы стать поставщиком продукции и услуг мирового уровня. Задача BPM CBOK – пролить свет на спектр имеющихся методов управления эффективностью процессов. Представительный набор таких методов рассмотрен в настоящей главе.

6.7. Значение и польза от измерения эффективности

Важность измерения эффективности процессов невозможно переоценить. Эксперты менеджмента и управления качеством от Эдвардса Деминга (W. Edwards Deming) до Питера Друкера (Peter Drucker) провозгласили: «Управлять можно только тем, что можно измерить»[112]. Это высказывание остается справедливым, и организация не должна инвестировать время и ресурсы в совершенствование процессов, если она еще не знает, чем совершенство можно измерить.

Через измерения обнаруживаются отклонения от приемлемых результатов и неэффективность процесса. Эффективность процесса может быть измерена через такие характеристики создаваемых процессом продукции или услуг, как надежность, производительность, время реакции на ошибку, комплексность услуги. Эффективность процесса может быть также измерена через характеристики самого процесса, такие как оперативность устранения дефектов, трудозатраты, время цикла. Измерения могут показывать текущую эффективность и предсказывать будущее поведение и результаты.

Менеджеры, отвечающие за эффективность процессов, должны находить баланс между ключевыми показателями эффективности, соответствующий долгосрочным стратегическим планам корпорации. Показатели эффективности, такие как удовлетворенность клиентов, продажи, издержки, показатели управления рисками, могут контролироваться с помощью панелей приборов, показывающих текущие значения в сравнении с целевыми.

Продемонстрируем важность измерения эффективности с помощью примера.

Предположим, что некоторая организация теряет свою долю рынка. Ее текущая доля рынка составляет 68 %, а цель – 80 %. Для простоты будем считать, что речь идет о зрелой отрасли, поэтому организация и ее конкуренты не заинтересованы в создании новых продуктов, а нацелены на доли рынка конкурентов.

В качестве показателя роста продаж организация использует долю рынка, но в чем причина проблем организации с процессной точки зрения, если отвлечься от доли рынка? Обратив внимание на процесс «Исполнение заказа», мы видим, что упала удовлетворенность клиентов, но почему? В результате анализа процесса было установлено, что текущий цикл заказа составляет девять дней. Другими словами, организации требуется девять дней, чтобы принять заказ, выполнить его и доставить клиенту. В условиях глобальной конкуренции подобная эффективность в данной отрасли неприемлема, особенно в отношении тех клиентов, которые с легкостью могут получить такой же продукт у конкурента, – отсюда падение доли рынка.

Следующий вопрос – что является причиной такого длительного срока исполнения заказа? Дальнейший анализ показал, что торговые представители вводят заказы клиентов с опозданием и к тому же среди них много ошибочных или не полностью заполненных. От 1 до 10 % форм заполнены не до конца, а точность ввода составляет всего 83 %. Более того, торговые представители вводят заказы раз в неделю вместо того, чтобы делать это ежедневно. Ожидаемые результаты не достигаются, и это отражается на разных уровнях процесса. Что еще важнее, это отражается на клиенте.

Этот пример также иллюстрирует, что не все в организации видят целостную картину происходящего. Вице-президент по маркетингу считает, что проблема в доле рынка. Вице-президент по снабжению видит проблему в сроках заказа у поставщиков, а вице-президент по продажам считает, что проблема в точности и своевременности заполнения форм клиентских заказов. Никто из них не понимает проблем другого. Генеральный директор знает только, что не растет выручка, а следовательно, и прибыль. Хотя у каждого из них, вероятно, есть метрики, по которым они отчитываются, маловероятно, что они осознают размах кросс-функционального процесса, который с точки зрения эффективности связывает их всех воедино. Что еще хуже, каждый сфокусирован на своей функциональной области, и все они независимо друг от друга борются с симптомами.

На рисунке 6.2 приведена адаптированная версия процесса «От заказа до оплаты» по Гэри Раммлеру (Geary Rummler) с точки зрения корпорации.



Подобный анализ чаще выполняется теми организациями, которые придают значение не только финансовым показателям, но и процессам и показателям их эффективности.

6.8. Ключевые определения эффективности процессов

Термины «измерение», «метрика» и «индикатор» зачастую трактуются неверно и ошибочно используются как синонимы.

Измерение – это количественная оценка данных (или набора данных), удовлетворяющая требованиям стандарта и качества (точность, полнота, непротиворечивость и актуальность).

Возьмем «10 сантиметров» в качестве примера измерения. Сантиметры – это стандарт, «10» показывает, сколько единиц или долей стандарта было получено.

Метрика – это количественная мера заданного атрибута системы, компоненты или процесса. Метрика – это производное значение, получаемое из результатов измерений путем экстраполяции или математической обработки.

Например, доля бракованной продукции по отношению к общему объему произведенной продукции (количество брака/общее количество продукции) или две ошибки, найденные пользователями в первые восемнадцать месяцев выполнения определенной деятельности (число ошибок/время). Учитывая, что производительность и результативность, как правило, являются функцией от одной или нескольких из четырех базовых измерений (время, стоимость, производительность и качество), они относятся скорее к метрикам, чем к измерениям.

Индикатор – это представление измерения или метрики в простой или интуитивно понятной форме для облегчения сравнения с эталоном или заданным целевым значением.

Пример индикатора: «зеленый цвет – хорошо, красный – плохо».

Метрики можно классифицировать по трем типам.

1. Метрики продукции: описывают характеристики продукции, такие как размер, сложность, конструктивные особенности, эксплуатационные параметры и уровень качества.

2. Метрики процесса: описывают характеристики процесса, такие как удовлетворенность клиентов, средняя наработка на отказ, эффективность устранения ошибок.

3. Метрики проекта: описывают характеристики проекта и его исполнение. Примеры: использование ресурсов, затраты, время и производительность.

Индикатор эффективности процесса (PPI)[113] определяется исходя из целей процесса и позволяет владельцу процесса контролировать его эффективность, выраженную через время, стоимость, производительность и качество. Существует двенадцать характеристик эффективного управления с использованием PPI (табл. 6.9).


Таблица 6.9

Источник: www.techrepublic.com (адаптировано)


Назначение индикаторов – дать менеджерам возможность вносить вклад в улучшение или изменение процесса.

Пример, охватывающий измерения, метрики и индикаторы: оценка точности выполнения плана проекта. Две важные меры, необходимые для оценки точности выполнения плана – фактическая продолжительность проекта и плановая продолжительность проекта. Проведем измерения для получения фактической продолжительности и плановой продолжительности. Метрика появляется, когда точность планирования продолжительности (ТПП) рассчитывается по формуле ТПП = фактическая продолжительность / плановая продолжительность. Индикатор же будет выражать ТПП в виде процентов, а не числа, чтобы облегчить интерпретацию и принятие решения. ТПП = 1 означает 100 %-ную точность оценки, таким образом, показатель ТПП = 100 %. Если значение ТПП лежит между 0 и 1, то значение индикатора есть просто ТПП, выраженный в процентах, – например, для ТПП = 0,5 индикатор ТПП = 50 % (точность 50 %). Если ТПП больше 1, то возьмем обратную величину с отрицательным знаком (–1/ТПП) – например, для ТПП = 2 индикатора ТПП = –1/2 (точность –50 %) (табл. 6.10).



Любой процесс может быть измерен через выполненную работу или полученный результат. Все измерения основаны на четырех базовых характеристиках: время, стоимость, производительность и качество.

6.8.1. Время

Время – это все, что связано с длительностью процесса. Время цикла определяется как время от начала процесса до его завершения, то есть получения конечного результата. Примеры временных характеристик:

• срок доставки;

• цикл исполнения заказа;

• цикл разработки продукции.

6.8.2. Стоимость

Стоимость – это связанные с процессом затраты (обычно выраженные в деньгах). Стоимость может рассматриваться с разных точек зрения; например, стоимость ресурсов – цена ресурсов (человеческих или материальных), требуемых для выполнения процесса, стоимость упущенных возможностей – упущенная выгода от процесса, который не достиг требуемого результата. Примеры стоимостных характеристик:

• затраты на реализацию;

• затраты на производство;

• затраты на логистику;

• стоимость складского хранения.

6.8.3. Производительность

Производительность – это сумма или объем выхода процесса. Примером может служить число транзакций, связанных с процессом. Производительность обычно ассоциируется с выручкой. Если можно улучшить работу (уменьшить отклонения) технологической линии, то это в конечном итоге увеличит число годной продукции, которая может быть продана клиентам, а значит, увеличит выручку производителя.

Производительность может также ассоциироваться с пропускной способностью. Пример – ручной ввод клиентских заказов в компьютерную систему торговыми представителями. Число обрабатываемых заказов в час будет определяться числом сотрудников и числом заказов, которые можно обработать за час (желательно без ошибок). Если клиент может ввести заказы в систему управления заказами самостоятельно через браузер, то число оформляемых в час заказов будет определяться ограничением на максимальное число посетителей сайта. Очевидно, это число будет больше, чем при ручном вводе заказов торговыми представителями. Примеры характеристик производительности:

• цена чека (доля кошелька покупателя);

• темп прироста числа клиентов;

• доля рынка.

6.8.4. Качество

Обычно качество выражается как процент текущего значения по отношению к оптимальному или максимальному значению, но применительно к процессам качество может принимать разные формы. Например, отклонение как метрика качества – это сумма, величина, коэффициент или степень изменения, в общем случае выраженные в виде разницы между достигнутым и целевым или ожидаемым результатом. Частота ошибок или брака – это пример метрики погрешности процесса. Уровень удовлетворенности, с другой стороны, это измерение качества, которое обычно ассоциируют с ожиданиями уровня сервиса со стороны потребителя. Примеры характеристик качества:

• отклонения в сроках вывода продукции на рынок;

• точность прогноза.

6.9. Отслеживание и контроль операций

Важно не просто измерять процессы – для достижения желаемых результатов гораздо важнее на постоянной основе осуществлять измерение, мониторинг и контроль процессов. С этой точки зрения управление эффективностью процессов – это скорее путь, чем конечная точка. Как только процесс «Исполнение заказа» задокументирован от начала и до конца, его исходные метрики установлены, собраны и взяты под управление, организация получает возможность наблюдать за изменениями, которые в конечном итоге повлияют на занимаемую долю рынка.

Нет ничего ужасного в том, что какой-то процесс, как выяснилось, не контролируется. Данный факт не должен скрываться от супервайзеров, руководителей, аудиторов, экспертов по качеству и, самое главное, потребителей. В известном смысле это событие стоит отпраздновать, так как у владельца процесса появляется возможность его усовершенствовать.

Роберт Хойер (Robert Hoyer) и Уэйн Эллис (Wayne Ellis), 1996

Некоторые аспекты использования индикаторов должны учитываться в ходе мониторинга и контроля. Индикаторы можно разрабатывать на основе моделей принятия решений.

Следуя шести шагам, описанным в табл. 6.11, лица, принимающие решения, смогут: 1) определить проблему; 2) определить все критерии; 3) оценить предпочтительность критериев; 4) выяснить подходящие альтернативные меры; 5) оценить каждую альтернативу с точки зрения каждого критерия; 6) аккуратно составить карту альтернатив и выбрать наиболее привлекательную.



В ходе выработки оптимального способа реагирования на проблему команда должна формализовать список рекомендаций, которые должны учитываться в процессе принятия решения. Список должен включать как очевидные, так и существенные, но не столь очевидные факторы. Этот список со временем должен расширяться, формируя своего рода стандартный свод рекомендаций для принятия решений. Используйте в качестве отправной точки табл. 6.12.


Таблица 6.12

Подводные камни при разработке индикаторов (источник: FNQ)


При всей важности понимания процесса решающую роль в бизнесе играет мониторинг и контроль эффективности процесса. С изменением бизнеса меняются и требования к эффективности процесса. Для достижения необходимой эффективности потребуется изменение самого процесса, но этого невозможно достичь без мониторинга и контроля процесса и его эффективности.

6.10. Выстраивание бизнес-процессов исходя из эффективности предприятия

Эффективность корпорации и соответствующие измерения лучше всего выражаются через удовлетворение потребностей и ожиданий клиентов. В примере на рис. 6.2 был рассмотрен процесс «Исполнение заказа» (от заказа до оплаты); все примеры метрик оценки корпоративной эффективности являются производными от времени, стоимости, производительности и качества. Вот некоторые примеры кросс-функциональных процессов, влияющих на метрики корпоративного масштаба:

• от заказа до оплаты;

• от закупки до оплаты;

• от маркетинговой кампании до коммерческого предложения;

• от плана до исполнения;

• от производства до дистрибуции;

• от инцидента до разрешения.


При традиционном подходе цели транслируются в план действий для каждого крупного операционного или вспомогательного подразделения. Однако данный подход имеет тот недостаток, что он порождает фрагментарные и частичные (то есть относящиеся к каждому подразделению отдельно) планы. При таком подходе сложно предсказать, какой план в конечном итоге приведет к ожидаемому результату.

Важно заметить, что кросс-функциональные процессы влияют больше чем на одну цель корпоративного масштаба. Например, процесс «От плана до исполнения» влияет на своевременность доставки, дату ответа на запрос и срок исполнения заказа.

При использовании различных методов трансформации процессов (бережливое производство, шесть сигм, реинжиниринг) важно понимать, будет ли метод иметь дело с кросс-функциональным процессом, с подпроцессом внутри кросс-функционального процесса или же с действием внутри подпроцесса.

Как показано на рис. 6.3, различные подходы, такие как реинжиниринг бизнес-процессов[114] и совершенствование бизнес-процессов[115], применяются по-разному на разных уровнях иерархии «процесс – подпроцесс – действие».



Хотя иерархия метрик, привязывающих процесс к операционной эффективности на уровне корпорации, пока не разработана, существующих связей между кросс-функциональными процессами и метриками уровня корпорации достаточно для того, чтобы BPM-специалист мог использовать их в качестве основы для выбора процессов для улучшения.

Процессная перспектива системы сбалансированных показателей увязывает цели эффективности организации с обеспечивающими процессами и тем самым обеспечивает их соответствие друг другу. Такие цели, как снижение затрат, повышение производительности, увеличение доли рынка, максимизация удовлетворенности потребителей и прибыльности, влекут за собой выявление процессов, отвечающих за их достижение. Таким образом, характеристики временные, стоимостные, производительности и качества переводятся в индикаторы, полностью следующие финансовой стратегии и стратегии работы с клиентами.

6.11. Что измерять

Что необходимо измерять при управлении эффективностью процесса, является загадкой для одних и дилеммой для других. Лучший способ понять, что необходимо измерять в процессе, это сначала выяснить, какого результата мы ожидаем.

Информация для измерения характеристик процесса может быть получена на входе или выходе подпроцесса либо в начале или конце процесса в целом, если речь идет о соответствии уровню сервиса. Ошибки и уровень брака – примеры метрик, основанных на качестве.

Информация, необходимая для измерения характеристик стоимости, обычно основана на ресурсах, необходимых для исполнения процесса, также по результатам процесса может оцениваться стоимость упущенных возможностей. Информация о производительности берется из результатов процесса. Временные характеристики определяют по данным процесса в целом.

6.11.1. Методы измерения эффективности процессов

Вообще говоря, существуют два механизма измерения процесса. Первый – ручной: сбор данных вручную, фиксация их на бумаге, ввод в электронную таблицу или в средство моделирования. Второй – автоматизированный, с использованием таких инструментов, как BPMS, средства моделирования корпоративных систем, BAM и др. Для всех применяемых сегодня методов есть соответствующее программное обеспечение.

Специалисты по BPM используют несколько общих методов измерения эффективности процессов, мы здесь рассмотрим только три: карта потока создания ценности, ABC, статистический контроль процесса. Цель данного раздела – не рекомендовать какой-то один в противовес другим, а лишь указать на существование различных методов мониторинга и контроля процессов, каждого со своими особенностями и назначением.

6.11.2. Карта потока создания ценности

Карта потока создания ценности – техника, используемая в Бережливом производстве для визуализации потока создания ценности в процессе.

Размещая процессы, создающие ценность, один за другим и обрабатывая по одному предмету за раз, мы добиваемся плавного перетекания работы от одного шага к другому и в конце – к клиенту. Такая цепочка процессов, создающих ценность, называется потоком создания ценности. Поток создания ценности включает в себя все, что надо сделать для создания ценности для клиента. Сначала проследите путь производства продукции от начала до конца, изобразите графически материальный и информационный поток каждого процесса. Затем отобразите карту того, как поток создания ценности должен протекать в будущем.

Согласно методологии бережливого производства, в ходе создания карты потока создания ценности выявляется семь видов потерь (рис. 6.4).



Важным аспектом управления эффективностью процессов является концепция добавления ценности. Данная концепция ведет свое начало от Деминга (Deming) и Джурана (Juran). Вкратце действие добавляет ценность, когда:

• оно необходимо для создания результата, требуемого клиентом;

• клиент готов платить за результаты процесса;

• необходимо обеспечивать качество и стабильность составляющих или результата в целом;

• непрерывность процесса подвержена влиянию обстоятельств.

В случае предоставления услуг дополнительная ценность возникает, когда улучшается потребительский опыт взаимодействия, даже если это не связано с определенной услугой. Например, личное приветствие и внимание, оказываемое на ресепшене гостиницы, добавляет ценность, хотя напрямую и не связано с предоставлением номера. Резюмируя, действие должно приводить к чему-то, что воспринимается клиентом как дополнительная ценность. Понимание того, добавляет действие ценность или нет, важно для улучшения процесса и принятия решения по упразднению или сохранению процесса или подпроцесса.

6.11.3. Учет затрат по действиям

Учет затрат по действиям (activity based costing, ABC) – это методология, которая относит затраты на выполняемые действия, а не на продукты или услуги.

Логика, стоящая за методом ABC, заключается в том, что с точки зрения учета нет никакой разницы между стоимостью и затратами: всё, что потребляется в организации, представляется как «объект учета затрат». Связи между объектами учета затрат и действиями и между действиями и ресурсами называются источниками затрат (рис. 6.5).



Метод ABC не устраняет и не меняет стоимость; он только предоставляет данные о том, как затраты относятся на процесс. Действия потребляют ресурсы. Это потребление наращивает затраты и определяет уровень производительности. Понимание этой взаимосвязи критично для управления накладными расходами. ABC используется для выявления возможностей по сокращению затрат и повышению производительности и фокусируется на накладных расходах. ABC скорее отслеживает составляющие затрат на определенный объект учета затрат, чем приписывает их к нему.

Метод ABC превращает косвенные затраты в прямые. Он предоставляет данные о частоте выполнения действий и о затратах, что дает возможность сравнивать операции до и после усовершенствования процесса. Он показывает, что будет в случае отказа от проекта (сценарий бездействия) и какие процессы создают ценность (необходимы для привлечения и удержания клиента или приведут к экономии в операционной деятельности).

ABC обычно используется там, где накладные расходы и цена ошибки высоки, процесс показал свою неэффективность, а конкуренция жесткая.

6.11.4. Статистический контроль процесса

Статистический контроль процесса имеет дело со сбором, классификацией, анализом и интерпретацией численных данных или фактов. Используя теорию математической статистики, статистический контроль процесса упорядочивает множество разрозненных элементов.

Всякая работа осуществляется в системе взаимосвязанных процессов, и каждый процесс подвержен вариациям. Вариации могут происходить по естественным причинам, вследствие природы процесса, или быть обусловлены какой-либо технической или бизнес-закономерностью. Статистический контроль процесса (SPC)[116] используется для изучения, уменьшения или устранения вариаций в процессах, подверженных нестабильности из-за ошибок и/или неэффективности. Снижение нестабильности процесса приводит к его улучшению. SPC фокусируется на входах X, влияющих на выходы Y, выясняя, какие процессы вносят главный вклад в Y. Далее SPC фокусируется на этих процессах с целью их улучшения.

SPC рекомендуется использовать при большом числе ошибок или нестабильных результатах процесса.

6.12. Голос процесса

Контрольная карта – это то, как процесс говорит с нами.

Ирвин Бёрр (Irving Burr), 1953

На эффективность процессов могут влиять такие общие факторы, как люди, обучение, процедуры, инструменты, оборудование, материалы, энергия, деньги, время, регламенты, цели, ограничения, законы, правила и нормы.

Когда организация берет на себя обязательство предоставить продукцию или услуги в соответствии с требованиями заказчиков и бизнес-целями, то процесс можно считать обеспечивающим требуемый результат, если обеспечены контроль стандартов качества, графика и стоимости. Статистический контроль процесса, осуществляемый в течение достаточно продолжительного периода, позволяет установить источник отклонений, исправить ошибки или дефекты и получить работоспособный процесс. Таким образом, чтобы можно было считать, что процесс обеспечивает требуемый результат, он должен находиться под определенным разумным статистическим контролем.

Существуют различные аналитические методы для выявления и контроля отклонений. Они включают:

• исследование данных (exploratory data analysis);

• байесовский анализ (bayesian statistics);

• регрессионный анализ (regression analysis);

• моделирование дискретных событий (discrete event simulations);

• методы анализа надежности (reliability analysis techniques);

• непараметрический анализ (non-parametric analysis);

• дисперсионный анализ (analysis of variance);

• контрольные карты (control charts).


По каждому из вышеперечисленных методов статистического контроля есть масса специализированной литературы для дальнейшего изучения, однако следует подчеркнуть критическое значение контрольных карт. Контрольные карты, также известные как карты Шухарта, представляют собой мощную и повсеместно используемую технику для слежения за тем, что отклонения бизнес-процесса не превышают статистически допустимых. Существуют различные типы контрольных карт, которые могут использоваться для отражения поведения процесса и слежения за «голосом процесса».

• Карты среднего (X-bar) и размахов (R).

• Карты среднего (X-bar) и стандартных отклонений (S).

• Карты индивидуальных значений и скользящих размахов (XmR).

• Карты индивидуальных значений и медианных скользящих размахов.

• Карты скользящих средних и скользящих размахов (MAMR).

• C-карты.

• U-карты.

• Z-карты.


Продемонстрируем на примере, как карта XmR (табл. 6.13) работает с непрерывным потоком данных и как ее можно использовать для исследования вариаций процесса. Нефтяная скважина производит сырую нефть круглый год (24 часа в сутки, 7 дней в неделю, 365 дней в году). Каждый день дежурный супервайзер регистрирует дневную добычу нефти по каждой скважине. Как мы можем удостовериться, что процесс стабилен и продолжается непрерывно? Эффективность процесса может быть количественно измерена через свойства продукта, производимого процессом, таким образом, контрольная карта может отразить значения атрибутов процесса, которые изучались в течение определенного периода времени.



Если:



То:

CL = 60,7

avg(mR) = 7,8

UCL = 81,5

LCL = 40,0



Поместим данные на диаграмму (рис. 6.6).

Для выявления необычного поведения процесса можно использовать как минимум 4 эффективных критерия (рис. 6.7).

Тест 1. Единичная точка выходит за пределы трех сигм от средней линии.

Тест 2. Минимум два из трех последовательных значений находятся на одной стороне и на расстоянии более двух сигм от средней линии.

Тест 3. Минимум четыре из пяти последовательных значений находятся на одной стороне и на расстоянии более одной сигмы от средней линии.

Тест 4. Минимум восемь последовательных значений находятся на одной стороне от средней линии.


В этих тестах предполагается, что наблюдаемая последовательность значений статистически независима, следовательно, естественные отклонения должны быть симметричны относительно среднего. В нашем примере серийные тесты могут выявить нестабильность процесса в дни с 15 по 17, сигнализируя о том, что с процессом произошло нечто, что следует исследовать.

Уолтер Э. Шухарт (Walter A. Shewhart) (1931) классифицировал два источника отклонений процесса.

Случайное отклонение. Отклонение из-за естественных и внутренних характеристик процесса, которые происходят в случайном порядке вблизи среднего значения.

Систематическое отклонение. Происходит из-за непредусмотренных факторов, которые препятствуют исполнению процесса и воздействуют на результат процесса. Отклонения происходят постоянно по одну сторону от среднего. Если отклонение является проблемой, необходимо среагировать и устранить. Примеры: оператор уснул на рабочем месте, случилась неисправность оборудования, скачок напряжения, остановка производственной линии из-за недостатка сырья, невозможность для работников выполнять свои обязанности из-за забастовки или климатических условий.

[Суммарное отклонение] = [Случайное отклонение] + [Систематическое отклонение]

Систематические отклонения могут быть обусловлены временными или постоянными причинами. Временные причины по отношению к процессу могут рассматриваться как риски, и должны быть предприняты действия для их смягчения (кратковременные причины достаточно нерегулярны и воздействуют на процесс непредсказуемым образом). Пример кратковременной причины – невозможность завершить работу из-за перебоев в подаче электроэнергии в городской зоне, где нарушения энергоснабжения редки. Напротив, постоянная причина – это нечто, не рассматривавшееся как часть процесса, но в дальнейшем ставшее частой и весьма вероятной проблемой. Может потребоваться внесение изменений в расчетную прогностическую модель или в процесс, чтобы учесть воздействие постоянной причины. Пример постоянной причины – невозможность завершить работу из-за перебоев в электроэнергии на отдаленной и слаборазвитой территории, где перебои в электроснабжении являются обычным делом.

Для минимизации или устранения систематических отклонений могут предприниматься корректирующие действия. Когда все систематические отклонения устранены и приняты меры, препятствующие их повторению, формула превращается в: [Суммарное отклонение] = [Случайное отклонение], что означает стабильный и предсказуемый процесс. Вывод: никогда не прекращайте использовать контрольные карты.

6.13. Имитационное моделирование будущего состояния процесса

Методы статистического контроля процесса, перечисленные выше, – действенные средства мониторинга и контроля эффективности существующего процесса. Имитационное моделирование – это следующий шаг, позволяющий спроектировать будущую желаемую эффективность процесса и выявить недостатки текущего процесса, мешающие переходу к желаемому состоянию.

Имитационное моделирование – это изучение поведения или характеристик одной системы с помощью другой системы. Применительно к бизнес-процессам имитационное моделирование – это имитация поведения процесса с помощью специального программного обеспечения. По сути, в программе моделируется процесс и все связанные с ним параметры.

Например, временные параметры для каждого действия:

• время ожидания во входной очереди (до начала работы);

• время задержки начала работы (от начала привлечения ресурса до начала работы);

• время работы (от начала работы до производства продукции);

• время ожидания в выходной очереди (от производства продукции до выхода ее наружу).


Примеры стоимостных параметров:

• суммарная стоимость персонала в соответствии с числом сотрудников на каждом действии и стоимостью каждого;

• материалы, расходуемые на каждое выполнение действия (прямые затраты);

• связанные с действиями накладные расходы за определенный интервал времени, такие как административные расходы, распределяемые как процент от общей численности штата (косвенные затраты).


Другие соображения, касающиеся параметров:

• сколько раз процесс отработал за определенный интервал времени (X раз в час/день);

• точки принятия решения в процессе (пример: распределение 60/40 между маршрутами A и B).


После того как все параметры модели процесса заданы, имитационное моделирование сначала запускается на текущем процессе. После завершения программа выводит результаты: каждое действие с просуммированными временными и стоимостными характеристиками. Опираясь на обширные данные, полученные в результате моделирования, можно идентифицировать проблемные с точки зрения эффективности области процесса.

После того как текущее состояние процесса полностью проанализировано, начинается моделирование желаемого будущего состояния. Моделируется будущий процесс, параметры процесса корректируются так, чтобы достичь желаемой эффективности, и запускается новое имитационное моделирование, также дающее на выходе информацию для анализа и интерпретации.

Специалист BPM может затем скорректировать параметры и продолжать имитационное моделирование до тех пор, пока исполнение процесса не будет соответствовать ожиданиям. Эта работа выполняется с помощью программного обеспечения до того, как специалист BPM со своей командой приступят к реальному совершенствованию процесса. Это позволяет сэкономить значительное время, издержки и усилия, поскольку вся работа смоделирована в программном обеспечении до внедрения в организации.

Имитационное моделирование с использованием программного обеспечения – это экспериментальная лаборатория по совершенствованию процессов до их реального внедрения. Оно не заменяет работу с живыми людьми и не является идеальным методом определения будущего состояния процесса. Тем не менее это мощный инструмент, помогающий специалисту BPM оценить необходимые корректировки быстрее, чем если бы измерения тестировались вручную. Самая большая польза от имитационного моделирования с использованием программного обеспечения – это возможность автоматически рассчитать выгоду от улучшения процесса в разрезе времени, стоимости, производительности и качества. Результатом является бизнес-кейс, позволяющий обосновать усовершенствование процесса.

Дополнительную информацию по имитационному моделированию см. в главе 3 (раздел 3.11), главе 5 (раздел 5.9) и главе 6 (раздел 6.13).

6.14. Поддержка владельцев и менеджеров процессов в принятии решений

Поддержка владельцев и менеджеров процессов в принятии решений – важный аспект непрерывного мониторинга эффективности процесса. Ограниченная или неточная информация о бизнес-процессе может приводить к плохим решениям о выделении инвестиций и о способах повышения эффективности организации.

Многие организации для мониторинга эффективности процессов используют панели приборов, основанные на фреймворке системы сбалансированных показателей (BSC)[117]. Эти панели приборов являются формой поддержки принятия решения, они упоминались выше как средства бизнес-аналитики. Вообще говоря, бизнес-аналитика имеет дело с управлением эффективностью процессов в корпоративном контексте. Когда бизнес-аналитика внедряется на корпоративном уровне, она извлекает информацию об определенных кросс-функциональных процессах и их эффективности в реальном времени и отображает эту информацию через панели приборов.

Организации с развитыми способностями бизнес-аналитики в корпоративном масштабе знают, что задача выходит далеко за рамки данных и технологий: она включает также умение работать с процессами, определенные навыки и культуру организации[118].

Поддержка принятия решения начинается с планирования мониторинга эффективности процесса – когда, что и как будет контролироваться. Например, график технического обслуживания механизма может включать очистку клапана каждые 3000 часов, регулировку конвейерной ленты каждые 1000 часов, замену фильтров каждые 5000 часов и т. д. Четкий план обслуживания машины был продуман изготовителем и изложен в инструкции. Соблюдение графика обслуживания возложено на владельца механизма.

Управление эффективностью процессов начинается с планирования того, какие процессы будут измеряться, как часто они будут измеряться, как будут приниматься решения по проблемам эффективности процессов в случае их возникновения и т. д. При планировании мониторинга полезными будут фреймворки поддержки принятия решений, такие как BSC. Они предоставляют процессному менеджеру взгляд на процесс. Как только план управления эффективностью процессов принят и организация определила кросс-функциональные процессы для мониторинга, программное обеспечение бизнес-аналитики предоставляет возможность исследовать эффективность бизнес-процессов вглубь. Такие средства, предоставляя ценную информацию о проблемах процессной эффективности, экономят массу времени.

6.15. Фреймворк зрелости управления эффективностью процессов

В зависимости от уровня процессной зрелости организации управление эффективностью процессов различается углом зрения и глубиной. Модели зрелости способности определяют зрелость по шкале от 1 до 5, где первый уровень – незрелость, а пятый – высокий уровень зрелости. На первом уровне от организации не ожидается ничего, кроме «просто сделай и доставь клиенту то, что он хочет». На втором уровне определяются некоторые характеристики времени, стоимости, производительности и качества. С ростом зрелости, при достижении уровня 3, появляются измерения, метрики и индикаторы эффективности сквозных процессов, проходящих сквозь границы структурных подразделений и нацеленных на требования внутренних и/или внешних потребителей. На уровне 4 измерения, метрики и индикаторы эффективности процессов привязываются к стратегическим целям компании. На уровне зрелости 5 управление эффективностью процессов привязывается к стратегическим целям корпорации.

Интегрированная модель зрелости способностей (CMMI®)[119] Института программной инженерии (SEI)[120] – это референтная модель, отражающая передовые методы совершенствования процессов с целью создания лучших продуктов (CMMI для разработки [CMMI-DEV]) и лучших услуг (CMMI для услуг [CMMI-SVC]). CMMI включает две процессные области, относящиеся к управлению эффективностью процессов: 1) измерение и анализ (на втором уровне зрелости) и 2) эффективность процессов организации (на четвертом уровне зрелости).

Согласно CMMI, назначение процессной области «Измерение и анализ» (MA)[121] – «создание и поддержание способности проводить измерения для обеспечения потребностей в управленческой информации»[122]. Особые цели (SG)[123] области MA достаточно примитивны, так как это лишь первый шаг от незрелости. Для области MA CMMI предлагает особые цели: SG1 – упорядочить измерение и анализ и SG2 – предоставить результаты измерений. CMMI предлагает следующие особые виды деятельности (SP)[124] для достижения данных целей.

SG1 – упорядочить измерение и анализ.

SP 1.1 – установить цели измерения. SP 1.2 – определить измерения. SP 1.3 – определить процедуры хранения и сбора данных. SP 1.4 – определить процедуры анализа.

SG2 – предоставить результаты измерения.

SP 2.1 – получить данные измерений. SP 2.2 – проанализировать данные измерений. SP 2.3 – сохранить данные и результаты. SP 2.4 – оповестить о результатах.

Назначение процессной области «Эффективность процессов организации» (OPP)[125] – «устанавливать и поддерживать понимание количественной эффективности группы стандартных процессов организации с целью обеспечения качества и достижения требуемой эффективности процессов, а также представлять данные о процессной эффективности, отправном уровне и модели». У OPP есть только одна особая цель SG1 – установить отправной уровень эффективности и модель. Однако задачи процессной области OPP, относящейся к более высокому четвертому уровню зрелости, сложнее, чем задачи области MA. Область OPP требует, чтобы определенные способности, в частности виды деятельности области MA второго уровня зрелости, уже наличествовали. CMMI предлагает следующие особые виды деятельности (SP) для достижения цели OPP.

SG1 – установить отправной уровень эффективности и модели.

SP 1.1 – установить цели в области качества и эффективности процессов. SP 1.2 – выбрать процессы. SP 1.3 – утвердить измерения эффективности процессов. SP 1.4 – проанализировать эффективность процесса и установить отправные уровни эффективности процессов. SP 1.5 – утвердить модель эффективности процессов.

Помимо особых целей для областей MA и OPP, существуют также общие цели (GG)[126], достигаемые через общие виды деятельности (GP)[127]. Следовательно, для достижения целей процессных областей MA и OPP организация должна также внедрить следующие общие виды деятельности.

GG 2 – институализировать управляемый процесс.

GP 2.1 – установить организационные правила. GP 2.2 – спланировать процесс. GP 2.3 – выделить ресурсы. GP 2.4 – назначить ответственных. GP 2.5 – обучить персонал. GP 2.6 – проконтролировать результаты работы. GP 2.7 – выявить и вовлечь заинтересованные стороны. GP 2.8 – выполнять мониторинг и контроль процесса. GP 2.9 – объективно оценить следование правилам. GP 2.10 – обсудить состояние дел с высшим руководством.

GG 3 – институализировать описанный процесс.

GP 3.1 – утвердить описание процесса. GP 3.2 – накапливать процессный опыт.

Эффективность процессов организации (OPP) частично пересекается с измерением и анализом (MA), отличаясь углом зрения. Цель OPP – осознать пользу измерения процессной эффективности в организации. Цель MA – познакомить с идеей и необходимостью простейшей деятельности по измерению процесса и анализу; OPP расширяет эту концепцию усовершенствованными методами управления процессной эффективностью.

Измерения процессной эффективности имеют смысл, если затраты на них приемлемы. Поэтому не все процессы следует измерять и управлять их эффективностью – только избранные, критически важные процессы.

OPP обращает внимание не только на цели в области процессной эффективности, но и на цели в области качества. Это требует пересмотра бизнес-целей организации в области качества. OPP также требует наличия модели процессной эффективности, чтобы можно было оценивать эффективность процесса на основании значений других показателей. К моделям процессной эффективности относятся системная динамика[128] и увеличение надежности[129]. В достижении целей эффективности и качества OPP в значительной мере опирается на статистический контроль процессов.

6.16. Рекомендации для достижения успеха

Важная часть любого управления эффективностью процессов – поддерживающая ее организационная структура. Некоторые рекомендации по такой структуре представлены ниже.

• Адекватная компетентность: удостоверьтесь, что люди, которые будут управлять процессной эффективностью, действительно обладают набором умений, требуемых для достижения желаемых результатов.

• Роли и ответственность: удостоверьтесь, что роли и ответственность четко определены и доведены до сведения заинтересованных сторон.

• Организационная структура: удостоверьтесь, что организационная структура хорошо подготовлена к тому, чтобы воспринять управление эффективностью процесса.

• Полномочия вместе с подотчетностью: удостоверьтесь, что те, кто наделен полномочиями по трансформации процессов, отвечают за результат трансформации.

• Результаты процессной эффективности: удостоверьтесь, что с ролями связаны не только цели, но также результаты, вознаграждения и иные поощрения.

• Избегание проблем: удостоверьтесь, что показатели эффективности используются так, как надо, и там, где надо, и что при их разработке удалось избежать того, что Майкл Хаммер (Michael Hammer) назвал «семь смертных грехов измерения» в своей книге «Быстрее, лучше, дешевле»[130] (2010).


«Греховное» поведение зачастую является отражением организационной культуры.

• Тщеславие: использование измерений исключительно для того, чтобы выставить компанию, ее сотрудников и особенно менеджеров в лучшем свете. Так как бонусы и вознаграждения обычно завязаны на показатели эффективности, руководители ожидают благоприятных метрик. Реальная картина эффективности организации воспринимается скорее как угроза, чем как информация для корректирующих действий.

• Провинциальность: функциональные подразделения диктуют только те метрики, которые их руководители могут контролировать (эффективность процессов подразделений затмевает кросс-функциональную процессную эффективность).

• Нарциссизм: измерение с позиции внутреннего наблюдателя (inside-out), а не клиента (outside-in).

• Лень: уверенность, что уже и так известно, что именно надо измерять, без приложения усилия и адекватного осмысления.

• Мелочность: измерение только малой части того, что действительно имеет значение.

• Глупость: ввод метрик без обдумывания их влияния на поведение людей и, следовательно, на эффективность предприятия.

• Легкомысленность: несерьезное отношение к измерениям, споры о метриках, поиск оправданий низкой эффективности и способов переложить вину на других.


Управление процессной эффективностью, сосредоточенное на бизнес-целях и поощряющее прозрачность, создает здоровую среду, в которой организация процветает.

6.17. Ключевые понятия

• Управление эффективностью – это путь, эффективность должна меняться вслед за изменениями в бизнесе.

• Способность измерять эффективность процессов и анализировать полученные результаты определяется уровнем процессной зрелости компании.

• Управление эффективностью начинается с мониторинга и четкого понимания, что и зачем будет контролироваться.

• Измерение эффективности должно подкрепляться целевыми значениями: стандартами, KPI, стоимостными ограничениями и т. п.

• Любая система измерения эффективности должна приниматься рабочей группой с участием руководителей, чья деятельность будет измеряться, и тех, кто будет пользоваться этой информацией.

• Все изменения должны проходить через формализованную процедуру одобрения рабочей группой.

• Любая система измерения эффективности должна развиваться, иначе она потеряет связь с бизнесом и не будет представлять ценности.

• Измерение напрямую связано с количественной оценкой данных в соответствии с принятыми стандартом и качеством (точность, полнота, непротиворечивость и актуальность).

• Метрика есть результат экстраполяции или математической обработки результатов измерений.

• Индикатор – это упрощенное представление измерения или метрики, служащее определенной цели.

• Измерения работы или результата процесса базируются на четырех фундаментальных характеристиках: время, стоимость, производительность, качество.

• Показатели эффективности процессов обладают двенадцатью характеристиками: соответствие, подотчетность, прогнозируемость, стимулирование действий, краткость, понятность, сбалансированность и взаимосвязанность, поддержка преобразований, стандартизированность, ориентированность на контекст, подкрепленность стимулами, актуальность.

• Карта потока создания ценности, учет затрат по действиям и статистический контроль процесса являются общепризнанными и надежными методами проведения измерений.

• Когда процесс стабилен, отклонения в его работе предсказуемы, так что непредвиденные результаты крайне редки.

• [Суммарное отклонение] = [Случайное отклонение] + [Систематическое отклонение]

• Качество мирового уровня = точно в цель с минимальными отклонениями.

• Базирующийся на передовом мировом опыте фреймворк, такой как CMMI, помогает руководителю структурировать методы управления эффективностью процессов и последовательно достигать высоких уровней зрелости.

6.18. Библиография

ABPMP International «ABPMP BPM CBOK, V2.0 – Guide to the Business Process Management Common Body of Knowledge», 2009

SEI, Carnegie Mellon University «CMMI for Development, V1.3 (CMMI-DEV, V1.3)», Technical Report CMU/SEI-2010-TR-033, 2010

SEI, Carnegie Mellon University «CMMI for Services, V1.3 (CMMI-SVC, V1.3)», Technical Report CMU/SEI-2010-TR-034, 2010

Cokins, G. «Activity-based Cost Management: An Executive's Guide», Wiley, 2001

Florac, W. A., Carleton, A. D. «Measuring the Software Process – Statistical Process Control for Software Process Improvement», The SEI Series in Software Engineering, Addison-Wesley, 1999

Kaplan, R., Norton, D. «Balanced Scorecard: Translating Strategy into Action», Harvard Business School Press; 1996. (Русский перевод: Каплан Р., Нортон Д. Сбалансированная система показателей. От стратегии к действию. М.: Олимп-Бизне