ПО CRM: необходимые атрибуты

Предлагаю обсудить необходимые атрибуты программного обеспечения CRM:

/что должно быть реализовано
/необходимые качества
/желаемый интерфейс
/чего быть не должно

Речь НЕ идет о конкретных продуктах - только о необходимых качествах данного софверного продукта вообще, как класса.

Прошу НЕ переходить на конкретные системы и личности...

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

_________________
Пусть Путь Ваш освещается Светом Души Вашей!

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

_________________
-= Monitor CRM - больше, чем CRM! =-

ОК.
Предлагайте.
С данной классификацией Вы знакомы много лучше меня.


Согласен.
Но ведь нельзя же строить классификацию по принципу:
/ПО CRM для автосалона
/ПО CRM для судостроительного завода
/ПО CRM для деревообрабатывающего завода
/ПО CRM для торгового предприятия

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

Как я понимаю, возможно делить ПО принципу:
/Для розничной торговли
/Для производства
/Для услуг

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

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

_________________
Пусть Путь Ваш освещается Светом Души Вашей!

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

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

_________________
-= Monitor CRM - больше, чем CRM! =-

Согласен, но...
Многие виды бизнеса сочетают розницу и опт, b2b и b2c, разовые продажи и поток.
Тот же софт.
Тогда приобретать разные продукты?
Или что-то не включать в CRM?

По логике структура ПО должна позволять подобную подстройку (конфигурирование): создание групп пользователей, разделение полномочий и бизнес-процесов, выделение ответственных менеджеров.
Ну и имеющие доступ получат доступ к целостной картине.
Соответственно и ПО должно иметь соотв. модули:
/для "длинных" проектов - это запись переговоров и структурированное хранение документации
/для отпуска товаров - возможность отключения функции для "длинных" проектов

_________________
Пусть Путь Ваш освещается Светом Души Вашей!

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


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

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

И именно такое ПО можно считать конфигурируемым.

------------------------------------------

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

Именно здесь и вступает в "игру" КОНФИГУРИРОВАНИЕ и АДАПТАЦИЯ!

2 Czyan

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

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

Поэтому, сейчас на первый план выходит не сам набор функций (он почти у всех одинаковый), а их реализация и практическое применение этого функционала в конкретной компании. Два примера:

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

Все говорят от наличии "маркетинговой" аналитики. Но кто-то под этим имеет в виду только отчетность "по откликам" и "ABC-анализ" и т.п., а где-то более широкие возможности. И некоторым клиентам хватает и отчетности 1С, а кого-то не устроит аналитика ни одной из CRM-систем... им уже надо что-то типа "Дедуктора"...

На мой взгляд, "абсолютно совершенной" и универсальной CRM-системы "подходящей для всех" все-равно нет и не будет!

_________________
-= Monitor CRM - больше, чем CRM! =-

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

Все решения разные с разным функционалом, который где-то лучше, где-то хуже подходит для решения тех или иных задач.

Это еще один разрез... Где-то действительно не обойтись без глубокой настройки и доработки и он готов за это платить, а для кого-то излишняя "конфигурирумость" только неоправданно увеличивает стоимость проекта.

_________________
-= Monitor CRM - больше, чем CRM! =-

Вы себе противоречите в одном предложении. Если она (конфигурируемость) не нужна, то как она может увеличивать проект.
И персональная просьба: расшифруйте понятие - ИЗЛИШНЯЯ конфигурируемость. Это как - широкие возможности в тягость?
))))))
И вы очень много говорите об увеличении стоимости проектов - приведите КОНКРЕТНЫЕ ПРИМЕРЫ, пусть абстрактные.