Workflow, CRM, ERP czy dedykowany system — czego naprawdę potrzebuje Twój proces?

Nie wybieraj systemu od nazwy kategorii

Rozmowa o systemach w firmie często zaczyna się od nazwy: „potrzebujemy CRM-a”, „chyba czas na ERP”, „może zbudujmy coś własnego”. Tymczasem nazwa kategorii mówi niewiele o tym, czy narzędzie rozwiąże konkretny problem. Dwa systemy z tej samej kategorii potrafią się bardzo różnić, a system z innej kategorii czasem lepiej pasuje do procesu.

Dlatego zasada tego artykułu brzmi: nie wybieraj systemu od nazwy kategorii. Zacznij od problemu i procesu. Najpierw ustal, co dokładnie nie działa i gdzie. Potem sprawdź, która klasa rozwiązań jest projektowana do takiego problemu.

W skrócie:

• CRM rozwiązuje przede wszystkim procesy związane z klientem i sprzedażą.
• ERP koordynuje główne zasoby i procesy operacyjne firmy.
• Workflow porządkuje sekwencje zadań, akceptacji i statusów.
• Dedykowany system ma uzasadnienie, gdy zachowania specyficznego dla procesu nie da się wystarczająco dobrze odwzorować w istniejących narzędziach.

Te kategorie na siebie zachodzą. Wiele CRM ma moduły zadań i prostego workflow, część ERP ma moduł sprzedaży, a narzędzia workflow pozwalają przechowywać dane klientów. Producenci rozszerzają swoje produkty w różne strony, więc granice są umowne. Podział pomaga jednak zadać właściwe pytanie: gdzie leży środek ciężkości problemu?

Cztery klasy rozwiązań w skrócie

Poniższe opisy są uproszczone. Konkretne produkty różnią się zakresem, a ten sam problem bywa rozwiązywany różnymi narzędziami.

CRM

• Czym zarządza: relacją z klientem — kontaktami, zapytaniami, ofertami, sprzedażą i historią komunikacji. Nazwa pochodzi od Customer Relationship Management.
• Co zwykle robi dobrze: pokazuje, na jakim etapie jest każdy klient i kto się nim zajmuje.
• Gdzie często przestaje wystarczać: gdy zaczyna obsługiwać procesy operacyjne, które nie dotyczą relacji z klientem.

ERP

• Czym zarządza: wspólnymi zasobami firmy i danymi operacyjnymi — magazynem, zakupami, produkcją, logistyką i informacjami potrzebnymi do rozliczeń. Nazwa pochodzi od Enterprise Resource Planning.
• Co zwykle robi dobrze: utrzymuje jedną wersję danych podstawowych, z której korzysta kilka działów.
• Gdzie często przestaje wystarczać: przy bardzo specyficznych procesach pracowników pierwszej linii, którzy potrzebują innego interfejsu niż ogólny moduł.

Workflow

• Czym zarządza: przebiegiem sprawy — stanami, akceptacjami, przydziałami i terminami. Bardziej rozbudowane narzędzia tego typu nazywa się czasem systemami BPM, od Business Process Management.
• Co zwykle robi dobrze: odpowiada na pytanie, kto robi następny krok i co utknęło.
• Gdzie często przestaje wystarczać: gdy proces potrzebuje bogatego modelu danych, którego narzędzie nie przechowuje.

Dedykowany system

• Czym zarządza: konkretnym procesem firmy — jego danymi, stanami, regułami i uprawnieniami, zaprojektowanymi pod ten proces.
• Co zwykle robi dobrze: odwzorowuje logikę, której gotowe narzędzia nie przewidują, i daje interfejs dopasowany do osób, które na nim pracują.
• Gdzie często przestaje wystarczać: gdy próbuje zastąpić dojrzałe narzędzia w obszarach standardowych, takich jak księgowość, albo gdy nikt nie odpowiada za jego rozwój.

CRM: relacja z klientem i sprzedaż

CRM porządkuje wszystko, co dzieje się między firmą a klientem, zanim i po tym, jak klient coś kupi. Typowe zastosowania:

• Leady — zapytania z formularzy, telefonów i poleceń w jednym miejscu, z informacją o źródle.
• Lejek sprzedaży — etapy, przez które przechodzi szansa sprzedaży, od pierwszego kontaktu do decyzji.
• Historia klienta — wcześniejsze oferty, zamówienia, rozmowy i ustalenia.
• Aktywność handlowa — kto, z kim i kiedy rozmawiał.
• Komunikacja i follow-up — przypomnienia o kontakcie, szablony wiadomości, zadania na kolejny krok.
• Podstawowe automatyzacje — przypisanie leada, powiadomienie, zmiana etapu po zdarzeniu.

