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

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

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

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

Надеемся, Вы, приблизительно, поняли, что собой представляет CRM система с точки зрения проекта, в который вносятся изменения.

Сколько человек участвуют в изменении или добавлении одного условия в работу CRM системы?

Почему добавление “одной галочки” стоит столько денег?

По нашему опыту, добавление какого-то дополнительного фильтра поиска или условия в CRM отчет или на другую страницу, в понимании пользователя, равносильно рисованию данной “галочки” на листе бумаги от руки. Многие клиенты думают, что добавить галочку, это же “просто добавить галочку”. Но он не учитывает то, на какое количество взаимосвязанных алгоритмов эта галочка повлияет и сколько всего нужно будет доделать, переделать и проверить после.

Как же все происходит на самом деле?

Описание процесса доработки

1. Пользователь хочет доработку и минимально описывает свой запрос.
2. Специалист техподдержки принимает запрос, уточняет детали, ищет и предлагает альтернативные варианты и далее передает запрос ответственному разработчику - архитектору.
3. Разработчик-архитектор изучает запрос, уточняет задачу и цель, которую клиент хочет достичь, получив желаемую доработку. А также задает ряд вопросов, связанных с работой дополнительных алгоритмов, на которые влияет данная доработка. Это необходимо сделать, т.к. часто бывает ситуация, когда клиент говорит, что хочет добавить какую-то колонку в какой-то отчет, но не объясняет, какая именно у него цель, какой именно управленческий смысл он вкладывает в эту колонку. Архитектору необходимо выкристаллизовать этот смысл со слов клиента.
4. После того, как задача полностью уточнена, разработчик-архитектор продумывает пути ее реализации в системе, а также обрамление, т.е. на что эта доработка повлияет и какие части системы будут затронуты. После этого предлагает клиенту варианты реализации.
5. Когда вариант реализации выбран, наступает стадия написания технического задания для программиста, который будет выполнять данную задачу. Это также делает архитектор, самый профессиональный и дорогой специалист.
6. Далее задача передается разработчику-исполнителю.
7. Разработчик-исполнитель выполняет данную задачу, периодически консультируясь с архитектором. Кроме выполнения самой задачи, он пишет, так называемые, миграции базы данных, т.е. алгоритмы адаптации старых данных (которые уже были внесены в систему) под новые условия работы программы.
8. Кроме разработчика-исполнителя к задаче подключается программист-фронтендщик, который реализует визуальную часть задачи и следит за тем, чтобы вновь добавленный функционал правильно адаптировался под разные устройства, а также работали все кнопки и ссылки на большинстве платформ (Десктоп, Android, iOS).
9. Если интерфейс доработки состоит более чем из 2-х элементов, то также привлекается специалист по юзабилити и дизайну, который отвечает за красоту и удобство дорабатываемой функции.
10. После того, как все специалисты выполнили свои задачи и получили конечный вариант доработки, она заливается на тестовый сервер и передается тестировщику.
11. Тестировщик знакомится с техническим заданием, чтобы понимать, как правильно должен работать доработанный алгоритм.
12. Далее, тестировщик пишет чек-лист, другими словами - план, в котором описаны все случаи, которые нужно проверить в самой доработке, а также случаи по другим функциям, которые могли быть затронуты.
13. После этого тестировщик приступает к тестированию системы.
14. По окончанию тестирования задача передается на исправление разработчику-исполнителю, а также специалисту отвечающему за визуальную часть.
15. После исправления - снова на тестирование. Пункты 12, 13 могут повторяться от одного до 5 и более раз в зависимости от сложности разработки.
16. После того, как тестировщик подтверждает, что доработка работает правильно и замечаний больше нет, она уходит на проверку к архитектору.
17. Архитектор строчка за строчкой перечитывает и проверяет программный код, который написал разработчик-исполнитель и программист-фронтендщик.
18. В случае, если архитектор находит ошибки или уязвимости в коде (так называемые дыры, несущие угрозу хакерской атаки), он выписывает замечания и отдает их на исправление разработчику-исполнителю.
19. Далее разработчик-исполнитель исправляет эти замечания и передает код на повторную проверку архитектору.
20. Шаги 16, 17 могут повторяться несколько раз, в зависимости от сложности задачи и квалификации разработчиков.
21. После того, как код проверен на правильность, отсутствие ошибок и дыр в безопасности, он готов к тому, чтобы быть влитым в главную версию программы.
22. Архитектор аккуратно вливает данную доработку в главную версию системы, строчка за строчкой объединяя программный код и готовит новую версию системы.
23. В новой версии может быть соединено несколько разных доработок, каждая из которых прошла путь описанный выше. После объединения всех доработок, версия отдается на проверку тестировщикам (2-3 человека).
24. Тестировщики делают финальное тестирование новой версии на тестовом сервере и, если находят ошибки, возникшие в результате слияния версий, передают их на исправление архитектору.
25. После того, как новая версия протестирована и ошибок больше не найдено, она готова к тому, чтобы быть опубликованной для клиентов.
26. Архитектор делает обновление ночью, заливая новую версию на живой сервер.
27. На следующий день рано утром тестировщики (2-3 человека) оперативно тестируют новую версию на живом сервере на предмет ошибок в новых доработках, а также на предмет ошибок в стандартных, наиболее часто используемых функциях, что занимает не менее одного дня.
28. Если тестировщики находят ошибку, архитектор очень оперативно ее исправляет.
29. После того, как тестировщики полностью протестировали версию и утвердили, что ошибок больше нет, начинается работа с клиентами и документацией.
    • Специалисты технической поддержки оповещают клиентов о выходе новых доработок.
    • По всем новым функциям пишется документация, изменяется уже написанная справка, обновляются все рисунки интерфейсов, которые были затронуты в результате доработки. Также пишется и публикуется новость, чтобы донести информацию до клиентов.

