Как мы создаем свою CRM?

Представьте себе сложный выбор: потратить 10 млн сейчас или понадеяться на свои силы, силы трех программистов, в 20 раз меньший бюджет и 3 месяца работы… И спустя пять лет продолжать «пилить» систему, не добившись нужного для бизнеса результата.

Рассказываем, как вместо покупки готового решения мы начали писать свою CRM и узнали, что, даже «раздув» штат программистов в пять раз, можно не добиться нужного эффекта (спойлер: «эффект Рингельмана» мы испытали на себе).

Мы решили честно рассказать о своих ошибках, чтобы вы не наступали на наши грабли, не изобретали велосипед.

Зачем компании нужна CRM-система? В какой момент пришло понимание, что необходима своя разработка?

Виталий Колготин, CTO:

CRM мы используем с целью оптимизации обработки заявок от клиентов. Возникла необходимость внедрения такой системы, когда прошлый СТО компании Анатолий отметил, что взаимодействие между нашим сайтом и системой «1С» недостаточно эффективно. «1С» сковывает возможности наших сотрудников, которые отвечают за продажи, из-за ограниченного функционала. Нам хотелось сделать к сайту административную панель, которая позволит обрабатывать заявки, в то время как продажи будут осуществляться через систему «1С». CRM нужна для того, чтобы вынести процесс принятия решений в более удобную среду.

Сергей Смелов, генеральный директор:

Мы использовали «1С». В определенный момент в 2017 году, когда понимали, что число заявок будет существенно расти, хотели купить готовое решение (CRM) у одной из отраслевых компаний – и не смогли это сделать. Затем обратились в «Аксиоматику», но их решение показалось слишком дорогим. Оно обошлось бы в районе 10 млн рублей. Важно, что сейчас, спустя годы, мы понимаем: это недорого.

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

Какие функции должна была забрать на себя CRM? Определили ли бюджет, сроки разработки?

Виталий:

Наша задача заключалась в том, чтобы обработка заявок не осуществлялась в системе «1С», а все остальные процессы оставались в рамках этой системы. Для этого были введены дополнительные функциональные возможности, такие как список заявок и карточка заявки, где верификатор мог бы просто нажать кнопку «Да» или «Нет» для принятия решения.

Зачем мы вывели эту функцию из «1С»? Потому что сайт еле работал, когда мы дошли до 40 заявок в системе в день. Нам была нужна другая среда, и конкретная задача для этой среды – принятие решений.

Бюджет на внедрение CRM-системы мы заложили в районе 500–550 тысяч рублей. Срок – полгода. Летом 2017 года мы начали работу, к январю начали обрабатывать заявки, одновременно сидя и в «1C», и в новой CRM. Так было первые два месяца, после чего из «1С» полностью ушел последний верификатор.

Сергей:

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

Виталий:

Я помню, когда ты позвонил мне в конец 2021 года и сказал: «Если мы не достигнем определенного уровня продаж, то можно, в принципе, с тем же успехом сжигать деньги каждый день – толку будет больше». Но чтобы выйти на такой объем, необходимо было пересмотреть процессы, автоматизацию. В итоге в декабре 2021 года или январе 2022-го мы вышли на нужные показатели. И наша система это выдержала.

Сергей:

С точки зрения бизнеса это нам не сильно помогло. Мы не владели ни статистикой, ни аналитикой, качество того, что производило продукты, было низкое. Количество с такой системой мы могли сделать, но как понять, зарабатываем мы деньги или нет. Мы просто не умели считать. Шли как в темном лесу. Ощущение, будто у тебя работают 100 человек, но не приносят прибыль.

Что я хочу донести до читателей: наш путь – это путь больших ошибок, и я не рекомендую по нему идти!

Как вы решаете вопросы кибербезопасности и борьбы с мошенничеством?

Виталий:

Мы используем готовые решения для антифрода. Скоринг-система у нас своя, она объединяет готовые решения.

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

Как вы начали разрабатывать систему? Какие ресурсы имели изначально, какой штат?

Сергей:

С воодушевлением, энтузиазмом мы начали разработку с тремя программистами в штате. Мы обратили к вендору – он был уверен, что мы всех порвем. И этот процесс продолжался несколько лет… Он сопровождался расширением штата разработчиков, внедрением разных методик и подходов, поиском идеальной системы управления задачами.

Оказалось, что от расширения штата эффективность не особенно возрастает. Более того, даже от увеличения бюджета она не всегда зависит.

Виталий:

С ростом системы каждый отдел в компании начал ставить свои задачи. Разработчики проектировали и реализовывали всё новый функционал. Функций становилось больше, и программисты уже не успевали сопровождать их работу. Из-за банальной нехватки рабочих рук нужно было нанимать людей.

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

Результат – общее снижение эффективности. Новички факапили задачи.

Сергей:

Базовой проблемой было отсутствие управления проектами. Моя гипотеза состояла в том, что при большем количестве людей получится закрывать больше вопросов. Но это не работает, когда не выстроена система. Если взять банду людей, которая работает в хаосе, и добавить к ним еще какое-то количество людей, хаос никуда не денется, его станет больше. Вопрос был не в разработчиках, не в их количестве, а в workflow.

Нашей проблемой было то, что мы не стали использовать самую эффективную в мире технологию, а начали копировать то, что уже придумано до нас, пытаться «изобрести велосипед» в каждом вопросе.

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

Виталий:

Эксперимент закончился тем, что мы из нанятых в ускоренном темпе разработчиков оставили только одного: он каким-то образом смог адаптироваться к этому хаосу и на самом деле решать задачи.

Как вы пытались справиться с этим хаосом? Какие подходы применяли?

Сергей:

В последний год мы пробуем различные варианты, меняем системы мотивации. Но, дорогие коллеги, от души рекомендую: не суйтесь в болото собственного мышления, когда вы думаете, что знаете, как нужно делать работу. До нас придумано всё, agile разработана много лет назад. Но нам почему-то нужно через мучения находить свою систему. Или внедрять agile не в полном режиме, что тоже не будет работать. Хотя мы и это пробовали…

Виталий:

В самом начале задач было мало, и мы их отправляли в Telegram без подробного описания. Разработчики самостоятельно докладывали о прогрессе и задавали вопросы при необходимости. В то время постановщиком был СТО.

Позже, с увеличением числа задач, мы перешли на использование Trello. Я, в качестве руководителя проекта, добавлял задачи в таск-менеджер, а разработчик их закрывал, и я перемещал карточки.

По мере роста количества задач, связанных с CRM, появились дополнительные разработчики и отдел техподдержки. Мы также внедрили систему баг-трекинга, где менеджеры сообщали о багах и задавали вопросы. Я общался с ними напрямую.

Позже мы перешли на другую систему, где работали по принципу спринтов: срок выполнения задач не должен быть превышать неделю. Но рутина не позволяла так быстро делать это, из-за того что нужно было фиксить баги или выполнять срочные задачи. Затем мы внедрили более структурированные спринты с ежедневными собраниями. Это произошло в конце прошлого или начале этого года.

Сергей:

Планирование, рефлексия, понимание, что мы на самом деле делаем, – это очень важно. В ином случае можно работать, работать и работать, а через год понять, что всё было зря. К сожалению, пока мы можем спланировать процентов 10 от того, что нужно.

Вопрос планирования особенно актуален в проектах, в которых есть много участников, много задач. И план должен быть осмыслен каждым из них. Кстати, точно спланировать всё нельзя еще и потому, что agile – это «гибкий» подход.

Виталий:

В этом году мы стали посвящать вопросам планирования много времени. Собрали карту всех проектов на год, но выяснили, что они очень динамичные, и от схемы ничего не осталось. Сейчас мы ежемесячно согласовываем проекты и мыслим примерно на 1–2 месяца вперед максимум.

Если перенести модернизацию системы на организацию работы, какие ограничения есть сейчас и как их исправлять?

Сергей:

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

Виталий:

Мы дошли до ограничений, проблем с «1С», и смогли обойти их благодаря разработке нового программного обеспечения, которое не зависит от «1С».

Сергей:

И при этом мы остаемся на безумном пути вечного созидания. Наши ограничения в том, что мы пытаемся сделать всё сами, а не использовать готовые решения.

И главный вопрос при разработке такой системы – это то, как к проблеме, задаче, цели относится заказчик и как – исполнитель.

Раскройте подробнее, пожалуйста, о чем здесь речь?

Сергей:

Речь о том, что в итоге мы даже свой таск-менеджер сделали. Но самого важного результата для бизнеса с помощью «самописной» системы не достигли: у нас нет аналитики и прочего. Виталий отметил, что ограничения обошли. И это здорово для CTO. Но для меня, как главы компании, результат пока не достигнут. Аналитики пока нет. План продаж есть, но эффективности нет.

Проще было месяц или два подождать, не запускаться, выкатить «Аксиоматику» в срочном порядке и обрабатывать заявки через нее так, чтобы анализировать, иметь аналитику, уметь управлять процессом. То, что сейчас есть, не отвечает нашим требованиям.

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

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