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