Опт до сих пор продаётся почтой. Приходит письмо: «нужны позиции такие-то, подтвердите наличие и цену». Менеджер открывает 1С, ищет клиента, смотрит его скидку по договору, проверяет остаток, отвечает письмом, согласовывает правки, а потом вбивает заказ руками. Двадцать заявок в день — это полтора человека, занятых перепечатыванием. Рано или поздно директор смотрит на это и говорит: сделаем личный кабинет, пусть заказывают сами. И почти сразу называет срок — «месяц, ну два».
Дальше — про то, из чего этот месяц складывается в действительности.
«Личный кабинет» — это пять разных проектов
Под одним словом заказчики держат в голове очень разные вещи, и разброс между ними огромный.
- Окно со статусами. Клиент заходит и видит, какие заказы приняты, что отгружено, что в пути. Данные подтягиваются из вашей учётной программы, менять на сайте ничего нельзя.
- Статусы и документы. Туда же складываются счета, накладные, акты. Бухгалтерия клиента перестаёт писать «пришлите ещё раз, потерялось».
- Заказ по персональному прайсу. Здесь всё меняется: появляются цены по договору, скидочные матрицы, кратность упаковки, минимальная сумма отгрузки, резерв товара под заказ.
- Деньги и роли. Оплата, дебиторка, лимит отгрузки и разные права для сотрудников клиента: закупщик видит цены, кладовщик — только отгрузки.
- Портал целиком. Загрузка заказа из Excel, повтор прошлой поставки, согласование спецификаций, рекламации, расчёт доставки.
Между первой ступенью и пятой разница не в полтора раза, а примерно в десять. Поэтому разговор о сроках без ответа на вопрос «какая из пяти» бессмыслен: любая цифра будет угадыванием.
Видимая часть — меньшая часть работы
Клиент видит список товаров, поле поиска, кнопку и корзину. Выглядит как обычный интернет-магазин — отсюда и ощущение, что работы немного.
Возьмём одну строчку — цену. Персональная цена в опте почти никогда не лежит готовым числом. Это набор правил: у клиента А двенадцать процентов на группу «светильники», у клиента Б фиксированный прайс из приложения к договору, у клиента В цена зависит от выбранного за месяц объёма, а у клиента Г действует старое соглашение, о котором знает только один менеджер. Правила существуют, но живут в учётной программе и в головах людей. Прежде чем показать цену на сайте, их приходится вытащить наружу до последней оговорки — и это работа не программиста, а разбор процессов вместе с вашим коммерческим отделом.
То же с остатками. Показать «в наличии» честно можно только тогда, когда понятно, откуда берётся число и насколько оно свежее. Мы ведём каталог на 400 000 позиций, где обмен с 1С шёл по расписанию: между выгрузками на витрине висели вчерашние цены, и клиент успевал заказать то, чего уже нет. Лечилось это не кнопкой в настройках, а отдельной программой, которая держит свежую копию цен и остатков и отдаёт их сайту даже в тот момент, когда 1С недоступна.
По нашему опыту, то, что видно глазами, — это примерно треть работы. Остальное — расчёт цен, права доступа, связка с учётной системой и та часть, которую замечают, только когда она сломалась.
Откуда берутся месяцы
Если разложить портал третьей-четвёртой ступени по этапам, картина выходит такая.
- Разбор процессов и проектирование — 2–4 недели. Кто заказывает, как считается цена, что происходит при частичной отгрузке, кто утверждает превышение лимита. Половина этого времени уходит не на нас, а на ваших сотрудников: вопросы задаются им.
- Прототип и дизайн — 2–3 недели. Сначала кликабельный черновик без картинок, потом внешний вид.
- Разработка — 6–12 недель, кусками по одной-две недели, с показом работающей версии на тестовом адресе после каждого куска.
- Связка с 1С — от 2 до 6 недель, и это самая непредсказуемая часть: всё зависит от состояния учётной программы и наличия у неё своего специалиста.
- Перенос данных, проверка и запуск — 2–3 недели.
Складывается три-пять месяцев, а не месяц. Причём часть срока вообще не в руках разработчиков: ждём доступ к учётной системе, ждём решения о том, кто владеет правилами ценообразования, ждём, пока вернётся из отпуска человек, который единственный помнит логику старых договоров. На проектах, где такие ответы приходят за сутки, работа идёт заметно быстрее.
Кто в этом участвует
Портал не делает один человек, и вот почему. Нужен тот, кто рисует и продумывает экраны, чтобы закупщик находил нужное без обучения. Нужен тот, кто пишет невидимую часть: расчёт цен и скидок, заказы, права доступа. Нужен тот, кто делает страницы, кнопки и корзину. Нужен человек по серверам — обновления, резервные копии, слежение за тем, что сайт работает ночью и в распродажу. Нужен проверяющий, который до выпуска пройдёт сценарии вроде «клиент с просрочкой платежа пытается оформить заказ». И нужен тот, кто держит все эти нитки вместе и разговаривает с вами, — проджект-менеджер, роль которого мы уже разбирали отдельно.
Это не значит, что в проекте шесть человек на полной занятости. На среднем портале один разработчик закрывает и видимую, и невидимую часть, дизайнер приходит на пару недель, специалист по серверам — на несколько дней и потом эпизодически. Бывает и вариант «один человек-оркестр», и он честно работает на первой-второй ступени: там немного правил и нет связки с учётной программой. На третьей ступени такой формат начинает подводить — не из-за квалификации, а потому что один человек становится единственной точкой отказа: заболел, ушёл, потерял интерес — проект встал, и разбираться в его коде некому.
Где ожидание расходится с результатом
Главный риск в таких проектах — не «сделают плохо», а «сделают не то». Портал получается работающим, аккуратным и мимо процесса.
Расхождение почти всегда растёт из трёх мест. Первое — формулировка «сделайте как у конкурента»: у конкурента другие договоры, другая номенклатура и, возможно, другая беда. Второе — приёмка по картинке: макет утвердили, а сценарий возврата и частичной отгрузки никто не проговорил, потому что на картинке его не было. Третье — проверка на выдуманных данных: на «Товаре 1» всё летает, а на настоящем каталоге с артикулами в кириллице и позициями без остатка вылезает половина проблем.
Лечится это скучными вещами. Кликабельный черновик до начала разработки — по нему видно, чего не хватает, и правка стоит часы, а не недели. Показ работающей версии каждые одну-две недели вместо большого показа в конце. Написанный простыми словами список «что должно работать»: конкретные ситуации, а не «удобный интерфейс». Проверка на выгрузке настоящих данных. И один человек с вашей стороны, который принимает решения, — иначе три отдела правят друг друга по кругу, а сроки съедаются согласованиями.
Цена ошибки здесь измеряется просто. Портал, которым клиенты не пользуются, ничего не экономит: менеджеры продолжают вбивать заявки руками, а к их работе добавляется поддержка системы, в которую никто не заходит.
Когда портал делать рано
Отдельная разработка нужна не всем. Если постоянных клиентов пятнадцать и каждый заказывает раз в квартал, ручная обработка обходится дешевле любого портала, и честнее так и посчитать. Если правила ценообразования простые — общий прайс и три уровня скидки, — стоит сначала посмотреть готовые решения: коробочные B2B-модули и надстройки над учётной системой запускаются быстрее и стоят кратно меньше. Ограничение у них одно, зато существенное: как только ваши правила перестают укладываться в шаблон, начинается борьба с продуктом, и переделка выходит дороже, чем разработка с нуля.
Работает и промежуточный шаг: сделать сначала окно со статусами и документами, без заказа. Это недели работы, а не месяцы, и оно сразу снимает ощутимую долю звонков «где мой заказ». Заодно видно, заходят ли клиенты вообще, — лучший аргумент за или против следующей ступени. У разработки под конкретный процесс минусы тоже есть: выше входная стоимость и нужен кто-то, кто будет вести систему дальше, потому что живой портал требует изменений вслед за бизнесом.
На что смотреть в первую очередь
Прежде чем обсуждать сроки и бюджет, ответьте себе на три вопроса:
- Какую именно ручную работу вы убираете и сколько часов в неделю она сейчас занимает.
- На какой из пяти ступеней находится нужный вам кабинет.
- Кто со стороны компании сможет за неделю выдать правила расчёта цены в письменном виде.
Ответы на них влияют на срок сильнее, чем выбор подрядчика и технологий.
И держите в голове простую пропорцию: чем больше времени ушло на разбор процессов до начала работы, тем меньше его уходит на переделки после запуска. Экономия на первом этапе — самая дорогая из возможных.
