Подробное описание всех этапов разработки ERP: аналитика, проектирование, разработка, тестирование, внедрение. Сроки и что происходит на каждом шаге.
Многих пугает разработка ERP с нуля — кажется что это непрозрачный процесс в котором легко потерять контроль. На самом деле хорошо организованный проект имеет чёткую структуру этапов, каждый из которых заканчивается конкретным осязаемым результатом.
Этап 1: Предпроектная аналитика (2–3 недели)
Что происходит: аналитик изучает ваши процессы — проводит интервью с руководителями и ключевыми пользователями, изучает текущие инструменты и документы, составляет карту процессов.
Результат: описание текущих процессов, список требований к системе, первоначальная оценка объёма работ.
На этом этапе часто обнаруживается что некоторые «проблемы» решаются реорганизацией процессов, а не разработкой. Это экономит деньги.
Этап 2: Проектирование (3–4 недели)
Что происходит: составляется техническое задание, разрабатываются прототипы интерфейса (wireframes), проектируется архитектура базы данных, описывается API.
Результат: согласованное ТЗ, прототипы экранов, план разработки с разбивкой по спринтам.
Ваше участие: активное. Нужно согласовать прототипы, утвердить ТЗ. Это лучший момент для правок — пока код не написан, изменения бесплатны.
Этап 3: UI/UX дизайн (2–3 недели параллельно с разработкой)
Что происходит: дизайнер создаёт финальные макеты на основе прототипов. Цветовая схема, компоненты, адаптивность для разных устройств.
Результат: дизайн-система и макеты всех экранов в Figma.
Этап 4: Разработка итерациями (основной этап)
Что происходит: разработка ведётся спринтами по 2 недели. Каждый спринт — новый пакет функционала. После каждого спринта — демонстрация и возможность дать обратную связь.
Ваше участие: участие в демонстрациях раз в 2 недели, оперативные ответы на вопросы команды. Задержки ответов с вашей стороны — задержки в проекте.
Этап 5: Тестирование (2–3 недели)
Что происходит: функциональное тестирование (работает ли каждая функция), интеграционное тестирование (работают ли системы вместе), нагрузочное тестирование (выдержит ли система реальную нагрузку), пользовательское тестирование (удобно ли работать).
Ваше участие: приёмочное тестирование — ваши сотрудники работают в системе и выявляют проблемы.
Этап 6: Миграция данных и развёртывание (1–2 недели)
Перенос данных из старой системы, настройка продакшн-сервера, финальное тестирование в боевой среде.
Этап 7: Обучение и запуск (1–2 недели)
Обучение пользователей, создание инструкций, постепенный переход от старой системы к новой. Первые 2–4 недели работы в продакшн — усиленная поддержка от команды разработки.
Общая схема сроков
| Этап | Небольшая CRM | Средняя ERP | Полная ERP |
|---|---|---|---|
| Аналитика + проектирование | 3–4 нед. | 5–7 нед. | 7–10 нед. |
| Дизайн | 2–3 нед. | 3–4 нед. | 4–6 нед. |
| Разработка | 2–3 мес. | 4–6 мес. | 6–10 мес. |
| Тестирование | 1–2 нед. | 2–3 нед. | 3–5 нед. |
| Запуск | 1 нед. | 1–2 нед. | 2–3 нед. |
| Итого | 3–4 мес. | 5–8 мес. | 8–14 мес. |
Часто задаваемые вопросы
Можно ли ускорить разработку?+
До определённого предела — да, через параллельную работу нескольких команд. Но «9 женщин не родят ребёнка за месяц» — некоторые вещи нельзя распараллелить. Попытка ускорить сверх меры приводит к росту числа ошибок.
Что происходит если я не успеваю давать обратную связь?+
Разработка тормозит. Ваша вовлечённость — такой же ресурс как бюджет. Заложите время в рабочий график: минимум 2–3 часа в неделю на работу с командой разработки.
Как часто нужны встречи с командой?+
В активной разработке: синхронизация раз в неделю (20–30 минут) + демонстрация по итогам каждого спринта (1 час). Этого достаточно.
Можно ли менять требования в процессе разработки?+
Да, но это влияет на сроки и стоимость. Изменения в аналитике — бесплатно. Изменения в уже написанном коде — дополнительные работы которые оцениваются отдельно.
Что значит «итерационная разработка» и зачем это нужно?+
Это когда система строится небольшими добавочными шагами, а не «полностью за 8 месяцев и сразу». Каждые 2 недели вы видите работающий функционал и можете корректировать направление. Это снижает риск получить «не то что хотели».
Нужно ли проводить нагрузочное тестирование?+
Если в системе одновременно работают 20+ пользователей — обязательно. Нагрузочное тестирование выявляет узкие места до запуска, а не после, когда исправление обходится дороже.