Agilis szereplőket agilis szerződések köthetnek össze

A világméretű gazdasági bizonytalanságok ellenére a vállalatvezetők elkötelezettek a digitális transzformáció, az innováció mellett; a vezetők 88 százaléka egyetért azzal, hogy az agilis megközelítés stratégiai fontosságú ebben a piaci környezetben. Ennek feltétele a rugalmasság és a gyors reagálóképesség, hogy a folyamatos iterációk és felülvizsgálatok révén lerövidüljön a piacra lépés ideje, és folyamatosan javuljon a minőség. A koncepció világos, a megvalósítás azonban a legtöbb vállalatnál döcögős, ezért születik annyi könyv és tanulmány az agilis módszertanról. Mi most egyetlen, de annál nagyobb problémát veszünk górcső alá, a beszállítói szerződéseket. 

A KPMG 2023-as Global Tech Report felmérése szerint a vállalatok 57 százaléka látja úgy, hogy a hosszú távú szállítói szerződéseik gátját jelentik az innovációnak, az új technológiák alkalmazásának. Ez nem véletlen. Ha szerződésben gondolkodunk, azt szeretnénk, hogy az legyen biztos, védjen minket minden körülmények között, legyenek benne világosan körülírt feladatok és feltételek, továbbá teremtsen kiszámíthatóságot. Ez az elvárásrend a vízesés módszertant, azaz a folyamatok egymásra épülését képezi le a maga módján tökéletesen, és az e modellre épülő szerződéses technikákat csiszolgatják a jogászok évtizedek óta.  

Csakhogy ez tökéletesen ellentmond az agilitás és a rugalmasság igényének. Ha mi magunk végre agilisak lettünk, akkor azt várjuk el a beszállítótól is, hogy ő is alkalmazkodjon okosan, és mindig a lehető legrövidebb időn belül a gyorsan változó elvárásainkhoz. Ezt az elvárást a ma leggyakrabban alkalmazott szerződéseink nem tudják leírni, jószerivel még a fogalomtár is hiányzik ahhoz, hogy a felek mindig tudják, ki miről beszél, és ez érvényesíthető is legyen egy üzleti vitában. 

A hagyományos fix áras szerződések nem kezelik a gyakran változó követelményeket

A vízesés modell tipikus szerződéses megtestesülése a fix terjedelmű, fix áras szerződés, amely a követelmények minél pontosabb meghatározását célozza, és az ezek leszállítását biztosító terveket helyezi fókuszba. Ebben a konstrukcióban a vevőt és a szállítót alapvetően ellentétes érdekek vezérlik: a vevő abban érdekelt, hogy a terjedelem, azaz az elvégzendő feladat minél tágabban értelmezhető módon kerüljön a szerződésbe, a szállító ezzel szemben a megállapodott munka minél precízebb és szorosabb lehatárolásában érdekelt. A fix áras szerződések lényegében akkor sem adnak teret a változó igényekhez és elképzelésekhez történő alkalmazkodásra, ha a felekben egyébként megvan a szándék az együttműködésre és a gyors reakcióra. Emiatt ezek a szerződések alapjaiban hiúsítják meg – a valós felhasználói iterációkon nyugvó, a fókuszpontokat rugalmasan alakító – agilis működés előnyeinek kiaknázását.

A Time and Materials (T&M) alapú szerződés tűnik a legkézenfekvőbb megoldásnak

A fix áras szerződések helyett éppen ezért az agilis projektekben nagyrészt Time and Material alapon szerződnek a felek. Ez jellemzően tartalmazza a munka várható terjedelmét és egy fix napi- vagy óradíjat, valamint egy anyagköltség leírást. Ez már rugalmasabb, mint a fix áras szerződés, de azt eredményezi, hogy teljes egészében a vevő viseli a változtatási igények kockázatát és költségét, ez pedig egyáltalán nem támogatja az agilis működést és a partneri viszonyt. Ráadásul a  szállítónak nincs konkrét eredmény felelőssége, az idejéért cserébe megkapja a fizetséget, függetlenül a szállított eredmény minőségétől. Tapasztalatok szerint az ilyen alapon szerződött projektek sokkal gyakrabban zárulnak le azért, mert a vevő anyagi erőforrásai kimerülnek, semmint azért, mert a projekt elérte a valós célját.

Az agilis működési modellek újfajta szerződéses megközelítést igényelnek

A hagyományos szerződéses technikák mindezek miatt számos ponton nem támogatják olyan megoldások kialakítását, amelyek összhangban vannak az agilitás alapelveivel. Sokszor elmosódik az eredménytermék létrehozásáért járó felelősség, és gyakran fordul elő, hogy a szerződéstechnika eltér a projekt jellegétől. Ennek eredményeként „különutas” megállapodások jönnek létre a megrendelő és szállító között. Az így létrejövő megállapodások és az aláírt szerződés közötti eltérések félreértéseket eredményeznek, és nehezítik a vitás helyzetekben a közös, win-win megoldás létrejöttét.

