CRM oparty na chmurze - model dostępu, dane i warunki umowy

CRM oparty na chmurze a instalacja lokalna

CRM oparty na chmurze to system zarządzania relacjami z klientami hostowany na zewnętrznych serwerach. Dane firmy nie leżą na komputerach pracowników ani w serwerowni w biurze, a dostęp do nich odbywa się przez przeglądarkę. Według opisu SoftwareStudio takie rozwiązanie eliminuje konieczność utrzymywania własnej infrastruktury serwerowej i pozwala pracować w dowolnym miejscu.

Pojęcie chmury ma precyzyjną definicję. Amerykański instytut NIST w dokumencie The NIST Definition of Cloud Computing wymienia pięć cech usługi w chmurze, w tym szybką elastyczność i pomiar zużycia. Nie każdy system udostępniony przez przeglądarkę je spełnia, dlatego przed zakupem warto sprawdzić, co dostawca rozumie pod hasłem chmura.

Trzy modele wdrożenia CRM

Wybór modelu zaczyna się od ustalenia, kto utrzymuje serwer, kto instaluje aktualizacje i gdzie leżą dane. Tabela zestawia trzy sposoby pracy z CRM, które pojawiają się w ofertach.

Model mobilny nie jest osobną alternatywą, lecz nakładką. Aplikacja na telefon czy tablet łączy się z centralną bazą, która stoi lokalnie albo w chmurze. Pozostałe rozdziały opisują, co z tego wynika w codziennej pracy.

Kiedy instalacja lokalna nadal ma sens

Chmura nie jest odpowiedzią na każde wymaganie. Firma, której polityka bezpieczeństwa zabrania przechowywania danych klientów poza własną siecią, wybierze instalację lokalną albo prywatną chmurę we własnym centrum danych. Podobnie firma z głęboką integracją CRM z lokalnym ERP może woleć serwer w tej samej sieci, ponieważ eliminuje to zależność od łącza internetowego przy każdej operacji.

Argumentem za instalacją lokalną bywa także pełna kontrola nad terminem aktualizacji. W chmurze dostawca wdraża nową wersję według własnego harmonogramu, więc firma musi zaakceptować zmiany interfejsu bez wpływu na ich termin. Dla części organizacji to zaleta, dla innych ryzyko wymagające zapisu w umowie.

Dostęp przez przeglądarkę i praca w terenie

Praca w przeglądarce oznacza brak instalacji na stanowisku. Pracownik loguje się pod wskazanym adresem, a system pokazuje aktualny stan danych, taki sam dla całego zespołu. Zmiana wprowadzona przez jednego handlowca jest widoczna dla pozostałych po odświeżeniu widoku, bo wszyscy korzystają z jednej bazy.

Wydajność zależy od dwóch czynników: opóźnienia sieci między użytkownikiem a centrum danych i sposobu, w jaki aplikacja pobiera dane. Widok listy klientów, który ładuje tysiące rekordów naraz, działa wolno nawet przy dobrym łączu. Dobrze zaprojektowana aplikacja pobiera dane stronami i filtruje je po stronie serwera, dlatego test w warunkach zbliżonych do produkcyjnych jest ważniejszy niż deklaracja z oferty.

Rejestracja wizyt u klientów

Opis systemu CRM.net wskazuje, że handlowiec rejestruje wizyty przez interfejs webowy, wybiera kontrahenta z rozwijanej listy z pełnymi danymi adresowymi, a system zapisuje czas i miejsce wizyty. Uzupełnia to notatka ze spotkania wprowadzona bezpośrednio do systemu. Szczegóły produktu znajdują się w artykułach o aplikacjach CRM i mobilnym CRM.

Aplikacja dla handlowców, którą SoftwareStudio opisuje na stronie produktu, umożliwia według opisu szybkie tworzenie ofert oraz rejestrowanie spotkań, a także raportowanie działań z urządzenia mobilnego. Dane synchronizują się z centralnym systemem CRM firmy.

Łączność mobilna i brak zasięgu

Praca w terenie wymaga zasięgu, którego nie ma w każdym miejscu. Przed wyborem trzeba sprawdzić, jak aplikacja zachowuje się bez połączenia: czy pozwala zapisać notatkę lokalnie i wysłać ją później, czy wymaga aktywnego łącza przy każdej operacji. Moduł na Androida, opisany w materiałach o CRM dla handlowca, uzupełnia aplikację działającą w przeglądarce. Podobne zagadnienia w kontekście magazynu omawia artykuł o CRM na Androida.

Skalowanie i model rozliczeń

Największą praktyczną różnicą jest sposób płacenia. Instalacja lokalna wymaga zakupu licencji i serwera na starcie, a chmura rozkłada koszt na abonament. Opis SoftwareStudio wskazuje, że firmy mogą dostosować subskrypcję do potrzeb przez dodawanie lub usuwanie użytkowników. Zmiana liczby stanowisk nie oznacza wtedy zakupu sprzętu.

