CRM система - це об'ємний програмний продукт з величезною кількістю сутностей і глибоких логічних взаємозв'язків між ними, що має ще більшу кількість алгоритмів і умов, за допомогою яких відбувається безліч алгоритмів і умов, за допомогою яких відбувається обробка даних. У результаті роботи CRM системи, щодня створюються сотні тисяч, а то й мільйони записів у базі даних, яка, в свою чергу, складається з декількох сотень таблиць, логічно пов'язаних між собою.

Якщо одна або кілька умов у системі змінюється, це впливає на величезну кількість інших умов і алгоритмів, пов'язаних зі змінюваною логікою роботи програми, а також на дані, які вже внесені в систему, тому що вони були внесені за іншими правилами. У разі зміни умов ці мільйони даних потрібно адаптувати до нових умов життя. Після внесення змін необхідно перевірити з нуля працездатність усієї системи.

Інакше кажучи, CRM проект - це живий організм, у якому найменші зміни в будь-якому місці тягнуть за собою безліч змін в інших підсистемах і вже існуючих даних.

Відповідно, внесення змін - це не тільки витрати часу дорогих фахівців, які здатні розібратися в тисячах складних взаємопов'язаних алгоритмах, але також великі ризики того, що щось буде порушено або зламано і завдасть шкоди всім користувачам системи. Від помилок не застрахований навіть найгеніальніший і найпрофесійніший фахівець.

Сподіваємося, Ви, приблизно, зрозуміли, що собою являє CRM система з точки зору проєкту, в який вносяться зміни.

Скільки людей приймає участь у зміні чи допрацюванні однієї умови в роботі CRM системи?

Чому додавання "однієї галочки" коштує стільки грошей?

З нашого досвіду, додавання якогось додаткового фільтра пошуку або умови в CRM-звіт або на іншу сторінку, в розумінні користувача, рівносильно малюванню цієї "галочки" на аркуші паперу від руки. Багато клієнти думають, що додати галочку, це ж "просто додати галочку". Але він не враховує те, на яку кількість взаємопов'язаних алгоритмів ця галочка вплине і скільки всього потрібно буде доробити, переробити і перевірити після.

Як же все відбувається насправді?

Опис процесу доопрацювання

