Как провести демонстрацию 1С, после которой можно принять решение

Начните с вопроса, на который должна ответить встреча

Демонстрация часто заканчивается словами «выглядит интересно», но через неделю команда всё ещё не понимает, подходит ли продукт. Причина обычно в том, что участники оценивали разные вещи. Руководителю нужен контроль исполнения, оператору — удобный ввод, администратору — совместимость.

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

Например: увидит ли диспетчер необработанную приёмку, сможет ли кладовщик исправить фактическое количество, откуда руководитель узнает о расхождении.

Опишите процесс через начало, действие и результат

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

Где останется недопоставка? Что увидит менеджер продаж? Такая история сразу задаёт маршрут показа.

Полезно подготовить две версии: обычную и проблемную. Обычная показывает базовую последовательность, проблемная — поведение системы при отклонении. Не пытайтесь за одну встречу проверить все подразделения.

Выберите сценарий, который достаточно часто повторяется и заметно влияет на работу. Тогда участники смогут сравнивать показанное со своим опытом, а не оценивать абстрактную функциональность.

Подготовьте небольшой обезличенный набор данных

Для содержательного разговора не нужна выгрузка всей рабочей базы. Обычно достаточно нескольких строк с типичными товарами, условными контрагентами, датами и суммами. Сохраните особенности, которые влияют на задачу: разные единицы измерения, частичную оплату, несколько мест хранения или перенос срока.

Коммерческие условия, персональные сведения и реальные банковские реквизиты замените вымышленными. Подпишите, какие данные условные, а какое правило должно остаться неизменным. Если пример содержит две валюты, не объединяйте их в одну колонку без пояснения.

Если важна история изменений, добавьте последовательность событий. Чем аккуратнее пример, тем меньше времени уйдёт на выяснение того, что именно означает каждая строка.

Пригласите людей, которые выполняют и принимают работу

Минимальный состав — владелец процесса, будущий пользователь и специалист, который отвечает за 1С. Руководитель определяет ожидаемый результат, пользователь проверяет повседневные действия, администратор уточняет ограничения среды. Заранее назначьте одного ведущего со стороны заказчика: он удерживает сценарий и фиксирует открытые вопросы.

Отдельный человек может вести короткий протокол. Не превращайте встречу в спор о том, какой отдел важнее. Если возникает новый процесс, запишите его в список следующего этапа.

Для каждого вопроса полезно указывать автора и того, кто примет ответ. Это избавляет от ситуации, когда после показа выясняется, что ключевой участник не согласен с общей оценкой.

Попросите пройти путь целиком

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

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

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

Проверьте неудобный сценарий, а не только успешный

Возьмите один сбой, который действительно случается: пользователь не имеет прав, товар принят частично, документ перепроведён или обещание оплаты перенесено. Посмотрите, как это отражается в системе и можно ли объяснить результат другому сотруднику. Важно увидеть возможность восстановления: кто исправляет данные, сохраняется ли причина изменения, как команда понимает, что вопрос закрыт.

Не требуйте мгновенного ответа на любую комбинацию условий. Если вопрос требует проверки на копии вашей базы, запишите его как условие пилота. Честное «проверим на стенде» лучше уверенного обещания без демонстрации.

У каждого такого пункта должны быть срок ответа и понятное доказательство результата.

Обсудите совместимость и состав поставки отдельно

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

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

Это позволит сравнивать варианты по одинаковому объёму и объяснять бюджет внутри компании без дополнительных догадок.

Составьте короткую матрицу проверки

Для каждого важного требования используйте четыре поля: рабочий пример, ожидаемый результат, что показано, что осталось проверить. В строке «частичная приёмка» ожидаемый результат можно описать так: принятый товар доступен на складе, остаток заявки виден отдельно, решение о закрытии принимает назначенный сотрудник. Не пишите «удобно» или «быстро» без пояснения.

Удобство лучше раскрыть через число обязательных действий и возможность найти незавершённую операцию. Скорость — через измеряемое время на согласованном стенде. Матрица не обязана быть большой: десять содержательных строк дают больше пользы, чем сотня функций без контекста.

В конце встречи пройдите по ней вместе и устраните разные трактовки.

Завершите встречу конкретным следующим шагом

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

Не подменяйте решение приглашением «давайте ещё созвонимся». Хороший итог демонстрации помещается на одной странице: задача, показанный маршрут, ограничения, состав предложения и следующий шаг. Сохраните запись встречи, если участники согласовали запись, и приложите протокол к заявке.

Через месяц команда должна суметь восстановить, почему выбрала продукт и какие вопросы сознательно оставила на этап внедрения.

Что отправить перед демонстрацией

• Название конфигурации, релиз, версию платформы и описание доработок.
• Один обычный и один проблемный сценарий с обезличенными данными.
• Роли участников и ожидаемый результат каждого сценария.
• Список обязательных условий и вопросов, которые нельзя перенести на запуск.
• Контакт человека, который подтвердит итог встречи и согласует пилот.

Для знакомства с решениями АСБИЗ выберите продукт в каталоге и укажите этот сценарий в запросе демо. Команде будет проще подготовить содержательный показ, а вам — сравнить увиденное с задачей бизнеса.