Инжиниринг корпорации

А нужны ли программисты в штате?
Из переписки: «Ок, мы поняли про WIP, шаблоны, эскалации, ИТ-слой процесса. Но тогда нужно нанимать программистов в штат? И каких?»

Сначала базовая развилка: «гигиена» vs «двигатель»
Есть автоматизация-гигиена: CRM, учет, документооборот, заявки, типовые шаблоны, интеграции. Это нужно всем и всегда это дешевле купить готовым.

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

Правило: своя разработка оправдана, если это «двигатель» конкурентности, который влияет на unit economics и плохо покупается коробкой. Но команда должна жить как продуктовая/проектная единица с roadmap, а не как «вечный цех по хотелкам».

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

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

Вечный настройщик коробки – это не стратегия
Если «коробку» нужно «донастраивать» всю жизнь, значит это не «коробка», а вечная стройка. Это не значит, что «все коробки плохие». Это значит, что вы либо купили не тот класс решения, либо пытаетесь одной коробкой заменить процесс и архитектуру (объять необъятное и впихнуть невпихуемое), либо строите вокруг неё костыли на все случаи жизни, вместо того, чтобы стабилизировать вход/выход и правила.

Кого на самом деле нужно нанимать и когда
Теперь аккуратно «отрежем» малый бизнес. Пока вы маленькие, у вас обычно 1–2 ключевые системы, изменения редкие, интеграций мало, а половина процессов держится на голове владельца (и на его телефоне). В таком состоянии постоянный программист чаще вреден: он превращается в личного шамана, который «единственный знает как». И вы получаете новую зависимость вместо скорости.

Но как только вы становитесь средним предприятием, появляются признаки, которые нельзя «перетерпеть»:
• 3+ критичных систем (CRM + учет + документы + что-то ещё),
• 2–3 потока, которые должны работать параллельно и быстро,
• регулярные изменения и интеграции,
• видимые очереди между функциями.

Вот здесь почти неизбежно нужны две роли. И это не «IT-директор с армией». Это две точки управления скоростью:

Роль 1. Архитектор потока (процесс/BA-роль).
Это человек, который держит контракты процессов: вход/выход/DoD, SLA, эскалации, метрики потока. Он превращает «работу отдела» в сервис с понятными правилами. Из этой роли естественным образом вырастет бизнес-архитектор.

Роль 2. Инженер автоматизации и интеграций.
Не «настройщик одной коробки», а тот, кто строит нервную систему: API, события, оркестрация, надежность, наблюдаемость. Он делает так, чтобы ваши системы работали как единый поток, а не как зоопарк с пересылкой Excel по почте. Из этой роли вырастает enterprise/integration architect – архитектура ландшафта, а не «прикрутить кнопку».

Разработка ИТ-слоя процесса: в штате или на стороне?
Моё мнение простое – прямо по Хлебникову: архитектура должна быть своей, исполнение может быть смешанным (зависит от контекста).

Если ИТ-слой процесса – критичен (а он критичен, когда от него зависит P&L напрямую), то внутри должен быть человек, который определяет события, контракты данных, «источники истины» и правила оркестрации, а разработку адаптеров/коннекторов можно отдавать наружу, но строго по вашим контрактам и под его контролем.

Если вы отдаете наружу архитектуру, смыслы и интеграции – вы не аутсорсите, вы отдаете управление своей скоростью.

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

#автоматизация #производительностьтруда

Что такое «ИТ-слой процесса» и как он «женит» разные системы

ИТ-слой процесса – это не «ещё одна программа». Это прослойка, которая заставляет несколько разных систем работать как один процесс: одинаково понимать статус задачи, данные, правила и события.

Если по-простому: CRM, ERP, ТОиР, склад, документооборот – это «органы». А ИТ-слой процесса – это нервная система: кто кому что сказал, когда, по какому правилу, и как это отразилось на статусе работы. И в большинстве случаев сейчас это люди.

Чтобы «поженить» разное ПО на этом уровне, нужны 4 вещи:

1. Единая модель событий процесса
Например: «сделка создана», «договор подписан», «вагон назначен», «ремонт начат/окончен», «счёт выставлен/оплачен».
Смысл: системы разные, но события процесса общие.

2. Контракты данных
Не «перекинем файлик», а стабильные структуры: идентификаторы, справочники, статусы, атрибуты.
Смысл: чтобы не было 5-ти разных «клиентов» и 7-и разных «статусов» в каждой системе.

3. Оркестрация
Это ответ, кто где главный. Например, где-то главный CRM (продажи), где-то ERP (учёт), где-то ТОиР-SaaS.
Смысл: у каждого шага есть «источник истины», иначе начинается бардак синхронизации.

4. Интеграция через API/шины/очереди событий
Для тех, кто не из IT: вы (человек) взаимодействуете с тем или иным ПО через его интерфейс. Программы так могут, но это им не удобно. Для них существует другой тип взаимодействия – интерфейсы «программа-программа». Технически это делается через API или брокер сообщений (шину).
Смысл: процесс не должен падать, если одна система «чихнула».

Итог: ИТ-слой процесса – это правила + события + контракты + оркестрация, которые превращают зоопарк систем в единый поток с измеримым SLA и статусами.

Пара нетривиальных выводов:
1. Если вы покупаете ПО без официальных документированных интеграционных интерфейсов (API/Events/Connectors), вы покупаете технологический долг – устаревший продукт, который трудно встроить в современную архитектуру без «шаманства и плясок с бубном» (читай – много денег).

2. Если вы IT-компания и ваш продукт нельзя встроить в внешнюю оркестрацию и событийный контур, то он не соответствует текущей «гигиене» рынка, а ваше отставание – примерно 3-5 лет от текущей потребности, вне зависимости от длины списка фич.

На чем строить «ИТ-слой процесса»
Это обычно 4 класса продуктов:

• iPaaS (Integration Platform as a Service) – чтобы быстро соединять приложения и данные, управлять интеграциями и API. Это «трубы» и трансформаторы данных. Бери, если есть задача «поженить» более 3-4 систем. Пример.

• Process Orchestration / BPM – чтобы управлять именно процессом, людьми, решениями, сервисами и API как одним потоком. Это «диспетчер процесса» и его «карта прохождения». Бери, если нужен управляемый процесс «от начала до конца» с этапами, правилами, ролями, SLA, эскалациями и видимостью статусов. Пример.