1. Користувач хоче доопрацювання і мінімально описує свій запит.
2. Спеціаліст техпідтримки приймає запит, уточнює деталі, шукає і пропонує альтернативні варіанти і далі передає запит відповідальному розробнику - архітектору.
3. Розробник-архітектор вивчає запит, уточнює завдання і мету, яку клієнт хоче досягти, отримавши бажане доопрацювання. А також ставить низку запитань, пов'язаних із роботою додаткових алгоритмів, на які впливає це доопрацювання. Це необхідно зробити, тому що часто буває ситуація, коли клієнт каже, що хоче додати якусь колонку в якийсь звіт, але не пояснює, яка саме в нього мета, який саме управлінський сенс він вкладає в цю колонку. Архітектору необхідно викристалізувати цей сенс зі слів клієнта.
4. Після того, як завдання повністю уточнено, розробник-архітектор продумує шляхи її реалізації в системі, а також обрамлення, тобто на на що це доопрацювання вплине і яких частин системи торкнеться. Після цього пропонує клієнту варіанти реалізації.
5. Коли варіант реалізації обрано, настає стадія написання технічного завдання для програміста, який виконуватиме це завдання. Це також робить архітектор, найпрофесійніший і найдорожчий фахівець.
6. Далі завдання передається розробнику-виконавцю.
7. Програміст виконує це завдання, періодично консультуючись з архітектором. Крім виконання самого завдання, він пише, так звані, міграції бази даних, тобто алгоритми адаптації старих даних (які вже були внесені в систему) під нові умови роботи програми.
8. Крім розробника-виконавця до завдання підключається програміст-фронтендщик, який реалізує візуальну частину завдання і стежить за тим, щоб новододаний функціонал правильно адаптувався під різні пристрої, а також працювали всі кнопки і посилання на більшості платформ (Десктоп, Android, iOS).
9. Якщо інтерфейс доопрацювання складається більш ніж з 2-х елементів, то також залучається фахівець з юзабіліті та дизайну, який відповідає за красу і зручність допрацьовуваної функції.
10. Після того, як усі фахівці виконали свої завдання й отримали кінцевий варіант доопрацювання, воно заливається на тестовий сервер і передається тестувальнику.
11. Тестувальник знайомиться з технічним завданням, щоб розуміти, як правильно має працювати доопрацьований алгоритм.
12. Далі тестувальник пише чек-лист, іншими словами - план, у якому описані всі випадки, які потрібно перевірити в самому доопрацюванні, а також випадки за іншими функціями, яких могли торкнутися.
13. Після цього тестувальник приступає до тестування системи.
14. Після закінчення тестування завдання передається на виправлення розробнику-виконавцю, а також фахівцеві, який відповідає за візуальну частину.
15. Після виправлення - знову на тестування. Пункти 12, 13 можуть повторюватися від одного до 5 і більше разів залежно від складності розробки.
16. Після того, як тестувальник підтверджує, що доопрацювання працює правильно і зауважень більше немає, воно йде на перевірку до архітектора.
17. Архітектор рядок за рядком перечитує і перевіряє програмний код, який написав розробник-виконавець і програміст-фронтендщик.
18. У разі, якщо архітектор знаходить помилки або вразливості в коді (так звані звані дірки, що несуть загрозу хакерської атаки), він виписує зауваження і віддає їх на виправлення розробнику-виконавцю.
19. Далі розробник-виконавець виправляє ці зауваження і передає код на повторну перевірку архітектору.
20. Кроки 16, 17 можуть повторюватися кілька разів, залежно від складності завдання та кваліфікації розробників.
21. Після того, як код перевірено на правильність, відсутність помилок і дірок у безпеці, він готовий до того, щоб бути влитим у головну версію програми.
22. Архітектор акуратно вливає це доопрацювання в головну версію системи, рядок за рядком об'єднуючи програмний код і готує нову версію системи.
23. У новій версії може бути поєднано кілька різних доробок, кожна з яких пройшла шлях, описаний вище. Після об'єднання всіх доопрацювань, версія віддається на перевірку тестувальникам (2-3 людини).
24. Тестувальники роблять фінальне тестування нової версії на тестовому сервері і, якщо знаходять помилки, що виникли внаслідок злиття версій, передають їх на виправлення архітектору.
25. Після того, як нову версію протестовано і помилок більше не знайдено знайдено, вона готова до того, щоб бути опублікованою для клієнтів.
26. Архітектор робить оновлення вночі, заливаючи нову версію на живий сервер.
27. Наступного дня рано вранці тестувальники (2-3 людини) оперативно тестують нову версію на живому сервері на предмет помилок у нових доопрацюваннях, а також на предмет помилок у стандартних, найбільш часто використовуваних функціях, що займає не менше одного дня.
28. Якщо тестувальники знаходять помилку, архітектор дуже оперативно її виправляє.
29. Після того, як тестувальники повністю протестували версію і затвердили, що помилок більше немає, починається робота з клієнтами та документацією.
    • Фахівці технічної підтримки сповіщають клієнтів про вихід нових доробок.
    • За всіма новими функціями пишеться документація, змінюється вже написана довідка, оновлюються всі малюнки інтерфейсів, які були порушені в результаті доопрацювання. Також пишеться і публікується новина, щоб донести інформацію до клієнтів.

Отже, у додаванні галочки у звіт бере участь мінімум 4-6 осіб, деякі з них по кілька разів і це є неминучим процесом для випуску якісного продукту, з яким клієнти можуть бути впевнені у коректності звітів і в безпеці своїх даних.

Стандартна позиція клієнта, який хоче індивідуальне доопрацювання і реальний стан речей