CRM dobrze pasuje do procesu sprzedaży, kwalifikacji leadów i kontaktu z klientem po sprzedaży. Nie wszystkie systemy CRM działają tak samo: różnią się modelem danych, możliwościami konfiguracji, automatyzacjami i integracjami, więc to, co w jednym jest wbudowane, w innym wymaga dodatku albo nie jest możliwe.

Sygnały, że CRM obsługuje coś, do czego nie był projektowany:

• CRM służy jako harmonogram produkcji albo kalendarz pracy ekip.
• Złożona logika obsługi serwisowej jest wciskana w etapy lejka sprzedaży.
• Setki pól niestandardowych pełnią rolę bazy danych dla procesów niezwiązanych ze sprzedażą.
• Krytyczne informacje operacyjne istnieją tylko w notatkach do rekordu klienta.

Żaden z tych sygnałów nie oznacza automatycznie, że trzeba zmienić narzędzie. Oznacza, że warto sprawdzić, czy część procesu nie potrzebuje innego miejsca.

ERP: wspólne zasoby i dane operacyjne

ERP to system, który łączy procesy wielu działów wokół wspólnych danych. Zakres zależy od produktu i wdrożenia, ale typowe obszary to:

• współpraca z finansami i księgowością,
• magazyn i stany towarów,
• zakupy i dostawcy,
• produkcja i planowanie,
• zasoby, takie jak maszyny, pojazdy czy ludzie,
• logistyka i wysyłki,
• dane podstawowe: kartoteki towarów, kontrahentów, cenniki.

ERP dobrze pasuje do procesów silnie związanych ze wspólnymi zasobami i danymi operacyjnymi: gdy zamówienie sprzedażowe zmienia stan magazynu, uruchamia zakup i ostatecznie trafia do rozliczeń, a każdy dział widzi te same liczby.

Sygnałem złego dopasowania bywa próba odwzorowania bardzo specyficznego procesu pracowników pierwszej linii — na przykład techników w terenie — w ogólnym module ERP, gdy ci użytkownicy potrzebują zupełnie innego interfejsu: prostego, mobilnego, z kilkoma krokami zamiast kilkudziesięciu pól. W takiej sytuacji ERP często dalej jest właściwym miejscem na dane, a zmienia się tylko narzędzie, w którym ludzie wykonują pracę.

Workflow: kto robi co i kiedy

System workflow prowadzi sprawę przez zdefiniowane kroki. Jego podstawowe elementy to:

• Stany — gdzie jest sprawa: nowa, do akceptacji, w realizacji, zamknięta.
• Akceptacje — kto musi zatwierdzić, zanim sprawa pójdzie dalej.
• Przydziały — kto odpowiada za bieżący krok.
• Terminy — do kiedy krok ma być wykonany i co się dzieje po terminie.
• Kierowanie — reguły, które decydują, dokąd sprawa trafia, na przykład według kwoty albo działu.
• Powiadomienia — informacja dla osoby, na którą czeka kolejny krok.
• Widoczność procesu — lista spraw w toku i miejsc, w których coś utknęło.

Workflow dobrze pasuje do powtarzalnego procesu, w którym główny problem brzmi: „kto robi następny krok?”. Przykłady to obieg dokumentów do akceptacji, obsługa wniosków i zgłoszeń, wewnętrzne zatwierdzenia wydatków czy lista kroków przy wdrożeniu nowego pracownika.

Ograniczenie: silnik workflow może uporządkować proces, nie stając się systemem, w którym przechowywane są wszystkie dane danej dziedziny. Sprawa w workflow może wskazywać na klienta w CRM i zamówienie w ERP, ale nie musi ich zastępować. To zaleta, dopóki wiadomo, który system jest źródłem której informacji.

Prostsze przepływy da się zbudować także w platformach automatyzacji. Kiedy to wystarczy, a kiedy proces potrzebuje własnego narzędzia, opisujemy w artykule Make, n8n, Zapier czy dedykowany system. Szerzej o samej automatyzacji — na stronie automatyzacja procesów.

Dedykowany system: kiedy proces nie mieści się w gotowych narzędziach

Dedykowany system to oprogramowanie zbudowane pod konkretny proces. Nie jest z definicji lepszy ani gorszy od gotowych narzędzi. Ma inny profil: daje dopasowanie, ale wymaga budowy, utrzymania i kogoś, kto odpowiada za jego rozwój.

Kiedy ma uzasadnienie