• Workflow orchestration – если хочешь надёжную оркестрацию длинных бизнес-транзакций. Это «движки гарантированного исполнения», реализуемые, как правило, в коде (увы). Бери, если процессы длинные, с ожиданиями и повторами, и важна надёжность исполнения без ручного «дожима». Пример.

• Плюс часто рядом живёт Event Streaming / Kafka-платформа – когда интеграции строятся на событиях («договор подписан», «инвойс оплачен» и т.п.) и нужна шина и коннекторы. Это «нервная система» – события летят всем, кто должен реагировать. Добавляй, если нужен событийный контур: много подписчиков, реактивность, масштаб, слабая связанность и журнал событий. Пример.

Можно ли объединить что-то с чем-то из этого списка? Да, можно – такие системы сейчас начинают выходить на рынок. Это отдельная тема, и к ней мы еще обязательно вернемся. Особенно в контексте ИИ.

Итого: «ИТ-слой процесса» на практике – это комбинация интеграций (iPaaS/API), оркестрации (BPM/Workflow) и иногда событийная шина. И если ваш ИТ-директор на это скажет, что «для такой схемы нам нужно много людей и денег», то не пора ли опять вернутся к теме аутсорсинга или просто расстаться со старыми калошами? Ведь чувак не в теме 😉

Хороший вам выходных!

#автоматизация #производительностьтруда

Автоматизация: а почему не КИС?
Сразу расставим все точки над i

Пора идти дальше. И мы переходим к теме автоматизации, как одному из способов повышения производительности труда. И сейчас речь пойдет о корпоративных информационных системах – КИС.

Раньше была простая мечта: поставим большую КИС, накроем ею все процессы, и компания станет работать, как швейцарские часы.

В 90-х это ещё выглядело как истина. В нулевых – еще более-менее логичная идея. А вот сегодня это звучит просто как бред. И дело даже не в самих КИС, а в том, что мир изменяется быстрее, чем монолитные системы умеют меняться.

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

Современный же бизнес живёт иначе: меняются каналы, ценообразование, продуктовые пакеты, требования клиентов, партнёры, логистика и законодательство. Если изменение бизнеса происходит раз в месяц, а изменение системы – раз в квартал, система становится тормозом, а не «платформой».

Во-вторых, «покрыть всё» означает «заморозить всё»
Когда ты пытаешься описать весь бизнес «правильно» и навсегда, ты неизбежно усложняешь модель, плодишь согласования, делаешь исключения отдельными проектами. И вместо ускорения получаешь рост WIP, очереди и вечный режим «мы на внедрении». То есть бизнес обслуживает систему, а не система – бизнес.

В-третьих, бизнес-модель
Любая КИС – это не «нейтральный софт». Это упакованная бизнес-модель, просто спрятанная в справочниках, ролях, проводках, статусах, документах и «правильных» сценариях. Вендор не продаёт вам пустой конструктор. Он продаёт то, как устроены продажи, как устроены закупки, что считается «заказом», «отгрузкой», «счётом», «закрытием», какие бывают роли и полномочия, какая логика контроля и рисков «правильная».

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

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

1. вы ломаете бизнес под систему – теряете скорость и особенности,
2. вы ломаете систему под бизнес – теряете деньги, сроки и нервы,
3. вы строите над системой «вторую систему» из костылей и интеграций и потом живёте в ней. Но цена такой кастомизации – просто запредельная.

В-четвертых, монолит не переваривает разнообразие
Современный ландшафт – это не один огромный комбайн, а связка:
• CRM, биллинг, документооборот, поддержка,
• финтех и партнёрские сервисы,
• витрины, маркетплейсы, интеграции,
• и всё это через API.

И я еще ни слова не сказал про ИИ! Добавьте его сюда и становится очевидно: «накрыть всё одним» означает просто бороться с реальностью.

Что работает вместо «накрыть всё»
Не «анти-ERP», а более взрослая модель:
• «узкая» ERP является ядром управленческого учёта (важно: не бухгалтерского, а именно управленческого учета) – деньги, склад, активы, проводки, нормативка.
• Поверх – слой процессов и интеграций, который можно менять быстро.
• Вход/выход/SLA/WIP – в правилах, а не в головах.
• Автоматизация начинается с типового, а исключения уходят в эскалации.
• ИИ подключается как усилитель типового труда, а не как «мозг компании».

Мечта «покрыть всё одной КИС» умерла потому, что бизнес стал жить в режиме постоянной адаптации 7/24/365. Сегодня выигрывают не те, у кого «всё в SAP», а те, у кого скорость изменения процесса выше скорости изменения рынка – и автоматизация как система помогает этой скорости.

Конечно, из всего этого не следует, что «SAP всё». Думаю, подобные системы еще вашим детям будут «пить кровь». Если, конечно, вы их не воспитаете правильно…

😊

#производительностьтруда #автоматизация

Одной матрицы мало

Скажу прямо: многие проваливают аутсорс не потому, что «подрядчики плохие» или их нет, а потому что выбирают неправильную игру. Есть еще 5 факторов, которые убивают аутсорсинг в реальности.

Фактор 1. Нужна конкуренция
Если ваш «аутсорсер» – монополист, вы не покупаете услугу. Вы покупаете зависимость. Монополист всегда будет медленный и дорогой.

На прошлой неделе я рассказывал, как создавать искусственную конкуренцию там, где ее нет.

Фактор 2. «Оверфлоу компетенций» внутри – не аргумент против аутсорса
«У нас юрист дерёт зад всем» – это не причина держать отдел. Это сигнал: либо компетенция стратегически важна и её надо защищать/развивать, либо вы просто гордитесь человеком, который случайно оказался сильнее рынка в типовой ситуации. Матрица Хлебникова как раз про это: сила внутри не всегда означает «держим внутри».

Фактор 3. Перераспределение накладных
Как только вы выводите функцию наружу, ваши накладные расходы не исчезают магически. Они перераспределяются. И внезапно может выясниться, что «внутренние результаты» стали дороже, потому что постоянные накладные легли на меньшее число людей/процессов.

Если накладные высокие – считать надо внимательно, иначе вы «сэкономите» на функции и проиграете в себестоимости продукта.

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

Фактор 5. Нельзя становиться «якорным клиентом» подрядчика
Если ваши заказы составляют значимую долю объёма подрядчика (порог – порядка 35-40%), вы по факту начинаете оплачивать ему постоянные издержки почти как внутренний отдел, только без контроля. В этот момент аутсорс превращается в «ваш отдел, который сидит не у вас».

