Основы Agile-методологий

Процессный подход как конкурентное преимущество

В материале рассматриваются современные процессные методологии — последовательная (Waterfall), итеративная и Agile. Изложение строится от анализа статистических данных о популярности и успешности Agile к детальному сравнению преимуществ и недостатков каждого подхода. Далее вводятся критерии выбора: размер проекта, определённость требований и технологий (матрица сложности Ральфа-Стейси). На примере практического кейса внедрения HR-системы показано применение этих критериев. Завершается материал обобщением условий, при которых использование Agile целесообразно, а когда оно не принесёт ожидаемого эффекта.

Основные мысли

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


2.1. Процессный подход

Смысл процессного управления

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как и множество информационных систем, workflow-системы стали реакцией ИТ-рынка на появление процессного подхода к управлению, именно в workflow-системах появился такой объект, как бизнес-процесс, который настраивался разработчиком или системным аналитиком при внедрении workflow-системы, и в соответствии с которым маршрутизировались задачи в рамках исполнения бизнес-процесса. Впоследствии вместе с расширением функционала workflow-системы приобрели название BPMS (Business Process Management Suite), сейчас данные системы называются iBPM (intelligent Business Process Management).

По мнению многих руководителей, автоматизация бизнес-процессов часто является единственным результативным способом внедрить бизнес-процесс "как должно быть" в деятельность в точном соответствии с целевой моделью. И именно поэтому в некоторых компаниях стали использоваться системы iBPM для автоматизации некоторых кросс-функциональных бизнес-процессов, а некоторые компании даже смогли замкнуть цикл управления для ключевых бизнес-процессов, внедрив помимо систем iBPM ИТ-решения класса BI (Business Intelligence) для анализа процессных показателей.

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

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

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

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

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

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

Контроллинг бизнес-процессов

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

Помимо систем класса PI для анализа бизнес-процессов могут быть использованы специализированные ИТ-решения. Такие как Process Mining - в решениях этого класса на основании данных о фактическом исполнении бизнес-процесса выстраивается графическая модель бизнес-процесса, а также системы класса Business Activity Monitor (BAM), которые собирают в оперативном режиме статистику по исполняемому процессу.

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

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

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

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

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

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

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

2.2. Значимость процессного офиса во внедрении процессного подхода. Возможные варианты

От центра компетенции к процессному офису

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответственность за бизнес-процесс

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

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

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

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

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

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

Варианты организации процессного офиса

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

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

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

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

2.3. Движение в направлении гибкости. Пилотные процессы и управление изменениями

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

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

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

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

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

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

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

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

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

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

2.4. Регламент как основа процессного подхода

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

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

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

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

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

В начале документа нужно указать цель регламента, например, установление порядка взаимодействия при расчете заработной платы или сокращение времени обработки заявки клиента. Далее необходимо сделать раздел с терминами и сокращениями, которые будут использоваться в регламенте бизнес-процесса: например, ДУП - Департамент управления персоналом или ЦФО - центр финансового обеспечения.

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

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

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

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

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

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

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

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

2.5. Краткие выводы

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

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

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

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

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

Современные исследования (включая отчёты Standish Group) фиксируют растущую популярность и более высокую успешность Agile по сравнению с последовательным подходом (Waterfall). Выделяют три типа процессных методологий.

Последовательная (Waterfall) — жёсткая цепочка этапов, возврат к началу при ошибках. Надёжна, но дорога, медленна, критична к изменениям, требует объёмной документации. Проблемы выявляются лишь на финальном тестировании.
Итеративная — работа делится на итерации (1–6 месяцев). Планы корректируются по итогам каждой итерации. Сохраняется высокая определённость, документационная нагрузка и частичная критичность изменений.
Agile — итеративный процесс с двухнедельными итерациями и обязательным постоянным участием заказчика. Это обеспечивает быстрые результаты и адаптивность. Недостатки: возможно низкое качество на старте, риск архитектурных проблем и недостижения первоначальных целей (но продукт всё равно несёт ценность).

