Инструменты методики АЦТ, часть 16: бережливое управление проектами (Lean Management), роботизированная автоматизация процессов (RPA), управление бизнес-процессами (BPM) и управление проектами по критической цепи (CCPM)

Это шестнадцатая статья цикла по инструментам методики «Аккордная цифровая трансформация». Продолжаем группу B «Управление проектами и процессами» — подгруппу B3 «Оптимизация и интеграция», инструменты B3-01, B3-02, B3-03 и B3-04.

Эта статья открывает подгруппу B3 «Оптимизация и интеграция». Все четыре инструмента относятся к сложным: на освоение каждого отводится от 30 до 36 часов. Бережливое управление проектами (B3-01) убирает из проектной работы потери: ожидание согласований, переделки, дублирование документов. Роботизированная автоматизация процессов (B3-02) поручает программному роботу операции, которые сотрудник повторяет по одним и тем же правилам. Управление бизнес-процессами (B3-03) ведет сквозной процесс как непрерывный цикл — от проектирования до мониторинга и оптимизации. Управление проектами по критической цепи (B3-04) защищает срок проекта общим буфером времени и отказом от многозадачности. Каждый из них повышает эффективность там, где у предприятия уже накопились потери, рутина и просроченные задачи. 

B3-01 — Бережливое управление проектами (Lean Management)

Откуда появился инструмент. Бережливый подход (Lean) вырос из производственной системы Toyota, которую в 1950-х создавали Тайити Оно и инженеры компании. Суть системы — давать клиенту максимум ценности при минимуме потерь. Само слово «lean» («бережливый», «экономный») ввел в 1988 году исследователь Джон Крафчик, изучавший Toyota в Массачусетском технологическом институте, а мировую известность подход получил после книг Джеймса Вумека и Дэниела Джонса «Машина, которая изменила мир» (1990) и «Бережливое мышление» (1996), где сформулированы пять его принципов: определить ценность, выстроить поток создания ценности, обеспечить его непрерывность, работать под вытягивание спроса и стремиться к совершенству. Из производства бережливый подход перенесли и на проекты: в 1992 году финский исследователь Лаури Коскела заложил основы бережливого строительства, а затем принципы Lean распространились на управление проектами в целом.

Суть и механика. Бережливое управление проектами применяет принципы Lean к проектной работе: дать заказчику максимум ценности, устранив все виды потерь. Потери — это все, за что заказчик не стал бы платить: лишние согласования, ожидание, переделки, ненужные функции, простои, избыточная документация. Команда оценивает проект с позиции заказчика, отделяет создающие ценность действия от потерь и убирает второе, высвобождая силы на действительно важное. В отличие от бережливого производства (A2-05), которое работает с повторяющимся потоком на конвейере, здесь тот же принцип применяют к разовому проекту.

Границы применимости. Бережливый подход полезен почти в любом проекте, где есть потери (а они есть почти всегда), особенно там, где важны скорость и эффективность. По методике это сложный инструмент (30 часов): он требует умения видеть потери и менять устоявшиеся процессы. Lean задает философию (максимум ценности, минимум потерь), но не дает готового календарного плана или структуры управления — их берут из других инструментов группы B. Он пересекается с бережливым производством (A2-05) и гибкими подходами (B1-05), с которыми делит установку на ценность и устранение лишнего.

Чек-лист перед применением бережливого управления проектами:

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

Типовые ошибки:

• Сокращают людей вместо потерь. Lean воспринимают как повод сократить штат, и высвобожденное время уходит на прежний неупорядоченный процесс. → Сначала устранять лишние операции и ожидание, а освободившийся ресурс направлять на работу, создающую ценность.
• Оптимизируют участок в ущерб потоку. Отдел ускоряет свой шаг и передает результат туда, где он накапливается в очереди. → Измерять сквозное время всего маршрута, а не выработку отдельного звена.
• Улучшения без владельца. После разовой сессии изменения не закрепляются, и маршрут возвращается к прежнему. → Закрепить ответственного и регулярный пересмотр процесса.
• Цеховые шаблоны на творческих задачах. Инструменты серийного производства применяют к исследованиям, где повторяемости нет. → Отделять повторяющиеся процессы от уникальных и применять Lean только к первым.

B3-02 — Роботизированная автоматизация процессов (Robotic Process Automation, RPA)

Откуда появился инструмент. RPA выросла из простых средств автоматизации 1990-х — макросов (например, в Excel) и считывания данных прямо с экранов программ (так называемого скрапинга). В начале 2000-х появились программы, воспроизводившие действия человека за компьютером: британская компания Blue Prism, основанная в 2001 году Аластером Батгейтом и Дэвидом Моссом, вывела на рынок программных «роботов», воспроизводящих щелчки мышью и нажатия клавиш. Сам термин «роботизированная автоматизация процессов» закрепился около 2012 года, а массовым инструментом RPA стала после 2018-го, на волне цифровой трансформации, вместе с платформами вроде UiPath и Automation Anywhere. В управлении проектами RPA дополняет операционную автоматизацию (A5-01), принимая на себя рутинные операции проектных процессов.

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

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

Границы применимости. RPA оправдана для частых, однообразных и четко описанных задач с понятными правилами — перенос данных, формирование отчетов, обработка типовых заявок. По методике это сложный инструмент (30 часов): нужно грамотно описать сценарии и поддерживать их. Робот хорош на стабильных процессах; если процесс постоянно меняется или требует суждения, автоматизация ломается или ошибается. Важно сначала упорядочить процесс, а уже потом автоматизировать: робот, настроенный на некорректно выстроенный процесс, лишь ускорит неупорядоченную работу. Поэтому RPA естественно применяется после упорядочивания процессов (BPM, B3-03).

Чек-лист перед внедрением RPA:

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

Типовые ошибки:

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

B3-03 — Управление бизнес-процессами (Business Process Management, BPM)

Откуда появился инструмент. Управление бизнес-процессами как дисциплина сложилось в 1990-е годы на стыке реинжиниринга процессов (A2-01) и управления рабочими потоками. В методике различаются два уровня: базовое управление процессами (B1-02), разобранное в части 12, и углубленное управление сквозными бизнес-процессами (B3-03), о котором идет речь здесь. BPM как подход не следует путать с нотацией BPMN (B2-07): первое — способ управлять процессами, второе — язык их графического описания.

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

Границы применимости. Это сложный инструмент (36 часов на освоение). BPM требует владельца процесса, дисциплины описания и данных для мониторинга; для небольшой организации с простыми процессами полный цикл может оказаться избыточным, и достаточно базового уровня (B1-02). Для описания процессов метод опирается на нотацию BPMN (B2-07), для автоматизации отдельных шагов — на RPA (B3-02). Без встроенных показателей и регулярного пересмотра BPM превращается в разовое описание процессов, которое устаревает.

Чек-лист перед внедрением BPM:

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

Типовые ошибки:

• Описание ради описания. Процессы описаны схемами, но управления по ним нет. → Привязать к каждому процессу показатели и цикл пересмотра.
• Локальная оптимизация вместо сквозной. Улучшают участки, а сквозной срок не меняется. → Измерять и оптимизировать процесс целиком, от входа до результата для клиента.
• Процесс без владельца. За сквозной маршрут не отвечает никто, решения принимаются на границах отделов. → Назначить владельца процесса с полномочиями поверх подразделений.
• Схемы, оторванные от практики. Описан идеальный процесс, а люди работают по прежнему маршруту. → Описывать процесс «как есть», проверять по факту исполнения и обновлять при расхождениях.

B3-04 — Управление проектами по критической цепи (Critical Chain Project Management, CCPM)

Откуда появился инструмент. Метод создал Элияху Голдратт (1947–2011) — израильский физик и консультант, автор теории ограничений, которую он изложил в деловом романе «The Goal» (1984). Управление по критической цепи Голдратт представил в романе «Critical Chain» (1997). CCPM применяет логику теории ограничений к проектам: расставляет приоритеты и ведет проект с опорой на ключевые ограничивающие факторы и минимальный расход ресурсов.

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

Границы применимости. Это сложный инструмент (36 часов на освоение). Метод силен там, где сроки срывают конкуренция за общие ресурсы и многозадачность. Он отличается от метода критического пути (B2-05), который расставляет задачи по порядку и датам, но не учитывает ограниченность ресурсов, — CCPM добавляет именно ресурсное измерение. Основание метода — теория ограничений (A3-08). У подхода есть критика: допущения о том, что оценки задач всегда завышены и их можно смело делить, а любая многозадачность вредна, справедливы не в каждой организации, поэтому применять CCPM как догму без проверки на собственных проектах не стоит.

Чек-лист перед применением управления по критической цепи:

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

Типовые ошибки:

• Буфер возвращают в задачи. Общий буфер негласно распределяют по задачам, и защита срока исчезает. → Держать буфер единым и управлять только его общим расходом.
• Контроль по датам задач вместо буфера. С исполнителей требуют завершить каждую задачу точно в срок, возвращая прежнюю модель. → Перенести контроль на скорость расходования буфера проекта.
• Сокращают оценки, не сняв давление. Оценки сократили, но за срыв конкретной задачи по-прежнему наказывают. → Объяснить, что задачи планируются по 50-процентной вероятности, и оценивать проект, а не отдельную задачу.
• Игнорируют многозадачность. Люди формально ведут критическую цепь, но их постоянно переключают на другие проекты. → Обеспечить приоритет задач критической цепи и защитить исполнителей от параллельных поручений.

Резюме

Бережливое управление проектами (B3-01) устраняет из проектной работы потери и лишние шаги. Роботизированная автоматизация процессов (B3-02) освобождает сотрудников от повторяющихся операций и связывает несвязанные системы. Управление бизнес-процессами (B3-03) смещает управленческое внимание с отдельных отделов на сквозной процесс и ведет его как непрерывный цикл. Управление проектами по критической цепи (B3-04) защищает срок проекта общим буфером и отказом от многозадачности.

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

В следующей статье цикла продолжим разбор группы B — стык оптимизации и координации: интеграцию разработки и операций (DevOps, B3-05), масштабируемый Agile (SAFe, B3-06), искусственный интеллект в управлении проектами (B3-07) и управление стейкхолдерами (B4-01).