Бизнес-процессы: почему «быстро» не получится?
«Нам нужно внедрить процессный подход. Желательно за квартал».
«Мы хотим автоматизировать ключевые процессы. К концу месяца реально?»
«Посмотрели видео на YouTube – там всё просто. Почему у нас так долго?»
Знакомые фразы? За каждой из них стоит одно и то же: желание получить результат быстро. Без долгого пути. Без «лишних» этапов. Нажал кнопку – и заработало.
Это не лень и не глупость. Это нормальное человеческое желание – видеть результат. Проблема в другом: путь от идеи до работающего решения нельзя сократить волевым решением. Можно только пройти – шаг за шагом.
Определение сроков по принципу «я так хочу» приводит к разочарованию и впустую потраченным ресурсам. И, как обычно, виноват будет процессный подход, сотрудники, консультанты – но не тот, кто ставил нереалистичные сроки.
Откуда вообще берётся убеждение, что «всё просто»?
Во многом – из интернета. YouTube или посты в популярных соцсетях. Контента много, он доступен, часто бесплатен. Казалось бы – бери и учись.
Проблема в том, что этот контент фрагментарен. Автор показывает один приём, один инструмент, один кейс. Вырванный из контекста. Без предыстории. Без объяснения ограничений. Без честного разговора о том, что работает только в специфических условиях.
Зритель смотрит и думает: «О, как просто! Почему мы так не делаем?»
А потом пытается повторить – и ничего не работает. Или работает, но не так. Или работает неделю, а потом ломается.
Фрагментарные знания создают иллюзию понимания. Человек знает термины, видел примеры, может поддержать разговор. Но когда доходит до реальной задачи – обнаруживается, что между «видел видео» и «могу сделать» – пропасть.
Хуже того: фрагментарные знания мешают учиться. Зачем проходить системный курс, если «и так всё понятно»? Зачем разбираться в основах, если хочется сразу к практике?
В результате – каша в голове. Набор несвязанных фактов вместо системы. И ошибки, которых можно было избежать, если бы фундамент был прочным.
Покажу на примере. Возьмём популярную тему – построение RAG-системы для работы с корпоративными документами. RAG (Retrieval-Augmented Generation) – это когда сотрудник задаёт вопрос обычным языком, а система находит ответ в базе знаний компании: регламентах, инструкциях, методичках. Не нужно помнить, где что лежит. Не нужно перечитывать десятки документов. Спросил – получил ответ со ссылкой на источник.
В YouTube полно видео: «Как сделать RAG за 10 минут», «Простой RAG на n8n», «RAG для новичков».
Вот типичный процесс из такого видео:
Выглядит просто, правда? Открываем форму, загружаем файл, нажимаем Submit – и магия происходит. Три-четыре шага, красивые иконки, понятная логика.
Для демонстрации концепции – достаточно. Но попробуйте применить это в компании, где сотни документов разных типов и форматов.
А вот фрагмент реального процесса – только начальный этап, загрузка и категоризация. Видите разницу?
Только на входе – маршрутизация по десяти типам: Документ, Книга, Метод, Методология, Модель, Свод знаний, Спецификация, Стандарт и т.д. И это ещё не сам процесс обработки – это только категоризация входящего файла. Т.е. ОДИН шаг на примере из видео в реальной практике (продакшн) «превращается» в целый подпроцесс.
В реальном продакшн-процессе тот шаг, который в видео занимает одну ноду, превращается в 30-50 элементов. И это не перфекционизм – это необходимость.
Каждый «лишний» элемент появляется не просто так. Он закрывает конкретную проблему, которую автор видео, где «все просто и быстро», не показал:
- Обработка разных форматов – потому что реальные документы приходят в PDF, DOCX, сканах, и каждый формат требует своего подхода
- Валидация и проверка ошибок – потому что пользователи загружают не то, не туда и не так
- Логирование – потому что когда что-то сломается (а оно сломается), нужно понять, где именно
- Обработка исключений – потому что «а что если файл битый?» случается регулярно
- Версионирование – потому что документы обновляются, и нужно знать, какая версия актуальна
- Права доступа – потому что не все документы для всех.
И это не полный перечень нюансов реальных процессов, который надо учесть.
Это как рецепт в кулинарном шоу: шеф-повар за 5 минут собирает блюдо из подготовленных ингредиентов. А за кадром – два часа работы су-шефов, которые всё нарезали, отмерили и разложили по мисочкам.
То, что в видео занимает 10 минут просмотра, в реальности требует недель разработки и отладки. Авторы видео об этом не говорят – не потому что врут, а потому что у них другая задача: показать концепцию, привлечь внимание. А не научить делать продакшн-решения.
Та же логика работает с бизнес-процессами. Поверхностное изучение процесса «как есть» – это как туториал на YouTube: общая картинка есть, а деталей нет.
Чем глубже вы изучаете процесс, тем больше обнаруживается нюансов:
- Исключения, которые «все знают, но нигде не записано».
- Неформальные договорённости между отделами.
- Обходные пути, которые сотрудники придумали сами.
- Узкие места, которые компенсируются «героизмом» отдельных людей. На таком «героизме», кстати, многие строят карьеры – в компаниях с низким качеством менеджмента всегда востребованы «решатели проблем» и «тушители пожаров».
Если остановиться на уровне «в целом понятно» – всё это останется невидимым. А потом всплывёт на этапе внедрения. Или, что хуже, на этапе автоматизации – когда система работает строго по алгоритму и не умеет «ну, тут мы обычно по-другому делаем».
Хорошо проработанный регламент – это почти готовое техническое задание на автоматизацию. Все шаги описаны, все условия учтены, все исключения обработаны. Остаётся только перевести на язык системы.
Плохо проработанный регламент – это иллюзия готовности. Автоматизация по такому документу превращается в бесконечные доработки: «а мы забыли сказать, что тут ещё вот так бывает».
Когда руководитель спрашивает «сколько займёт внедрение процессного подхода?» – честный ответ звучит так: «Зависит от...»
- Масштаб компании. Процессы в компании на 20 человек и на 200 – это разные истории. Больше людей – больше участников процессов, больше интервью, больше согласований, больше сопротивления.
- Количество и сложность процессов. Процесс внутри одного отдела и кросс-функциональный процесс, затрагивающий пять подразделений – разные сроки. Кросс-функциональный процесс – это разные интересы, разные приоритеты, разные «а у нас так исторически сложилось».
- Отрасль. В некоторых отраслях процессы жёстко регулируются (финансы, медицина, фармацевтика). Это добавляет требований и ограничений. В других – больше свободы, но и больше хаоса.
- Наличие региональных подразделений. Если компания распределённая – добавляйте время на координацию, разницу во времени, локальную специфику.
- Уровень зрелости менеджмента. Это фактор, который часто недооценивают. А он влияет критически. Он – ключевой. Если руководители понимают, зачем нужны процессы, готовы выделять время сотрудников на проект, умеют принимать решения и не меняют приоритеты каждую неделю – проект движется. Если каждое решение согласовывается месяц, ключевые люди «заняты текучкой», а приоритеты меняются по настроению – проект буксует. И никакая методология это не исправит.
- Уровень сопротивления. Любые изменения встречают сопротивление. Вопрос – насколько сильное и откуда идёт. Сопротивление исполнителей преодолевается относительно легко. Сопротивление руководителей – это совсем другая история.
Понимая всё вышесказанное – какие сроки реалистичны?
Этап «как есть» (изучение и моделирование текущих процессов):
- Малая компания, простые процессы: 1-1,5 месяца
- Средняя компания, кросс-функциональные процессы: 2-4 месяца
Полный цикл одного процесса (изучение → анализ → оптимизация → регламентация → внедрение):
- Процесс одного подразделения: 2-3 месяца
- Кросс-функциональный процесс: 4-6 месяцев
Полноценный проект внедрения процессного подхода (несколько ключевых процессов, формирование регламентов, обучение, запуск):
- Малые и средние компании: 6-8 месяцев
- Крупные компании: 8-12 месяцев и более
И это – при условии нормального уровня менеджмента и умеренного сопротивления. Если с этим проблемы – смело умножайте на полтора-два.
Отдельно про автоматизацию: это не «добавка» к проекту по процессам. Это отдельный проект со своими сроками. Автоматизировать имеет смысл только стабильный, отлаженный процесс. Иначе вы автоматизируете хаос – и получите хаос, только быстрее.
Как эти ориентиры соотносятся с реальными запросами рынка? Что происходит, когда ожидания расходятся с возможностями? Разберём на конкретном примере – в следующем материале.
Путь к работающим процессам – это марафон, а не спринт. Медленная, но упорная черепаха обгоняет зайца, который мечется между «срочными» задачами.
Это не значит, что нужно растягивать проект до бесконечности. Это значит, что реалистичные сроки – основа успеха.
Если вы понимаете, что проект займёт восемь месяцев, а не два – вы иначе планируете ресурсы, иначе управляете ожиданиями, иначе реагируете на неизбежные сложности.
Для тех, кто хочет разобраться в теме системно – не по фрагментам из видео, а с пониманием логики и взаимосвязей – есть структурированное обучение. Не набор лайфхаков, а система знаний, которая позволяет видеть целое, а не только части.
«Хотим быстро» – это желание. Результат начинается с вопроса: сколько реально нужно времени, и готовы ли мы его инвестировать?
