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

4.8. Отчет по результатам анализа

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

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

• Обзор текущей бизнес-среды.

• Назначение процесса (ради чего он существует).

• Модель процесса (что и как делается, входы и выходы).

• Потенциал повышения эффективности процесса.

• Внешние и глубинные причины неэффективности процесса.

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

• Рекомендуемые решения и прочие рекомендации.

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

4.9. Рекомендации

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

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

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

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

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

Оценка зрелости процессов помогает оценить потенциал процессной трансформации и вносит важный вклад в составление перспективных планов процессных изменений и инвестиций в IТ. Модели процессной зрелости рассматриваются в главе 9 «Управление процессами предприятия».

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ключ к успешному преодолению сопротивления – вовлечение в анализ владельца процесса.

4.10. Заключение

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

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

4.11. Ключевые понятия

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

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

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

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

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

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

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

• кросс-функциональные процессы, нуждающиеся в координации.

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

• не достигаются целевые показатели эффективности;

• не оправдываются ожидания клиентов;

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

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

• узкие места.

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

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

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

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

Вступительное слово: Джим Сайнур (Jim Sinur), вице-президент, Gartner

Освоение BPM приводит организации к проектированию[88]88
  В оригинале используется слово design, причем где-то в значении действия, а где-то – его результата. Действие всюду переводится как «проектирование», а результат – как «модель». – Прим. ред.


[Закрыть] бизнес-процессов. Процесс может моделироваться заранее (до начала его исполнения) или выявляться уже существующий, но в любом случае заложенный в ходе проектирования фундамент и получившиеся в результате модели имеют большое значение для восприятия процесса. Существуют три основных подхода к проектированию процессов: моделирование до исполнения, через пользовательские интерфейсы и автоматизированное выявление[89]89
  ABPD – Automated Business Process Discovery. – Прим. пер.


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

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

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

Моделирование бизнес-процессов заранее

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

Проектирование через пользовательские интерфейсы

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

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

Этот подход основан на анализе фактического исполнения процесса. Тактика при этом может варьироваться. Это может быть простое наблюдение за работой исполнителей, непрерывно обращающихся к различным пунктам меню существующей информационной системы, с целью создания полной процессной модели. Несколько сложнее наблюдать за работниками умственного труда (штатными сотрудниками и фрилансерами), совместно выполняющими задание, с целью выявления альтернативных путей выполнения фрагментов процесса. Еще один распространенный вариант – воссоздание процессной модели по записям в аудиторских журналах информационных систем. По нашему мнению, такой подход дополняет адаптивный кейс-менеджмент (ACM)[90]90
  Adaptive Case Management. – Прим. пер.


[Закрыть], в котором процесс, за исключением желаемых конечных и промежуточных результатов, остается неструктурированным.

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

5.0. Введение

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

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

Проектирование процесса представляет собой проект, которым, как и любым другим проектом, необходимо управлять. Но, несмотря на критическую важность формального проектного управления, в этой главе оно не рассматривается, так как это отдельная и самостоятельная компетенция. Читателям, интересующимся этой темой, мы предлагаем обратиться к материалам Института проектного управления (PMI)[91]91
  Project Management Institute. – Прим. пер.


[Закрыть].

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

5.1. Что такое проектирование процесса

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

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

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

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

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

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

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

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

Всюду ниже мы будем принимать изображенную на рис. 5.2 структуру «процесс – подразделение – поток работ» как данность и для краткости называть ее просто «процесс». А работу внутри подразделения мы будем обозначать термином «поток работ».

Такая терминологическая дифференциация должна помочь дистанцироваться от распространенной практики, когда процессом называют любую работу или деятельность. Мы считаем, что такое использование термина компрометирует фундаментальное представление о процессе как о кросс-функциональном и сквозном[92]92
  End-to-end. – Прим. пер.


[Закрыть], то есть охватывающем всю работу, необходимую для удовлетворения потребности потребителя в продукции или услуге.

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

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