Зачем разрабатывать CRM / ERP систему.

Как выбрать разработчика.

Как оплачивать разработку и контролировать проект.

Как написать техническое задание.

Зачем разрабатывать систему.

У любого владельца бизнеса, который хочет упорядочить и автоматизировать свой бизнес встает вопрос: “Воспользоваться готовым решением или разработать систему под себя?”.

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

У каждого из этих вариантов есть свои плюсы и минусы. Но в итоге к разработке CRM / ERP системы под себя приходят по следующим причинам:

    Нет хороших решений под специфику бизнеса;

    Хочется максимальной автоматизации без ограничений;

    Не хочется платить каждый месяц за системы-сервисы;

    В существующих решениях не хватает функционала, который хочется автоматизировать.

Как выбрать разработчика

Это самый важный момент в разработке системы.

Разработка CRM или ERP системы это не просто работа программиста. Как минимум это работа UIX-специалиста, верстальщика и программиста.

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

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

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

При разработке системы важны следующие моменты:

• Срок разработки
• Насколько система интуитивна понятна сотрудникам
• Стабильность, скорость работы системы
• Поддержка
• Цена

Причем цена не на самом верху списка, потому что если нет всего остального, то неважно сколько стоит система. Деньги будут выброшены на ветер.

Как же выбрать разработчика.

Есть два хороших способа выбрать разработчика.

1. В мире IT сарафанное радио всегда было самым популярным способом. Если у вашего знакомого есть рабочая CRM / ERP система, он ей доволен и доволен разработчиками, попросите его показать ее. Если вы согласны с тем, что она на самом деле удобна, если вы в ней без особого труда разобрались (при учете что вы пользовались системами, и это не первая ваша система), если время, за которое сделали эту систему вам подходит, если сотрудники на самом деле используют систему и это не просто заблуждение владельца, то явно это тот разработчик, к которому стоит обратиться. Это однозначно лучший вариант.
2. Если по первому варианту у вас ничего нет, это не беда. Найти хорошего разработчика не так трудно. Все, что вам нужно - это портфолио. Причем, если речь идет о разработке CRM / ERP системы, вам нужно посмотреть именно CRM или ERP системы, которые делал этот разработчик. Если они не могут вам предоставить демо-доступ или хотя бы демонстрацию, нет никакого смысла продолжать с ними общение.

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

Как оплачивать разработку и контролировать проект.

Для начала поделите все разработку на несколько частей. В каждой части должна быть сделана четко определенная часть системы, которую можно увидеть, проверить, “пощупать” и убедиться, что все идет по плану.

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

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

Другой вариант развития событий.

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

Поэтому обязательно вся работа делится на несколько этапов.

Соответственно вся оплата по проекту так же поделена на части.

Последовательность действий:

1. Перед началом первого этапа разработчик получает от вас оплату за этот этап.
2. По истечению срока выделенного на разработку этого этапа разработчик показывает вам результат.
3. Вы в течении определённого времени (указанного в договоре) вносите правки по проекту.
4. Вносятся правки в проект.
5. Переходите ко второму этапу разработки.
    

Вы убеждаетесь, что разработчик не халтурит, что все идет как вам нужно и оплачиваете вторую часть. И так до конца.

Не надо плодить эти части. В зависимости от сложности системы достаточно разделить разработку на 2-4 этапа. Иначе больше времени будет тратиться на контроль оплаты и подписания актов, чем на разработку.

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

Как написать техническое задание.

Итак, нам нужно ТЗ на разработку системы

Для начала нужно понять.

Вы можете потратить несколько месяцев, немалую сумму денег, расписать ТЗ по ГОСТу на 200 страниц, а в итоге получить не то, что вы хотите.

А можете расписать все на одной странице и получите именно то, что хотели.

ТЗ пишется не для того чтобы было, а для того чтобы получить желаемый результат.

Что нужно, чтобы получить систему такой какой вы ее видите:

• Вы должны понимать, что вы хотите;
• Подробно расписать функционал системы как вы ее видите (совместно с разработчиком);
• Согласовать дизайн;
• Постоянно контактировать с руководителем проекта;
• Грамотный руководитель проекта.

Как расписать функционал, чтобы вас поняли?

Для начала нужно понять, что такое система.

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

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

Определитесь, что должно быть в системе: Продажи, Склад, Производство, Финансы.

А теперь подробно все это распишите.

Например, если рассматривать продажи, то какие основные элементы можно выделить:

• Клиенты
• Задачи
• Сделки / Продажи

• Звонки
• Письма

Если мы рассматриваем склад:

• Товар
• Остатки
• Списания
• Закупки

Теперь как бы вы хотели видеть это в системе?

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

Например, зашли в раздел и видите там только звонки. Да эти звонки связаны много с чем в системе (например с клиентом), но в разделе звонки, вы видите именно звонки. И таким образом, мы имеем отдельный раздел.

Каждый из этих разделов может состоять из подразделов.

Например, раздел клиенты.

В случае b2b клиентами являются компании. Но у компании есть контактные лица. И таким образом мы имеем два подраздела: компании и контактные лица.

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

Например, компания.

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

Соответственно у нас есть теперь разделы и подразделы.

Теперь расписываем подробно каждый подраздел.

Что должны вы видеть в этом подразделе, когда вы заходите в систему. Определите это.

На примере подраздела компании:

• Сам список компаний, сортировка списка по …
• Поиск компании по ….
• Фильтр компаний по …
• Меню для массовой постановки задач сотрудникам по компаниям, массового удаления компаний и тд.

Далее описываем сам элемент “компания”.

Что мы должны видеть, когда заходим в карточку компании.

Всю информацию, которую мы должны видеть по компании можно поделить на три типа:

1. Редко изменяемая информация о компании: Название, город, сфера деятельности, номер телефона, почта, адрес и тд.
2. Другие связанные элементы с компанией:
   1. Сделки, которые были оформлены с этой компанией
   2. Документы по работе с этой компанией
   3. Контактные лица этой компании

Укажите по каждому такого элементу можно ли его создавать из компании. Можно ли с компанией связывать уже созданные элементы (контактные лица и т.д.).

1. Коммуникация с компанией – звонки, письма, комментарии сотрудников по компании, сообщения в чатах.

Опишите по каждому типу информации, какая информация должна отображаться в карточке.

Если в карточке должен быть дополнительный функционал, например, удаление, опишите это.

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

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

Вам нужен разработчик CRM/ERP системы, которому можно доверять?

Оставьте свои контактные данные и вы сможете посмотреть наши работы: