К:ЛАБ ТЕХ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

Система не исправит отсутствие процесса: кейс заявочной кампании в промышленной компании

Старая история, но актуальная сегодня.
Промышленная компания. Заявки на закупку оформлялись в бумажном виде, с живой подписью. Их передавали из цеха в снабжение, иногда теряли, иногда дублировали. Прослеживаемости не было: непонятно, на какой стадии заявка, кто её согласовал, когда и что с ней дальше. Руководство решило: «Внедряем систему управления заявочной кампанией на базе SAP». Логично — вроде бы.

Внедрили. И получили два системных провала.

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

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

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

Цена ошибки:
- закупки не по назначению и срывы сроков;
- дублирование и ручные обходные пути;
- потеря доверия к системе у пользователей;
- дополнительные часы на разбор и исправление данных;
- риск остановки производства из-за неверной заявки.

Что нужно было сделать до внедрения:
1. Описать процесс «как есть» и оптимизировать его: кто инициирует, какие данные обязательны, кто согласует, в какие сроки, как эскалировать.
2. Привести в порядок справочник материалов: коды, описания, единицы измерения, ответственные закупщики. Если кода нет — регламент его создания, а не выбор «любого похожего».
3. Настроить маршруты по ролям, а не по фамилиям. Назначить владельца процесса и порядок актуализации при кадровых изменениях.
4. Обучить пользователей и провести пилот на одном подразделении.
5. Только после этого масштабировать автоматизацию.

Вывод: Система — это инструмент. Она не создаёт порядок, а закрепляет то, что уже есть. Если процесс заявок хаотичен, ERP сделает хаос быстрым, масштабируемым и дорогим. Сначала процесс и данные — потом автоматизация.

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

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

Пример из жизни. Компания решила автоматизировать закупки. Купили SRM-систему. Но перед этим не описали процесс согласования заявок. В итоге в системе появилось 12 этапов согласования, потому что «так было в Excel». Время обработки заявки выросло с 3 дней до 7. Почему? Потому что раньше часть согласований можно было провести устно или пропустить, а теперь система требовала формального подтверждения от каждого. Автоматизация усилила бюрократию, а не устранила её.

Другой пример: внедрили MRP. Но данные о запасах в системе неактуальны (кладовщики не успевают вносить изменения). В результате MRP формирует заказы на закупку того, что уже есть, и не заказывает то, что нужно. Производство встаёт. А виновата «плохая система».

Вывод: автоматизация без предварительного описания и оптимизации процессов — это просто перевод хаоса в цифровой формат. Дорого, долго, бесполезно.

Что делать вместо этого?

Генеральная линия нашего сообщества: сначала процессы — потом автоматизация. Вот пошаговый алгоритм, который сэкономит вам бюджет и нервы:
1. Опишите процессы как есть. Используйте BPMN или хотя бы блок-схемы. Важно увидеть реальную картину, а не идеальную. Привлеките исполнителей — они знают, где на самом деле «тонко».
2. Найдите узкие места и потери. Где задерживается информация? Где дублируются действия? Какие согласования можно убрать без потери контроля? Часто достаточно простых улучшений, чтобы процесс стал быстрее и дешевле.
3. Оптимизируйте и регламентируйте. Создайте чёткие инструкции: кто, что, когда и в какой системе делает. Убедитесь, что все участники понимают и принимают новые правила.
4. Оцените, нужна ли автоматизация. Иногда после наведения порядка выясняется, что процесс настолько прост, что автоматизировать его невыгодно — хватит и ручного управления. Или что нужна не тяжёлая ERP, а лёгкий инструмент.
5. Выберите ПО под оптимизированный процесс. Только теперь, когда вы знаете, как должно работать, можно искать систему, которая это поддержит. И требовать от неё гибкости, а не подстраивать процесс под софт.

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

Заключение

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

Поэтому прежде чем покупать ERP, MES или SRM, задайте себе вопрос: «А у нас процесс готов к автоматизации?» Если ответ «не уверен» — начните с описания процессов. Это дешевле, быстрее и надёжнее.

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

