К:ЛАБ ТЕХ

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

Давайте разберемся, где заканчивается порядок и начинается бюрократический «Мордор», и как найти ту самую золотую середину.

Ловушка «Синдрома Вавилонской башни»

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

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

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

Принцип «Достаточной зрелости»

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

Здравый смысл требует задать вопрос: «Какую бизнес-цель решает этот идеальный процесс?» Если мы тратим три недели на описание процесса закупки канцелярии, чтобы сэкономить 500 рублей в месяц, — это провал. Если мы выстраиваем сверхсложную систему контроля качества для стартапа, который еще не нашел PMF (product market fit), — это убийство бизнеса.

Идеальный процесс — это не тот, где учтено всё, а тот, где:
1. Устранены критические риски (финансовые, юридические, безопасность).
2. Убраны очевидные «узкие горлышки» (bottlenecks), тормозящие работу.
3. Процесс понятен исполнителю без чтения 50-страничной инструкции.

Автоматизация как драйвер упрощения

Существует парадокс: иногда лучший способ понять, что процесс «перегружен», — это попытаться его автоматизировать. Когда система требует ввести 30 полей, а сотрудник в реальности использует только 5, это сигнал: процесс не оптимизирован, он раздут.

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

Резюме: Разумный минимализм

Итак, как же не «перегнуть»?

1. Правило Парето (80/20): Описывайте и оптимизируйте те 20% шагов, которые создают 80% ценности или рисков. Остальное оставьте на откуп профессионализму сотрудников.
2. Пилотные проекты: Не пытайтесь внедрить «идеальный процесс» на всю компанию сразу. Проверьте его на одном отделе. Если люди начинают работать медленнее и злее — процесс плох, даже если он логичен на бумаге.
3. Цифровизация без фанатизма: Не превращайте компанию в машину. Бизнес — это живой организм.

Мое главное утверждение остается неизменным: порядок (процесс) первичен, автоматизация вторична. Но помните: порядок нужен для того, чтобы бизнес рос и зарабатывал, а не для того, чтобы бизнес-аналитик мог с гордостью смотреть на идеальную схему, пока компания теряет клиентов из-за волокиты. Здравый смысл — это лучший инструмент оптимизации.

#бизнеспроцессы #автоматизация #снабжение #производство

тельность, надёжность, безопасность. Вспоминают о них, когда система падает.
- Передача требований без контекста. Вендор не знает ваш процесс. Приложите схему BPMN и регламент.

Как это связано с генеральной линией

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

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

Что должно быть готово до общения с вендором

- Описанный процесс «как должно быть» (BPMN или блок-схема).
- Регламент и матрица согласования по ролям.
- Реестр требований с приоритетами и критериями приёмки.
- Список исключений и нестандартных ситуаций.
- Понимание, какие требования критичны, а какие можно отложить.

С этим пакетом вы говорите с вендором на одном языке. Вы не просите «сделайте красиво», а показываете, что именно должна делать система.


#бизнеспроцессы #автоматизация #снабжение #производство #требования #middle #senior

Управление требованиями: как не потерять суть процесса при автоматизации

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

Требование — это формализованное описание того, что система должна делать, вытекающее из процесса и потребностей бизнеса. Хотелка — это «сделайте красиво» или «как у конкурентов».

Пример:
- Хотелка: «Хотим удобный интерфейс для закупщика».
- Требование: «Закупщик должен видеть все заявки, срок согласования которых истекает сегодня, и иметь возможность отправить напоминание согласующему в один клик».

Требование проверяемо. Хотелку нельзя проверить.
Классификация, которая помогает не утонуть:
Функциональные — что система делает. «Система должна автоматически создавать заявку на основе данных MRP». «Система должна поддерживать параллельное согласование».
Нефункциональные — как делает. «Время отклика при поиске позиции — не более 2 секунд». «Система должна поддерживать 50 одновременных пользователей».
Бизнес-правила — ограничения из процесса. «Заявка на сумму свыше 100 000 рублей требует согласования финансового директора». «Закупка у единственного поставщика допускается только при наличии обоснования».
Требования к данным — что должно быть в справочниках. «Код материала обязателен для всех позиций, кроме услуг». «Единица измерения выбирается из справочника, а не вводится вручную».

Если вы описали процесс в BPMN, многие требования уже видны: шлюзы становятся бизнес-правилами, дорожки — ролями и правами доступа, задачи — функциями системы.

Почему теряется суть процесса

Три главные причины.
1. требования собирают с менеджеров, а не с исполнителей. Руководитель скажет, как должно быть, но не всегда знает, как есть на самом деле. Закупщик расскажет, где реально застревает заявка. Спрашивайте всех, кто участвует в процессе.
2. требования пишут «на будущее», а не под текущий процесс. «Давайте сразу заложим возможность тендеров на 10 этапов». В итоге система становится сложной, а текущий процесс — не поддерживается. Сначала автоматизируйте то, что есть. Потом расширяйте.
3. требования не проверяют на полноту и непротиворечивость. Один отдел просит одно, другой — противоположное. Если это не выявить до внедрения, система будет метаться или не работать вовсе.

Как собирать требования: практический подход

Шаг 1. Возьмите процесс «как должно быть». Это ваша основа. Каждый шаг процесса — потенциальное требование.

