doc/BPM/theory/triangle/version2.md

Proj-triangle. V2

1 Базовый вопрос

Есть проектный треугольник. По аналогии построй процессный треугольник. Вершины: группа владельцев процессов, группа владельцев продуктов и руководители орг-структурных подразделений (начальники департаментов). Ресурсы – исполнители в процессах – ограничены (используй теорию ограничений). Примеры противоречий:

• 1 каждое структурное подразделение заинтересовано в сквозном процессе взять меньше работ, при этом как можно больше переложить на другое.
• 2 Владелец процесса заинтересован не оставлять незакрытых участков, но подразделения стараются по минимуму участвовать в сквозном процессе
• 3 Владелец продукта заинтересован чаще менять продукты (частая модернизация), в тоже время владелец процесса заинтересован в стабильности (малой изменчивости технологии процесса, управлению изменениями с минимальным риском)
• 4 Владелец продукта заинтересован в снижении себестоимости продукта, в тоже время чтобы выполнить SLA процесса Владелец процесса заинтересован в увеличении привлекаемых ресурсов (численности и квалификации персонала) и увеличении контрольных процедур.
  Продолжи противоречия в таблице и покажи примеры наиболее острых ситуаций.

Комменты:

• тема возникла из НеФактический владелец бизнес-процесса и Треугольник орг-структур компании. Часть 1
• version1.md

Ответ ИИ (дипсик)

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

Давайте построим Процессный треугольник и проанализируем его.

Процессный Треугольник

Это система динамического взаимодействия и противоречий между тремя ключевыми ролями, которые "тянут одеяло" на себя в условиях ограниченных ресурсов (исполнителей).

Вершины треугольника:

1. Владельцы продуктов: Отвечают за ценность продукта для клиента и рынка.
2. Владельцы процессов: Отвечают за эффективность, стабильность и качество выполнения сквозных процессов.
3. Руководители подразделений (начальники департаментов): Отвечают за эффективное использование выделенных им ресурсов (сотрудников) и выполнение функциональных задач.

Ограничение (по Теории Ограничений): Ограниченное количество и capacity исполнителей (сотрудников), которые являются общим ресурсом для всех процессов, продуктов и подразделений.

---

Таблица противоречий Процессного треугольника

Сторона 1	Сторона 2	Суть противоречия	Пример острой ситуации
Руководитель подразделения (хочет минимизировать свою нагрузку в сквозных процессах)	Владелец процесса (хочет полного контроля над всеми этапами)	1. Противоречие распределения работы. Каждое подразделение стремится формально участвовать в процессе, минимизируя свои трудозатраты, в то время как владелец процесса заинтересован в четком распределении зон ответственности и объемов работ.	Ситуация с KPI: Владелец сквозного процесса "Выпуск новой карты" требует от каждого отдела предоставить сотрудника на 20% времени. Руководители отделов вписывают в планы самых слабых сотрудников, сохраняя лучших для "основной" работы. Владелец процесса не может управлять этими ресурсами, так как они ему не подчинены.
Руководитель подразделения (хочет сохранить контроль над ресурсами)	Владелец процесса (хочет эффективно управлять ресурсами в процессе)	2. Противоречие полномочий. Руководители подразделений стремятся сохранить административный контроль над своими сотрудниками, даже когда те работают в сквозном процессе. Владелец процесса нуждается в оперативном управлении этими людьми для скорости и качества.	Ситуация с приоритетами: Владелец процесса "Обработка претензий" требует срочно выделить двух аналитиков на расследование массового инцидента. Руководитель отдела аналитики отказывает, так как его команда загружена срочным отчетом для директора по финансам (его прямого начальника). Процесс останавливается.
Владелец продукта (ориентирован на гибкость и скорость изменений)	Владелец процесса (ориентирован на стабильность и предсказуемость)	3. Противоречие изменчивости. Владелец продукта требует быстрых изменений в процессе для адаптации продукта под рынок. Владелец процесса сопротивляется, так как каждое изменение ломает отлаженную схему, требует переобучения персонала и создает риски ошибок.	Ситуация с запуском акции: Владелец карточного продукта требует за 3 дня изменить процесс рассмотрения заявок для новой акции ("одобрение за 1 минуту"). Владелец процесса заявок говорит, что это невозможно без тестирования и корректировки регламентов, и предлагает срок 3 недели. Продукт упускает рыночное окно.
Владелец продукта (ориентирован на прибыльность продукта)	Владелец процесса (ориентирован на качество и выполнение SLA)	4. Противочие "Качество vs. Затраты". Владелец продукта требует снизить себестоимость обслуживания. Владелец процесса, чтобы гарантировать качество (SLA), требует больше ресурсов (например, более квалифицированных сотрудников) или введения дополнительных контрольных точек, что увеличивает стоимость.	Ситуация с упрощением процесса: Владелец продукта "Дебетовая карта" требует убрать один из этапов верификации для ускорения и удешевления процесса. Владелец процесса "Оформление карт" протестует, так как это приведет к росту мошеннических операций на 15%, что съест всю экономию.
Владелец продукта (хочет уникальный процесс для своего продукта)	Руководитель подразделения (хочет унификацию задач для ресурсов)	5. Противочие кастомизации. Для повышения конкурентоспособности своего продукта его владелец требует уникальных, отличных от других, шагов в процессе. Руководитель подразделения против, так как это усложняет работу его сотрудников, которым приходится переключаться между разными схемами работы, что ведет к ошибкам и требует большего обучения.	Ситуация с VIP-обслуживанием: Владелец "Премиум-карты" требует, чтобы на этапе анкетирования его клиентам задавали 10 дополнительных вопросов о предпочтениях. Руководитель колл-центра против, такому его операторам придется работать по двум fundamentally разным скриптам, что резко снизит их эффективность.
Руководитель подразделения (оценивается по загрузке своих ресурсов)	Владелец продукта (оценивается по прибыльности продукта)	6. Противочие модели финансирования. Подразделения часто являются "центрами затрат", и их эффективность считают по загрузке их ресурсов. Владелец продукта же хочет платить только за реально оказанные услуги в рамках его продукта (модель "центр прибыли").	Ситуация с IT-отделом: Владелец цифрового продукта хочет перейти на аутсорс разработки, так как это дешевле. Руководитель внутреннего IT-департамента, имеющий штат из 50 разработчиков, блокирует это решение, так как ему нужно обеспечивать их загрузку, иначе придется сокращать штат.