"Хлопці, додайте у звіт галочку, вона так потрібна, так потрібна, ну ніяк без неї не можу. Адже вона потрібна не тільки мені, вона потрібна всім клієнтам! Чому я маю за неї платити, коли вона потрібна всім? Ось додайте і Ваша система стане такою крутою, такою крутою! Щоб би Ви без мене робили взагалі, я Вам таку ідею запропонував. Ви маєте бути вдячні за те, що я Вам ідеї накидаю, а Ви ще 10$ вимагаєте. Жах, який поганий сервіс, не хочуть безкоштовно реалізовувати мої геніальні ідеї".

Так, ідеї клієнтів для нас справді потрібні й важливі, і ми збираємо та фіксуємо всі ідеї та пропозиції, які до нас надходять. Але бізнес процеси в організаціях настільки різні, що прохання щодо доопрацювань надходять від кожної другої компанії попри те, що CRM система Відмічалка має величезну кількість функціоналу та гнучких налаштувань що розробляються роками за запитами клієнтів. Деякі компанії надсилають цілі списки, що складаються з 15-20 пунктів. І виконання абсолютно всіх запитів йде в розріз із початковою ідеєю створення CRM Відмічалка.

У команди CRM Відмічалка є своє бачення розвитку проєкту, є інформація про те, що потрібно ринку, які функції найбільш затребувані і що принесе більше зручності нашим користувачам і підвищить цінність і привабливість CRM Відмічалка. У зв'язку з цією інформацією ми розставляємо пріоритети завдань, видаємо ці завдання розробникам і платимо їм за виконання цих завдань, які, як правило, беруться зі скарбнички запитів клієнтів. Крім того, є графік регулярних безкоштовних оновлень, які проводяться раз на 2-4 тижні і містять масу корисних можливостей. Це те, що виходить безкоштовно, тобто входить в абонплату за сервіс. Якщо клієнт хоче, щоб ми відклали виконання планових завдань і додали в CRM саме його функцію, це означає, що він отримує розробників, які виконують завдання його бізнесу. І, як наслідок, клієнт оплачує роботу фахівців, які працюють на нього.

"Але моє доопрацювання стане доступним усім користувачам, чому я маю за нього платити?"

Ми аналізуємо, наскільки Ваш запит затребуваний іншими клієнтами і виходячи з цієї інформації коригуємо вартість таким чином, що частину вартості оплачуєте Ви, а частину витрат бере на себе сам сервіс Відмічалка. Тому, як правило, ціна, яку ми називаємо клієнту становить 15-30% від реальної суми вартості доопрацювання. Доопрацювання, які будуть доступні виключно одному клієнту (якщо це не стосується індивідуальних доступів для користувачів), ми не виконуємо, тому що CRM Відмічалка НЕ є індивідуальним рішенням для кожної організації за рахунок своєї доступності для компаній з різним рівнем доходу.

Так ось і під час використання IT-сервісів усе те саме. Якщо Ви хочете індивідуальне доопрацювання, то Ви маєте бути готові заплатити фахівцям за їхню роботу. Коли Ви купуєте ванну, Ви ж не очікуєте, що Вам проведуть усю сантехніку по дому безкоштовно.

Так і у випадку CRM системи, є продукт, за який Ви платите абонплату і Ви використовуєте максимально всі його доступні можливості, тобто те, за що платите абонплату.

Якщо Ви хочете, більше, по-іншому, максимально зручно саме для Вас, тоді це індивідуальне замовлення, яке завжди і всюди коштує грошей. Буде воно корисним для інших клієнтів чи ні, чи вплине воно на привабливість системи для інших користувачів чи ні, але це робота 4-6 фахівців щонайменше за планом у 30 пунктів описаним вище. І ця робота не може бути безкоштовною.

Чому Ви можете хотіти доопрацювання?

