Сколько стоит разработка CRM

Почему количества экранов недостаточно

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

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

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

Первый этап стоит описывать через один рабочий процесс и его участников. Разработка CRM и ERP

Что сильнее всего влияет на объём

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

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

Как выделить первый самостоятельный модуль

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

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

Не каждой задаче нужна полноценная CRM: иногда достаточно отдельного приложения. Веб-приложения и внутренние инструменты

Какие расходы обсудить кроме разработки

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

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

Разбор первого модуля на примере заявки

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

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

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

Результат этапа можно принять на этом же примере: создать заявку, назначить мастера, перенести визит и завершить работу. Так проверяется рабочий маршрут вместе с правами и исключениями, а не только наличие экранов

Почему перенос данных бывает отдельной задачей

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

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

Объём этой работы зависит не только от числа строк. Чистую однотипную таблицу и несколько противоречащих друг другу файлов нельзя оценивать одинаково. Для предметной оценки достаточно сначала показать структуру и обезличенные примеры проблемных записей

Что должно быть понятно в оценке CRM

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

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

• Границы: с какого события начинается процесс и каким результатом заканчивается
• Участники: кто получает, меняет и подтверждает сведения
• Исключения: возврат, отмена, повторная заявка и сбой обмена
• Приёмка: какие сценарии сотрудники пройдут на проверочных данных
• Эксплуатация: кто поддерживает систему, данные и подключения после запуска

Мой опыт разработки систем для команды

Я разрабатывал системы для учёта, торговли и командной работы. Работал с данными, задачами сотрудников и взаимодействием отделов. Эти направления опыта представлены в моём портфолио

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

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