Webtown blog

Gondolataink cikkekbe rendszerezve

null Gátfutás szögesdróttal

Gábor Lázár

Gátfutás szögesdróttal - a beszerzésbe kódolt bukás

Ha feketén-fehéren nézzük a dolgot, szállítóként kijelenthetjük, hogy a vállalati beszerzés jó dolog. Kérnek valamit, amit mi eladunk nekik. Ők ezért fizetnek, tehát mi pénzt kapunk. Miért viszolyog mégis minden szoftverfejlesztéssel foglalkozó cég jóérzésű munkatársa a beszerzési folyamatoktól? Nem viszolyog. Tegyük fel kicsit másképpen a kérdést: miért viszolyog mégis minden szoftverfejlesztéssel foglalkozó cég jóérzésű, alkotni és értéket teremteni kívánó munkatársa a beszerzési folyamatoktól? Na, erre próbálunk választ találni.

Kezdjük az elején. 

 

Hogyan néz ki egyszerűsítve egy átlagos nagyvállalati szoftverfejlesztési projekt?

Onnan indul, hogy valahol keletkezik egy üzleti igény, melyet egy új szoftverrel szeretnének kiszolgálni. Valamilyen módon jóváhagyást kap az igény, elindul a beszerzési folyamat, hogy megtalálják az ideális beszállítót. A beszerzési folyamat végén előáll az az örömteli helyzet, hogy a már említett ideális beszállítót megtalálta a szervezet, sikerült aláírni mindent, elkezdődhet a fejlesztés. Ha már elkezdődött a fejlesztés, az le is zárul szépen. A megrendelő illetékesei aláírják a teljesítési igazolásokat, a szállító számláz, mindenki boldog, mindenki mosolyog, projektnek vége és pont.

Tegye fel a kezét, aki szerint az ilyen folyamatok vannak túlsúlyban, hadd lássam a kezeket!

Senki?

Rendben.

Kijelenthetjük ugyanis, hogy a fehér hollók gyakoriságával vetekszik az az állapot, amikor mindenki valóban jó szájízzel zárhat le egy projektet.

Ha lecsupaszítjuk a szituációt, akkor azt láthatjuk általában, hogy a megrendelői oldalon éppen azok nem tűnnek boldognak, akiktől az üzleti igény kiszolgálására tett kísérlet elindult.

Szállítói oldalon pedig még a projekt elején eltörik valami: a beszerzési folyamat során. Hiszen az esetek 99,9 százalékában az a helyzet, hogy a már fentebb említett, szoftverfejlesztéssel foglalkozó cég jóérzésű, alkotni és értéket teremteni kívánó munkatársai valóban szeretnék kiszolgálni a megrendelői oldal üzleti igényeit, azonban a funkciók (és úgy általában a lendület) jelentős része már az ártárgyalások során elpárolog.

Elpárolog, mert el kell, hogy párologjon.

 

Hogyan is néz ki a matek?
Lássunk egy példát:

Adott egy üzleti igény, melyet a beszerzési dokumentáció szerint egy szoftver 1000 funkciója szolgálhat ki, valamint adott egy csapat, akik a 1000 funkciót 1000 “embernap” alatt le tudják szállítani. A csapat “üzemeltetési költségei” (munkabér, rezsi stb.) 1000 forintot emésztenek fel 1000 embernap során, a szállító cég pedig szeretne a projekten mondjuk 200 forintot keresni, így beadja az ajánlatát az üzleti igény 1000 funkcióval történő kiszolgálására, 1000 embernapos határidővel, 1200 forintért.

Elindul az ártárgyalás, pörög a negatív licit és hirtelen ott tartunk, hogy az 1200 forintos ajánlattal a szállítónak esélye sincs nyerni. Elindulunk lefelé. Jó esetben megáll a licit valahol 1000 forint felett, így minimális profittal van esély kiszolgálni a megrendelői igényeket. Rosszabb esetben nulla forintos várható profittal vág bele a szállító a projektbe és bízik benne, hogy valahogy még tud pénzt keresni. Egy olyan szállító, aki nincs rákényszerülve az “ingyen munkára”, kiszáll a licitből már akkor, amikor a várható profit nullára csökkent. 