Рекомендации по применению:
• Waterfall — когда требования полностью ясны, стабильны, технологии известны, проект крупный и хорошо финансируется.
• Итеративная — когда общие цели ясны, команда стабильна и технологии известны.
• Agile — когда пользователь вовлечён с начала до конца, цели могут корректироваться, проект относительно небольшой, команда стабильна, система модульна.

Статистика успешности и размер проекта
Анализ более 100 000 проектов за 5 лет показывает:
• На больших проектах Agile успешнее, а Waterfall лидирует по явным провалам.
• На средних проектах преимущество Agile усиливается.
• На малых проектах Agile продолжает лидировать по успеху, но Waterfall выходит вперёд по спорным результатам, что говорит о его вытеснении даже из этой ниши.

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

Матрица сложности Ральфа-Стейси
Помимо размера, важно учитывать определённость требований и технологий.
• Простые проекты (всё определено) → Waterfall.
• Комплексные проекты (неопределённость и требований, и технологий, но ситуация стабильна) → Agile.
• Полная анархия (хаос по обеим осям) → нельзя начинать разработку. Необходимо предварительное исследование для снижения неопределённости и перехода в зону комплексности.

Практический кейс (внедрение HR-системы)
Крупная компания заменяет устаревшую систему управления персоналом. 40 процессов автоматизированы, 15 новых описаны поверхностно. Критично: быстрый старт (первая волна за 3 месяца, весь проект до полугода) и поэтапный запуск. Сравнение эффективности Waterfall и Agile ведётся по участию руководства, определённости требований, объёму работ, срокам, модульности системы и необходимой документации. Анализ склоняется в пользу Agile из-за сжатых сроков, неполных требований и модульной структуры.

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

Выводы

1. Статистика Standish Group подтверждает, что Agile превосходит Waterfall по доле успешных проектов и реже приводит к провалам.
2. Последовательная методология (Waterfall) незаменима, когда требования стабильны, технологии известны, а проект крупный.
3. Итеративная модель сокращает риски по сравнению с Waterfall, но сохраняет высокую документационную нагрузку и критичность изменений.
4. Ключевое отличие Agile — вовлечение пользователя в постоянную работу и ультракороткие итерации до двух недель.
5. Главный недостаток Agile — возможное низкое качество на старте и риск архитектурных проблем при слабом контроле.
6. На больших, средних и малых проектах Agile стабильно показывает более высокую успешность.
7. В малых проектах Waterfall лидирует по доле спорных результатов, что говорит о его вытеснении даже из этой ниши.
8. Матрица сложности Ральфа-Стейси предписывает использовать Waterfall в простых проектах, а Agile — в комплексных.
9. При полной анархии (неопределённость и требований, и технологий) нельзя начинать проект — необходимо предварительное исследование.
10. Практический кейс демонстрирует, что сжатые сроки и частичная неопределённость требований склоняют выбор в пользу Agile.
11. Agile требует поддержки руководством гибкой культуры, ответственности за продукт и взаимного доверия.
12. Использование Agile без выполнения базовых ценностных и культурных условий нецелесообразно и не приведёт к успеху.

Вопросы для самопроверки

1. Какие три типа процессных методологий рассмотрены и в чём их принципиальные различия?
2. Какова рекомендуемая длительность итерации в классическом Agile и почему она важна?
3. Какие преимущества и недостатки последовательной методологии (Waterfall) были выделены?
4. Чем итеративная методика отличается от чисто последовательной и от Agile?
5. При каких условиях целесообразно применять Waterfall?
6. Какие факторы, согласно статистике, делают Agile более успешным в малых и средних проектах?
7. Как интерпретировать оси матрицы сложности Ральфа-Стейси и каким типам проектов соответствует каждая зона?
8. Почему начинать проект в зоне «полной анархии» не рекомендуется и что следует предпринять?
9. Какие параметры требовалось оценить в практическом кейсе для сравнения Waterfall и Agile?
10. Почему вовлечённость конечного пользователя считается кардинальным преимуществом Agile?
11. Какие культурные и управленческие условия необходимы для успешного внедрения Agile?
12. Можно ли считать Agile универсально лучшим подходом для любых проектов? Обоснуйте ответ.
Вернуться к учебному плану