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

Команда, приступающая к проектированию или перепроектированию процесса, должна понимать что представляет собой процесс от начала до конца, какие подразделения вовлечены в его исполнение и какие действия они выполняют (рис. 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.