Стандартна функціональність в CRM-системах
Тематика: CRM-системи
Галузь: Універсальні рішення
Автор: Дуже люблять наші люди будувати замки з піску. Ось куплю я готову систему і на стандартних бізнес-процесах у мене все запрацює. Тільки ось система для всіх однакова, тому як стандартна. Двох однакових організацій не буває і при детальному розгляді реалізованих бізнес-процесів в готовій CRM-системі з’ясовується, що не всі в ній підходить. Ось це нам би по-іншому зробити, а ось це зовсім не годиться, а ось те хочеться переробити… Руйнується піщаний замок. Настає крах ілюзій.
На жаль, дуже багато людей мають ілюзії з приводу стандартної функціональності в CRM-системах. Ось вам аналогія: дитячий конструктор Lego. Конструктор має набір різних елементів, які з цілком певною логікою можна з’єднувати. Продається конкретний набір з картинкою, що зображує літак, зібраний з цих самих елементів. Так ось, що тут стандартна функціональність? Літак, який збирається з цього набору або можливість збирати різні конструкції?
Невже хтось купує дитині конструктор Lego, щоб вона зібрала одну конкретну конструкцію один раз?
Ось і виходить, що стандартна функціональність — це набір конструктивних елементів із закладеною логікою їх комбінування. До речі, остання теза цілком прийнятна і до CRM-систем.
Продовжимо аналогію … Подивилася дитина на наявне різноманіття та вирішила замість літака побудувати, наприклад, вежу. При певному рівні просторової уяви це легко вдасться. На це творці Lego та розраховували. Але в якийсь момент творчого процесу дитина натрапляє на труднощі — потрібен елемент такої хитрої форми, а нічого підхожого не знаходиться.
Що робити? Є два шляхи виходу з подібної ситуації.
Можна зробити новий «потрібний» елемент. Наприклад, вирізати з дерева або побудувати пінопластову модель. Потім по ній зробити ливарну форму та відлити зі свинцю, отриманого переплавлянням рибальських важків, куплених в рибальському ж магазині. У прив’язці до CRM-системи це виглядає так: наймаємо розробників, формуємо та погоджуємо технічне завдання. Розробники працюють, ми формуємо та погоджуємо сценарії тестування, готуємо дані для тестів і тестуємо. Доробки й знову тестування… Потім перенесення розробок на продуктивну систему. Дослідна експлуатація. А потім з’ясовується, що ще щось не врахували, або вимоги змінилися.
А можна злегка переглянути задум і підібрати рішення з наявних елементів. Знову-таки, що в Lego, що в CRM-системі.
Ось чим відрізняється хороший конструктор від звичайного? Ну, по-перше, тим, що елементи, які повинні з’єднуватися, все-таки з’єднуються. І завдяки такому з’єднанню досить міцно і стійко тримається вся конструкція. Але це, так би мовити, базові вимоги. Без цього конструктор — не конструктор. А по-друге, й це набагато істотніше, вибір елементів повинен бути широким, щоб були елементи на всі випадки життя. Щоб, якщо й переглядати задум, то зовсім незначно.
Впровадження CRM-системи є ефективним, якщо набір наявних стандартних засобів широкий, та всі вони між собою логічно узгоджені. Це дозволить реалізувати конкретні завдання з мінімальними витратами ресурсів і дасть впевненість в тому, що закінчене рішення буде працювати злагоджено та без суперечностей.
А то ж, якщо пластмасову вежу накрити саморобним свинцевим дахом, то завалиться вся конструкція 🙂