Как сравнивать «свои vs чужие» по цене честно

Тут люди чаще всего врут себе дважды:
(а) «чужие дорогие, потому что в счёте большая сумма»,
(б) «свои дешёвые, потому что зарплата маленькая».

Но честная, да и правильная схема, такая:

Шаг 1. Чужих считаем по цене без НДС. НДС – вредный налог по многим причинам – прежде всего он не позволяет экономике развиваться быстро, но это отдельная тема. В рамках решаемой задачи нам важно другое – для сравнения «свой/чужой» берём чистую стоимость услуги без НДС.

Шаг 2. Своих считаем по полной стоимости владения (TCO).
Это не просто «зарплата», а:

• зарплата + все налоги и отчисления на рабочую силу,
• плюс доля накладных (управление/админка – по численности; офис/тепло/свет – по площади; IT-инфраструктура – по потреблению/учёткам; и т.п.),
• плюс стоимость управления (время руководителя и согласования – это тоже деньги),
• плюс стоимость капитала,
• плюс ваша внутренняя «норма прибыли» (да-да: внутренний сервис должен жить как бизнес, иначе он всегда будет «удобным» и медленным).

По сути, это небольшой ABC/ABS-подход: распределяем накладные по понятной базе, без фанатизма, но честно.

Шаг 3. Не забываем про главный экономический смысл.
Даже если «свои дешевле» по расчёту, свои – это постоянные затраты, а чужие – чаще переменные. Переменные расходы покупают вам гибкость: когда спрос падает, вы не продолжаете кормить хвост «потому что люди в штате».

Но всё это только в контексте конкретного SLA, одинакового, как для своих, так и чужих.

Вывод на сегодня: аутсорсинг – это не про «отдать наружу и забыть». Это про то, чтобы купить рыночную конкуренцию, скорость и управляемый сервис, опираясь на контракт (вход/выход/SLA/WIP/эскалация), который вы уже научились формулировать.

#производительностьтруда #аутсорсинг

Вопрос подписчика: «Как выстроить отношения с аутсорсом, если поставщиков мало и обсуждать требования почти невозможно? Аутсорс работает по принципу “не нравится – не покупай”.»

Во-первых, нужно признать реальность: это рынок поставщика (по Портеру), со всеми вытекающими. Это не партнёрство, это зависимость. А зависимость в бизнесе лечится только одним способом – её нужно устранять.

Исключая незаконные и этически неприемлемые меры, у вас остаётся всего несколько нормальных путей (пойдём от простого к более элегантному). Суть одна: Карфаген монополия должна быть разрушена.

Скажу сразу: мы с Хлебом (Д. Хлебниковым) на этом поле оттоптались не по-детски. Всё ниже – не «советы из книжек», а опыт, добытый через ошибки и деньги.

1. Расширить географию поиска
Цель: найти альтернативу монополисту.
Суть: искать нужно не «за забором предприятия», а шире. Мир большой, и почти всегда можно найти тех, кто готов прийти в вашу локацию при нормальном контракте и объёме.

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

Другими словами,
• «местные незаменимые» заменяются «неместными, но быстрыми»,
• а разница в производительности перекрывает разницу в цене.

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

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

2. Дробление работ
Цель: завести на рынок больше поставщиков.
Суть: монополии часто держатся не потому, что они лучшие, а потому что объём работ неделим или «так исторически сложилось». Если есть возможность – делите!

Что делаем:
• дробим «одну большую услугу» на несколько меньших работ по специализации или по объёму;
• для каждой работы фиксируем не процесс, а ваш требуемый результат: вход, выход, критерии приёмки, дефекты, сроки, правила эскалации.

И после этого на рынок заходят мелкие игроки, которым «целый комбинат» не по зубам, а «кусок работ» – вполне.

Если мелким не хватает оборудования, а оно у вас есть – сдавайте в аренду. Иногда даже с правом выкупа (это уже шаг к следующему уровню).

Критическое временно забираем внутрь. Да, иногда придётся. Но цель не «вечно держать внутри», а выиграть время и разрушить зависимость. Переманивание персонала монополиста – приемлемая мера.

Риск: потребуется нормальная «служба заказчика» (планирование, контроль, эскалации).
Но это не минус – это признак зрелости.

3. Создать нового игрока (свой бизнес как анти-монополия)
Цель: та же – создать альтернативу и рыночную силу, а может быть и выйти на новый рынок.
Суть: вы уже сделали шаг 2: дробление, SLA, служба заказчика.

Дальше варианты:
• M&A: купить пару мелких игроков и собрать компетенцию.
• Создать ДЗО: нанять персонал и построить поставщика с нуля.
• Выделить внутреннее подразделение в ДЗО, если оно уже есть.

Ключевые правила, чтобы это работало:
• вы даёте стартовый объём работ;
• каждый год доля работ «на сторону» должна расти (лучше всего – за счёт клиентов нынешнего монополиста, но сойдут любые);
• даёте опцион на выкуп компании менеджментом/коллективом через 3 года.

Почему это работает:
• с вашим SLA у нового игрока хорошие рыночные шансы;
• возможность стать собственником стимулирует лучше любого KPI;
• при правильной реализации за 2–3 года можно снизить совокупные затраты примерно на 15–20% при заданном качестве и точно перестать быть заложником.

Совет: начинать с пилота небольшого масштаба – иначе увязнете в «великом строительстве».

Риски:
• нужно держать стратегический фокус;
• относиться к своему ДЗО как к бизнесу: не выкручивать руки «админресурсом», не заставлять работать ниже рынка.

Иначе вы потеряете людей и качество.

Собственно, всё!
Хороших выходных!

#аутсорсинг

Аутсорсинг без идиотизма

Аутсорсинг – это не «найм чужих людей вместо своих». Это архитектурное решение: что должно остаться внутри, а что выгоднее покупать как сервис. Делать это «на глазок» – значит гарантированно купить себе новую очередь и новую зависимость, только уже снаружи.

Начинаем не с цены, а со смысла. Первое правило: выносить наружу нужно не «что раздражает», а то, что не является стратегически важным и при этом стандартизируется. Основа – логика матрицы Дмитрия Хлебникова: стратегическая важность vs уровень компетенций.

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

Стратегическая важность функции – это оценка того, насколько она влияет на конкурентное преимущество и выживаемость бизнеса, а не насколько она «всем нужна». Оценивать это можно быстро, без занудства – функция стратегически важна, если проходит хотя бы два из четырех тестов ниже:

