Что я ищу в бизнес-процессе, прежде чем предлагать систему

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

Это похоже на осмотр дома перед ремонтом. Можно сразу выбирать плитку и светильники, но разумнее сначала проверить проводку, воду и несущие стены. В бизнес-процессе такими «стенами» становятся ответственность, данные и договорённости между людьми.

Где процесс начинается и где он на самом деле заканчивается

У любого процесса есть формальное начало: заявка создана, заказ принят, договор подписан. Но полезнее спросить, что было за минуту до этого. Откуда пришла информация? Кто её проверил? По какому признаку решили, что с ней можно работать?

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

Какие данные люди переносят руками

Ручное копирование не всегда зло. Иногда оно занимает минуту и помогает быстро проверить необычную ситуацию. Проблема начинается, когда одно и то же имя, сумма, срок или статус переписываются в нескольких местах каждый день. Тогда ошибка становится не случайностью, а встроенной частью процесса.

Я ищу не только места ввода, но и источник правды. Если менеджер смотрит на CRM, склад — на свою таблицу, а руководитель — на отчёт, собранный вручную, у компании появляется несколько версий реальности. До интеграции важно договориться, какая из них главная для каждого типа данных.

Где человеку приходится угадывать

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

Здесь не нужно сразу превращать каждое решение в жёсткий алгоритм. Сначала я отделяю действительно нужную гибкость от привычки обходить неясные правила. Для первого варианта системы можно оставить пространство для выбора, но сделать его заметным и понятным другим участникам.

Какие исключения съедают время

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

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

Кто отвечает за результат, а не за свой шаг

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

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

Что получается на выходе

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

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

Пять вопросов для первой встречи

• Как выглядит один обычный случай от первого сигнала до результата?
• Где данные появляются впервые и кто отвечает за их точность?
• На каком шаге люди чаще всего ждут или переделывают работу?
• Какие исключения случаются регулярно?
• Как мы увидим, что после изменений процесс стал лучше?

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

Я смотрю на процесс без поиска виноватых

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

Это особенно важно в компаниях, где опытные сотрудники давно компенсируют слабые места личными договорённостями. Их обходные пути — не повод упрекать людей. Это карта того, чего не хватает процессу и будущей системе.

Разные решения требуют разной степени автоматизации

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

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

Какие вопросы задаю о будущем

Процесс важно смотреть не только в сегодняшнем объёме. Что будет, если заявок станет вдвое больше? Что случится, если ключевой сотрудник неделю недоступен? Где появится новая точка риска при подключении партнёра или нового канала продаж? Эти вопросы не требуют рисовать фантастическое будущее. Они помогают не построить решение, которое перестанет работать ровно в момент роста.

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

Как превратить наблюдения в план

В конце полезно ранжировать находки не по громкости жалобы, а по влиянию на результат и сложности исправления. Сначала идут риски, из-за которых теряются деньги, данные или доверие клиента. Затем — повторяющаяся ручная работа. После этого — удобство и улучшения, которые не мешают основному пути. Такой порядок даёт команде спокойный старт и защищает бюджет от расползания.

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