Azonban, ha valakinek nagyon kell az adott munka (akár azért, mert nincs egyéb munka a láthatáron, akár azért, mert referenciának, vagy hosszabb távú befektetésnek jónak tűnik az adott megrendelő), az belemegy a nullszaldós projektbe is, vagy akár a mínuszosnak tűnő szituációt is bevállalja.

És itt már bukott is a projekt. 

Milyen kudarc-indikátorokat láthatunk a fenti példában?
Eleve mínuszosnak, vagy nullszaldósnak ígérkező projekt esetében a szállítónak egy esélye van a kiadások ellensúlyozására: törekedni a minél kevesebb befektetésre, a beszerzés által megfogalmazott minimum elvárások teljesítésére hajtani (csak a TIG számít és, hogy minél hamarabb véget érjen a projekt). Ebben az esetben a veszteség-minimalizálásra hajtó szállító már a projekt elején sérült, a valós üzleti igények kiszolgálására vágyó megrendelő pedig a közös, konstruktív gondolkodást veszíti el. Minimum.

Aztán ott az idő. A fenti példa talán túlzottan is ideális állapotot vázolt, ugyanis meglepően ritka, hogy a megrendelői oldal a szállító csapata által becsült fejlesztési időre csak úgy rábólint, de ezzel az aprósággal már ne bonyolítsuk a szituációt... :)

Egy átlagos nagyvállalati projektben (kb. 10-15 hónapos fejlesztési idővel számolva) a projekt elején megfogalmazott igények alapján összeírt funkcionális és dokumentációs követelmények megvalósulnak ugyan, de egészen biztosan semmi aktualizálás nem történik a projekt során, így az igények igen nagy része már nem lesz aktuális a projekt végére. Ahogy a University of Missouri, Kansas City tanulmányából is látszik, 2011-ben már olyan sebességgel pörgött a világ, hogy a korábban megfogalmazott követelmények fele 6 hónap elteltével már abszolút elavulttá vált:

 

Tehát a példa alapján vázolt 1000 embernapos fejlesztés végére (számoljunk az egyszerűség kedvéért 4 fős fejlesztői csapattal, akik folyamatosan csak ezen a projekten dolgoznak, így 250 munkanap, azaz kereken 1 év szükséges a nettó fejlesztésre) az igények alapján összeírt 1000 funkcióból jó eséllyel csak kb. 250-re van valós igény, a többivel teljesen felesleges foglalkozni, mert elavulttá vált.

 

Tegye fel a kezét, aki szerint költséghatékony megoldásnak tűnik szükségtelen dolgok elkészítése!

Senki?

Rendben.

 

Akkor nézzük, hogy hol bukott még el a példa-projekt.

Figyelt valaki, hogy az üzleti igényekből hogyan, miként és főleg miért lett egy 1000 funkcióból álló követelmény-lista a beszerzési dokumentációban? Mikor született meg az a gondolat bárki fejében, hogy egy hosszú átfutási időre tervezett projekt összes követelménye előre rögzíthető, a piaci történések figyelembe vételének teljes figyelmen kívül hagyásával?

Miért érezte azt valaki, hogy az üzleti igények céljának megfejtése helyett már a folyamat elején, párbeszéd és tapasztalat-alapú ötletek, javaslatok helyett eszközöket célszerű definiálni?

Vannak az informatikában szakértők. Nekik az a dolguk, hogy szakértsenek. Egy jó szakértő azonban nem jós. Ezért nem szakért meg előre egy nettó 1 év átfutású fejlesztési projektet, hanem a kisebb, priorizált, aktualizált és validált igények kiszolgálását igyekszik segíteni. Ettől lesz ő jó, nem pedig jós.

 

Igazából ott felejthetjük el a sikert, ahol a szereplők sokasodni kezdenek.

Vegyünk alapul egy átlagos nagyvállalatot. Az egyes részlegek gondosan le vannak választva egymásról, a részlegek közti kommunikáció legbiztonságosabb módja a rendszeres igazgatósági meetingeken történik, felsővezetői szinten (mert hát ugye alsóbb szinteken miért keresse magának az ember a bajt, ha egyszer vannak folyamatok is..), addig pedig néhány emberen azért át kell jutnia az üzeneteknek...

 

Hogy ez milyen hatásokkal jár, arról itt egy igen rossz minőségű, de legalább annyira pazar mozgóképes illusztráció:

 

Ezt a jelenséget a nagyvállalati silósodás rendkívül hatékonyan segíti elő.

Adott egy osztály, ahol az első üzleti igények keletkeznek. Ők valahogyan elérik a szervezetben, hogy megpróbálják kiszolgálni ezeket az igényeket egy új projekttel. Mivel a nagyvállalatok jellemzően lassan reagálnak bármilyen történésre és ezt tudják is magukról, igyekeznek egyetlen gigantikus projektet indítani, melyhez összegyűjtik az összes érintett igazgatóság és az alájuk tartozó osztályok random ötleteit, mert hát ugye inkább próbáljuk meg kiszolgálni mindet egy füst alatt, hiszen olyan körülményes egy újabb projektet indítani…

Na, az igények összegyűltek. De ezt ugye nem lehet még kiadni a potenciális szállítóknak, mert ahány ház, annyi szokás, még a végén nem lesz miket összehasonlítani!

A beszerzésen dolgozó munkatársak megkapják az ukázt, hogy az igények alapján írják össze a funkciókat, vagy pofozzák ki az igény megfogalmazójából, hogy szerinte miként is kellene megvalósítani azt. 

Miben érdekelt a beszerző?

Minél hamarabb szolgálja ki az igényeket, a lehető legmegfelelőbb szállító kiválasztásával.

Igen ám, de az esetek döntő többségében a beszerző csak a papírra vetett információval találkozik, magával az üzleti igénnyel nem. Így aztán a számára elérhető input alapján ír egy követelmény-specifikációt. Összeállít egy megkövetelt funkció-listát. Egy bonyolult algoritmus alapján további, fehér alapon feketével írt információ-morzsákat próbál összehasonlítani és pontozni.

A számok pedig nem hazudnak, meg is van a győztes hamar.

Az megvan, hogy néhány évtizeddel ezelőtt hogyan csempésztek szoftvereket?

Kinyomtatták a forráskódot és azt vitték magukkal.

Egy egyedi szoftvernek ugyanis létezik tökéletes dokumentációja: a saját forráskódja.

És létezik ezer másféle dokumentáció, amelyek viszont sokkal szabadabb elvek mentén születnek. Többen, többfélét gondolhatnak és fogalmazhatnak az ilyen anyagokban. 

A forráskódot, ha kinyomtatnánk, kapnánk egy könyvet. Hozzám hasonló, egyszerű halandók számára nem volna túl izgalmas könyv, de könyv volna. 

Ha ezt a könyvet le akarjuk képezni 10 oldalban, akkor a történet óhatatlanul egy kicsit más lesz. Olyan ez, mint a “Kötelezők röviden” sorozat. Hasznos, de messze nem tökéletes. 

A beszerzés egy ilyen kivonat megírását vállalja, amikor követelmény-specifikációt szolgáltat egy tender dokumentációjaként a meghívottak számára.

És az ilyen dokumentumokban szerepelnek azok a mondatok, mint például:

  • “szükséges a szállítandó szoftvercsomag részeként CMS (content management system), azaz tartalomkezelő modul implementációja.”

  • “a rendszernek integrációs céllal interfészen szükséges kapcsolódnia a vállalat számlázási rendszeréhez”

És sorolhatnánk…

Ne is azon ragadjunk le, hogy melyik követelmény megfogalmazása milyen, hanem gondoljunk csak bele, hogy ha tényleg csak a követelmény kiszolgálására koncentrálunk, akkor mit kezdünk például a CMS témakörével.

Remek CMS az eZ Platform. Szintén nagyszerű CMS funkciói vannak a Liferay DXP-nek. Borzasztó népszerű a Wordpress, vagy a Drupal. Vannak cégek Magyarországon is, amelyek teljesen egyedi, saját fejlesztésű, kvázi dobozos termékként is működő CMS-t szállítanak.

Jó eséllyel 10 benyújtott árajánlat 7-10 CMS javaslatot tartalmaz. 

Ez a beszerzési táblázatokban valahogy így jelenik meg:
 

 

Szállító #1

Szállító #2

Szállító #3

Szállító #4

Szállító #5

Szállító #6

Szállító #7

Szállító #8

Szállító #9

Szállító #10

CMS

x

 

Hogy a javasolt megoldásnak milyen felhasználói felülete van, valóban támogatja-e az alapvető igény kiszolgálását, vagy csak teljesíti a megfogalmazott követelményt, az már nem derül ki.

Ilyen, és ehhez hasonló jelenségek, jellemzők, magatartásformák mondatják azt velem, hogy az átlagos vállalati beszerzési folyamat nem hatékony. Nem az üzleti célokat támogatja.

Nem azért, mert a beszerzési folyamatokban résztvevő emberek nem jó munkaerők, nem jó gondolkodású kollégák. Egyszerűen azért, mert a folyamatok rosszak, elavultak, merevek.

Amikor valahol egy beszerzési folyamatban megjelenik az például, hogy legyen valami közös “próba projekt”, mondjuk 1-2 fejlesztői sprint erejéig, ott azért már látjuk a fényt az alagút végén. Ott már alakul az érzés, hogy együttműködésre törekednek, nem csak számolgatásra.

Jó jel egyébként, legalábbis azt tapasztaltuk az elmúlt években, hogy az üzleti oldal egyre inkább az érték alapú megközelítésben hisz. Együttműködő partnereket keresnek, akikkel közösen gondolkodhatnak, közösen találhatják ki a lehető legjobb megoldásokat az aktualizált üzleti igények informatikai kiszolgálására.

Reméljük, hogy az idén nagykorúvá váló Agilis Kiáltvány és a mögötte álló gondolkodásmód hamarosan befészkeli magát a beszerzési folyamatokba is.

Fontos ugyanis leszögezni, hogy az agilis vállalatok, akik szállítóként részt vesznek különböző projektekben, nem azért próbálnak menekülni az éveken túlnyúló projektek előre specifikált követelményeinek megvalósítása elől, mert nem akarnak dolgozni. 

Az agilis vállalatok legfontosabb ismérve az, hogy nem akarnak feleslegesen dolgozni. Valós üzleti igényeket szeretnének kiszolgálni, nem pedig dokumentumokkal tömni random fiókokat.

Együttműködésre törekednek a megrendelővel, nem csupán szolgáltatnak. Értéket kell teremteni.

Ha az egyes agilis módszertanok (Scrum, Kanban, Lean startup stb.) minden elemével nem is értek egyet, a már említett Agilis Kiáltvány (Agile Manifesto - 2001) kijelentéseit magaménak érzem:

 

Értékesebbnek tartjuk

  • az egyént és a személyes kommunikációt a módszertanoknál és az eszközöknél

  • a működő szoftvert az átfogó dokumentációnál

  • a megrendelővel való együttműködést a szerződéshez való ragaszkodással szemben

  • a változásokra való reagálást a tervek rigorózus követésével szemben…

 

… noha fontosak az utóbbiak is…


 

folyt.köv.