CRM та ERP: розробити, налаштувати чи інтегрувати?

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

01Налаштувати готовий продукт

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

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

02Поєднати наявні системи

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

Наприклад, CRM зберігає історію спілкування з клієнтами, а ERP — дані про виконання замовлень. Вирішіть, які записи мають бути доступні обом командам і як вони бачитимуть неповні чи запізнілі оновлення.

03Створити індивідуальне ПЗ

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

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

Кейс Global Business Assistant↗ показує взаємопов’язані процеси закупівель, складу, логістики й фінансів. Кейс порталу BDO↗ стосується документів, завдань і погоджень.

04Порівнюйте однаковий обсяг

Підготуйте для оцінки таблицю з такими рядками:

• Основний процес і підтримувані виняткові ситуації.
• Ролі, погодження та контроль доступу.
• Інтеграції й відповідальність за постійний обмін.
• Перенесення історичних даних та їх перевірка.
• Звіти, формули й узгодженість джерел.
• Запуск, підготовка користувачів і підтримка.
• Початкові та регулярні витрати з явними припущеннями.

Для кожної вимоги зазначте: підтримується, потребує налаштування, потребує розробки або ще не з’ясовано. Дослідіть невідоме до того, як вважати оцінки порівнюваними.

05Перевірте зміну замовлення між відділами

Розгляньмо умовного дистриб’ютора: відділ продажів приймає замовлення, склад резервує товар, фінансовий відділ перевіряє кредитний статус клієнта, а операційна команда організовує доставку. Після резервування клієнт змінює кількість. Корисна перевірка простежує цю зміну в усіх пов’язаних записах і звітах.

Попросіть продемонструвати однаковий сценарій у кожному запропонованому рішенні:

1. Хто має право погодити зміну й що бачить склад, поки погодження триває?
2. Яка система є основною для погодженої кількості та доступних запасів?
3. Що відбувається, якщо зв’язок із бухгалтерською системою недоступний?
4. Чи може команда виявити неповне оновлення й повторити його без дублювання замовлення?
5. Який звіт показує відхилення та хто відповідає за його усунення?

06Зафіксуйте вибір і наступні перевірки

У цьому умовному прикладі поточні CRM та ERP вже підтримують внутрішні процеси дистриб’ютора. Запис рішення визначає, що перевірити далі; запропоновані випробування ще не виконано.

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

Налаштувати: варіант залишається відкритим, якщо обраний продукт демонструє зміну, права доступу та звіт винятків за допомогою підтримуваних налаштувань. До перевірки винятку, ліцензій і відповідальності за оновлення рішення не остаточне.

Поєднати: попередній вибір, якщо CRM та ERP правильно виконують власні завдання, а бракує передачі між ними. Перевірте ідентифікатори, відповідальність і збої обміну. Наш приклад інтеграції CRM–ERP↗ показує повтори та запізнілі оновлення.

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

Рішення для прикладу: спочатку дослідити інтеграцію. Не погоджувати повну заміну, поки наявні системи відповідають внутрішнім процесам, а інтерфейс ще не перевірено. Наступна інвестиція — обмежена оцінка конектора зі зразком замовлення, зміною та перерваним обміном.

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

Зафіксуйте підстави для налаштування, інтеграції чи розробки

Порівняйте однаковий процес, зафіксуйте невідоме та докази, які змінять ваш вибір. Шаблон містить заповнений приклад дистриб’ютора.

• Один процес і його складний виняток
• Докази для кожного варіанта та невирішені припущення
• Попереднє рішення, відповідальний і наступна перевірка

Завантажити шаблон вибору підходу до ПЗ↓

Текстовий файл для редагування (.txt)

Заповніть у зручному редакторі. Для звернення надішліть короткий опис без конфіденційних даних.

07Порахуйте витрати після запуску

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

• Ліцензії продукту, платні розширення та сервіси з оплатою за використання.
• Налаштування чи розробка, тестування, міграція та запуск.
• Хостинг, моніторинг, резервні копії та перевірки відновлення.
• Підтримка, оновлення залежностей і робота адміністраторів.
• Зміни інтеграцій під час оновлення будь-якої з пов’язаних систем.
• Експорт, документація та перехід у разі подальшої зміни постачальника.

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

08Визначте, коли індивідуальна розробка передчасна

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

09Перевірте головне припущення

Якщо Salesforce є серед кандидатів, скористайтеся порівнянням власної CRM та Salesforce↗: воно розбирає один процес дистрибутора, відділяє задокументовані механізми від неперевіреного обсягу та порівнює однаковий період роботи.

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

Опишіть процес, який потрібно покращити↗, наявні системи й один складний виняток. Ми допоможемо визначити обсяг дослідження та критерії приймання. Розділ вартості й процесу роботи↗ пояснює, як цей обсяг стає основою пропозиції.