Почему автоматизировать бардак — дорого и бесполезно
(или как купить софт и получить автоматизированный хаос)

Представьте склад. Приезжает фура с товаром. Кладовщик дядя Вася достаёт заветную амбарную книгу — толстую, потрёпанную, с чайными пятнами и следами от печатей. Он торжественно записывает: «Принято: 40 коробок гвоздей, 20 коробок саморезов, 3 упаковки неизвестно чего, но пусть будет». Руководство смотрит на это и говорит: «Хватит это терпеть! Внедряем автоматизацию!» Покупают современную систему учёта. Обучают дядю Васю. И что вы думаете? Теперь дядя Вася при поступлении товара сначала пишет всё в ту же бумажную книгу — потому что «так надёжнее», а потом идёт к компьютеру и вносит те же данные в систему. Иногда забывает, иногда путает, иногда вносит не то. В журнале — 40 коробок, в системе — 4, а на складе — 44, и никто не понимает, где правда. Товар ищут всем складом, как клад. Начальник кричит: «Работайте в системе!» Дядя Вася кивает и достаёт книгу. В итоге автоматизировали учёт, а бардак не только остался — у него теперь два источника правды, бумажный и электронный, и оба врут по-своему. Знакомо?

Компании годами живут с хаотичными процессами в снабжении и производстве, а потом решают: «Нам нужна автоматизация!» Покупают ERP, WMS, MES, SRM — и ждут чуда. Чуда не происходит. Становится только хуже. Давайте разберёмся, почему автоматизировать бардак — это дорого, бесполезно и иногда опасно.

Что такое «бардак» в процессах снабжения и производства?

Бардак — это не обязательно грязь и разруха. Это отсутствие прозрачных, повторяемых и управляемых процессов. Вот его типичные признаки:
- «Исторически сложилось» — так часто отвечают на вопрос, почему заявка на закупку проходит через пять согласований, а документ, регламентирующий согласование заявок, отсутствует или устарел.
- Зоопарк систем — Excel, почта, бумажные журналы, 1С, SAP и ещё пара самописных баз. Данные дублируются, противоречат друг другу, теряются.
- Ручное управление — планировщик производства каждый день героически тушит пожары, потому что данные о запасах вносят в систему с опозданием, и они не соответствуют реальности. Например, завели материал под неправильной кодировкой и система считает его другой позицией.
- Отсутствие регламентов — никто точно не знает, кто и что должен делать, поэтому все делают всё, а в итоге не делает никто.
- Метрики ради метрик — OTIF, OEE, оборачиваемость считаются, но на их основе ничего не меняется, потому что данные недостоверны, а первопричины не анализируются.

Если хотя бы половина пунктов про вас — поздравляю, вы в зоне риска. И автоматизация здесь не спасёт. Почему?

Дорого: вы платите за хаос дважды

Автоматизация бардака — это как покупка дорогого спортивного автомобиля для поездок по бездорожью. Деньги потрачены, а толку ноль. Разберём по статьям затрат:
1. Прямые расходы на ПО и внедрение. Лицензии, интеграция, настройка, доработка под «уникальные» процессы (которые на самом деле — хаос). Чем запутаннее процессы, тем больше доработок и тем дороже проект.
2. Косвенные потери. Сотрудники отвлекаются на внедрение, обучение, параллельное ведение дел в старой и новой системе. Производительность падает.
3. Упущенная выгода. Пока вы автоматизируете хаос, конкуренты наводят порядок и оптимизируют процессы, улучшают качество продукции. Вы теряете время и рынок.
4. Скрытые риски. Автоматизированная система фиксирует ошибки и тиражирует их с огромной скоростью. Если в процессе закупки заложено ненужное согласование, электронная система будет требовать его всегда — и никто не сможет быстро отменить.

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

Бесполезно: софт не думает, он выполняет правила

Любая система автоматизации — это исполнитель. Она не обладает здравым смыслом, не может понять, что «так исторически сложилось, но вообще-то это глупо». Она выполняет