Предел стандартизации

«Всё должно быть сделано как можно проще, но не проще»
— Альберт Эйнштейн

Однажды, на Уимблдоне в 1986 году, организаторы впервые задумались: а насколько чётко должны быть стандартизированы действия мальчиков и девочек, подающих мячи? Сколько шагов делать до точки сбора? Кто должен реагировать первым? На удивление, даже на таком престижном турнире многие детали оставались… недоопределёнными. Решили провести тренинг и создать стандарты – но довольно быстро поняли, что в некоторых моментах слишком “жёсткая” унификация мешает работе команды, лишая игроков гибкости. Ведь как предусмотреть каждую возможную ситуацию на корте?

Теперь к бизнесу. В наше время хочется всё автоматизировать: “давайте сначала всё максимально унифицируем, заведём регламенты, чек-листы, инструкции — а потом автоматизируем!” Знакомо? Я и сам регулярно говорю: “Автоматизировать хаос — значит получить автоматизированный хаос.” 😅

Но иногда мы забываем задать себе важный вопрос:
Где тот предел, где стандартизация уже не полезна, а наоборот, начинает мешать?
Стандартизировать до единого алгоритма? До шаблонных действий или общей “технической политики”? Или, может, оставить немного пространства для решений “по ситуации”?

Эта дилемма особенно острая, когда речь о сложных процессах — стройках, ремонтах, сервисе и т.д. Можно потратить месяцы и горы часов, создавая тех. карты до мелочей… Будете логически правы — везде стандарты! Но жизнь часто ярче любого стандарта 😉.

Мой вывод: не стоит стремиться “кипятить океан” — слишком сильно унифицировать и автоматизировать всё подряд. Иногда небольшой “хаос” — это не ошибка, а творческое пространство для роста.

👉🏻 Делайте стандарты где это реально нужно. Автоматизируйте там, где это приносит пользу.
А иногда просто хватит: “Да пусть они сами между собой разберутся!”

Как думаете, где, на ваш взгляд, проходит тот самый предел унификации? Поделитесь опытом!📝

Один комментарий к “Предел стандартизации

  1. Унификация должна помогать, а не создавать проблемы или тратить время на пустые занятия.

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *