Административная панель и CRM — это внутренние инструменты, с которыми сотрудники компании проводят рабочий день целиком. От того, как они устроены, зависит скорость обработки заявок, число ошибок в данных и то, насколько руководитель доверяет отчётам. При этом внутренние системы почти всегда проектируют по остаточному принципу: сайт вылизывают, а панель управления собирают из того, что дал шаблон. Ниже — как мы подходим к разработке таких систем и что в них обычно оказывается важнее красоты.
Готовая CRM или своя система
Первый вопрос, который стоит задать до начала разработки: нужна ли вообще своя система. Готовые продукты закрывают типовые процессы продаж дешевле и быстрее любой заказной разработки, и если компания продаёт стандартную услугу по стандартной воронке, разумно начать с них.
Заказная разработка оправдана в других случаях:
- процесс не укладывается в воронку сделок: производство, монтаж, логистика, согласования, работа с подрядчиками;
- нужны расчёты, специфичные для отрасли, — сметы, спецификации, подбор по параметрам;
- система должна работать в связке с уже существующими учётными системами и обменом данными;
- количество пользователей и объём данных делают лицензии готового продукта сопоставимыми со стоимостью разработки;
- требуется хранить данные на своей инфраструктуре по требованиям безопасности или отраслевого регулирования.
Часто правильный ответ — комбинация: продажи ведутся в готовой CRM, а специфическая часть процесса живёт в своей системе, обменивающейся с ней данными.
С чего мы начинаем разработку
Проект начинается не с макетов и не с выбора технологий, а с разбора работы. Мы садимся с теми, кто будет пользоваться системой ежедневно, и разбираем текущий процесс по шагам: откуда приходит задача, кто её берёт, где фиксирует, что делает дальше, где данные переносятся вручную.
Результат этого этапа — описание ролей и сценариев. Роль отвечает на вопрос «кто», сценарий — «что человек делает и в каком порядке». Именно из сценариев вырастает структура разделов, а не наоборот. Панель, спроектированная от структуры базы данных, выглядит логично для разработчика и неудобно для менеджера: чтобы оформить один заказ, приходится открыть четыре справочника. Проектирование и разработку такой панели обычно ведёт постоянный состав — IT-команда под проект, которая помнит принятые решения.
Интерфейс внутренней системы
Требования к интерфейсу админ-панели отличаются от требований к сайту. Здесь не нужно производить впечатление — нужно, чтобы человек выполнял повторяющееся действие максимально коротким путём.
- Основной сценарий — в один-два клика. Если менеджер сто раз в день создаёт заявку, кнопка создания должна быть на виду, а форма — открываться сразу заполненной значениями по умолчанию.
- Списки важнее карточек. Большую часть времени сотрудник смотрит в таблицу. Ей нужны фильтры, сортировка, поиск, сохранение выбранных условий и возможность настроить состав колонок.
- Массовые операции. Смена статуса у двадцати заявок должна делаться выделением, а не двадцатью открытиями карточек.
- Работа с клавиатуры. В системах ввода данных это экономит больше времени, чем любая оптимизация внешнего вида.
- Понятные ошибки. Сообщение должно говорить, что именно не так и что сделать, а не «произошла ошибка».
- История изменений. Кто и когда поменял статус, цену, ответственного. Без этого разбор спорных ситуаций превращается в допрос.
Отдельный вопрос — обучение. Хорошо спроектированная панель не требует инструкции на сорок страниц: названия полей совпадают с тем, как их называют в компании, а порядок действий повторяет привычный процесс.
Модульность и рост системы
Внутренняя система живёт дольше сайта и растёт вместе с компанией. Поэтому её собирают модулями по направлениям работы: учёт клиентов, заявки и сделки, документы, склад, финансы, отчётность. Модуль можно добавить или переделать, не трогая остальные.
Практические следствия такого подхода: новые требования не приводят к переписыванию системы целиком; разные отделы получают разные наборы прав и видят только свою часть; запуск можно разбить на этапы и начать пользоваться первым модулем, пока делаются остальные.
Мы стараемся запускать первый рабочий модуль как можно раньше. Система, которую полгода делают целиком и показывают в готовом виде, почти всегда оказывается не тем, что нужно: за полгода процесс успевает измениться, а пользователи впервые видят интерфейс уже после того, как его невозможно дёшево переделать.
Что делаем и что получает заказчик
| Этап | Что делаем | Что получает заказчик |
|---|---|---|
| Разбор процессов | Интервью с пользователями, описание ролей и сценариев | Схема процесса и список того, что автоматизируется |
| Проектирование | Структура разделов, прототипы основных экранов | Кликабельный прототип до начала разработки |
| Модель данных | Схема сущностей, связей и справочников | Понятная структура, в которую можно добавлять поля |
| Разработка | Модули по очереди, начиная с основного сценария | Рабочая часть системы на раннем этапе |
| Права доступа | Роли, ограничения по разделам и действиям | Сотрудник видит только то, что ему нужно |
| Обмен данными | Интеграция с учётной системой, сайтом, почтой, телефонией | Данные не переносятся вручную |
| Запуск и перенос | Миграция данных, обучение, сопровождение первых недель | Переход без остановки работы |
Права доступа и безопасность данных
Внутренняя система содержит клиентскую базу, цены, условия договоров и персональные данные. Это делает её привлекательной целью и одновременно объектом регулирования.
Базовые вещи, которые мы закладываем по умолчанию: роли с разграничением прав на уровне разделов и действий; журнал действий пользователей; шифрование канала связи; регулярные резервные копии с проверкой восстановления; разделение боевой и тестовой среды; отдельные учётные записи вместо одной общей на отдел.
По персональным данным действуют требования законодательства: их нужно хранить на серверах в России, ограничивать доступ, определять сроки хранения и удалять по истечении надобности. Для системы это означает конкретные технические решения — от выбора площадки размещения до механизма удаления данных клиента по запросу.
Интеграции: где система соединяется с остальным
Внутренняя система редко существует изолированно. Типовой набор связей выглядит так:
- сайт — заявки с форм попадают в систему автоматически, с источником и историей визита;
- учётная система — обмен номенклатурой, остатками, контрагентами и документами;
- телефония — звонки привязываются к клиенту, записи разговоров доступны из карточки;
- почта и мессенджеры — переписка хранится вместе со сделкой;
- складские и логистические сервисы — статусы отгрузок;
- отчётность — выгрузка показателей в понятном руководителю виде.
Каждая интеграция добавляет систему в цепочку зависимостей, поэтому её нужно проектировать с расчётом на сбои: очередь на повтор, журнал обмена, понятное сообщение, когда внешний сервис недоступен.
Отраслевая специфика видна как раз в админке: производственной компании нужны не только сделки, но и заявки в цех, спецификации и сроки выпуска. Такой набор мы закладываем, когда делаем CRM для производства — карточка заказа там доходит до партии продукции, а не заканчивается на счёте.
Если админка нужна не менеджеру, а руководителю — со сводными показателями и отчётами по подразделениям, — это уже разработка управленческой информационной системы.
Типовые ошибки при разработке внутренних систем
- Проектирование от базы данных, а не от работы пользователя.
- Попытка автоматизировать все процессы разом вместо запуска первого модуля.
- Отсутствие представителя пользователей в проекте: требования собирают только у руководителя, а работать будут менеджеры.
- Перенос в новую систему беспорядка из старых таблиц без чистки данных.
- Отсутствие журнала изменений и прав доступа «на потом».
- Игнорирование производительности: интерфейс, удобный на сотне записей, становится непригодным на сотне тысяч.
Мы делаем такие панели и системы на заказ — под процессы конкретной компании, с разбором работы, прототипами и поэтапным запуском. Посмотрите, как устроена разработка информационных систем: CRM, ERP и документооборот, и напишите нам — обсудим вашу задачу и предложим порядок работ.
Такие панели мы и делаем на заказ — под процессы конкретного отдела продаж: разработка CRM-системы. Если задача шире продаж, смотрите разработку информационных систем.
