Практические разборы о внедрении, автоматизации и порядке в бизнес-процессах
Чек-лист для заказчика: участники, данные, интеграция, приёмка и обучение. Помогает отделить доступ к сервису от работающего процесса.
#разборы
Купили SaaS, но процесс не заработал: что согласовать до внедрения
Редакция ИЗИ Контроль · 26 сентября 2026
Доступ есть — что должно произойти дальше?
После покупки сервиса у сотрудников могут появиться учётные записи, но прежние таблицы и переписки никуда не исчезнут. Сам факт подключения не определяет, кто создаёт документ, где его согласуют и какое действие завершает работу.
До настройки полезно описать один повторяющийся процесс. Например: сотрудник создаёт заявку, руководитель проверяет её, исполнитель выполняет действие, а заявитель получает результат. Это условный пример, не описание клиентского проекта.
Главный вопрос: какое изменение в ежедневной работе должно произойти и кто сможет его проверить?
Что согласовать до внедрения
Четыре раздела: роли и данные, границы и приёмка, обучение и готовность к запуску.
1. Назначьте владельца результата
У процесса должен быть сотрудник, который может согласовать правила и разрешить спор между участниками. Его задача — не обязательно выполнять все операции. Он подтверждает, что новый порядок подходит бизнесу.
Для каждого действия запишите исполнителя и замену. Если согласующий отсутствует, процесс не должен зависеть от поиска случайного человека, который «тоже умеет нажать кнопку». Возможность замещения и права проверяют при настройке.
2. Определите источник данных
Если одни и те же реквизиты ведутся в нескольких местах, договоритесь, какое из них основное. Затем выясните, кто исправляет ошибку и как изменение попадёт в остальные системы.
Интеграция не решает автоматически, какое значение верное. До обмена полезно составить таблицу «поле — источник — ответственный». Не нужно описывать все данные компании: начните с тех, без которых не проходит выбранный сценарий.
3. Отделите стандартную настройку от доработки
Перечислите необходимые действия пользователя. Затем сопоставьте их с возможностями выбранного сервиса и вашей конфигурации. То, что показали на демонстрации, может требовать другого тарифа, версии или дополнительной настройки — эти условия нужно проверить до оценки.
Запишите, что входит в первую очередь, а что обсуждается отдельно. Иначе пожелание «было бы удобно» незаметно превращается в ожидание, что функция уже включена в договорённость.
4. Согласуйте приёмку на примере
Формулировка «всё работает» плохо помогает при споре. Лучше описать проверку: пользователь создаёт согласованный документ, данные поступают из нужного источника, следующий участник видит задачу, итог доступен ответственному.
Добавьте существенное исключение: неполные данные, возврат на исправление или отсутствие согласующего. Какие исключения входят в работы, решают заранее. Система не обязана обрабатывать любой мыслимый случай, чтобы первый этап имел понятную ценность.
5. Проверьте самостоятельную работу сотрудника
Просмотр демонстрации и способность повторить действие — разные результаты. После обучения предложите пользователю пройти свой сценарий и найти результат без подсказки на каждом шаге.
Проверьте также, знает ли он, куда обращаться при ошибке. Инструкция должна помогать выполнить конкретное действие, а не повторять весь интерфейс продукта.
6. Договоритесь о работе после запуска
Определите, кто собирает вопросы, кто исправляет данные, кто занимается техническими сбоями и как согласуются новые пожелания. Период и состав сопровождения фиксируют отдельно; не стоит считать любую дальнейшую работу автоматически включённой.
У процесса есть владелец, исполнители и замены.
Источники критичных данных определены.
Первая очередь и исключения описаны.
Способ интеграции проверен для конкретной системы.
Приёмка основана на наблюдаемых действиях и результате.
Пользователи знают свой сценарий и порядок помощи.
Границы запуска и сопровождения согласованы.
Этот список — практическая рекомендация, а не обещание определённого срока или экономии. Он помогает сделать ожидания проверяемыми до начала проекта.
Следующий шаг: опишите один процесс, который пока не заработал в сервисе. Обсудим, что мешает: правила, данные, настройка, обмен или готовность пользователей. Обсудить задачу: оставьте описание через форму ниже.