2. Тест клиента (мягкий тест): клиент выбирает компанию из-за этого (скорость, качество, сервис, уникальные условия), и конкуренты не могут быстро повторить.
Смысл: если это легко копируется рынком – это не стратегия, это операционка.

1. Тест денег: если сегодня сократить расходы на функцию на 20%, то выручка/маржа упадет в минус в течение недели.
Смысл: стратегическое всегда чувствуется в P&L.

3. Тест риска: ошибка в функции создаёт экзистенциальный риск (вероятные потери выше размера собственного капитала).
Смысл: тут важно не «страшно», и не «может быть», а точно убьёт бизнес. Измеримо, просто, легко запомнить. Но ошибка должна быть реальная, а не изворотливо высосанная из пальца, типа «а что если...», за которым следует цепочка из 100500 маловероятных событий. То есть, «а что если мы проиграем в суде 100 миллиардов долларов» – не подходит – вы сначала заработайте столько!

4. Тест метеорита (hardcore-тест): если эту функцию забрать в одно мгновение, бизнес не может работать 1–2 недели даже при наличии неограниченного количества денег на подрядчиков.

Как понимаете, тест метеорита – мой самый любимый. Он очень честно донесёт вам простую истину: «незаменимых нет» не работает только в стратегически важных областях, которые и есть суть вашего бизнеса. А для всего остального есть MasterCard аутсорсинг.

И короткое заключение:
• стратегическое – то, что даёт преимущество или держит бизнес живым.
• не стратегическое – всё, что важно, но одинаково у всех и покупается на рынке.
• «хвосты» чаще всего растут из стратегически не важных областей.

О дополнительных критериях поговорим на следующей неделе. А завтра разберем интересный вопрос от подписчика.

#производительностьтруда #аутсорсинг

Свой или чужой

Мы уже поговорили про WIP-лимиты, типизацию, шаблоны, эскалацию и уведомления вместо согласований. Если вы это реально запустили хотя бы на одном процессе – поздравляю: вы сделали то, чего не умеет половина «серьёзных компаний». Вы превратили «работу отдела» в сервис с понятным контрактом. А раз так – дальше начинается самое интересное.

1. Покупать результат вместо «людей»
Надеюсь, что вы уже хоть где-то смогли перейти от «юристы тормозят», «бухгалтерия не успевает», «ИТ опять в домике» к простой инженерной конструкции:
• корректный вход (чек-лист; «без этого не принимаем»),
• корректный выход (что значит «готово»),
• SLA (правило очереди: сколько времени при нормальном входе),
• WIP (предохранитель от «впихнуть невпихуемое»),
• эскалация (лимиты ответственности и риска).

Это и есть «контракт сервиса». И теперь можно говорить не «кто виноват», а «что требовать».

2. Теперь подразделения можно мерить
Потому что у вас появляются нормальные вопросы, которые можно задавать и своим, и чужим:
• «Сколько задач вы реально выпускаете за неделю при корректном входе?»
• «Какое среднее время цикла?»
• «Какой SLA вы гарантируете?»
• «Какой процент возвратов по входу?»
• «Где у вас забивается WIP и что вы делаете при перегрузке?»

Это уже не придирки и не «давайте уважать коллег». Это управление потоком.

3. «Свой/чужой»
Теперь нет разницы, кто делает работу, потому что если она описана через вход/выход/SLA/WIP/эскалацию, то безразлично, кто выполняет операции – внутренний отдел, сервисная компания, фрилансер, автоматизация, ИИ-агент. И все они становятся просто исполнителями одного и того же контракта. Требования одинаковые, оправдания разные, но нам они не интересны.

4. «Свой» отдел – это тоже подрядчик.
Если ваш внутренний сервис не принимает на себя SLA, не уважает входной чек-лист, не выдаёт результат по DoD, обходит WIP («ну мы же взяли ещё чуть-чуть»), то это не «свой». Это внутренний монополист, который живёт в логике «как получится». А монополии почти никогда не быстрые. Они комфортные.

5. Аутсорсинг – это не «сократить», это – «купить скорость»
Правильный смысл аутсорса:
• убрать очереди,
• стабилизировать выпуск результата,
• разгрузить узкое место,
• и удерживать ритм потока «заявка → деньги»,
• распределить риски между несколькими подрядчиками.

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

6. Мини-тест: готовы ли вы к аутсорсу (10 минут)
Возьмите одну функцию, которая у вас в категории «всё своё» (юристы, бухгалтерия, IT, кадры – что болит) и ответьте:
1. Можете ли вы на одной странице описать вход и выход этой работы?
2. Можете ли вы сказать, какой SLA нужен бизнесу (не «как удобно отделу»)?
3. Можете ли вы назвать метрику потока (время цикла / % старых задач)?
4. Есть ли понятное правило эскалации (когда и кто принимает риск)?

Если «да» хотя бы на 3 пункта, то вы готовы! Если «нет» – вы пока не готовы к аутсорсу, вы готовы только к «передаче хаоса наружу» и готовы платить за нерасторопность и комфорт. Тоже выбор! Главное делать его осмысленно!

Итог. WIP, шаблоны и эскалация – это не «про бюрократию». Это про то, чтобы работа стала контрактом, а не «ручным искусством». И как только работа стала контрактом – вам уже всё равно, кто её выполняет: свой отдел или внешний. Важно одно: выпуск результата в срок и без переделок.

Следующий пост будет про аутсорсинг – матрицу Дмитрия Хлебникова и мои собственные критерии, как и что выносить наружу, как выбирать подрядчика. И немного про подводные камни.

#производительностьтруда

С праздником, наши дорогие и любимые женщины!

Будьте любимы и счастливы, освещайте нашу планету как долгожданное вешнее солнце🌷🌷🌷

Типизация, шаблоны и эскалация

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

Но если нужна скорость, нужен другой принцип: Типовое – делаем быстро и молча. Нетиповое – эскалируем. Всё! Остальное – детали реализации.

1. Полномочия надо делить
Линейный сотрудник должен иметь право принимать решения в пределах лимита. Например, сейл имеет право продавать до X евро / давать скидку до Y% / обещать срок до Z дней. Всё, что выше – не «запрещено», а эскалируется.

Ключевой эффект: вы превращаете 70% действий из «ждём решения» в «делаем сразу».