Итого, в добавлении галочки в отчет участвует минимум 4-6 человек, некоторые из них по несколько раз и это является неизбежным процессом для выпуска качественного продукта, с которым клиенты могут быть уверены в корректности отчетов и в безопасности своих данных.

Стандартная позиция клиента, который хочет индивидуальную доработку и реальное положение вещей

“Ребята, добавьте в отчет галочку, она так нужна, так нужна, ну никак без нее не могу. Ведь она нужна не только мне, она нужна всем клиентам! Почему я должен за нее платить, когда она нужна всем? Вот добавьте и Ваша система станет такой крутой, такой крутой! Чтобы бы Вы без меня делали вообще, я Вам такую идею предложил. Вы должны быть благодарны за то, что я Вам идеи накидываю, а Вы еще 10$ требуете. Ужас, какой плохой сервис, не хотят бесплатно реализовывать мои гениальные идеи”.

Да, идеи клиентов для нас действительно нужны и важны, и мы собираем и фиксируем все идеи и предложения, которые к нам поступают. Но бизнес процессы в организациях настолько различны, что просьбы по доработкам поступают от каждой второй компании несмотря на то, что CRM система Отмечалка имеет огромное количество функционала и гибких настроек разрабатываемые годами по запросам клиентов. Некоторые компании присылают целые списки, состоящие из 15-20 пунктов. И выполнение абсолютно всех запросов идет в разрез с начальной идеей создания CRM Отмечалка.

У команды CRM Отмечалка есть свое видение развития проекта, есть информация о том, что нужно рынку, какие функции наиболее востребованы и что принесет больше удобства нашим пользователям и повысит ценность и привлекательность CRM Отмечалка. В связи с этой информацией мы расставляем приоритеты задач, выдаем эти задачи разработчикам и платим им за выполнение этих задач, которые, как правило, берутся из копилки запросов клиентов. Кроме того, есть график регулярных бесплатных обновлений, которые производятся раз в 2-4 недели и содержат массу полезных возможностей. Это то, что выходит бесплатно т.е. входит в абонплату за сервис. Если клиент хочет, чтобы мы отложили выполнение плановых задач и добавили в CRM именно его функцию, это означает, что он получает разработчиков, которые выполняют задачу его бизнеса. И, как следствие, клиент оплачивает работу специалистов, работающих на него.

“Но моя доработка станет доступна всем пользователям, почему я должен за нее платить?”

Мы анализируем, насколько Ваш запрос востребован другими клиентами и исходя из этой информации корректируем стоимость таким образом, что часть стоимости оплачиваете Вы, а часть расходов берет на себя сам сервис Отмечалка. Поэтому, как правило, цена, которую мы называем клиенту составляет 15-30% от реальной суммы стоимости доработки. Доработки, которые будут доступны исключительно одному клиенту (если это не касается индивидуальных доступов для пользователей), мы не выполняем, т.к. CRM Отмечалка НЕ является индивидуальным решением для каждой организации за счет своей доступности для компаний с различным уровнем дохода.

