Руслан Раянов: Как создать свою CRM

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

Конечно, разработка собственной CRM стоит дороже, чем внедрение готовой, т.к. программное приложение по сути пишется под потребности вашего бизнеса. Также сроки внедрения собственной CRM больше, чем готовой системы. Здесь важно определиться с краткосрочными и долгосрочными приоритетами. Что важнее? Скорость внедрения, стоимость, учет специфики бизнес-процессов, безопасность, удобство и др.

В дальнейшем мы рассмотрим третий вариант внедрения CRM – создание CRM под требования вашего бизнеса.

В этом случае необходимо будет пройти все стадии разработки программного продукта, а именно:

➢ концепция;

➢ техническое задание;

➢ проектирование и кодирование;

➢ тестирование и доработки;

➢ внедрение в эксплуатацию.

В следующей главе мы кратко поговорим о концепции проекта и как ее правильно составить.

Глава 2. Концепция проекта CRM.

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

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

Что должна содержать концепция проекта:

➢ Краткое описание проекта (1 предложение).

➢ Состав модулей (определение ролей и их функций).

➢ Требования к технологиям.

➢ Параметры проекта (сроки, стоимость).

➢ Требования к команде разработки + состав брифа для нее.

Пройдемся подробнее по каждому пункту.

Краткое описание проекта.

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

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

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

Плохие примеры:

Создание сайта

Нужна программа

CRM

Хорошие примеры:

Нужна студия на разработку движка CRM

Разработка CRM на заказ

Разработка CRM на заказ, только Москва.

Состав модулей(определение ролей пользователей и их функций).

Для начала хотя бы в общих чертах определитесь, какие будут в вашей системе роли. Роль – это типовой пользователь в вашей системе. Например, продавец, администратор, оператор, менеджер, работник склада и т.д.

После того, как вы определили роли в системе, кратко опишите их.

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

Требования к технологиям

Если у вас на предприятии уже используются сервера, то подумайте о том, чтобы будущая CRM была совместима по технологиям с существующей инфраструктурой. Это необязательное требование, но лучше заранее продумать этот момент. К примеру, если у вас на сервере используется ПО MS Windows, то нет смысла делать свою CRM на технологиях, которые подразумевают использование серверов Linux. Если все ваши системы будут сделаны на одних и тех же технологиях, это снизит стоимость поддержки IT-решений.

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

Параметры проекта.

Указывайте всегда вилки оценки стоимости и сроков.

Точную стоимость указывать бессмысленно, т.к. в ходе проекта будут новые дополнения и развитие функционала. Нужен просто порядок цен и сроков, чтобы подрядчик это соотносил со своими возможностями / ресурсами.

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

Есть еще один параметр проекта – качество. Но его довольно сложно описать кратко в концепции. Как вариант, вы можете требовать некоторых гарантий. С другой стороны, гарантии вам выдают продавцы от IT компаний, а обеспечить их будут разработчики. И здесь иногда возникает некоторое рассогласование обещаний продавцов и фактического сервиса компании.