2. Руководитель – это не тот кто водит руками
Руководитель линейного подразделения – это тот же сейл/инженер/оператор, только с большим лимитом на цену/скидку/срок/исключения – правом принимать большие риски и нести за них личную ответственность.

Распределение работ – это важная функция, но вторичная. Главная – принимать исключения и риски, чтобы поток не вставал.

3. Эскалация
Эскалация должна быть описана как система лимитов рисков и ответственности:
• цена, скидка, отсрочка платежа;
• сроки, гарантия, штрафы;
• объём работ/бюджет;
• периодичность, исключения, особые условия.

Чем выше роль, тем выше полномочия – тем выше личная ответственность. Не «коллективно решили», а кто разрешил, на основании чего, какой риск принял.

4. Сценарии и процессы пишутся только для типового
Одна из причин бюрократии: люди пытаются описать процесс так, будто жизнь – это блок-схема на 400 развилок. Нормальная инженерная логика иная:

• типовое действие – есть сценарий/инструкция/шаблон;
• отклонение – не «ветка в BPMN», а «поднимаем на уровень выше по лимитам» – эскалация.

Так вы держите модели простыми, а систему – быстрой.

5. Высшее образование – это не почетное звание
В офисе полно людей, которые умеют читать, писать и иногда думать. Значит, например, сейл может выписать приходный документ по шаблону, завести инвойс в систему, инженер – заполнить акт/отчёт по форме, менеджер – может оформить закупку по чек-листу.

Бухгалтерия, юристы и иные не должны быть «ручками», которые набирают текст. Они должны быть:
• владельцами правил,
• аудиторами качества,
• теми, кто подключается по эскалации.

Иначе любой внутренний сервис создаёт очередь.

6. Вместо согласований – уведомления
Согласование типового шага – это самоубийство. Если шаг типовой и в лимитах, то уведомил и сделал, а руководитель не «разрешил», а получает сигнал для контроля.

Согласование нужно только на исключения, потому что исключение = риск.

7. Типовое должно быть действительно типовым
Чтобы типизация не стала фарсом, нужны две вещи:

• Библиотека шаблонов. Договор, инвойс, КП – всё в шаблоны. И запрещено плодить «чуть-чуть другой файл». Любое «чуть-чуть» – это либо новый тип (официально), либо эскалация.

• Чек-лист завершения на каждую типовую операцию. Не «почти готово», а «готово», то есть, когда выполнены все пункты чек-листа.

Пример для продажи:
• запись в CRM создана/обновлена,
• инвойс заведён,
• документ отправлен клиенту,
• следующий шаг запланирован (follow-up).

Нет пункта – нет «готово» – нет зарплаты! Именно так: нет записи в системе + нет обязательных артефактов – нет начисления зарплаты.

Да, это сурово! Но это единственный способ вылечить «я всё сделал, просто не записал». В бизнесе «не записал» равносильно «не существует».

8. Как это не превратить в новый ритуал
Для каждого процесса (продажа, закупка, договор, счёт) достаточно трёх таблиц:

• Таблица лимитов (кто что может): должность; лимит; что делать при превышении (эскалация).
• Список типовых операций (10–20): операция; шаблон; чек-лист завершения.
• Правила уведомлений: кого, как и в каком случае уведомляем.

И всё! Никаких регламентов на 80 страниц.

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

#производительностьтруда

Что делать, когда «всё встало»?
или инструкция для руководителя подразделения по разгребанию завалов

Когда WIP-лимит забит и Ready-лимит на походе, а работа не движется, не надо кричать «быстрее!». Нужно включить логику. Вот пошаговая «лесенка» решений для руководителя.

Шаг 1. Найдите «самое легкое»
Не хватайтесь за новые задачи. Посмотрите в колонку In Progress. Что из этого можно закрыть прямо сегодня?
Цель: дожать задачи до статуса Done, двигаясь от простого к сложному. Как только одна задача выйдет – освободится слот для новой.

Шаг 2. Расчистите завалы – убейте блокеры
Часто работа стоит, потому что мы «ждем ответа», «не подписали» или «нет доступа».

Типовые блокеры:
• зависло на согласовании;
• ждём правку/ответ,
• не подписали/не подтвердили,
• нет данных от инициатора,
• нет доступа,

Что делать: вместо новой задачи потратьте час на пинки звонки и письма тем, кто вас тормозит. Поставьте жесткий дедлайн (например, до 16:00). Если не помогло – эскалируйте наверх. Одно закрытое «зависшее» дело ценнее трех начатых.

Шаг 3. Делайте «Обмен»
Если на вас давят, заставляя взять новую задачу – держите удар. Ну а если у них «прямо горит» то:

1. Выберите самую несрочную задачу из тех, что в работе.
2. С почестями верните её обратно в Ready (в очередь).
3. На освободившееся место берите срочную.
Это честный приоритет, а не раздувание хаоса.

Кто решает, что попадёт в Ready? Руководитель! Когда вход лавинообразный, спасает не «планирование на квартал», а короткая регулярная сортировка.

Формат: 10–15 минут один-два раза в день, на каждую новую задачу ровно одно решение: в Ready (делаем) /в Backlog (позже) / закрыть (не делаем). Если нет опции «не делаем», вы всё равно утоните, просто культурнее.

Что делать если это не помогло разгрузить очереди?
Давайте быстро проверим:

Ready пухнет, а работа не идет?
Гипотеза: узкое место не там, где вы думали. Скорее всего, у вас не хватает мощности в другом месте. Что делать: вернитесь к схеме процесса и сделайте повторный анализ.

Слишком часто всё «срочно»?
Гипотеза: значит, у вас либо плохой входной контроль – берут всякий мусор, либо вы хронически не справляетесь с потоком.
Что делать: проверяйте справедливость гипотезы! Если проблема в мощности – подключайте подрядчиков, ищите способы автоматизации.

Вывод для босса: WIP-лимит – это не про «нельзя работать». Это про выбор: что мы заканчиваем, а что вообще перестаем принимать, чтобы не захлебнуться.

И еще… Ваша главная проблема не в том, что люди работают медленно, а в том, что работа слишком много «отдыхает». Если вы посмотрите на путь любой задачи, то увидите, что 80% времени она просто лежит и ждёт: подписи, ответа, данных или когда у исполнителя дойдут руки. Когда вы бросаетесь «делать новое», вместо того чтобы «разбивать блокеры» в старом, вы увеличиваете время этого простоя.

Производительность – это не когда все бегают в мыле – это называется хаос, а когда у вас в системе есть «пустое место» – запас мощности. Только имея его и свободные слоты, вы можете мгновенно реагировать на кризисы.