---

Примеры наиболее острых ситуаций (Конфликт "Треугольника в действии")

1. Запуск инновационного продукта.

   • Владелец продукта: "Дайте мне команду лучших специалистов из всех отделов, мы сделаем прорывной продукт за 2 месяца!"
   • Владелец процесса: "Я не могу разорвать действующие процессы ради вашего эксперимента. Мои SLA рухнут."
   • Руководители подразделений: "Мои лучшие сотрудники заняты на плановых работах. Я не могу отдать их вам, иначе мои отдельные показатели будут не выполнены."

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

2. Критический сбой в сквозном процессе.

   • Владелец процесса: "Срочно нужно 10 человек из всех смежных отделов для устранения последствий и работы с клиентами!"
   • Руководители подразделений: "Это не по штатному расписанию. У меня нет лишних людей. Кто будет оплачивать сверхурочные? Чьи текущие задачи будут сорваны?"
   • Владелец продукта: "Этот сбой бьет по репутации моего продукта! Немедленно все исправьте, но бюджет на исправление я несу не я, так как это проблема процесса."

   Итог: Поиск виноватых и решение проблемы затягиваются, ущерб для бизнеса и клиентов растет.

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

2 Уточнение

Приведи только чисто процессные ситуации (рутинные операции). Ключевое: ситуация из "Кто сшил костюм?" А. Райкина. Т.е. функциональные подразделения "только ответсвенны за пуговицы или рукава", но в целом за общий конвейер отвечать не готовы и х вообще хотят сократить свое участие в конвейере.
Кроме того, управление сквозным процессов - эффективно на примере бригадного подхода в дофордовскую эпоху (бригадир был владельцем процесса по сборке автомобиля). Покажи конфликт интересов и невозможность создать бригады, неэффективность матричного подхода. А также сравни Владельца процесса, Владельца продукта и начальника Департамента с сюжетом "Лебедь, рак и щука" из басни Крылова.

2.1 Размышления

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

Ключевые моменты:

• Функциональные подразделения (как в монологе Райкина) заточены на узкую операцию (пришить пуговицу, втачать рукав), но не несут ответственности за весь костюм (сквозной процесс).
• Владелец сквозного процесса (как бригадир в дофордовской сборке) пытается координировать всю цепочку, но не имеет полной власти над ресурсами.
• Матричная структура, где сотрудник подчиняется и начальнику отдела (функциональному менеджеру), и владельцу процесса, часто приводит к конфликту приоритетов.

Сравнение с басней "Лебедь, Рак и Щука":

• Владелец продукта (Лебедь) тянет в небо (к частым изменениям, к новому).
• Владелец процесса (Рак) тянет назад (к стабильности, к отлаженным процедурам).
• Начальник департамента (Щука) тянет в воду (в сторону интересов своего подразделения, в сторону функциональных задач).

Теперь рассмотрим чисто процессные (рутинные) ситуации. Пример 1: Процесс "Оформление кредита" в банке.

