Hogyan készítse fel vállalatát a workflow/BPM/RPA/ERP/CRM rendszer kiválasztására, hogy elkerülje a vendor lock-int?

Ezután rögzítse azokat a követelményeket, amelyek védenek a vendor lock-in ellen: az adatok és az ügyek előzményeinek exportálhatósága nyílt formátumban, dokumentált API, BPMN szabványban rögzített folyamatok, saját konfigurációhoz való jog és egyértelmű kilépési feltételek a szerződésből. Nevezze meg azokat a kockázatokat, amelyeket ma már azonosítani tud. Ne legyen naiv, és írja össze az összes kockázatot. Az ajánlatokat saját forgatókönyvek alapján és többéves teljes költség (TCO) szerint hasonlítsa össze (beruházás plusz ismétlődő üzemeltetési költségek). Licencek, megújítások, oktatás, a csapat fenntartása, módosítások, migrációk. Gondolja át, mennyire valószínű, hogy a szállító elveszíti kulcsfontosságú tanácsadóit, úgy dönt, hogy az adminisztrátorokat és fejlesztőket mesterséges intelligenciával helyettesíti, vagy megszünteti a jelenlegi operációs rendszer támogatását.

Ez a bejegyzés azoknak a vállalati és önkormányzati tulajdonú társaságok (spółka komunalna) vezetőinek szól, akik rendet szeretnének tenni a dokumentumok, a költségszámlák, a szerződések vagy a kérelmek kezelésében, és egy workflow rendszer kiválasztása előtt állnak – vagyis olyan eszköz előtt, amely az ügyet egyik személytől a másikig vezeti előre meghatározott szabályok szerint. Jellemzően három út közül lehet választani: kész BPM-platform, low-code eszköz vagy egyedi fejlesztésű, megrendelésre írt rendszer; az alábbi elvek mindhárom esetben érvényesek. Hasznos lehet a pénzügyi igazgatóknak is, hiszen jellemzően ők fizetik meg egy rossz döntés következményeit.

Miért alakul ki a vendor lock-in már az induláskor

A vendor lock-in ritkán egyetlen rossz döntés következménye. Rendszerint korábban kezdődik, mint ahogy a vállalat ezt észrevenné: a folyamatok a szállító eszközében kerülnek dokumentálásra, nem a saját dokumentumokban; az adatok és az ügyek előzményei olyan formátumban vannak, amelyből nem könnyű kinyerni őket; a konfigurációt csak a bevezetést végző partner ismeri; a szerződés pedig sokat mond a bevezetésről, de keveset arról, mi történik, ha a vállalat ki szeretne lépni. Néhány év múlva a rendszerváltás többe kerül, mint a fenntartása, még akkor is, ha az már nem felel meg az igényeknek.

1. lépés: Írja le a folyamatokat, mielőtt a szállítókkal tárgyalni kezd

Mielőtt elkészülne az ajánlatkérés, érdemes leírni azokat az ügymeneteket, amelyeket a rendszernek ki kell szolgálnia: ki jelenti be az ügyet, ki és milyen sorrendben hagyja jóvá, melyek a kivételek és a küszöbértékek (például egy meghatározott összeg felett eltérő útvonal), mik a határidők, és milyen döntési nyomnak kell megmaradnia egy esetleges audit esetére. Ezt legjobb BPMN szabványban rögzíteni, amelyet különböző eszközök is értenek. Így a folyamat leírása a vállalaté marad, nem a rendszeré.

Egy ilyen leírás nélkül valójában a szállítók bemutatóit hasonlítják össze, nem a megoldásokat. Minden bemutató jól néz ki, mert a szállító a saját legjobb forgatókönyvét mutatja be, nem az Önök legnehezebb kivételét.

2. lépés: Nézze meg, mi áll már rendelkezésére

Az ügymenetek egy része gyakran a vállalat már meglévő eszközeivel is kezelhető: a CRM-ben, az ágazati rendszerekben, az iktatórendszerben vagy az irodai csomagban. Az elemzés néha arra a következtetésre jut, hogy nincs szükség új rendszerre, elég egy eljárás vagy konfiguráció módosítása. Egy ilyen leltár azokat az integrációkat is megmutatja, amelyeket az új rendszernek kezelnie kell majd – például a pénzügyi-könyvelési rendszerrel és a KSeF-fel (lengyel elektronikus számlázási rendszer) –, valamint azokat a pontokat, ahol ma elvész az információ. Bővebben: informatikai rendszerek leltározása.

3. lépés: A vendor lock-in ellen védő követelmények

Ezeket a követelményeket érdemes feltételként, nem pedig kívánságként beépíteni az ajánlatkérésbe:

1. Az adatok és az ügyek előzményeinek exportálhatósága nyílt, dokumentált formátumban, bármikor és külön díj nélkül.
2. Dokumentált API más rendszerekkel való integrációhoz, azzal a joggal, hogy azt más szállítók is használhassák.
3. Szabványban (BPMN) rögzített folyamatok, amelyek exportálhatók és máshol is újraépíthetők.
4. A konfigurációhoz való jog a saját csapat vagy bármely partner számára, a módosítások dokumentálásával.
5. A szerződésből való kilépés szabályai: átmeneti időszak, segítség az adatmigrációban, és annak előre ismert költsége.
6. Az üzemeltetési partner szabad megválasztása: a bevezetés után át lehet-e váltani másik bevezetőpartnerre a gyártói támogatás elvesztése nélkül.

