К:ЛАБ ТЕХ

10 вопросов для аудита процесса перед выбором ПО: чек-лист, который сэкономит бюджет

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

10 вопросов для аудита процесса перед выбором ПО

1. Кто владелец процесса и кто принимает финальное решение?
Если владельца нет, автоматизация закрепит конфликт между закупкой, производством, финансами и складом. Red flag: «у нас все участвуют, но никто не отвечает».

2. Процесс описан end-to-end: где начинается и где заканчивается?
Нужна карта от возникновения потребности до оплаты и закрытия заказа. Red flag: процесс существует только в головах сотрудников и в переписке.

3. Какие шаги, роли и зоны ответственности закреплены?
Проверьте RACI: кто делает, кто согласует, кого информируют. Red flag: «обычно Вася подписывает, но если его нет — Маша».

4. Где узкие места и сколько времени занимает цикл?
Замерьте цикл закупки, количество согласований, возвратов на доработку. Red flag: никто не знает базовых цифр — значит, эффект автоматизации не с чем будет сравнить.

5. Какие данные используются и кто за них отвечает?
Справочник номенклатуры, остатки, цены, сроки поставки, BOM. Red flag: несколько версий Excel и дубли позиций в справочнике.

6. Какие правила принятия решений описаны?
Пороги согласования, выбор поставщика, работа с исключениями, эскалация. Red flag: решения принимаются «по ситуации» и не фиксируются.

7. Какие метрики процесса измеряются сегодня?
Время цикла, OTIF, доля срочных закупок, количество ошибок, стоимость процесса. Red flag: KPI есть только у отделов, но не у сквозного процесса.

8. Где типовые потери и ошибки?
Повторный ввод данных, дубли счетов, закупки вне регламента, авралы, избыточные запасы. Red flag: потери «все знают», но никто не считал.

9. Какие требования к ПО реально следуют из процесса?
Сначала must-have и nice-to-have из описанного процесса, потом сравнение поставщиков ПО. Red flag: требования сформулированы по демо поставщика, а не по своим шагам.

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

Как использовать чек-лист
- Ответ «да» — 1 балл, «частично» — 0,5, «нет» — 0.
- 8–10 баллов: процесс в целом готов, можно переходить к выбору ПО и формированию требований.
- 5–7 баллов:** сначала опишите процесс, назначьте владельцев данных и закройте ключевые пробелы.
- 0–4 балла: автоматизация преждевременна. Сначала аудит, регламенты и пилот с изменениями на одном участке.

Что должно быть на выходе аудита
- карта процесса «как есть»;
- список узких мест и потерь;
- владельцы данных и регламент изменений;
- baseline-метрики;
- требования к ПО, разделённые на must-have и nice-to-have;
- критерии выбора и план пилота.

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

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

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

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

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

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

В погоне за прозрачностью рождаются процессы, которые красиво выглядят на схеме в 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