Milyen a jó ERP szállítói szerződés?

Sokszor látjuk tanácsadóként, hogy az ERP-kiválasztásnál sokan a szállító kiválasztását érzik a nagy döntésnek. Azt hiszik, ha ez jól megalapozott volt, akkor innen már „csak” projektmenedzselni kell a sikerhez. A tapasztalat szerint az ideális szoftver kiválasztása csak az alap, ezer pontja van még a történetnek, ahol el lehet bukni. Ez a cikk egy pontot jár körül, ami legalább ennyire meghatározza a következő 2–5 évet: milyen szállítói szerződés keretében indul el a közös munka.

És itt érdemes rögtön tisztázni valamit: a szállítói szerződés nem csak jogi dokumentum. Valójában arról szól, hogyan fogjuk irányítani a projektet, hogyan fogjuk mérni a teljesítést, és mi történik akkor, ha eltérés van a tervhez képest.

Alap, hogy jogilag rendben legyen a szállítói szerződés

Egy jó jogi szöveg megvéd vitás helyzetekben. De egy jó ERP-szerződés ennél többet tesz: segít megelőzni a vitás helyzeteket. Egyértelművé teszi mindenki feladatait, jogait, kiegészítve egy jó Projekt Alapító Dokumentummal, ami a részletes projekt működési szabályokat fekteti le.

A bukott projekteket visszanézve sokszor azt látni, hogy a felek jó szándékkal álltak neki, csak éppen:

• túl általánosan fogalmaztak a feladatokról,
• nem volt egyértelmű, mit jelent az, hogy „kész”,
• és nem volt kézben tartva, mi számít változásnak, és hogyan kezelik.

Ezek a hiányok később szinte mindig az ügyfél oldalán okoznak plusz költséget, időveszteséget vagy működési kockázatot. Ezek aztán hatalmas feszültséget okoznak a szállítóval a szakmai kapcsolatban is. A végén mindenki veszít: az ügyfél elégedetlen, a szállító pedig nem tudja referenciaként használni a projektet.

Nem egy szállítói szerződés van, hanem több, egymásra épülő megállapodás

A legtöbb ERP-projektnél nem egy „nagy szerződést” kötünk, hanem több, egymást kiegészítő megállapodást. Tipikusan külön téma:

• A rendszer használatának feltételei és díjai (licenc vagy előfizetés).
• A bevezetési szolgáltatás (mit szállít a szállító, milyen ütemezéssel).
• Az éles indulás körüli támogatás (a fokozott odafigyelés időszaka).
• A későbbi támogatás (reakcióidők, hibakezelés, rendelkezésre állás).

A gond ott szokott kezdődni, amikor ezek nincsenek összhangban. Például a bevezetés lezártnak minősül, de a működéshez szükséges tudás vagy tesztelési eredmény még nincs a szervezetben. Papíron rendben, a valóságban kockázat. Számos bukott ERP projektet auditáltunk az elmúlt években, és ezen a ponton szinte mindegyik gyenge lábakon áll.

Fix díj igény: teljesen érthető – de ettől még kezelni kell a bizonytalanságot

A cégvezetők részéről nagyon gyakori és jogos igény a fix díj: így lehet felelősen 5 éves teljes költséget tervezni, döntést előkészíteni, és a pénzügyi kockázatot kézben tartani.

A szállítók pedig azért óvatosak a teljesen fix díjjal, mert a bevezetés során vannak nehezen előre látható tényezők:

• az adatok minősége,
• a belső döntések gyorsasága,
• a kulcsemberek rendelkezésre állása,
• a kapcsolódó rendszerek és összekötések bonyolultsága,
• és az, hogy menet közben változnak-e az igények. (vettünk egy új céget, teljesen más profillal, szuszakoljuk bele a projektbe valahogy)

A gyakorlatban ezért működnek jól a hibrid megoldások: ami jól körülírható, az rögzített díjon megy, ami bizonytalanabb, arra pedig előre megállapodott keretek és szabályok vonatkoznak. Önmagában ez nem rossz konstrukció — a lényeg az, hogy a szabályai tiszták legyenek.

A „szakmaiság” egyik legfontosabb része: hogyan zárunk le oktatást és tesztelést?

Sokan itt hibáznak a legnagyobbat, teljesen jó szándékkal.

Oktatás: mikor mondjuk, hogy lezártuk?

Nem attól lesz lezárt, hogy „megtörtént az oktatás”. Attól lesz lezárt, hogy a munkatársaink készség szinten, ténylegesen képesek használni a rendszert a saját folyamataiban.

Ezért érdemes előre rögzíteni például:

• Kiknek kell részt venniük (kulcsfelhasználók, vezetők, napi felhasználók).
• Mi az elvárt tartalom (nem „általános bemutató”, hanem a saját folyamatokra építve).
• Milyen minőségű az oktatási anyag (kapsz egy linket a szoftverleíráshoz vagy egy standard ppt-t)
• Mi számít elfogadásnak (például: gyakorlati feladatok teljesítése, egyszerű tudásellenőrzés, vagy folyamatonként kijelölt felelős jóváhagyása – mi szeretjük a vizsgáztatás sikerét és a mérföldkő teljesítését összekötni).
• Mi a felelősség: mit ad a szállító, és mit kell az ügyfélnek megszerveznie (jelenlét, idő, belső kommunikáció).

Ha ez nincs kimondva, akkor az oktatás papíron lezárul, a valóságban viszont az éles indulásnál derül ki, hogy túl sok a bizonytalanság a csapatban.

Tesztelés: mi alapján mondjuk, hogy „mehetünk élesbe”?

A tesztelésnél a legnagyobb félreértés az, hogy „kipipáltuk”. Valójában az a kérdés: a rendszer üzemszerűen használható-e, minden üzleti folyamat és aleset esetében is.

A szerződésnek (vagy a mellékleteknek) érdemes konkrétan rögzítenie:

• Ki mit tesztel (szállító, ügyfél, közösen).
• Milyen tesztlépések vannak (folyamatpróba, üzleti elfogadás).
• Milyen hiba fér bele, és milyen nem (például: lehet-e nyitott kritikus hiba az éles indulás előtt).
• Ki mondja ki a végső „mehet / nem mehet” döntést, és mi ennek a feltétele.

Ha nincsenek objektív feltételek, az éles indulás környékén könnyen vita lesz abból, hogy mi számít késznek — ez pedig azonnal kritikus helyzetet teremthet.

Zárógondolat vezetőknek

A szerződéskötésnél nem az a cél, hogy „szigorúbbak legyünk”, hanem az, hogy a projekt irányítható legyen. Ehhez jogi és szakmai gondolkodás egyszerre kell: a jog ad keretet, a szakmaiság pedig definiálja, mit jelent a teljesítés a valóságban. Hiszek a win-win helyzetekben, de ehhez le kell rakni az alapokat.