Коллектив авторов - Свод знаний по управлению бизнес-процессами: BPM CBOK 3.0
Процессные методологии гарантируют, что анализ будет следовать общепринятым подходам и приведет к наилучшим результатам. Анализ процессов может следовать формальной методологии или прагматично подойти к изучению имеющихся стандартов и опыта выполнения работы.
Критическими факторами успеха анализа процессов являются поддержка высшего руководства и включение в рассмотрение метрик, бенчмаркинга, взаимодействия с клиентом и культурных особенностей.
Глава 5
Проектирование процессов
Вступительное слово: Джим Сайнур (Jim Sinur), вице-президент, Gartner
Освоение BPM приводит организации к проектированию[88] бизнес-процессов. Процесс может моделироваться заранее (до начала его исполнения) или выявляться уже существующий, но в любом случае заложенный в ходе проектирования фундамент и получившиеся в результате модели имеют большое значение для восприятия процесса. Существуют три основных подхода к проектированию процессов: моделирование до исполнения, через пользовательские интерфейсы и автоматизированное выявление[89]. В любом случае результатом является модель процесса в целом или его фрагмента.
Модель процесса, будь то планируемого или существующего, задает контекст выполняемой работы, применяемые политики, данные, информацию и аналитику, на которые опирается процесс, а также события, на которые он реагирует, потребляемые ресурсы, установленные KPI и целевые показатели. Таким образом, модель процесса – это гораздо больше, чем просто диаграмма потока работ. Это результат приложения умственных усилий к статическим или динамическим схемам, описывающим работу.
Модель процесса может быть простой и статической, но мы наблюдаем эволюцию в направлении интеллектуальных и динамических моделей – эта тенденция является следствием происходящего усложнения и дифференциации бизнес-контекста.
Моделирование бизнес-процессов заранееПервый и наиболее популярный на текущий момент подход – это предварительное моделирование бизнес-процесса, когда процессные модели создаются до исполнения, а затем, по мере обнаружения новых путей, исключений и шагов, в проект вносятся изменения. В этой главе в основном рассматривается именно такой подход, и организации, делающие на него ставку, найдут в тексте главы много полезного. В то же время надо отдавать себе отчет, что существуют альтернативы, которые перечислены ниже.
Проектирование через пользовательские интерфейсыНе оспаривая полезность проектирования процессных моделей в ходе совместной аналитической работы, некоторые организации предпочитают реализовать процесс в интерфейсах информационной системы и протестировать его на пользователях. Такой подход привлекателен для тех, кто привык больше полагаться на непосредственные ощущения и предпочитает вместо изучения графических схем, путей и решений увидеть что-то работающее. Прототипирование и эмпирическая обкатка – это отличный способ привнести в модель процесса реализм.
Автоматизированное выявление бизнес-процессовЭтот подход основан на анализе фактического исполнения процесса. Тактика при этом может варьироваться. Это может быть простое наблюдение за работой исполнителей, непрерывно обращающихся к различным пунктам меню существующей информационной системы, с целью создания полной процессной модели. Несколько сложнее наблюдать за работниками умственного труда (штатными сотрудниками и фрилансерами), совместно выполняющими задание, с целью выявления альтернативных путей выполнения фрагментов процесса. Еще один распространенный вариант – воссоздание процессной модели по записям в аудиторских журналах информационных систем. По нашему мнению, такой подход дополняет адаптивный кейс-менеджмент (ACM)[90], в котором процесс, за исключением желаемых конечных и промежуточных результатов, остается неструктурированным.
Существует несколько подходов к проектированию процессов, и необходимо правильно оценивать, какие из них более применимы к вашей ситуации и к культуре вашей организации.
5.0. Введение
Данная глава посвящена проектированию и перепроектированию существующих процессов с целью повышения их результативности, производительности, качества и согласованности. В ней рассматриваются ключевые аспекты сбора информации, основные работы, выполняемые в ходе подготовки к проектированию и проектирования, а также ключевые факторы успеха таких инициатив.
При этом целью не является продвижение или поддержка конкретных методологий или каких-либо стандартов; рекомендации даются только с целью помочь читателю разобраться с подходами и методами.
Проектирование процесса представляет собой проект, которым, как и любым другим проектом, необходимо управлять. Но, несмотря на критическую важность формального проектного управления, в этой главе оно не рассматривается, так как это отдельная и самостоятельная компетенция. Читателям, интересующимся этой темой, мы предлагаем обратиться к материалам Института проектного управления (PMI)[91].
В данной главе мы рассмотрим все шесть наборов действий, приведенных на рис. 5.1, но при этом мы не будем ни ограничиваться только ими, ни структурировать главу согласно этому списку.
5.1. Что такое проектирование процесса
Процесс: сочетание всех действий, требуемых для достижения цели, получения результата, продукции или услуги, вне зависимости от того, где они выполняются, и необходимого обеспечения. Действия, показанные в контексте их взаимосвязей, образуют последовательность или поток.
Процессы состоят из групп действий, выполняемых людьми и/или машинами для достижения одной или нескольких целей. Они инициируются определенными событиями и порождают определенный результат (или несколько результатов) в виде завершения процесса или передачи ответственности другому процессу. В контексте BPM бизнес-процесс может пересекать любые функциональные границы в интересах полного удовлетворения потребности потребителя в продукции или услуге.
Процесс состоит из потока подпроцессов, каждый из которых производит определенную часть конечной продукции или услуги. Поскольку процессы, как правило, являются кросс-функциональными, то есть проходят через несколько подразделений, проектирование процесса должно охватывать как верхний уровень процесса, так и действия, выполняемые бизнес-подразделениями. Так как любое подразделение, скорее всего, будет выполнять однотипную работу для множества процессов, любое изменение в деятельности подразделения будет иметь далеко идущие последствия. Поскольку деятельность подразделения структурируется исходя из требований производительности, а не по подпроцессам или бизнес-функциям, связь между действиями подразделения и процессом или процессами оказывается размытой. Из-за этого сложно оценить влияние изменения на процесс. На этом уровне в центре внимания – производительность, а не процесс. Это уровень потока работ.
Поток работ: набор действий, выполняемых одним бизнес-подразделением, включающий работу в одном или нескольких процессах. Такая работа структурируется исходя из требований производительности. Поток работ изображается в виде потока, связывающего каждое действие с остальными, выполняемыми бизнес-подразделением.
Эффективное проектирование процесса подразумевает рассмотрение действий как на уровне процесса, так и на уровне потока работ. Объясняется это тем, что результативность процесса можно повысить за счет производительности на уровне потока работ, и наоборот. Во избежание проблем необходимо рассматривать последствия изменений как на одном, так и на другом уровне.
5.1.1. Проектирование процесса
Итак, модель процесса – это формализованное описание целей, результатов и порядка выполнения действий и правил, необходимых для производства продукции или услуги. Данное определение включает представление всех действий в виде потока и описание навыков, оборудования и вспомогательных средств, необходимых для выполнения каждого действия.
Кроме того, процесс является кросс-функциональным, то есть составляющие его действия выполняются несколькими подразделениями и многими людьми. Таким образом, каждое подразделение выполняет действия, относящиеся к нескольким процессам. С целью повышения производительности эти действия обычно группируются по типу выполняемой работы. Такое упорядочивание работы в рамках подразделения называется потоком работ. Процессная команда должна осознавать эту разницу между процессом и потоком работ.