• Этапы: прием заявки, проверка данных, скоринг, принятие решения, оформление договора, выдача кредита.
• Владелец процесса (кредитный процесс) хочет, чтобы весь процесс занимал 2 часа.
• Начальник отдела проверки данных: "Мои сотрудники загружены проверкой данных по другим продуктам, мы не можем выделить человека только под кредиты. К тому же, мы отвечаем только за свою часть, а то, что после нас договор долго оформляется — это не наша проблема."
• Начальник отдела оформления договоров: "Мы не можем работать быстрее, потому что у нас есть регламент, и мы отвечаем за юридическую чистоту. Пусть скоринг быстрее делают."

Пример 2: Процесс "Выпуск банковской карты".

• Владелец продукта (карточный продукт) хочет увеличить долю рынка, поэтому требует выпускать карты за 1 день.
• Владелец процесса (процесс выпуска карт) говорит, что это невозможно, потому что:
  • Отдел персональных данных (начальник — Щука) требует 1 день на проверку клиента.
  • Производственный отдел (начальник — Раки) говорит, что печать карты занимает 1 день, и они не могут сделать быстрее, потому что у них очередь и на другие продукты.
• Владелец продукта (Лебедь) говорит: "Надо изменить процесс, чтобы карту можно было выпускать в течение дня, иначе мы проигрываем конкурентам!"
• Владелец процесса (Рак): "Мы не можем изменить процесс, не нарушив контрольные точки. Надо либо увеличить штат, либо изменить регламенты, что займет месяц."
• Начальник отдела персональных данных (Щука): "Мои сотрудники и так перегружены, если мы будем делать быстрее, возрастут ошибки, а за них отвечаю я."

Пример 3: Процесс "Обслуживание клиента в отделении банка".

• Клиент приходит с несколькими вопросами: открыть счет, получить карту, консультация по кредиту.

• Владелец процесса обслуживания (например, начальник отдела обслуживания) хочет, чтобы клиент был обслужен в одном окне и быстро.

• Но:

  • Специалист по открытию счетов (из отдела расчетных операций) не может консультировать по кредитам (это другой отдел).
  • Специалист по кредитам (из кредитного отдела) не может выпускать карты (это делает отдел карт).

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

Теперь о конфликте интересов и неэффективности матричного подхода: В матричной структуре сотрудник (исполнитель) имеет два руководителя:

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

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

Проблемы:

• Приоритеты: Кому подчиняться в первую очередь? Если начальник отдела говорит: "Сначала сделай мою задачу, а потом процессную", а владелец процесса требует срочно, то сотрудник в стрессе.

• Оценка: Кто оценивает сотрудника? Функциональный начальник может не учитывать вклад в сквозные процессы, а владелец процесса не имеет рычагов влияния на премию.

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

Аналогия с дофордовскими бригадами:

• Бригадир (владелец процесса) собирает автомобиль с начала до конца с помощью бригады рабочих, которые владеют несколькими навыками. Это эффективно, но медленно и не масштабируется.

• Функциональный подход (конвейер Форда) разбивает сборку на простые операции, за которые отвечают разные подразделения. Это увеличивает скорость, но теряется гибкость и ответственность за конечный продукт.

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

Сравнение с "Лебедь, Рак и Щука":

• Владелец продукта (Лебедь) — тянет в сторону инноваций, изменений, чтобы продукт был конкурентоспособен.
• Владелец процесса (Рак) — тянет в сторону стандартизации, стабильности, чтобы процесс был предсказуем и эффективен.
• Начальник департамента (Щука) — тянет в сторону своих функциональных интересов (загрузка своих сотрудников, выполнение своих KPI).

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

Пример острой ситуации из монолога Райкина:

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

В итоге, чтобы решить эти проблемы, нужно:

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

2.2 Ответ

Отлично, углубимся в чистую процессную рутину и классические организационные противоречия, убрав проектный контекст.

Процессный Треугольник: "Лебедь, Рак и Щука" корпоративного мира

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

• Владелец продукта — Лебедь. Тянет в небо, к рынку и клиенту. Его лозунг: "Нужно быстрее и дешевле, чтобы удовлетворить спрос!"
• Владелец процесса — Рак. Тянет назад, к стабильности и регламенту. Его лозунг: "Так не положено! Нарушим технологию — получим брак!"
• Начальник департамента — Щука. Тянет в воду, вглубь функциональной "норы" (функциональному колодцу, silos). Его лозунг: "Мои люди не должны простаивать, их главная работа — это задачи моего отдела!"

Ограничение (по Теории Ограничений): Общее время исполнителей, которое безжалостно дробится между этими тремя "хозяевами".

---

Конфликт на конвейере: "Кто сшил костюм?" по-корпоративному

Рассмотрим сквозной процесс "Оформление и выдача кредита" в банке.

• Владелец процесса: Управляет всей цепочкой: от заявки до выдачи денег.
• Владельцы продуктов: Менеджеры по продаже "Кредита наличными", "Ипотеки", "Автокредита".
• Начальники департаментов: Начальник отдела приема заявок, начальник службы безопасности (СБ), начальник юридического отдела, начальник операционного отдела.