Ugyanez vonatkozik az RPA-ra, az ERP-re és a CRM-re is

Ezek az elvek minden olyan rendszerre érvényesek, amely rendet tesz a vállalat munkájában. Mindig érdemes azonban azzal a kérdéssel kezdeni, hogy mit szeretnénk elérni, mert a válasz határozza meg, hogy egyáltalán a megfelelő eszközosztályt választjuk-e.

RPA. Az első kérdés az, hogy miért éppen RPA-t választanánk, és nem BPM-et? A szoftverrobot átveszi az ember ismétlődő feladatait a meglévő rendszerekben, de magát a folyamatot nem változtatja meg; a BPM viszont magát a folyamatot teszi rendbe. Ha a cél az, hogy tehermentesítsük az embereket az adatok rendszerek közötti átírásától, a robot elegendő lehet. Ha a cél egy új, rövidebb ügymenet, a robot gyakran a régit rögzíti. A robot ezenkívül függ a többi rendszer képernyőitől és formátumaitól: ezek bármilyen változása megállíthatja, ezért érdemes ismerni a forgatókönyvek fenntartási költségét, és a leírásukat a gyártó eszközén kívül is tárolni.

ERP. Itt a kulcskérdés az, hogy az ERP-nek a legjobb gyakorlatokat és kész folyamatokat kell-e biztosítania, vagy a mi saját, versenyelőnyt teremtő folyamatainkat kell-e támogatnia. Az első esetben érdemes a rendszer szabványához tartani magunkat, és korlátozni a módosításokat, mert mindegyik megnehezíti a frissítéseket és a partnerváltást. A második esetben néha jobban beválik egy egyszerű ERP, amelyet egy rugalmas BPM rendszer vesz körül, és amelyben a vállalatot megkülönböztető folyamatokat a mag átalakítása nélkül lehet módosítani. Mindkét esetben a pénzügyi, raktár- és személyzeti adatoknak, valamint a KSeF-fel és a bankokkal való integrációknak teljes egészükben, az előzményekkel együtt exportálhatónak kell lenniük.

CRM. Mielőtt az ajánlatok összehasonlításába kezdenénk, érdemes tisztázni, mit értünk CRM alatt: az ügyfélszolgálati folyamatok rendbetételét, a többcsatornás értékesítést vagy a szerződésszerzési platformot. Ez három különböző projekt, más felhasználókkal, más integrációkkal és más sikermérővel. A változattól függetlenül az ügyféladatbázis – a kapcsolattörténettel és a hozzájárulásokkal együtt történő – exportálhatóságának, valamint az értékesítési és ügyfélszolgálati rendszerekhez kapcsolódó API-nak feltételként, nem pedig kiegészítésként kell szerepelnie az ajánlatkérésben.

4. lépés: Hasonlítsa össze a teljes költséget, ne a licencárat

Az ajánlatokat érdemes többéves teljes költség alapján összevetni: beszerzés és bevezetés, üzemeltetés és licencek, fejlesztés, valamint a szerződésből való kilépés költsége. A legolcsóbb licenc gyakran a harmadik évben bizonyul a legdrágábbnak, amikor minden folyamatmódosítás egyetlen partnernél fizetős megrendelést jelent. Az összehasonlítást legjobb az Önök saját forgatókönyvein elvégezni: minden szállító ugyanazt a nehéz esetet mutassa be az Önök vállalatától. Bővebben az ajánlatok értékeléséről: ajánlatok értékelése és tárgyalások a szállítókkal.

5. lépés: Átvétel és üzemeltetési szerződés

A rendszert érdemes előre egyeztetett tesztforgatókönyvek és kritériumok alapján átvenni, nem a szállító nyilatkozatai szerint. Az üzemeltetési szerződésnek meg kell határoznia, milyen időn belül hárítják el a hibákat, ki és milyen áron hajtja végre a módosításokat, valamint meg kell erősítenie az adatexportra és a szerződésből való kilépésre vonatkozó rendelkezéseket.

Gyakorlati példa

Egy nemzetközi konszern leányvállalati csoportjában a vállalat központi ERP-rendszert használt, ugyanakkor automatizálnia kellett a procure-to-pay csoportba tartozó pénzügyi folyamatokat, mégpedig a vállalati beszerzési irányelveknek (corporate purchasing guidelines) megfelelően. Erős volt a kísértés, hogy a vállalati csoportmunka-eszközöket válasszák, de ezek meglehetősen drágának bizonyultak, és nem feleltek meg sem a függetlenségi követelményeknek, sem a könnyű kilépés igényének, ha problémák merülnének fel.

Az érdekelt felekkel tartott megbeszéléseken olyan részletes követelményleírást készítettünk, amely túlmutatott a kész megoldások szabványos funkcióin. Több alternatív módot dolgoztunk ki az ágazati rendszerekkel való integrációra, valamint olyan mechanizmusokat, amelyek csökkentik az egyetlen szállítóhoz való kötődés kockázatát. Az eredmény egy szabványokon alapuló, koherens alkalmazásstratégia lett, valamint egy olyan környezet, amelyben az új ügymenetek rugalmasan jönnek létre, a folyamatgazdákkal – köztük nem technikai szakemberekkel is – tartott rövid megbeszéléseken végzett prototípuskészítés révén. Ez a környezet veszi körül az ERP-rendszert: nagy rugalmasságot biztosít ott, ahol a vállalat megkülönbözteti magát, nagy bevezetési projektek költségei nélkül.