#производительностьтруда

WIP-лимит: что делать, когда он забит

Давайте разберемся, почему «впихнуть невпихуемое» убивает ваш бизнес.

Прежде всего, нужно понять (при невозможности – поверить), что если WIP-лимит начал мешать «назначить задачу» – это не баг. Это – момент истины – система стала прозрачной и впервые честно сказала «я перегружена».
Дальше два пути: либо обходим лимит и возвращаемся в болото, либо используем лимит как инструмент управления скоростью.

Вот три правила, как выжить, когда работы больше, чем рук:

1. Закон обмена: Срочное не «добавляется», а «меняется».
Если ваш лимит (WIP) заполнен, нельзя просто закинуть сверху «очень важную задачу».

Логика: втащил в очередь одну новую задачу – выкинь одну текущую обратно в очередь.
Зачем: чтобы общее количество незавершенки не росло. Иначе «срочное» станет дыркой в заборе, через которую в работу пролезает всякий хлам, и работа встанет колом.

2. География задач: не путать склад с верстаком.
Чтобы WIP-лимит не был враньем, наведите порядок на доске:
• Backlog – склад хотелок. Задач там может быть сколько угодно.
• Ready (входная очередь) – задачи готовы к старту - вход корректный, но ещё не в работе.
• In Progress – реальная работа – только WIP – здесь живет лимит.

Важно: Задача считается «назначенной», только когда она попала в In Progress. Всё остальное – просто список дел, а не нагрузка на реального человека.

3. Лимит на «Очередь».
Если колонка Ready бесконечна – это катастрофа. Вы всем пообещали, всё приняли, но никто не знает, когда это сделают. Клиенты нервничают и начинают «пинать» сотрудников.

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

WIP-лимит – это на самом деле инструмент борьбы с вашим страхом, а не с нагрузкой. Менеджеры часто «раздают задачи», чтобы просто успокоить себя: «Ну, работа же движется, все при деле». Это психологическая соска.

Главное: когда вы запихиваете в систему больше, чем она может переварить, вы не ускоряете работу – вы просто платите скоростью за своё временное спокойствие. Настоящее управление начинается там, где вы находите в себе смелость оставить сотрудника «праздным» на час, пока не освободится слот, вместо того чтобы нагрузить его бессмысленной текучкой, которая похоронит под собой реально важный проект.

#производительностьтруда

Что сделать прямо сейчас

Сейчас будет не «про подходы», а про конкретное действие. Если вы прочитали предыдущие посты и ничего не сделали – это нормально: мозг любит знания, а бизнес любит результат. Давайте дадим бизнесу результат. Прямо сейчас!

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

Шаг 0. Выбери один поток
Не «в целом работу отдела», а один поток «от запроса до результата».

Примеры:
• лид > КП >договор > деньги
• договор > визы > подпись
• счёт/акт > оплата > закрытие
• заявка клиента > решение > ответ

Лучше то, где сейчас больше всего «ждём».

Шаг 1. Процесс на салфетке
Просто цепочка действий, 7–12 шагов. На каждом шаге подпиши:

• кто делает,
• что получается на выходе
• артефакт: письмо, документ, запись в CRM, отгрузка, решение.

Это нужно не ради схемы. И да, методологически это выглядит стрёмно. Но это нужно, чтобы перестать спорить «кто виноват» и увидеть «где стоит».

Шаг 2. Входной чек-лист: «без этого не начинаем»
5–10 пунктов.

Пример логики:
• данные клиента/контакты,
• предмет запроса,
• сумма/сроки,
• файлы/приложения,
• кто инициатор и кто принимает результат.

Если чего-то нет – задача возвращается инициатору. Не «пожалуйста уточните», а «п.3 отсутствует – вернул».

Это момент, где обычно люди боятся «обидеть коллег». Не бойтесь. Пусть обидится и начнёт приносить нормальный вход.

Шаг 3. Определяем «готово»
Без «почти». Только проверяемое «готово».

Пример для сделки:
• есть запись в CRM,
• есть инвойс/КП в системе,
• отправлено клиенту + поставлен следующий шаг (follow-up).

Если не выполнены пункты – задача не закрыта. Точка.

Шаг 4. SLA без ритуалов
Берем шаблон выше и заполняем. Работаем не как Лев Толстой над «Война и мир», а как упоротый зумер – кратко, лаконично, в меру лениво, до 18:00.

Шаг 5. Один WIP-лимит в одном месте
Выбери одну точку, где «всё стоит чаще всего» (роль/должность/подразделение/процесс) и поставь лимит: в работе одновременно не больше K задач. «K» ставь не более 3-х для роли или должности, 6-ти – для подразделения или процесса.

Важно: лимит ставится на «в работе», а не на «в очереди». Очередь будет жить отдельно.

Что делать «когда лимит забит?». Пока просто поставь лимит и начни его соблюдать. Разбор «что делать, когда WIP забит» будет отдельным постом.

Шаг 6. Заведи электронную канбан-доску.

Самую простую, ту, что легче «поднять», желательно бесплатно.

Минимум колонок: Backlog; Ready; In Progress; Review/Approve; Done

Минимум правил:
• назначение исполнителя – только при входе в In Progress;
• в In Progress нельзя, если WIP достигнут;
• Done – только если выполнен DoD (шаг 3).

Это превращает «поработай» в «сделай задачу» и показывает очереди без истерик.

Шаг 7. Одна метрика
Выбери одну метрику и снимай её раз в неделю: среднее время цикла (сколько обычно проходит от старта до «готово»). Если хочешь вторую – бери «% задач старше X часов/дней». Но не более, пока этого точно хватит.

Что должно получиться через неделю
Если всё сделано честно, будет три эффекта:
1. меньше возвратов и переделок,
2. очередь станет видимой (за счёт доски и WIP),
3. появится факт «где горлышко» (а не мнение).

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

#производительностьтруда

Эффективность, которая ломает систему?

Мы слишком долго путали «все заняты» с «дело движется». Когда так называемая «оптимизация» превращает компанию в двигатель, разогнанный до красной зоны, яд прячется в незавершёнке – WIP – и именно она тихо убивает производительность. Давайте разберемся в механике прежде, чем двинемся дальше. И возможно из того, что изложено ниже вы не узнаете ничего нового для себя, но я точно уверен, что теперь вы будете правильно реагировать на любые предложения повысить эффективность.


