Когда «подстраховаться» становится бизнес-процессом
Есть процессы, которые прекрасно работают.
Пока конкретный человек на месте.
Он помнит, кому написать. Знает, кому лучше позвонить после письма. Понимает, какое слово в документе вызовет вопрос, а какое никто не заметит. Знает, что одному контрагенту надо напомнить утром, другому - после обеда, а третьему сначала написать в мессенджер, иначе письмо будет лежать до пятницы.
Формально всё это называется опытом.
Иногда - экспертизой.
А иногда я смотрю на такую конструкцию и думаю, что передо мной довольно дорогой вид ручной интеграции.
Особенно хорошо это видно в финансах, логистике и проектном бизнесе. На схеме процесс выглядит вполне прилично: заявка → согласование → оплата → поставка.
В жизни между стрелочками живёт человек.
Он проверил. Напомнил. Переспросил. Сопоставил две версии документа. Заметил, что сумма та же, а реквизиты уже другие. И на всякий случай позвонил ещё раз.
Самое коварное, что такая система может годами считаться работающей.
Ошибок мало, потому что человек их ловит. Сроки в основном соблюдаются, потому что он толкает процесс руками. Критических сбоев нет, потому что он заранее знает, где они обычно возникают.
И постепенно организация начинает путать надёжность процесса с надёжностью конкретного сотрудника.
Для CFO здесь есть неприятный эффект.
Стоимость такого контроля почти нигде не видна.
Она растворена в рабочем времени, сообщениях, звонках, памяти и постоянном «я ещё проверю». Поэтому автоматизация процесса на бумаге может выглядеть экономически сомнительной: зачем инвестировать, если всё и так работает?
Действительно.
Работает.
Просто часть корпоративной информационной системы почему-то приходит утром на работу, пьёт кофе и иногда уходит в отпуск.
Мне кажется, один из полезных тестов зрелости процесса звучит не так: «Сколько в нём ошибок?»
А так:
Что перестанет происходить само, если завтра из процесса убрать самого внимательного человека?
Ответ иногда довольно точно показывает, где у компании процесс, а где человек, который много лет заменяет его собой.
#управление #финансы #бизнеспроцессы #операционнаяэффективность #автоматизация
· 1 ч
На Хабре была статья про эффективность в команде и приводился пример. Посчитали эффективность каждого человека в команде и у самого низкоэффективного сократили. Ожидание, что эффективность команды не измениться. Реальность - резко снизилась. Как оказалось этот человек был неформальным лидером, вокруг него всегда все собирались, он помогал другим, фактически снижая уровень стресса в команде. ( Про подход человека к выполнению своих служебных обязанностей я тут промолчу). А вот если бы его роль официально закрепили и описали? Можно быть и “подстраховаться” это просто плохо описанный процесс?
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 1 ч
Николай, вот этот пример как раз отлично показывает опасность локальной оптимизации. В таблице человек оказался “низкоэффективным”, а на уровне системы - частью инфраструктуры команды. Убрали строку с плохим показателем, а вместе с ней случайно удалили несколько невидимых связей.
Но с формализацией я бы была осторожна. Увидеть такую функцию и создать для неё условия - нужно. А вот записать в должностной инструкции “быть человеком, вокруг которого все собираются” вряд ли получится: неформальное лидерство во многом работает именно потому, что оно не назначено приказом.
Формализовать, скорее, можно то, что его поддерживает: наставничество, обмен знаниями, помощь коллегам, время на онбординг, командные показатели. А главный вывод для меня другой: прежде чем признать человека неэффективным, неплохо бы понять, какую часть системы мы вместе с ним собираемся удалить
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён