Систему купили, на настройку потратили месяцы, сотрудников отвлекали от основной работы. Но остатки по-прежнему перепроверяют вручную, руководитель собирает отчёт из нескольких таблиц, а сложные случаи решаются в переписке.
Это собирательная ситуация, с которой предприятие может столкнуться после внедрения ПО. Когда такой опыт уже был, предложение «давайте автоматизируем» воспринимается настороженно. Руководитель помнит расходы, сотрудники — неудобства, а обещание новой системы звучит как предложение пройти тот же путь ещё раз.
Я считаю такую осторожность нормальной. Начинать следующий проект стоит с разбора предыдущего: что именно не получилось, почему и как проверить, что новое решение не повторит ту же ошибку.
Почему презентация не отвечает на главный вопрос
На сайте поставщика обычно подробно объясняются возможности продукта. Демонстрация показывает, как система работает в подготовленном сценарии. Это полезная информация, но она ещё не доказывает, что продукт подходит конкретному предприятию.
У вас могут быть другие маршруты производства, правила учёта, ограничения оборудования, исключения при отгрузке или требования к интеграциям. Наличие функции с подходящим названием не означает, что она поддерживает нужный порядок работы.
Поэтому вопрос «есть ли у вас управление производством?» слишком общий. Гораздо полезнее попросить показать конкретный сценарий: частичное выполнение заказа, возврат на доработку, замену материала, исправление ошибки после закрытия операции.
И отдельно выяснить, что доступно в стандартной поставке, что настраивается, а что потребует разработки и дополнительных расходов.
Два вида несоответствия: не хватает нужного или слишком много лишнего
Для оценки применимости коробочного ПО я использую два понятных вида несоответствия.
Недостаточность. Нужной функции нет либо она слишком ограничена для реального процесса. Приходится достраивать систему, использовать внешние таблицы или менять работу предприятия ради ограничений программы.
Избыточность. Продукт рассчитан на значительно более широкий круг задач. Предприятию нужна небольшая часть возможностей, но приходится разбираться в сложной модели, обучать людей и поддерживать настройки, которые не дают соразмерной пользы. Возможность отключить лишнее и стоимость такого упрощения нужно проверять у конкретного продукта.
Это не классификация всех коробочных систем на «плохие» и «очень плохие». Одна и та же программа может хорошо подойти одному предприятию и оказаться неудобной для другого. Более того, в одном внедрении могут сочетаться оба вида несоответствия: много возможностей в целом и недостаток именно тех, которые нужны пользователям ежедневно.
Картина на стене и правильно выбранный инструмент
Чтобы повесить картину на бетонную или кирпичную стену, нужно подобрать инструмент для сверления, подходящий крепёж и размер отверстия с учётом стены и нагрузки.
Если вместо этого предложить крошечный гвоздь или промышленный отбойный молоток, проблема будет в соответствии инструмента задаче. В первом случае подходящего отверстия не получится, во втором вмешательство окажется несоразмерным.
С программами похожая история. Количество функций и масштаб бренда сами по себе не отвечают на вопрос, решит ли система вашу задачу приемлемым способом и с понятными затратами.
Проверяйте стоимость рабочего решения
Цена лицензии или первоначальной разработки — только часть расходов. Перед выбором стоит отдельно оценить:
- обследование и настройку процессов;
- подготовку справочников и перенос данных;
- интеграции и доработки;
- обучение и время сотрудников на участие в проекте;
- инфраструктуру, обновления и сопровождение;
- дальнейшие изменения и возможность выгрузить данные при смене системы.
Не каждый пункт обязательно потребует крупных затрат. Важно, чтобы его проверили, а не обнаружили после подписания договора. Например, стоит выяснить, сохраняются ли доработки при обновлениях и кто оплачивает восстановление совместимости.
Какие вопросы задать поставщику до покупки
Просите ответы на примере ваших данных и операций. Для обсуждения подойдут такие вопросы:
- Покажите наш основной процесс целиком. Где заканчиваются стандартные возможности и начинается доработка?
- Как обрабатываются исключения? Что произойдёт при частичном выполнении, браке, возврате или ошибочном вводе?
- Что входит в расчёт стоимости? Какие лицензии, модули, интеграции и работы учтены, а какие оплачиваются отдельно?
- Что потребуется от нас? Кто готовит данные, принимает решения и проверяет результат? Сколько участия нужно от подразделений?
- Как проверить работу в наших условиях? Можно ли провести пилот на согласованном участке с характерными данными, оборудованием и нагрузкой?
- Как будут приниматься работы? Какие сценарии должны пройти проверку и что считается дефектом?
- Что произойдёт после обновления или изменения процесса? Кто отвечает за совместимость и как оцениваются новые работы?
- Как устроены поддержка и восстановление? Куда обращаться, когда доступен исполнитель и как проверяются резервные копии?
- Как выйти из решения? Какие данные, документы, доступы и права останутся у предприятия?
Ответы удобно свести в таблицу: «требование — стандартная функция — настройка — доработка — ограничение — стоимость — способ проверки». Если ответ пока неизвестен, это должно быть видно до принятия решения.
Что делать, если внедрение уже не удалось
Сначала отделите причины от последствий. Отсутствие нужной функции, ошибки миграции, неготовые данные, непродуманный процесс и отсутствие обучения требуют разных действий. Замена программы не устраняет их автоматически.
Сохраните то, что работает. Неудачный проект не обязательно означает, что всё нужно выбросить. Иногда достаточно исправить интеграцию, заменить отдельный модуль или упростить участок процесса. Иногда замена действительно обоснована — но это вывод обследования, а не отправная точка.
Выберите ограниченный участок для проверки. Согласуйте сценарии, данные, участников и критерии результата. Например, можно проверить прохождение заказа через определённый участок или точность выполнения складских операций. Показатель должен отражать рабочую задачу, а исходное состояние — быть зафиксировано до пилота.
Принимайте решение по наблюдаемому результату. Пилот должен помочь ответить, пригодна ли система для процесса и что потребуется для расширения. Успешная демонстрация интерфейса сама по себе для этого недостаточна.
Коробка или индивидуальная разработка?
Если процесс близок к стандартному, подходящая готовая система может быть рациональным выбором. Индивидуальную разработку имеет смысл рассматривать, когда существенные правила предприятия плохо укладываются в доступные продукты, а стоимость обходных решений и доработок становится значимой.
При этом у заказного ПО есть свои риски: сроки, ошибки проектирования, зависимость от исполнителя, необходимость сопровождения. Их нужно оценивать так же внимательно, как ограничения коробки. Отдельно стоит обсудить передачу кода и документации.
Я начинаю работу с границ задачи и разбора процесса. Посмотреть, для каких ситуаций подходит такой формат, можно на странице о выборе подхода к автоматизации. Для производственных и складских задач есть отдельные разделы MES и WMS.
Если у вас уже был неудачный опыт, начнём с него. Для первого разговора полезно описать исходную задачу, используемую систему, оставшиеся ручные операции и то, что не удалось получить. Это поможет обсуждать причины и возможные действия предметно. Обсудить ситуацию.
При выборе подрядчика важно проверить ресурсы, приёмку и сопровождение. Подробнее — в статье об оценке ИП и ООО как исполнителей. О том, как я определяю границы проекта, — на странице о подходе «Контура Логики».