Składniki kosztu CRM w chmurze

Sama opłata abonamentowa nie oddaje pełnego kosztu. Do rachunku dochodzą wdrożenie i migracja danych. Dochodzą też integracje oraz szkolenia, a przy zmianie dostawcy koszt wyjścia. Poniższy wzór ma charakter porządkujący i nie zawiera cen, bo te zależą od oferty.

koszt_roczny = liczba_uzytkownikow * oplata_miesieczna * 12
             + koszt_integracji_rocznie
             + koszt_szkolen_rocznie

koszt_calkowity_N_lat = koszt_wdrozenia + koszt_migracji
                      + N * koszt_roczny + koszt_wyjscia

Wzór pozwala porównać ofertę abonamentową z licencją stałą, dla której zamiast opłaty miesięcznej pojawia się zakup serwera wraz z licencją oraz koszt utrzymania przez dział IT. Zasady takiego porównania w innej klasie systemów opisuje artykuł o licencji i modelu SaaS w oprogramowaniu magazynowym.

Reguła: porównanie modeli robi się w horyzoncie kilku lat i z uwzględnieniem kosztu wyjścia, a nie tylko pierwszej faktury.

Bezpieczeństwo danych i podział odpowiedzialności

Często powtarzany argument mówi, że dane w chmurze są bezpieczniejsze niż w serwerowni firmy. Bywa to prawdą, ale zależy od umowy i od tego, co dostawca faktycznie zapewnia. Opis SoftwareStudio wymienia regularne kopie zapasowe i aktualizacje po stronie dostawcy jako zaletę modelu. Trzeba jednak wiedzieć, co dokładnie obejmuje ta odpowiedzialność.

Model współdzielonej odpowiedzialności

W modelu SaaS dostawca odpowiada za infrastrukturę i aktualizacje systemu, a klient za konfigurację uprawnień oraz jakość danych. Klient prowadzi też konta użytkowników. Podział ten opisuje dokumentacja współdzielonej odpowiedzialności w chmurze. Firma, która zakłada, że bezpieczeństwo załatwia dostawca, pozostawia otwarte konta byłych pracowników i zbyt szerokie role.

Kopie zapasowe i czas odtworzenia

Dla kopii zapasowych liczą się dwa parametry: RPO, czyli maksymalna ilość danych, którą można stracić, oraz RTO, czyli czas przywrócenia usługi. Dla usług opartych na Azure SQL zasady automatycznych kopii opisuje dokumentacja automatycznych kopii zapasowych. Dostawca CRM powinien podać wartości RPO i RTO w umowie, a nie tylko zapewnić, że kopie są wykonywane.

Integracje CRM z ERP i pocztą

CRM izolowany od reszty firmy wymaga podwójnego wprowadzania danych. Zamówienia i faktury klientów zwykle powstają w ERP, więc przepływ do CRM powinien być automatyczny. W modelu chmurowym integracja odbywa się przez interfejs REST, a nie przez bezpośrednie połączenie z bazą, do której klient nie ma dostępu.

Wywołanie API z ponawianiem

Wywołania przez sieć mogą się nie udać z przyczyn przejściowych. Prosta integracja ponawia próbę z rosnącym odstępem, a do żądania dołącza klucz, który zapobiega dwukrotnemu zapisowi tego samego zamówienia. Wzorzec ponawiania opisuje dokumentacja wzorca Retry. Poniższy przykład jest ogólny i nie odzwierciedla interfejsu konkretnego produktu.

async function wyslijZamowienie(zamowienie) {
  const klucz = `zam-${zamowienie.id}`;
  for (let proba = 1; proba <= 3; proba++) {
    const odp = await fetch('https://crm.example.com/api/zamowienia', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json', 'Idempotency-Key': klucz },
      body: JSON.stringify(zamowienie)
    });
    if (odp.ok) return odp.json();
    if (odp.status < 500) throw new Error(`Odrzucono: ${odp.status}`);
    await new Promise(r => setTimeout(r, 2 ** proba * 500));
  }
  throw new Error('Brak odpowiedzi serwera CRM');
}

Kody 4xx oznaczają błąd po stronie żądania, więc ponawianie nic nie da. Kody 5xx wskazują na problem po stronie serwera, w którym kolejna próba ma szansę się udać. Klucz zapobiega utworzeniu drugiego zamówienia, gdy pierwsze zostało zapisane, a odpowiedź zginęła po drodze.

Integracja z asystentem AI

Dane z CRM w chmurze mogą zasilać asystenta, który podpowiada handlowcom kolejne kroki. Zasady działania takiego rozwiązania opisuje artykuł o CRM z asystentem AI.