• proces jest wyróżnikiem firmy albo ma kluczowe znaczenie dla jej działania,
• kilka systemów musi współpracować w ramach jednego procesu,
• model danych jest bardzo specyficzny i nie mieści się w polach gotowego narzędzia,
• interfejs dla osób wykonujących pracę ma duże znaczenie, na przykład w terenie albo przy obsłudze zleceń,
• uprawnienia, stany albo reguły biznesowe są specyficzne dla firmy,
• gotowe narzędzie wymaga coraz większej liczby obejść,
• proces stał się przypadkowym systemem złożonym z arkuszy i wiadomości.

Kiedy nie ma uzasadnienia

• gotowe narzędzie pokrywa już niemal wszystkie krytyczne wymagania,
• proces zmienia się co tydzień i nie jest jeszcze dobrze zrozumiany,
• wolumen jest bardzo mały,
• wartość biznesowa procesu jest niewielka,
• organizacja nie jest gotowa na utrzymanie oprogramowania.

Częstym rozwiązaniem jest mała aplikacja dedykowana, która obsługuje jedną nietypową część procesu, a resztę zostawia sprawdzonym narzędziom. Kiedy własny system ma sens, piszemy szerzej na stronie oprogramowanie dedykowane.

Porównanie: czym różnią się te klasy rozwiązań

Tabela opisuje typowe profile, a nie konkretne produkty. Nie wskazuje lepszej opcji — pokazuje, do jakiego problemu każda klasa rozwiązań jest zwykle projektowana.

Od czego zacząć: drzewo decyzyjne

Poniższe pytania pomagają wskazać punkt wyjścia do dalszej analizy. Odpowiedź „tak” nie oznacza decyzji zakupowej — oznacza, od której klasy rozwiązań warto zacząć sprawdzanie.

Najczęściej odpowiedź nie brzmi: tylko jeden system

W wielu firmach pytanie „CRM czy ERP?” jest fałszywym wyborem. Proces przechodzi przez sprzedaż, operacje i rozliczenia, a każdy z tych obszarów ma inne potrzeby. Realistyczna architektura wygląda wtedy tak:

• CRM obsługuje leady i sprzedaż,
• ERP obsługuje zamówienia, magazyn i dane do rozliczeń,
• workflow prowadzi akceptacje i przydziały,
• mała aplikacja dedykowana obsługuje część procesu, której gotowe narzędzia nie odwzorowują dobrze,
• warstwa integracyjna synchronizuje statusy między nimi.

Taki układ nie jest uniwersalnie lepszy od jednego systemu. Każde połączenie to dodatkowy element do utrzymania, a każdy system — kolejna licencja, konfiguracja i miejsce, w którym coś może się rozjechać. Ma sens wtedy, gdy każdy element rzeczywiście dobrze obsługuje swoją część procesu, a granice odpowiedzialności są jasne. Bywa też, że jeden dobrze skonfigurowany system wystarcza na lata.

Skąd wiadomo, że obecne narzędzia zamieniły się w przypadkowy system?

Przypadkowy system powstaje, gdy kolejne narzędzia, arkusze i nawyki dokładane są do procesu bez wspólnego projektu. Nikt go nie zaprojektował, ale firma na nim działa. Sygnały:

• arkusz kalkulacyjny stał się główną bazą danych procesu,
• te same dane są ręcznie kopiowane między narzędziami,
• status tej samej sprawy wygląda inaczej w trzech systemach,
• pracownicy prowadzą nieoficjalne arkusze pomocnicze,
• proces zależy od jednej osoby, która zna wyjątki,
• pola niestandardowe w CRM odwzorowują procesy niezwiązane ze sprzedażą,
• ręczne eksporty i importy są rutyną,
• nikt nie wie, który system zawiera obowiązującą wartość,
• jedna poprawka wymaga aktualizacji kilku narzędzi,
• błędy wychodzą na jaw dopiero po skardze klienta.

Żaden z tych sygnałów nie oznacza automatycznie, że firma potrzebuje własnego oprogramowania. Czasem wystarczy ustalić, który system jest źródłem danych, usunąć zbędny arkusz albo połączyć dwa narzędzia. Kiedy arkusz przestaje wystarczać i jakie są rozwiązania pośrednie, opisujemy w artykule Excel czy dedykowany system.

Przykładowa architektura: firma serwisowo-instalacyjna

Przykładowa architektura — ogólny przykład, który nie opisuje konkretnej firmy. Pokazuje, jak jeden proces może przechodzić przez kilka systemów, z których każdy odpowiada za swoją część.

Proces: zapytanie, oferta, planowanie terminu, montaż albo serwis, protokół, faktura i obsługa posprzedażowa. Możliwy podział odpowiedzialności:

• CRM — zapytanie, oferta, sprzedaż i kontakt po realizacji.
• ERP lub system księgowy — zamówienie, faktura i magazyn tam, gdzie jest potrzebny.
• Workflow — akceptacja oferty powyżej ustalonej kwoty, przydział technika.
• Dedykowana aplikacja operacyjna — praca technika na miejscu: lista czynności, zdjęcia, dane z wizyty, protokół z podpisem.
• Integracja API — synchronizacja statusu zlecenia między systemami.

Ten sam proces można zorganizować inaczej. Mała firma może prowadzić całość w jednym CRM z modułem zadań, a firma z rozbudowanym magazynem — oprzeć więcej kroków na ERP. Przykład pokazuje sposób myślenia: najpierw podział odpowiedzialności, potem wybór narzędzi.

Gdy kilka systemów musi współpracować

Każda architektura złożona z kilku systemów potrzebuje połączeń między nimi. A połączenie to coś więcej niż przesłanie danych: trzeba obsłużyć limity czasu, ponowienia, zduplikowane zdarzenia, częściowe awarie, w których jeden system wykonał krok, a drugi nie, oraz okresowe porównywanie stanu w obu systemach. Te zagadnienia opisujemy w artykule najczęstsze problemy integracji API.

Nie każde połączenie wymaga od razu własnej warstwy integracyjnej. Przy niewielkiej liczbie operacji i niewielkich skutkach błędu wystarczy często scenariusz w platformie automatyzacji. Im ważniejszy proces i im więcej systemów, tym większe znaczenie ma to, jak integracja zachowuje się w razie błędu.

Złe pytanie: jaki system kupić?

Pytanie „jaki system kupić?” zakłada, że odpowiedzią jest produkt. Lepiej zacząć od pytań o proces:

• Który proces dokładnie nie działa i po czym to widać?
• Gdzie powstaje informacja?
• Kto ją zmienia?
• Przez jakie stany przechodzi sprawa?
• Które systemy już przechowują te dane?
• Gdzie powstają podwójne wpisy?
• Czego nie da się dziś odwzorować bez obejść?
• Co naprawdę wymaga automatyzacji?
• Co powinno pozostać ręczne?

Odpowiedzi na te pytania często pokazują, że problem leży gdzie indziej, niż zakładano — w podwójnym wprowadzaniu danych, braku właściciela kroku albo w jednym nieobsłużonym wyjątku. Od takich pytań zaczynamy analizę procesu.

Wdrażanie etapami

Wybór systemu nie musi być jedną dużą decyzją. Bezpieczniej jest przechodzić przez kolejne etapy i na każdym sprawdzać, czy problem nie został już rozwiązany.

Nie każda firma powinna dojść do szóstego etapu. Czasem odpowiedzią jest ustalenie źródła danych albo lepsza konfiguracja narzędzia, które już działa.

Czy potrzebuję dedykowanego systemu? Lista pytań

Odpowiedz „tak” albo „nie” na każde pytanie:

• Czy proces przechodzi przez więcej niż jeden system?
• Czy te same dane są wprowadzane kilka razy?
• Czy reguły biznesowe są zbyt specyficzne dla obecnych narzędzi?
• Czy wyjątki są częste, ale przewidywalne?
• Czy interfejs dla osób wykonujących pracę ma duże znaczenie?
• Czy uprawnienia i przejścia między stanami są specyficzne dla firmy?
• Czy ręczne uzgadnianie danych między narzędziami jest rutyną?
• Czy błąd w procesie ma odczuwalne skutki biznesowe?
• Czy obecne obejście jest coraz trudniejsze w utrzymaniu?
• Czy proces jest na tyle stabilny, żeby go sformalizować?

Nie ma progu liczby odpowiedzi „tak”, od którego należy budować własny system. Odpowiedzi są materiałem do analizy procesu, a nie automatycznym werdyktem.

Najpierw proces, potem narzędzie

Workflow, CRM, ERP i dedykowany system to narzędzia do różnych zadań. Dobór zaczyna się od zrozumienia procesu: gdzie powstają dane, kto je zmienia, gdzie się rozjeżdżają i co naprawdę wymaga zmiany. Czasem wynikiem jest konfiguracja obecnego narzędzia, czasem integracja, a czasem mały system dla jednej części procesu. Więcej o tym, jak podchodzimy do tych decyzji, piszemy na stronach automatyzacja procesów i oprogramowanie dedykowane. Jeden widok statusów i kolejek opisujemy w realizacji INTEVO OS.

Nie wiesz, od którego narzędzia zacząć?

Opisz proces w analizie procesu: jakie kroki obejmuje, jakich narzędzi dziś używacie i gdzie coś się gubi albo dubluje. Odpowiemy na piśmie, która klasa rozwiązań ma sens — także wtedy, gdy wystarczy konfiguracja narzędzia, które już macie.