Так вот и при использовании IT-сервисов все тоже самое. Если Вы хотите индивидуальную доработку, то Вы должны быть готовы заплатить специалистам за их работу. Когда Вы покупаете ванну, Вы же не ожидаете, что Вам проведут всю сантехнику по дому бесплатно.

Так и в случае CRM системы, есть продукт, за который Вы платите абонплату и Вы используете максимально все его доступные возможности, то есть то, за что платите абонплату.

Если Вы хотите, больше, по-другому, максимально удобно именно для Вас, тогда это индивидуальный заказ, который всегда и везде стоит денег. Будет ли он полезен для других клиентов или нет, повлияет ли он на привлекательность системы для других пользователей или нет, но это работа 4-6 специалистов минимум по плану в 30 пунктов описанному выше. И эта работа не может быть бесплатной.

Почему Вы можете хотеть доработку?

1. Вы не хотите адаптироваться под готовое решение, а хотите, чтобы решение адаптировалось под Вас. В таком случае Вам нужно заказывать написание индивидуальной CRM-системы, которая стоит десятки тысяч долларов, т.к. разрабатывается исключительно под Ваши бизнес-процессы.
2. Вам нравится CRM система, которой Вы пользуетесь, но не хватает какого-то отчета или небольшой функции.
   • Простое решение: рассмотреть обходные варианты решения в рамках данной системы, список которых можно запросить у специалистов технической поддержки бесплатно и адаптироваться под один из предложенных вариантов.
   • Сложное решение: озадачить разработчиков CRM системы придумать и доработать удобный для Вас вариант решения. Сложность заключается в Вашей готовности платить и ждать.

Для того, чтобы рассчитать выгодность доработки нужно иметь следующие данные:

• список альтернативных решений, то есть обходных путей решения с использованием существующих функций или других вспомогательных программ;
• стоимость доработки;
• зарплата сотрудника, который работает в системе и использует этот функционал.

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

Любой руководитель знает, как это сделать, но не каждый делает, поэтому мы это опишем кратко в данном материале.

Есть несколько предусловий, которые стоит учесть перед тем, как делать расчет.

Администраторы, которые сидят на рецепции и общаются с клиентами, не более чем исполнители задач за деньги, которые Вы им платите. И если им что-то не удобно делать, это значит, что они не хотят лишний раз напрягаться. В этом случае либо Вы платите свои личные деньги за то, чтобы им стало удобно у Вас работать, т.е. делаете для них доработку CRM системы за свой счет, либо же Вы платите им зарплату за работу, которую они должны просто выполнять задачи, удобно им это или нет. Ведь работа - это работа, а не диван для отдыха. И людей нанимают не для того, чтобы им было удобно, а для того, чтобы было удобно Вам делегировать им задачи, которые нужно выполнять. У сотрудника есть должностные обязанности, которые ему поручаются, и, устраиваясь на работу, он соглашается с тем, чтобы выполнять эти обязанности и получать за их выполнение зарплату. Поэтому если администраторы говорят, что им не удобно кликать один раз в день три кнопки вместо одной, это совсем не значит, что нужно все бросать и делать им удобно или отказываться от CRM, которая предоставляет Вам множество управленческой информации, статистики и возможность контроля за ситуацией и сотрудниками. Нужно понимать, что администратор - это наемный сотрудник, который выполняет ряд функций в Вашем бизнесе. Бизнесе, который приносит Вам деньги. Удобство администратора не является первоочередной задачей бизнеса.

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

[Стоимость ручной работы в месяц] = [Кол-во часов в месяц, которое идет на выполнение работы в ручном (полуручном) режиме] * [Стоимость одного часа работы данного специалиста].

Кол-во месяцев, за которое окупится доработка = [Стоимость доработки] / [Cтоимость ручной работы в месяц].

Пример: Администратор получает 300$ в месяц.

Стоимость часа работы:

(300$ / (20 рабочих дней))/ 8 часов = 1,875$ в час.

На перебронирование занятий в результате заморозки абонементов у него уходит в среднем по 1 часу в день. Соответственно за месяц - 20 часов.

Стоимость данной работы в ручном режиме составляет: 20 * 1,875$ = 37,5$ в месяц.

Допустим доработка стоит 60$ (всего лишь, за работу 6-ти специалистов по плану из 30-ти пунктов).

Кол-во месяцев окупаемости доработки: 60$ / 37,5$ = 1,6 месяца.

Соответственно, данная доработка окупится Вам меньше чем за 2 месяца.

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