1. Ви не хочете адаптуватися під готове рішення, а хочете, щоб рішення адаптувалося під Вас. У такому разі Вам потрібно замовляти написання індивідуальної CRM-системи, яка коштує десятки тисяч доларів, тому що розробляється виключно під Ваші бізнес-процеси.
2. Вам подобається CRM система, якою Ви користуєтеся, але не вистачає якогось звіту або невеликої функції.
   • Просте рішення: розглянути обхідні варіанти рішення в межах цієї системи, список яких можна запросити у фахівців технічної підтримки безкоштовно й адаптуватися під один із запропонованих варіантів.
   • Складне рішення: доручити розробникам CRM системи придумати і доопрацювати зручний для Вас варіант рішення. Складність полягає у Вашій готовності платити і чекати.

Для того, щоб розрахувати вигідність доопрацювання, потрібно мати такі дані:

• список альтернативних рішень, тобто обхідних шляхів вирішення з використанням наявних функцій або інших допоміжних програм;
• вартість доопрацювання;
• зарплата співробітника, який працює в системі і використовує цей функціонал.

Отримавши ці дані, Ви можете розрахувати вигідність пропозиції з доопрацювання для Вашого бізнесу.

Будь-який керівник знає, як це зробити, але не кожен робить, тому ми це опишемо коротко в цьому матеріалі.

Є кілька передумов, які варто врахувати перед тим, як робити розрахунок.

Адміністратори, які сидять на рецепції і спілкуються з клієнтами, не більше ніж виконавці завдань за гроші, які Ви їм платите. І якщо їм щось не зручно робити, це означає, що вони не хочуть зайвий раз напружуватися. У цьому випадку або Ви платите свої особисті гроші за те, щоб їм стало зручно у Вас працювати, тобто робите для них доопрацювання CRM системи власним коштом, або ж Ви платите їм зарплату за роботу, яку вони повинні просто виконувати завдання, зручно їм це чи ні. Адже робота - це робота, а не диван для відпочинку. І людей наймають не для того, щоб їм було зручно, а для того, щоб було зручно Вам делегувати їм завдання, які потрібно виконувати. У співробітника є посадові обов'язки, які йому доручають, і влаштовуючись на роботу, він погоджується з тим, щоб виконувати ці обов'язки й отримувати за їхнє виконання зарплату. Тому, якщо адміністратори кажуть, що їм не зручно клікати один раз на день три кнопки замість однієї, це зовсім не означає, що потрібно все кидати і робити їм зручно або відмовлятися від CRM, яка надає Вам безліч управлінської інформації, статистики та можливість контролю за ситуацією і співробітниками. Потрібно розуміти, що адміністратор - це найманий працівник, який виконує низку функцій у Вашому бізнесі. Бізнесі, який приносить Вам гроші. Зручність адміністратора не є першочерговим завданням бізнесу.

Після того, як Ви усвідомили, що адміністратор рецепції - це просто найманий співробітник, а не людина, яка приймає рішення у Вашому бізнесі, Ви можете розрахувати вигідність пропозиції з доопрацювання за формулами наведеними нижче.

[Вартість ручної роботи на місяць] = [Кількість годин на місяць, яка йде на виконання роботи в ручному (напівручному) режимі] * [Вартість однієї години роботи цього фахівця].

Кількість місяців, за яку окупиться доопрацювання = [Вартість доопрацювання] / [Вартість ручної роботи на місяць]. [Вартість ручної роботи на місяць].

Приклад: Адміністратор отримує 300$ на місяць.

Вартість години роботи:

(300$ / (20 робочих днів)) / 8 годин = 1,875$ на годину.

На перебронювання занять унаслідок заморозки абонементів у нього йде в середньому по 1 годині на день. Відповідно за місяць - 20 годин.

Вартість цієї роботи в ручному режимі становить: 20 * 1,875$ = 37,5$ на місяць.

Припустімо, доопрацювання коштує 60$ (всього лише, за роботу 6-ти фахівців за планом із 30-ти пунктів).

Кількість місяців окупності доопрацювання: 60$ / 37,5$ = 1,6 місяця.

Відповідно, це доопрацювання окупиться Вам менше ніж за 2 місяці.

Сподіваємося, цей матеріал допоможе Вам прийняти правильні рішення щодо питання автоматизації Ваших бізнес-процесів.