Почему «эффективность» стала ядом

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

А на практике происходило другое. Когда система работает на пределе загрузки, растёт объём незавершённой работы – WIP, Work In Progress. Когда растёт WIP, люди начинают переключаться между задачами. Переключение – это потери: на вход в контекст, на ошибки, на согласования. Ошибки порождают переработки. Переработки удлиняют цикл. Длинный цикл снижает пропускную способность всей системы. Всё это происходит незаметно и медленно.

В итоге компания работает напряжённо, все заняты, все устали – а производительность падает. А вместе с падением производительности деградирует экономика. И вот компания подходит к очередному кругу очередному порогу «оптимизации». И что начинает делать? Искать резервы, конечно!

Это не парадокс – это механика. И понять её можно без формул.


Механика: WIP как главный рычаг

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

Аутсорсинг, как инструмент оптимизации, работает ровно по той же логике: он разгружает узкое место. Но если WIP не управляется – аутсорсинг просто переносит хаос за периметр компании и делает его дороже и непрозрачнее.

Вывод: нужно учиться видеть WIP в своём процессе и задать себе вопрос – сколько задач сейчас «в работе», но ни одна не завершена?

Дальше будем отталкиваться от того, что вы «видите WIP»

#производительностьтруда

Приложение: шаблон, который можно просто заполнить

Я вынес в отдельный файл шаблон «Ускорить систему, никого не выгоняя».

Заполняешь его на один процесс, и у тебя появляется:
• ясный вход/выход,
• SLA без воды,
• WIP-лимит,
• канбан-правила,
• метрика потока.

Дальше продолжим пока «душить» – поговорим о шаблонах, типовых схемах и эскалации.

#производительностьтруда #SLA

Из переписки: «Ну, вот ты опять про «резать хвост по самые уши». Тебе хорошо – у тебя были и есть полномочия на это, а вот нам – рядовым аналитикам, такого не дадут. А требуют улучшить! Рассказал бы лучше народу, как сделать это «улучшить», никого не выгоняя»

Ну, что же… Это разумно! Ведь многие руководители предпочитают некоторую толику BDSM в управлении – помучить себя, своих подчиненных и особенно бизнес-аналитиков «медленным удушением» вместо «ампутации». Впрочем, чем только люди не занимаются на деньги акционеров...

Ок, давайте начнем с «мягкого» – как ускорить систему, никого не выгоняя. Кратко: убери ожидание и переделки, и будет тебе счастье!

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

Сначала коротко, как устроена магия – три рычага, которые реально ускоряют:

1. Уменьши согласования и очереди. Вы платите людям за ожидание, а не за «сделали».

2. Сделай стандарт «на одну страницу», а не ритуал. Стандарт нужен не для красоты, а чтобы не было переделок из-за «я думал иначе». Если документ не помогает выпускать результат быстрее – это не стандарт, это бюрократия.

3. Автоматизация и ИИ, но только после прояснения процесса. Если процесс «мутный», автоматизация делает его еще более «мутным» быстрее. Это называется «автоматизировать бардак» – эффект впечатляющий, но обычно в минус.

Про ИИ поговорим отдельно. Сейчас главная мысль: ускорять надо не людей, а поток. У любого процесса есть три аспекта:

1. что является корректным входом (без чего мы не стартуем);

2. что является готовым выходом (как понять, что сделано);

3. где живёт очередь (узкое место).

Если эти три элемента не определены – будет вечное «а я не так понял» и «подождём согласования».

Практика на 30–60 минут: «SLA без ритуалов»

Выбирай один поток, который реально кормит бизнес. Например, «лид → КП», «договор», «счёт/акт», «закупка», «обработка обращения клиента». В принципе, что угодно! Дальше делай эти четыре шага.

1. Сначала вход: «без этого работу не начинаем». Это убивает половину переделок. Если вход неполный – задача возвращается отправителю с указанием пункта чек-листа, а не «пожалуйста уточните».

2. Потом выход: «что считается готовым». Это убивает вторую половину переделок. Результат должен быть проверяемым: артефакт (например, документ или действие), критерии готовности, где лежит, кто принимает.

3. Потом правило очереди. SLA работает только при корректном входе. Иначе это не SLA, а обещание «мы постараемся». Нормальная формулировка:
«Если вход корректный – подтверждаем за N минут (часов), выпускаем за M часов (дней). Если вход некорректный – возвращаем за X минут с указанием пункта чек-листа».

4. И наконец WIP-лимит: ограничение незавершёнки. Это – самое мощное. Пока у роли/сервиса в работе 27 задач одновременно, срок будет расти бесконечно, а виноватых не будет.
Лимит «в работе не больше K задач» делает очередь видимой, и внезапно выясняется, где реальное горлышко.

Да, электронная канбан-доска обязательна! Какая? Любая, самая простая – это не ради красоты, а ради диагностики. За одно получите ответ на вопрос, кто чем занят. Можно вводить даже на уровне отделов – не обязательно на уровне работников. Она превращает «поработай» в «сделай конкретную задачу». Будут вопросы – зачем, почему, как, какую – задайте в комментариях!

Делайте и пробуйте внедрить. Только постарайтесь не утонуть в согласованиях.

#производительностьтруда

Меня часто спрашивают владельцы бизнеса, которые сами рулят компанией как реальное лицо, принимающее решения, «А не пора ли отойти в сторону и нанять наёмного руководителя?»

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

Признаки, что уже пора:

1. Рост компании ниже роста отрасли (или хотя бы ниже ВВП страны; для международных — ниже мирового ВВП). Это значит, что ты не выигрываешь рынок, ты просто «плывешь в потоке». Считать стоит в USD.

2. Производительность труда ниже средней по стране (или для международных — ниже ~50$/час на сотрудника). Если выработка слабая – внутри почти всегда либо хаос управления, либо неверная организация работы, либо и то и другое.

3. В команде видна «выученная беспомощность». Никто не принимает решений под свою ответственность, не спорит с тобой по делу, ждут твоего слова по каждому поводу.

4. Ты – главное «узкое горлышко». Без тебя не закрываются рядовые сделки, не двигаются проекты, решения стоят в очереди к твоей голове. У сотрудников второго эшелона война за «доступ к телу» – возможности изложить свою точку зрения и получить преференции.

5. Ты постоянно в операционке и тушишь пожары. Стратегия существует «где-то потом», а календарь забит текущими вопросами. Это не про занятость – это про отсутствие регулярного управления.