Шаг 2. Проведите интервью с исполнителями. Не один общий воркшоп, а отдельно с каждой ролью. Вопросы:
- Что вы делаете на этом шаге?
- Какие данные вводите, откуда берёте?
- Что вас замедляет или раздражает?
- Что будет, если этот шаг не сделать?
- Как вы понимаете, что всё готово?

Шаг 3. Зафиксируйте требования в едином реестре. Формат простой:
Смотри рисунок.

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

Шаг 5. Согласуйте с участниками. Требования должны быть понятны и приняты теми, кто будет работать в системе. Иначе саботаж.

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

Типичные ошибки

- Требования без приоритетов. Всё «важно». В итоге либо не делают ничего, либо делают всё, но плохо.
- Требования без критериев приёмки. Как понять, что требование выполнено? «Система должна быть удобной» — не критерий.
- Требования, которые противоречат процессу. Если процесс изменился, требования нужно обновить. Реестр — живой документ.
- Игнорирование нефункциональных требований. Производи

BPMN для снабжения: как описать процесс закупки до внедрения ERP

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

Разберём на примере закупки.

Шаг 1. Определите границы
Начало: цех подаёт заявку. Конец: товар принят на склад. Всё, что до и после, — отдельные процессы.

Шаг 2. Нарисуйте «как есть»
Не идеальную схему, а реальную. Возьмите пять последних заявок и пройдите по ним. Скорее всего, обнаружите:
- заявку согласуют пять человек, а нужны два;
- данные дублируют в свои файлы Excel;
- статус заявки никто не знает, пока не позвонишь.

Шаг 3. Используйте базовые элементы

Для снабжения хватит пяти:
- Дорожки (pools/lanes) — роли: цех, снабжение, финансы, склад.
- Задачи (tasks) — действия: «проверить заявку», «согласовать бюджет».
- Шлюзы (gateways) — развилки: «сумма > 100 000?», «поставщик из списка?».
- События (events) — старт, финиш, таймер просрочки.
- Потоки (flows) — последовательность и передача между ролями.

Этого достаточно. Не усложняйте.

Шаг 4. Найдите проблемы
Смотрите на схему и задавайте вопросы:
- Где заявка может застрять? Кто её ждёт и сколько?
- Какие согласования не создают ценность?
- Что будет, если согласующий в отпуске?
- Где дублируется ввод данных?

Шаг 5. Нарисуйте «как должно быть»
Уберите лишнее, добавьте эскалацию по срокам, замените фамилии ролями. Согласуйте с участниками. Только после этого идите к вендору ERP и показывайте: «Вот процесс, который система должна поддержать».

Типичные ошибки
- Рисуют «как надо», а не «как есть» — и не видят реальных проблем.
- Делают схему на 40 шагов и пугаются сами.
- Забывают про исключения: возврат, отказ, срочная закупка.
- Не согласуют схему с исполнителями — и получают «у нас всё не так».

Вывод
BPMN — не бюрократия, а способ увидеть процесс до автоматизации. Час на схему экономит месяцы переделок в ERP. Сначала процесс — потом софт.


#бизнеспроцессы #BPMN #автоматизация #снабжение #ERP #middle

Как подготовиться к автоматизации снабжения: чек-лист из 7 шагов

Мы много пишем, почему автоматизировать бардак дорого и бесполезно. Но как подготовиться? Ниже — чек-лист. Он подходит и зрелым компаниям, и стартапам: у первых есть данные и процессы, но чаще всего замусорены наследием, у вторых данных нет — их нужно создать. Компании по внедрению ПО сделают то же самое, но за деньги.

1. Определите границы процесса и владельца
- Где начинается и заканчивается: заявка → согласование → тендер → договор → поставка → приёмка → оплата?
- Кто участники: цеха, снабжение, финансы, юристы, склад?
- Что считается результатом: подписанный договор, принятый товар?
- Кто владелец — должность в компании, отвечающая за результат и улучшения?

2. Опишите процесс «как есть»
- Пройдите по реальным заявкам, включая зависшие.
- Зафиксируйте шаги: кто, что, когда, где.
- Отметьте, где застревает, дублируется, теряется.
- Посчитайте фактическое время обработки.

3. Оптимизируйте
- Уберите согласования без ценности. 12 этапов — не контроль, а хаос.
- Устраните дублирование данных.
- Определите, где нужен контроль, а где достаточно последующей проверки.
- Проверьте сроки и эскалацию.

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

5. Приведите в порядок мастер-данные

Зрелая компания:
- Справочник номенклатуры: уберите дубли, унифицируйте описания.
- Поставщики: слейте дубли, проверьте реквизиты.
- История цен — к единому формату.
- Правила создания новых кодов.

Стартап:
- Определите структуру справочников заранее.
- Зафиксируйте регламент ведения с самого начала.

Для всех:
- Назначьте ответственного за мастер-данные. Он следит за качеством и актуальностью справочников.

6. Замерьте метрики до автоматизации
- Срок обработки заявки.
- Доля закупок вне процесса.
- OTIF, оборачиваемость, срывы поставок.
- Ошибки в заявках: неверные коды, дубли.

Без базовой линии не докажете эффект.

7. Подготовьте людей
- Объясните, какие изменения упростят процесс.
- Обучите логике процесса.

Важно про коробочное ПО

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

Заключение

Автоматизация не создаёт порядок — она его закрепляет. Сначала процесс, роли и данные. Потом софт. Консалтинг скажет то же самое — вы можете сделать это сами.

#бизнеспроцессы #автоматизация #снабжение #чеклист #новичок #middle