Отдельный этап до разработки
Предпроектное обследование бизнес-процессов
Согласуем, как должна работать корпоративная система и по каким сценариям её принимать.
Для операционного директора и руководителя закупки: мы разбираем процессы, роли и действующие системы. Вы получаете схему работы, требования, границы первой версии и предварительную оценку разработки с допущениями.
Наш опыт связанных систем: Бакаев — приложение, админ-панель и 1С.
Для начала покажите один процесс, участников, таблицы и системы, которыми пользуется команда.
01 / Результат обследования
Материалы, по которым можно
обсуждать реализацию
Обследование можно заказать самостоятельно. До начала работ согласуем процессы и глубину проработки: от модели работы до подробного технического задания на систему автоматизации.
- 01Схема процесса и владельцы
- Как работа идёт сейчас, как должна идти после изменений, кто подтверждает правила и принимает решения по исключениям.
- 02Роли и данные
- Кто создаёт, видит, меняет и согласует записи. Где ведутся справочники, какие поля обязательны и как связаны документы.
- 03Интеграции и ограничения
- Какие системы остаются, что передают друг другу, кто отвечает за подключение. Проверенные возможности отделяем от вопросов, требующих эксперимента.
- 04Требования и приёмка
- Функции, правила, состояния и ожидаемые результаты проверок. Требование связываем с процессом и сценарием испытания.
- 05Первая версия и оценка
- Согласованный объём запуска, отложенные функции, состав работ и допущения по данным, доступам и участию вашей команды.
Передаём редактируемые схемы и требования, а также версию для чтения. Форматы и право использовать материалы с другим подрядчиком закрепляем в договоре. Реализацию и поддержку оцениваем отдельными работами.
02 / Демонстрационный пример
От заявки на закупку
до решения руководителя
Допустим, сотрудники собирают потребности в таблице, менеджер сверяет товары с учётом, а руководитель согласует закупку в переписке. Мы прослеживаем одну заявку, а затем описываем её маршрут в целевой системе.
- Входные данные
Сотрудник создаёт заявку
Организация, подразделение, позиции, количество и основание закупки. За справочник товаров отвечает владелец учётной системы.
- Проверка
Менеджер уточняет состав
Система проверяет обязательные поля. Менеджер возвращает заявку с причиной, если позиции или реквизиты требуют уточнения.
- Решение
Руководитель согласует
Видит заявку своего подразделения и принимает решение. Порядок согласования в зависимости от суммы, правила замещения и повторного согласования уточняем у владельца процесса.
- Результат
Отдел закупок получает согласованную заявку
Команда видит согласованный состав, ответственного и историю. Передачу в учёт описываем отдельным требованием с проверкой ответа системы.
Фрагмент требований · условный сценарий
Права на согласование
Требование R-07. Инициатор создаёт заявку и видит её статус. Руководитель согласует заявки своего подразделения. Право на согласование проверяется на сервере при каждой операции.
Проверка A-07. Войти как инициатор и попытаться согласовать заявку прямым запросом. Ожидаем отказ; статус и история решения сохраняются без изменения. Руководитель другого подразделения также получает отказ. Руководитель своего подразделения может согласовать заявку; статус и история отражают его решение.
Исключения меняют требования
- Руководитель отсутствует: кто вправе его замещать?
- Количество изменили после согласования: нужно ли новое решение?
- Учёт недоступен: кто видит ошибку и как повторяет передачу?
Решения фиксируем вместе с владельцем процесса. По ним уточняем объём первой версии и сценарии приёмки.
03 / Границы проекта
Сначала определим
один рабочий процесс
Для примера закупки в первую версию можно включить создание, проверку, согласование и передачу заявки в учёт. Автоматический выбор поставщика и прогнозирование потребностей потребуют своих данных и правил; их оцениваем отдельно.
При проектировании CRM, ERP и личного кабинета сначала сравниваем варианты на одном сценарии. Проверяем, где достаточно настройки готового продукта, где нужен отдельный модуль, а где оправдана заказная система.
Что уточняем до оценки разработки
- Источник данных
- В какой системе ведутся товары, организации и статусы; кто может их менять.
- Доступ и обмен
- Версии систем, документация интерфейсов, тестовая среда и участие их владельцев.
- Условия работы
- Объёмы записей, одновременная работа, допустимая задержка и действия при сбое.
- Передача и сопровождение
- Кто получит код и документацию, где разместят систему и кто отвечает за поддержку после запуска.
04 / Подтверждённый опыт
Проектируем с учётом
связей между системами
В наших проектах бизнес-сценарий проходит через несколько интерфейсов. Этот опыт помогает находить зависимости, которые нужно описать до разработки.
Бакаев: приложение, админ-панель и 1С
Мы связали мобильный магазин, админ-панель и 1С через сервер синхронизации. Фото, изменённое в админ-панели, отражается в 1С. Заказ в приложении меняет остатки в админ-панели и 1С; изменения из учёта доходят до приложения.
Для нового проекта заранее определяем источник каждого поля и ожидаемый результат обмена. Скорость обновлений и правила обработки конфликтов согласуем по его условиям.
Открыть кейс Бакаева ↗Malling: отдельный инструмент рядом с CRM
Мы сделали инструмент CRM-коммуникаций рядом с Битрикс24 и amoCRM. В обследовании вашего процесса проверим, можно ли сохранить действующую систему и добавить нужный модуль. Посмотреть Malling ↗
05 / Работа и оценка
Объём обследования
виден в предложении
Цена и срок зависят от числа процессов, подразделений и ролей, доступности материалов и глубины технической проверки. В предложении отдельно показываем изучение процесса, проектирование, проверку зависимостей и подготовку документов.
Предварительная оценка разработки включает допущения и открытые вопросы. Если неизвестен интерфейс учётной системы или качество исторических данных, сначала согласуем способ проверки этой зависимости.
Чтобы сравнить команды до договора, попросите разобрать один и тот же сценарий, назвать результат обследования, порядок его приёмки и условия передачи материалов. Кейсы должны подтверждать именно заявленные связи и функции.
Собираем исходные материалы
Владелец процесса, сотрудники с каждой ролью и специалисты действующих систем показывают обычную операцию и исключения. Начать можно с обезличенных таблиц и документов.
Согласуем модель работы
Мы описываем текущий и целевой процесс, данные и права. Ваша команда подтверждает правила и решения по спорным ситуациям.
Передаём пакет на приёмку
Проверяем с вашей командой: все согласованные роли и переходы описаны, у требований есть критерии проверки, у оценки — состав, исключения и допущения.
До договора
Вопросы о заказе обследования
Можно заказать обследование без разработки?
У нас уже есть ТЗ. С чего начнём?
Что входит в подробное техническое задание?
Как принимаются результаты обследования?
Можно работать удалённо из Москвы или Санкт-Петербурга?
Покажите один процесс
Расскажите, кто участвует, где хранятся таблицы и какие системы уже работают. Мы уточним состав обследования, предложим границы первой версии и определим данные для предварительной оценки.