tgoop.com/devops_architecture/28
Last Update:
Платформенный подход и трансакционные издержки
В начале 20 века английский экономист Рональд Коуз изучал причину появления фирм на свободном рынке, и в своей статье Природа фирм он пришел к следующему:
- Трансакционные издержки (расходы на поиск и взаимодействие контрагентов и их контрактацию) внутри фирмы ниже, чем трансакционные издержки на рынке, и поэтому найм может оказаться дешевле чем аутсорсинг. Контракт с сотрудником обслуживать дешевле, чем контракт с внешней организацией (даже если это рамочный контракт).
- В противном случая аутсорсинг дешевле, т.к. внешний подрядчик оптимизирует работу своей компании для того, чтобы стать более конкурентоспособным, и поэтому будет более эффективным чем внутренний сотрудник.
- Одновременно с этим при росте компании растут издержки на управление самой компанией, увеличивается количество ошибок управления и т.д.
- Размер компании определяется оптимумом между расходами на трансакционные издержки и расходами на издержки управления.
Подробнее предлагаю прочитать в википедии, либо в первоисточнике — я мог недостаточно четко пересказать основные мысли оттуда.
В этом контексте кажется можно рассматривать экосистемы и компании состоящие из самоорганизующихся команд как промежуточное звено между фирмами по Коузу и свободным рынком:
- Трансакционные издержки между командами внутри компании ниже, чем трансакционные издержки между компанией и внешним рынком
- В то же самое время расходы на управление такой компанией ниже, чем для “плановой экономики” с централизованным управлением
Почему же далеко не все идут в эту сторону несмотря на модный тренд? Для этого должна быть другая архитектура постановки задач и контроля, да и по большому счету вся архитектура взаимодействия с сотрудниками и подразделениями.
Команды должны быть либо максимально независимыми, вертикальными и достаточно узкими (Платформенный подход):
- с одной стороны для оптимизации команды вокруг предоставляемого сервиса (качества и стоимости для потребителя, в т.ч. трансакционной стоимости)
- с другой — для снижения управленческих издержек внутри самой этой команды
Либо команды должны быть горизонтальными, с максимально полностью делегированной ответственностью за сквозной Value Stream — для оптимизации команды вокруг пропорции “доставляемая до клиента ценность к running cost” этого стрима. При этом, чтобы не было роста управленческих издержек внутри команды вся непрофильная активность этого стрима будет аутсорситься на внешних вендоров (по отношению к команде, не к компании!), т.е. на платформенные и развивающие (enabling) команды.
Интересной особенностью здесь становится то, что мы можем в число поставщиков без особых проблем вносить и внешних вендоров если они будут соответствовать некоторым критериям, которым соответствуют все наши внутренние вендоры (платформенные команды). Подход “Private cloud” во многом как раз призван решить именно эту задачу — упростить онбординг партнеров и внешних вендоров внутрь ландшафта компании. На всех крупных заводах немалые площади выделены именно для компаний-партнеров для обеспечения локальности производства.
Чего не хватает в этой картине? Финансирования, т.е. циклов обратной связи между платформенной командой и “внутренним рынком”, и горизонтальной командой (но не компанией целиком!) и “внешним рынком”. Какие-то зачатки такой обратной связи предлагаются в практиках “error budget” и “security budget” и абстрактных отсылках к “продуктовому подходу” без конкретики, но их явно недостаточно.
Встречались ли кому-то еще какие-то материалы на эту тему?
BY Об DevOps и архитектуру
Share with your friend now:
tgoop.com/devops_architecture/28