6. Компания держится на личных договорённостях и твоём ручном контроле. Ключевые люди завязаны на тебя, а не на роли/процессы/метрики. Стоит тебе выпасть – и начинается рассыпание.

7. Ты не можешь нормально исчезнуть на 2–3 недели без ежедневных вопросов «что делать» и «управленческих пинков». Это не героизм. Это диагноз управленческой незрелости.

8. Финансы «вроде есть», но ты не веришь цифрам и не можешь быстро объяснить прибыльность по направлениям или продуктам. Если управленческий учёт не даёт ясности, решения становятся эмоциональными – и ты неизбежно начинаешь ошибаться. И цена таких ошибок становится дороже раз от раза.

Важная оговорка: наёмный руководитель – не «замена собственника» – это способ перестать быть диспетчером и стать владельцем: задавать цели, правила игры, контролировать по метрикам и делать крупные ставки, а не решать, «какую кнопку нажать прямо сейчас».

Если ты перестал быть ускорителем и стал ограничителем – пора выходить из операционки и строить управление без тебя. А может даже стоит и выйти из бизнеса...

Если же эти признаки не про тебя – поздравляю, ты на своем месте!

Коротко прокомментирую опрос о производительности труда.

Картина интересная, конечно, и, если честно, она даже не столько про «масштаб бедствия», а про масштаб неготовности мерить: более 60% аудитории выбрали «хочу посмотреть ответы». Да, понимаю, чаще всего это обычная лень, что хотя тоже интересный сигнал. Либо это другое – люди избегают цифры, потому что цифры потом задают неприятные вопросы. Ладно, пусть так...

Если же по сути, то стоит прежде всего отметить, что для малого бизнеса 600$, 700$ и даже 1000 $/ч на человека – это не фантастика, а частый эффект «рычага». Маленькая команда, минимум внутренних сервисов, высокий чек, узкая специализация, аутсорс хвоста, и главное – много «продающих часов» (billable). В таких моделях один сильный специалист тащит выручку, а всё остальное – тонким слоем.

А вот среднюю и тем более крупную компанию с 125 $/ч на человека в среднем найти реально сложно. У крупных неизбежно растёт доля «непродающих часов»: согласования, внутренние отделы, простои, проектная инерция, управление, корпоративные ритуалы, и банально «люди сидят и ждут». В итоге выручка сильно «размазывается» по огромному количеству «непродуктивного» времени.

Почему «в середине» провал (50–100)? В малом и среднем бизнесе чаще встречаются две группы – либо «дешёвый труд + много ручного труда» (10–50), либо «дорогая экспертиза/продукт + мало людей» (100+). Между ними просто меньше устойчивых бизнес-моделей (в данной экономической среде). И без системных усилий выйти за порог 30-40$ на человека в час трудно.

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

Проблема магазина решена – мы сменил прописку.

Что изменилось? Процесс покупки стал быстрее, а доступ к файлам – стабильнее. Цены сохранены на прежнем уровне.

И как говорят наши китайские партнёры, не стесняйтесь ставить 5 звёзд 🙂

Сначала вердикт по последнему опросу: остаёмся здесь. А теперь...

Всё своё или главная причина низкой производительности

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

Когда ты заводишь и наращиваешь функцию «внутри», происходит три вещи:

— Появляется свой интерес сервиса/функции. Любой отдел начинает оптимизировать то, что проще всего оптимизировать: риски для себя, «чтобы нас не наказали», «как бы чего не вышло». Это рационально. Но бизнесу нужна скорость и полезный результат, а не идеальная безопасность.

— Появляются стандарты ради стандартов. Внутренний сервис начинает выращивать правила. Сначала разумные. Потом «на всякий случай». Потом «так принято». Потом «мы – великие». В итоге регламент становится ритуалом, который важнее любой сделки.

— Появляется очередь. Каждая сделка приносит задачи. Эти задачи поступают неравномерно. Но каждая задача требует соблюдения созданных ритуалов. Возникает очередь. А очередь всегда увеличивает цикл «заказ › получение денег».

Работая в больших компаниях, я всегда задавал один простой вопрос: кто принимает решение? Руководитель, предлагающий сделку или клерк, который советует своему патрону не визировать её? И может ли этот руководитель пойти наперекор визам, взяв ответственность на себя?

Очень неприятный факт: внутренние отделы часто живут по KPI типа: «не допустить ошибок», «соблюсти регламент», «закрыть заявки», «не пропустить риск». А нормальный бизнес должен жить по KPI типа «быстро продать», «быстро отгрузить», «быстро получить деньги», «сделать клиента довольным». И вот тут начинается конфликт мировоззрений.

Сейчас будет быстрый тест. Будем выявлять симптомы, что «своё» уже стало тормозом. Если есть хотя бы 2 пункта – вы платите за «своё» производительностью.

— время согласования и визирования равно или больше времени проведения и закрытия сделки. Это значит, что твой основной ресурс – пропускная способность согласующего «бутылочного горлышка».
— Работники перестали инициировать улучшения, потому что «всё равно не согласуют». Это уже системная демотивация, только выглядит как «невовлечённые сотрудники».
— Появилось правило «сначала поговори с N отделами, потом сделай». Это не контроль, это паралич.
— Отделы пишут регламенты, но не отвечают за итоговый срок для клиента. Срок растёт, виновных нет.

Что сделать прямо сейчас: упражнение на 20 минут

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

1. Это влияет на скорость «заявка — деньги» каждый день?
2. Это можно стандартизировать до уровня шаблонов/инструкций/правил принятия решений?
3. Мы закроем текущие сделки, если этих людей внезапно похитят инопланетяне?

В небольшой компании (если ваша производительность труда меньше 50$ на человека в час) можете выписать всех сотрудников.

Если на 2 из 3 ответ «да» – это хвост, его пора выносить наружу. Ок, не сегодня, да, нужно подумать. Но делать-то надо!

«Всё своё» часто кажется признаком зрелости. На практике для малых и средних компаний это часто признак того, что вы путаете управление с содержанием мини-государства. А для крупных компаний – расточительность и «пир» за счёт акционеров. Производительность труда растёт не когда «всё своё», а когда у тебя быстрый поток и ядро жёстко отделено от хвоста.

Дальше мы будем говорить о способах отрезать хвосты. И лучше – по самые уши. Без героизма, без «серых схем», с понятным минимальным контуром и KPI по скорости закрытия месяца.

#производительностьтруда