Integracja z pocztą i kalendarzem działa podobnie. Wiadomości i spotkania przypisuje się do klienta po adresie e-mail, a każdy błędnie dopasowany adres tworzy wpis w niewłaściwej karcie. Reguły dopasowania trzeba więc ustalić przed uruchomieniem, a nie po zapełnieniu bazy.

Raportowanie wizyt i kosztów handlowców

System CRM służy nie tylko do przechowywania kontaktów, lecz także do rozliczania pracy handlowców. Opis aplikacji CRM.net wspomina o raportowaniu wizyt i o rozliczaniu kosztów, które pozwala monitorować wydatki poszczególnych handlowców, na przykład koszty delegacji i premie, w różnych ujęciach, także według regionu.

Zestawienie kosztów według regionu

Do takiego zestawienia wystarcza zapytanie grupujące koszty wizyt według regionu i handlowca. Poniższy przykład pokazuje mechanizm, a nazwy tabel są przykładowe.

SELECT r.Nazwa AS Region,
       h.Nazwisko AS Handlowiec,
       SUM(k.Kwota) AS Koszty
FROM dbo.KosztWizyty AS k
JOIN dbo.Handlowiec   AS h ON h.HandlowiecId = k.HandlowiecId
JOIN dbo.Region       AS r ON r.RegionId = h.RegionId
WHERE k.DataWizyty >= @Od AND k.DataWizyty < @Do
GROUP BY ROLLUP (r.Nazwa, h.Nazwisko);

Klauzula ROLLUP dodaje sumy pośrednie dla regionów i sumę ogólną, dzięki czemu jeden wynik wystarcza do przeglądu w dwóch ujęciach. Składnię opisuje dokumentacja klauzuli GROUP BY w T-SQL.

Szczegółowe omówienie kosztów wizyt handlowców znajduje się w artykule o systemie CRM dla handlowca, a działanie aplikacji można zobaczyć w demonstracji CRM online.

Migracja danych do CRM w chmurze

Przeniesienie kontaktów z arkuszy lub starego CRM zaczyna się od czyszczenia, a nie od importu. Zdublowani klienci i niepełne adresy przenoszą się do nowego systemu razem z resztą danych. To samo dotyczy różnych zapisów nazwy tej samej firmy. Klucz jednoznacznej identyfikacji kontrahenta, na przykład numer NIP, pozwala wykryć duplikaty przed wczytaniem.

Tabela pośrednia i import

Dane wczytuje się najpierw do tabeli pośredniej, a stamtąd przenosi do docelowej po walidacji. Poniższy przykład pokazuje wybór kontrahentów, których jeszcze nie ma w bazie docelowej. Nazwy tabel są przykładowe.

INSERT INTO dbo.Klient (Nazwa, Nip, Miasto)
SELECT s.Nazwa, s.Nip, s.Miasto
FROM stg.Klient AS s
WHERE s.Nip IS NOT NULL
  AND NOT EXISTS (SELECT 1 FROM dbo.Klient AS k WHERE k.Nip = s.Nip);

Rekordy bez NIP wymagają ręcznego przeglądu, bo automatyczne dopasowanie po nazwie łączy różne firmy o podobnych nazwach. Po imporcie sprawdza się liczbę rekordów w obu tabelach i losową próbę kart klientów, a stary system pozostaje dostępny do odczytu przez okres przejściowy.

Zapisy umowy przy wyborze dostawcy

Model chmurowy przesuwa część kontroli do dostawcy, więc umowa staje się jedynym narzędziem, którym klient tę kontrolę odzyskuje. Cztery zapisy decydują o tym, czy zmiana dostawcy lub awaria nie zaskoczą firmy.

• Dostępność usługi - poziom określony w procentach w skali roku, z opisem rekompensaty za jego naruszenie.
• Kopie zapasowe - częstotliwość i okres przechowywania kopii oraz wartości RPO i RTO.
• Lokalizacja danych - kraj lub region centrum danych oraz lista podwykonawców przetwarzających dane.
• Eksport i wyjście - format i termin wydania kompletnych danych po rozwiązaniu umowy.

Eksport danych przy zmianie dostawcy

Wyjście z usługi jest najczęściej pomijane przy podpisywaniu umowy. Zbiór kontaktów wraz z historią i załącznikami musi dać się wyeksportować w otwartym formacie, na przykład CSV z zachowaniem powiązań między tabelami, a dostawca powinien zobowiązać się do usunięcia danych po zakończeniu współpracy.

Inne materiały o modelu chmurowym

Podobne porównania w innych obszarach zawierają artykuły o programie magazynowym w chmurze i instalacji lokalnej, o chmurze obliczeniowej w oprogramowaniu awizacyjnym oraz o architekturze systemu TMS online.