Egy vállalati szoftver kiválasztása ritkán pusztán informatikai döntés. A rendszer évekre befolyásolhatja a folyamatokat, az adatok kezelését, a munkatársak napi működését és azt is, milyen könnyen képes később változni a szervezet.
ERP, CRM, workflow-, ügyviteli, HR- vagy más vállalati rendszer kiválasztásakor könnyű már az elején a termékekre koncentrálni: melyik rendszer mit tud, milyen moduljai vannak, mennyibe kerül, van-e mobilalkalmazása, használ-e mesterséges intelligenciát, és milyen referenciákat mutat a szállító.
Ezek releváns kérdések. Csakhogy van előttük egy fontosabb lépés.
Először nem a szoftvert kell megérteni, hanem azt a működést, amelybe a szoftver érkezni fog.
A rendszer önmagában nem teremt üzleti értéket. Egy technikailag megfelelő megoldás is okozhat csalódást, ha rosszul definiált problémára választották, nem illeszkedik a kulcsfolyamatokhoz, a szükséges adatok nem állnak rendelkezésre, vagy a szervezet nem képes a rendszer lehetőségeit ténylegesen kihasználni.
A követelmények tisztázásának jelentőségét projektmenedzsment-kutatások is alátámasztják. A Project Management Institute több mint 2000 projekt- és üzletielemzés-szakember bevonásával készült kutatásában az eredménytelen projektek közel felénél a pontatlan követelménykezelés hozzájárult ahhoz, hogy a projekt nem érte el eredeti céljait. 1
Ez természetesen nem jelenti azt, hogy minden sikertelen rendszerbevezetés oka a követelményekben keresendő. Azt viszont jól mutatja, hogy a probléma és az elvárások tisztázása nem adminisztratív előkészítés, hanem a döntés egyik lényegi része.
- Milyen üzleti problémát akarunk valójában megoldani?
- Hogyan működik ma az érintett folyamat?
- Mit szeretnénk megtartani és mit megváltoztatni?
- Kik fogják ténylegesen használni a rendszert?
- Mely követelmények valóban kritikusak?
- Hogyan kapcsolódik a meglévő rendszerekhez és adatokhoz?
- Mennyi lesz a rendszer valódi költsége?
- Milyen biztonsági és beszállítói kockázatot vállalunk?
- Mi történik, ha később másik rendszerre akarunk váltani?
- Honnan tudjuk majd, hogy jó döntést hoztunk?
Milyen üzleti problémát akarunk valójában megoldani?
Meglepően könnyű egy megoldással kezdeni.
Ezek azonban még nem feltétlenül üzleti problémák. Inkább feltételezett megoldások.
A mögöttes probléma lehet például az, hogy:
- az értékesítési információk több helyen találhatók;
- nem követhető egyértelműen egy megrendelés státusza;
- túl sok manuális adatbevitel történik;
- ugyanazt az adatot több rendszerben is rögzítik;
- a vezetők későn jutnak megbízható információhoz;
- egy folyamat túl sok ember közreműködését igényli;
- a hibák csak a folyamat végén derülnek ki.
„CRM kell.”
„Az értékesítési folyamat több pontján elvesznek vagy nem követhetők az ügyfélinformációk.”
Ha azt mondjuk, hogy „CRM kell”, már egy megoldási kategóriát választottunk. Ha viszont a problémát fogalmazzuk meg, nyitva hagyjuk, hogy valóban új rendszerre, integrációra, folyamatmódosításra vagy ezek kombinációjára van-e szükség.
Ha erre nincs egyértelmű válasz, valószínűleg még korai termékeket összehasonlítani.
Hogyan működik ma az a folyamat, amelyet a rendszernek támogatnia kell?
Nem azt érdemes elsőként dokumentálni, hogy a folyamatnak hogyan kellene működnie, hanem azt, hogyan működik ténylegesen.
A hivatalos folyamat szerint például egy megrendelés három lépésben jóváhagyható. A valóságban azonban lehet:
- egy e-mailes egyeztetés;
- egy Excel-frissítés;
- egy telefon a pénzügynek;
- egy vezetői jóváhagyás;
- egy adatbevitel az egyik rendszerbe;
- majd ugyanennek az adatnak a rögzítése egy másikban.
A dokumentált folyamat és a tényleges működés nem feltétlenül ugyanaz.
Ha csak az elméleti folyamatból indulunk ki, könnyen olyan rendszert választunk, amely papíron megfelelő, a napi működésben azonban komoly kompromisszumokat igényel.
ERP-rendszerek kiválasztásával foglalkozó kutatások is hangsúlyozzák a rendszer és az üzleti folyamatok közötti illeszkedést. 2
A folyamat feltérképezésének ráadásul van egy további előnye: láthatóvá válik, hogy mit nem kellene átvinni az új rendszerbe.
Mit szeretnénk megtartani a jelenlegi működésből — és mit szeretnénk megváltoztatni?
Egy rendszerbevezetésnél két szélsőség is problémát okozhat.
„A rendszer alkalmazkodjon mindenben hozzánk.”
Ennek következménye sok egyedi fejlesztés, konfiguráció és későbbi karbantartási igény lehet.
„Mostantól úgy működünk, ahogy a rendszer engedi.”
Ez olyan működési kompromisszumokhoz vezethet, amelyek nem illeszkednek a vállalat valódi igényeihez.
A kérdés ezért nem az, hogy a vállalat vagy a rendszer alkalmazkodjon-e, hanem az, hogy mely pontokon indokolt a folyamatot megváltoztatni, és mely pontokon jelent valódi üzleti követelményt a jelenlegi működés megtartása.
Kik fogják ténylegesen használni a rendszert — és mire?
A rendszer kiválasztását végzők és a rendszer napi felhasználói gyakran nem ugyanazok az emberek.
- riportálás;
- átláthatóság;
- kontroll;
- összehasonlítható adatok;
- döntéstámogatás.
- hány adatmezőt kell kitölteni;
- mennyi idő egy ügylet rögzítése;
- hogyan kezelhetők a kivételek;
- mennyire könnyű javítani egy hibát.
Mindkét nézőpont jogos, és mindkettő szükséges.
A felhasználói elfogadásról szóló kutatások szerint a rendszer észlelt hasznossága, használhatósága és a felhasználói bevonódás összefügghet a tényleges használati hajlandósággal. 3
A felhasználók bevonása nem garantálja a projekt sikerét. Arra viszont alkalmas, hogy korábban felszínre kerüljenek olyan munkafolyamatok, kivételek és használhatósági problémák, amelyeket a döntéshozók másként látnak.
Melyek a valóban kritikus követelmények — és melyek csak kívánságok?
Egy szoftverkiválasztási folyamat során könnyen kialakul egy több száz soros követelménylista. A probléma nem a részletesség, hanem az, ha minden követelmény ugyanolyan súlyúnak tűnik.
Enélkül a rendszer nem képes megfelelően támogatni egy alapvető üzleti folyamatot, jogszabályi elvárást vagy működési feltételt.
Jelentős előnyt ad, de adott esetben kerülőmegoldással vagy folyamatmódosítással kezelhető.
Hasznos lenne, de önmagában nem indokolhatja egy egyébként kevésbé megfelelő rendszer kiválasztását.
A rendszer kiválasztása nem funkciószámlálási verseny.
Nem feltétlenül az a jobb rendszer, amelyik több funkciót tud. Az a jobb választás, amelyik megfelelően támogatja a szervezet számára fontos működést, elfogadható kockázat és teljes költség mellett.
Hogyan fog kapcsolódni a rendszer a meglévő rendszereinkhez és adatainkhoz?
Egy vállalati rendszer szinte soha nem teljesen elszigetelten működik. Kapcsolódhat például:
- pénzügyi rendszerhez;
- CRM-hez;
- webshophoz;
- HR-rendszerhez;
- dokumentumkezeléshez;
- BI-megoldáshoz;
- gyártási rendszerhez;
- ügyfél- vagy beszállítói portálhoz.
Három kérdés, amit már az elején tisztázni kell
Milyen adat érkezik a rendszerbe?
Honnan származik, ki felel érte, és milyen minőségű?
Milyen adat távozik belőle?
Mely rendszerek használják tovább, milyen gyakran és milyen formában?
Mi lesz az elsődleges adatforrás?
Ha ugyanaz az ügyfél, termék vagy szerződés több rendszerben szerepel, egyértelműnek kell lennie, hol található a hiteles törzsadat.
Az integráció kérdését későbbre hagyni azért kockázatos, mert egy önmagában megfelelő szoftver is nehezen használható vállalati megoldássá válhat, ha az adatáramlás csak jelentős manuális munkával vagy komplex egyedi fejlesztésekkel oldható meg.
Mennyi lesz a rendszer valódi költsége — nem csak a licenc ára?
Két ajánlat összehasonlításakor a havidíj vagy licencdíj látványos szám. De nem feltétlenül ez mutatja meg a döntés gazdasági hatását.
Különösen SaaS-rendszereknél érdemes előre tisztázni:
- hogyan változhat az ár a felhasználók számával;
- mely funkciók igényelnek magasabb csomagot;
- milyen díja van az API-hozzáférésnek vagy integrációnak;
- milyen formában exportálható az adat;
- milyen támogatási szintek tartoznak az előfizetéshez.
Szoftver A ára vs. szoftver B ára
A két alternatíva várható teljes költsége és várható üzleti értéke egy ésszerű időtávon.
Milyen biztonsági, adatvédelmi és beszállítói kockázatot vállalunk?
Egy vállalati szoftver kiválasztásával nemcsak funkciókat vásárolunk. Bizonyos mértékig a szolgáltató működésére is ráutaljuk magunkat.
Érdemes megvizsgálni többek között:
- hol tárolják és dolgozzák fel az adatokat;
- milyen hozzáférés-kezelés érhető el;
- támogatott-e a többfaktoros hitelesítés;
- milyen naplózási lehetőségek vannak;
- hogyan kezeli a szolgáltató a biztonsági incidenseket;
- milyen mentési és helyreállítási lehetőségek vannak;
- milyen alvállalkozók vesznek részt a szolgáltatásban;
- milyen adatvédelmi és szerződéses kötelezettségeket vállal.
A NIST 2026-os beszállítói due-diligence útmutatója is azt hangsúlyozza, hogy az ICT-beszállítókkal kapcsolatos kockázatokat érdemes már a beszerzési döntés előtt megvizsgálni. 4
Az átvilágítás mélységét természetesen a kockázathoz kell igazítani. Egy kisebb belső feladatkezelő rendszer és egy kritikus üzleti rendszer nem igényel azonos vizsgálatot.
Mi történik, ha három év múlva másik rendszerre akarunk váltani?
Ezt a kérdést kevésbé kellemes feltenni egy új kapcsolat elején. Pedig éppen ekkor a legolcsóbb megválaszolni.
- Exportálhatók-e az adataink?
- Milyen formátumban?
- Milyen költséggel?
- Rendelkezésre állnak-e megfelelő API-k?
- Kié az egyedi konfiguráció vagy fejlesztés?
- Milyen dokumentációt kapunk?
- Mennyi idő alatt mondható fel a szolgáltatás?
- Mi történik az adatainkkal a szerződés megszűnése után?
A technológiai lock-in önmagában nem feltétlenül rossz. Egy mély integráció vagy specializált platform jelentős üzleti értéket teremthet, miközben nehezebbé teszi a későbbi váltást.
A brit kormány technológiai útmutatója is azt javasolja, hogy a szolgáltatóváltás lehetőségét már a technológiai döntések során vegyék figyelembe. 5
Honnan fogjuk tudni 6 vagy 12 hónap múlva, hogy jó döntést hoztunk?
Talán ez a legfontosabb kérdés mind közül.
Ha a rendszer sikerének definíciója mindössze az, hogy „működik és használjuk”, akkor nagyon alacsonyra tettük a lécet.
Érdemes már a kiválasztás előtt meghatározni, milyen változást várunk. Például:
Nem minden eredmény mérhető ilyen egyszerűen, és nem minden javulás tulajdonítható kizárólag a szoftvernek.
A mérőszámok célja ezért nem az, hogy mesterséges pontosságot teremtsünk, hanem az, hogy legyen egy előre rögzített elképzelésünk arról: milyen üzleti változás indokolja a beruházást.
A PMI 2024-es kutatásában a megkérdezettek 74%-a úgy definiálta a projekt sikerét, hogy az idő- és költségkeret teljesülése mellett értékes eredménynek is létre kell jönnie. 6
A rendszer nem attól jó beruházás, hogy bevezettük.
Attól válhat jó beruházássá, hogy a szervezet képes vele jobb működést létrehozni.
A jó szoftverkiválasztás nem a demón kezdődik
Egy meggyőző termékbemutató hasznos, de veszélyes is lehet, ha még nem tudjuk pontosan, mit keresünk.
A bemutató szükségszerűen azt mutatja meg, amiben a rendszer erős. A vállalat feladata ezzel szemben annak meghatározása, amiben neki kell erősnek lennie.
Ezért érdemes megfordítani a megszokott sorrendet.
„Melyik rendszer tetszik a legjobban?”
„Melyik megoldás illeszkedik legjobban ahhoz a működéshez, amelyet létre szeretnénk hozni?”
10 kérdés szoftverkiválasztás előtt
-
1
Milyen üzleti problémát akarunk megoldani?
-
2
Hogyan működik ma az érintett folyamat?
-
3
Mit akarunk megtartani, és mit akarunk megváltoztatni?
-
4
Kik használják majd a rendszert, és mire?
-
5
Mely követelmények valóban kritikusak?
-
6
Hogyan kapcsolódik majd a meglévő rendszerekhez és adatokhoz?
-
7
Mennyi a várható teljes költsége?
-
8
Milyen biztonsági, adatvédelmi és beszállítói kockázatot jelent?
-
9
Hogyan tudunk majd kilépni vagy rendszert váltani?
-
10
Miből fogjuk tudni, hogy a beruházás elérte a célját?
Ha ezekre nincs megfelelő válasz, az nem feltétlenül jelenti azt, hogy rossz rendszereket vizsgálunk.
Lehet, hogy egyszerűen még nem a rendszer kiválasztása a következő lépés.
Források és további olvasmányok
- Project Management Institute: Requirements Management – Core Competency for Project and Program Success
- ERP selection and business process fit research – ScienceDirect
- Amoako-Gyampah: Perceived usefulness, user involvement and behavioral intention in ERP implementation
- NIST SP 1326: Cybersecurity Supply Chain Risk Management – Due Diligence Assessment Quick-Start Guide
- UK Government: Managing technical lock-in in the cloud
- Project Management Institute: Maximizing Project Success – What is Project Success?