Azt gondoljuk, elengedhetetlen, hogy a vevő és a szállító olyan szerződéses modellt válasszon, amely a megvalósítás jellegéhez és a felek felelősségéhez igazítva osztja meg a kockázatokat a két fél között és amely elősegíti az agilis szemléletű együttműködést.

Helyezzük a hangsúlyt az együttműködésre!

Tapasztalataink szerint az agilis működést legjobban támogató szerződések a vevő oldali Product Owner, a Delivery (leszállításért felelős) csapat, a Beszerzési-Jogi terület és a Szállító együttműködése eredményeként születnek. Kiemelten fontos, hogy már a kezdetektől vonjuk be az egyeztetésekbe az érintetteket, így a közös megértés a projekt céljáról már a projekt elején, a felek együttműködése révén kialakítható. Amennyiben a Jogi és Beszerzési területnek nincs agilis működési tapasztalata, mindenképp szükséges lesz felkészítenünk őket az agilis értékekből, a klasszikustól eltérő működésből. Az így kialakított szerződéses keretek támogatják a felek közti együttműködést, segítik a transzparenciát és építik a bizalmat a felek között a projekt megvalósítása során.

Mire érdemes figyelnünk a szerződéses folyamat során?

Az alábbiakban néhány olyan szerződéses elemet emeltünk ki, melyeket véleményünk szerint érdemes szem előtt tartani kereskedelmi tárgyalások során:

• Fókuszáljunk az együttműködés folyamatára, kereteire a részletes tervek helyett: ahelyett, hogy egy előre meghatározott tervre és követelménylistára összpontosítanánk, az agilis szerződésben inkább az elvárt eredményeket fogalmazzuk meg, valamint írjuk le a vevő és a szállító közti interakciókat is. Például, mennyi ideig tartanak az egyes iterációk? Milyen gyakran kerül sor az iterációtervezésre? A tesztelés a sprintek során zajlik, vagy azokon kívül? Így a követelmények meghatározása és priorizálása is világos keretek között történik. Az, hogy tisztán látjuk, ki mit csinál és milyen agilis ceremóniákat követünk, segít elkerülni a későbbi félreértéseket.
• Kerüljük a részletes leszállítandók listáját: a részletes leszállítandó lista elviszi a fókuszt arra, hogy vajon megfelelő minőségű dokumentum születik-e, illetve erősíti azt a gondolkodást, hogy mindent előre meg tudunk tervezni, ahelyett, hogy inkább a közös munkára, tanulásra, rugalmasságra és működő szoftverre fókuszálnánk. Azt javasoljuk, hogy a vevő-szállító közösen készítse el a szükséges dokumentumokat akkor, amikor már kész a működő alkalmazás.
• Legyenek egyértelműen meghatározva a minőségi követelmények: a szerződésnek egyértelműen ki kell térnie a minőségi követelményekre, elvárásokra. Legyen meghatározva, hogy milyen feltételek teljesülése esetén élesíthető az adott funkció (Definition of Done). A minőségi szállításért a vevő felelőssé teheti a szállítót, de a felelősség legyen arányban a munka terjedelmével, illetve érvényesíthetősége függ attól is, hogy a vevő betartja-e saját kötelezettségeit, mint például a megfelelő minőségű tervezés.
• Változáskezelés helyett Backlog menedzsment: klasszikus, fix terjedelmű szerződések esetén nagy hangsúly helyeződik a változáskezelésre. Ahhoz, hogy az agilis projekt kellően rugalmas tudjon maradni, a klasszikus CR (Change Management = Változás Kezelés) folyamatot ki kell hagyni, helyette alakítsuk ki az elvégzendő feladat-egységek kezelésének (Backlog menedzsment) folyamatát.
• Előre legyenek meghatározva kontroll mechanizmusok: mindkét fél számára legyen tiszta és érthető a kockázatok megosztása. Előre határozzuk meg, hogyan és miként járunk el, amennyiben a szállítás nem az elvárt ütemben, minőségben halad. Egyértelműen definiáljuk a szerződésben, hogy milyen kereskedelmi következménnyel jár a szállítóra nézve, ha az ő hibájából fakadóan késik a szállítás (pl. beszállító kapacitásának ingyenes növelése, pénzügyi jóváírás vagy felmondás joga).
• A szerződés megszüntetése lehet pozitív esemény: ha a projekt korábban eléri a célját, akkor egy adott iteráció végén le is zárhatjuk a szerződést agilis működés esetén, és ez nem a sikertelenség jele! Nagyobb megbízásoknál korábbi lezárás esetén a vevő kártérítést is fizethet a szállítónak, mely összeg arányosan csökken a projekt végéhez közelítve.

Úgy gondoljuk, hogy a szerződéses védelemmel egyidejűleg lehetséges az agilis működés előnyeinek az érvényesítése is, és hogy a kockázat megosztása a felek között a jövő szerződéseinek új sztenderdje lesz.