Стандартная функциональность в CRM-системах
Тематика: CRM-системы
Отрасль: Универсальные решения
Автор: Очень любят наши люди строить замки из песка. Вот куплю я готовую систему и на стандартных бизнес-процессах у меня все заработает. Только вот система для всех одинакова, потому как стандартна. Двух одинаковых организаций не бывает и при детальном рассмотрении реализованных бизнес-процессов в готовой CRM-системе выясняется, что не все в ней подходит. Вот это нам бы по-другому сделать, а вот это совсем не годится, а вот то хочется переделать… Рушится песчаный замок. Наступает крах иллюзий.
К сожалению, очень многие люди питают иллюзии по поводу стандартной функциональности в CRM-системах. Вот вам аналогия: детский конструктор Lego. Конструктор имеет набор различных элементов, которые по вполне определенной логике можно соединять. Продается конкретный набор с картинкой, изображающей самолет, собранный из этих самых элементов. Так вот, что здесь стандартная функциональность? Самолет, который собирается из этого набора или возможность собирать различные конструкции?
Неужели кто-нибудь покупает ребенку конструктор Lego, чтобы тот собрал одну конкретную конструкцию один раз?
Вот и получается, что стандартная функциональность — это набор конструктивных элементов с заложенной логикой их комбинирования. Кстати, последний тезис полностью применим и к CRM-системам.
Продолжим аналогию… Посмотрел ребенок на имеющееся разнообразие и решил вместо самолета построить, например, башню. При определенном уровне пространственного воображения это легко получится. На это создатели Lego и рассчитывали. Но в какой-то момент созидательного процесса ребенок сталкивается с трудностью — нужен элемент такой хитрой формы, а ничего подходящего не находится.
Что делать? Есть два пути выхода из подобной ситуации.
Можно сделать новый «нужный» элемент. Например, вырезать ножом из дерева или построить пенопластовую модель. Потом по ней сделать литейную форму и отлить из свинца, полученного переплавкой рыбацких грузиков, купленных в рыбацком же магазине. В привязке к CRM-системе это выглядит так: нанимаем разработчиков, формируем и согласовываем техническое задание. Разработчики работают, мы формируем и согласовываем сценарии тестирования, готовим данные для тестов и тестируем. Доработки и опять тестирование… Потом перенос разработок на продуктивную систему. Опытная эксплуатация. А потом выясняется, что еще что-то не учли, или требования изменились.
А можно слегка пересмотреть задумку и подобрать решение из имеющихся элементов. Опять-таки, что в Lego, что в CRM-системе.
Вот чем отличается хороший конструктор от обычного? Ну, во-первых, тем, что элементы, которые должны соединяться, все-таки соединяются. И благодаря такому соединению достаточно прочно и устойчиво держится вся конструкция. Но это, так сказать, базовые требования. Без этого конструктор — не конструктор. А во-вторых, и это куда существеннее, выбор элементов должен быть широк, чтобы были элементы на все случаи жизни. Дабы, если и пересматривать задумку, то совсем незначительно.
Внедрение CRM-системы эффективно, если набор имеющихся стандартных средств широк, и все они между собой логически согласованы. Это позволит реализовать конкретные задачи с минимальными затратами ресурсов и даст уверенность в том, что законченное решение будет работать слаженно и без противоречий.
А то ведь, если пластмассовую башню накрыть самодельной свинцовой крышей, то завалится вся конструкция 🙂