Таблица противоречий в рутинных операциях

Сторона 1	Сторона 2	Суть противоречия	Пример острой ситуации "из жизни"
Начальник Юридического отдела	Владелец процесса "Оформление кредита"	Противоречие "узкой специализации vs. сквозной ответственности". Юрист отвечает только за юридическую чистоту одного пункта договора, но не за скорость всего процесса. Владелец процесса отвечает за скорость и цельность.	Ситуация "Пункт 5.1.7": Юрист находит незначительную неточность в формулировке договора, не влияющую на риски. Он останавливает всю выдачу кредитов по этому продукту, пока его правка не будет согласована со всеми инстанциями. Клиенты уходят, план по выдаче сорван. Владелец процесса в ярости, но юрист "чист" – он предотвратил юридическую риску.
Начальник Службы Безопасности	Владелец продукта "Кредит наличными"	Противочие "риск vs. доход". СБ заинтересована в многоуровневой проверке каждого клиента. Владелец продукта – в одобрении как можно большего числа заявок для выполнения плана по объему выдач.	Ситуация "Слишком бдительная СБ": Владелец продукта запускает акцию "Кредит за 2 часа". СБ, чтобы не увеличивать свои операционные риски, не меняет регламент проверки, который занимает 1 рабочий день. В результате акция проваливается. СБ говорит: "Наша задача – не одобрять, а отсекать рисковых".
Владелец продукта "Ипотека"	Владелец процесса "Оформление кредита"	Противочие "гибкость vs. стандарт". Владелец ипотеки требует для своих VIP-клиентов особую, ускоренную процедуру с пропуском некоторых этапов. Владелец процесса против, так как это ломает унифицированную схему, создает хаос и ошибки для рядовых операционистов.	Ситуация "Особый статус": По просьбе владельца продукта, VIP-клиента проводят вне очереди. Операционист, привыкший к стандартной схеме, теряется, забывает внести данные в нужную систему на втором этапе. В результате клиент все равно ждет, но теперь по вине внутренней неразберихи.
Начальник Отдела приема заявок	Все остальные	Противочие "перенаправление клиента". Задача отдела – принять заявку и максимально быстро передать ее дальше, сняв с себя ответственность. Но следующие в цепочке подразделения требуют, чтобы заявка была "идеальной" и заполненной на 100%.	Ситуация "Ваша проблема": Оператор call-центра (в подчинении нач. отдела) принимает заявку, но не уточняет какой-то незначительный, но обязательный для юристов параметр. Он отправляет заявку дальше, чтобы выполнить свой KPI по скорости. Юридический отдел возвращает заявку на доработку. Клиент ждет, цикл времени увеличивается втрое.

---

Почему "Бригадный подход" (как у владельца процесса) не работает в функциональной матрице

Бригадный подход (до Форда): Владелец процесса – это Бригадир. Он собирает команду (бригаду) из универсалов, которые вместе собирают весь автомобиль "с начала до конца". Бригадир полностью управляет ими, отвечает за результат и срок.

Почему это эффективно, но неприменимо в матрице:

1. Конфликт с начальниками департаментов (Щуками). Чтобы создать бригаду, бригадиру (Владельцу процесса) нужно "отобрать" лучших универсалов из отделов. Начальники отделов никогда на это не пойдут, так как лишатся ключевых ресурсов и останутся с худшими сотрудниками, неспособными выполнять их "основную" работу.
2. Невозможность универсализации. В современном банке (как в примере с костюмом) юрист не может быть специалистом по безопасности, а операционист – юристом. Функциональные "норы" слишком глубоки. Бригада из таких узких специалистов будет постоянно простаивать, пока один из них выполняет свою работу.
3. Неэффективность матричного подхода. Матрица – это попытка совместить оба подхода. Исполнитель находится в двойном подчинении. На практике это приводит к шизофрении:
   • Владелец процесса (Бригадир): "Иванов, срочно обработай 10 заявок, от этого зависит выполнение плана процесса!"
   • Начальник департамента (Функциональный босс): "Иванов, забудь про эти заявки, тебя ждет планерка по нашему отделу, а потом ты должен пройти обязательное обучение новым юридическим нормативам."

Итог: Исполнитель Иванов разрывается, его эффективность падает. "Телега" не едет. Владелец процесса не может повлиять на функционального босса Иванова. Бригада не собирается, а конвейер, разорванный на куски функциональными подразделениями, работает с бесконечными задержками и перекладками ответственности, в точности как в монологе Райкина: "А пуговицы кто пришивать будет? А я пуговицы пришиваю! А мы – рукава!". И пока кто-то один (клиент) ждет целый костюм.