Чек-лист для приемки работ по автоматизации учета: как понять, что компания-интегратор выполнила ТЗ

До 40% проектов по автоматизации учета в торговле завершаются с фактическим недовыполнением ТЗ, что выявляется только после полной оплаты и ухода интегратора. Приемка — это не формальная подпись акта, а жесткий стресс-тест системы, где цена ошибки в логике списания остатков может стоить компании от 200 000 до 1,5 млн рублей ежемесячных потерь из-за пересорта и воровства.

Верификация бизнес-процессов через сквозные сценарии

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

В моей практике был кейс, когда при приемке торговой сети запчастями выяснилось, что система не учитывала комплекты (kit-товары) при частичном возврате: списывался весь набор, а на склад возвращалась одна позиция. Ошибка в коде стоила клиенту 450 000 рублей за первый месяц эксплуатации. Экспертный вывод: приемка считается пройденной только после успешного выполнения 15-20 критических сквозных сценариев, описанных в ТЗ.

Контроль точности данных и скорости отчетов

Производительность системы при реальном объеме данных — главный камень преткновения. Если база содержит 50 000+ SKU и 100 000 транзакций в месяц, формирование отчета по прибыли и убыткам (P&L;) не должно занимать более 30-60 секунд. Время ожидания в 5-10 минут делает систему непригодной для оперативного управления и свидетельствует о некорректных индексах в базе данных.

Проверьте точность до копейки: сравните остатки по складу в новой системе с данными ручного или старого учета на дату среза. Допустимая погрешность — 0%. Любое расхождение в 1 единицу товара или 1 рубль говорит о дыре в алгоритме проведения документов. Мой вердикт: если отчеты «тормозят» или данные плавают, переходить к этапы работы профессионального интегратора: от аудита складских остатков до запуска системы в эксплуатацию нельзя до полной оптимизации запросов.

Проверка прав доступа и безопасности данных

Типичная ошибка — настройка прав по принципу «всем всё». При приемке проверьте матрицу доступа: кладовщик не должен видеть маржинальность товара или зарплату директора, а менеджер по продажам не может менять цены в карточке товара без согласования. В торговых компаниях СПб с штатом от 20 человек отсутствие разграничения прав приводит к утечке клиентских баз в 70% случаев в первый год работы.

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

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

Система без инструкции — это набор иконок. Требуйте «Пользовательский регламент», где описаны действия при нестандартных ситуациях (например, пересортица при приемке от поставщика), а не простое руководство по интерфейсу. Стоимость разработки качественной документации обычно составляет 5-10% от общего бюджета проекта, и ее отсутствие — повод для удержания финального платежа.

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

Вывод

Приемку работ нужно начинать с жесткого сопоставления фактического функционала с пунктами ТЗ, используя метод «черного ящика» (проверка результата, а не процесса). Избегайте подписания актов «под честное слово» о доработках в течение месяца — это гарантированный способ остаться с недостроенным софтом. Рекомендую удерживать 10-15% от общей стоимости контракта до завершения периода опытной эксплуатации (обычно 30 дней). Если вы еще на этапе выбора, обязательно изучите KPI для компании по автоматизации учета: какие показатели эффективности прописать в договоре для гарантии результата, чтобы иметь рычаги давления при приемке.