Hibák az e-beszerzési rendszer kiválasztásánál, avagy hogyan lehet egy rendszer kiválasztást menedzsment szinten elrontani

Kicsit provokatív témába kezdünk bele, de mindenki számára hasznos lesz. Szerencsére számos amerikai és nyugat-európai tapasztalat van már ezen a téren, úgyhogy itt nem magyarországi történetekről fogunk beszélni – annak ellenére, hogy azért erős párhuzamokat lehetne húzni.

A téma azért is roppant időszerű, mivel - ahogy mi már ezt előre jeleztük - a vállalatok egyre jobban kezdik a belső és tranzakciós költségeiket nézni, így az e-beszerzési rendszerek egyre nagyobb keresetnek örvendenek. Mi is számos ilyen-olyan problémával találkoztunk a cégeknél, ezért megpróbáltuk ezen hibákat egy kis csokorba szedni:

Mellékelve látunk egy folyamatot, melyet általában érdemes betartani.

Menjünk végig a szamárvezető ábránkon:

- A cégeket meg kell néznünk pénzügyi szempontból is: a kis cégek nagyobb kockázatot jelentenek (ehhez még érdemes elolvasni ezt a linket )

- Hozzáértésnél érdemes olyan céget kiválasztani, aki már valóban végzett/végez beszerzést. Általában informatikai cégek informatikai megoldásokat kínálnak, melyet valahogy rászabnak az ügyféligényekre.

- Benchmarking-nál általános probléma, hogy a vállalatok nem üzleti funkcionalitásokra, hanem inkább informatikai dolgokra koncentrálnak. Az e-beszerzési rendszerek értékelői általában informatikai munkatársakból kerülnek ki, vagy a menedzserek az ő előterjesztéseikre támaszkodnak.

- Az üzleti területek igényeit nem minden esetben mérik fel (vagy nem teljes körűen) és egyfajta elképzelt állapothoz próbálják a kiválasztást hozzáilleszteni, a folyamatokat korlátozottan definiálják előre, akkor is csak viszonylag felső szinten. Mivel az informatika játssza a legnagyobb szerepet, így a folyamatok és valós üzleti és menedzsment igények a háttérben maradnak. Ez egy természetes hozzáállás, az informatikusok az informatikai lehetőségek/problémák mentén akarnak döntést előkészíteni, így például korlátozottan alkalmasak teljes haszon/előny kalkulációk elvégzésére (második fázis, lásd egy kicsit később)

Probléma az informatikai megközelítéssel még az, hogy az informatikusok értik ugyan, de nem látják világosan az e-beszerzési rendszerek fejlődését, és hogy milyen üzemeltetési megoldások nyernek teret, illetve körvonalazzák a jövő útját. Az egyik legjellemzőbb példa, hogy a vállalatok az informatikától vezérelve saját szoftvert akarnak üzemeltetni, saját szervereken. Ez tökéletesen ellentétes a világ fejlődésével (nem véletlenül fél a Microsoft a Google-tól és akarja a Yahoo-t megvenni, ill. lásd következő Windows verziók stb.), ahol is már inkább központi applikációk nyernek teret. Ez meg van fűszerezve egy olyan megoldással, hogy bizonyos - nagy szerverkapacitással bíró - vállalatok a saját infrastruktúrájukat felajánlják használatra (Amazon, Google stb.) és ebből a kapacitásból a vállalatok a megoldásaik üzemeltetéséhez a terheltségüknek megfelelően vesznek igénybe kapacitásokat. Így nem kell a saját szervereiket a ritka csúcsterheltségre méretezni, amit talán soha, vagy több évente egyszer használnak ki. További előny, hogy az ilyen megoldások, illetve üzemeltetés kevesebb erőforrást vesz igénybe és erősebb és magasabb színvonalú a rendszergazdai támogatás, és a variábilis költség (nem kell nagy beruházásokat kifizetni).

A cégek az e-beszerzési rendszereket sok esetben stratégiainak kezelik, noha ez nem az! Éppen ezért más megközelítés kell: az e-beszerzési rendszerek a működést kell hogy támogassák!

Mellékelten a szerepek egy klasszikus megbontása a direkt és indirekt beszerzések között:

 

 

És a célja

 

A megtérülés kalkulációról már részben szót ejtettünk, de a lenti ábrán felsoroltuk a legfőbb költségblokkokat. Egyedi installáció esetén jelentősek a szoftver és hardver költségek, és ami általában még nagyon meg szokta dobni a költségeket, azok az úgynevezett change request-ek! Ezeket a szoftverszállítók nagyon szeretik, mert ezek adják a bevételeik egy jelentős részét, a vállalatvezetők pedig inkább szeretnének pontosan kalkulálható (és lehetőleg variábilis) költségeket.

 

A bevétel oldalon szintén sok esetben hiányoznak a pontos kalkulációk, vagy ezek a pontos elvárások az informatikai jellemzők árnyékában maradnak, ezzel nehezítve meg egy pontos ROI kalkulációt.

 

 

Nem ejtettünk szót még a döntési mátrix másik két eleméről, a bevezetés sebességéről, ami egy standard, jól definiált rendszernél alacsony, míg egy egyedi igényekre szabott alapszoftvernél hosszadalmas lehet.

A kockázatokról szintén szót kell ejtenünk, mert ezek, noha nehezen számszerűsíthetők, ugyanakkor nagy költségeket tudnak okozni. 

 

Javasoljuk, hogy további, a témával kapcsolatos információkért forduljanak kollégáinkhoz, akik számos rendszer elemzésében, kiválasztásában és beüzemelésében vettek már részt az elmúlt években.