A projektalapító okirat

Az ERP rendszerek üzembeállításánál is van egy elhatározási pont, ahol még egy irtózatos fékezéssel a bukást elkerülve lehet megállni. Ez a pont a „Projektalapító okirat” aláírása. Ugyanakkor az ember belefut olyan helyzetbe, amikor a beruházó még az aláírás előtti pillanatban sincs tisztában ezzel a fogalommal, ezért foglalkozzunk egy kicsit a kérdéssel.

A projektalapító okirat az anno angol és a magyar kormányzati szabványként is bevezetett PRINCE projektvezetési módszertan legfontosabb eleme. Első találkozásom az 1994-es választási szoftver technológiának a kialakításakor volt, ugyanis ezt jelölték ki kötelezendően alkalmazandó módszertannak. Ez nem a NINCS ADAT választás volt (-: A módszertannak az azóta megjelent agilis módszertanok mellett ma is meg van a maga helye.
A PRINCE szerint az okirat előírt tartalma a következő:
„

• a projekt célja, tartalma és terjedelme
• a projekt határai, korlátok
• a projekt szponzor valamint a projektbe bevontak személye (a projekt team)
• a projekt feladat elvégzésének és a szakmai minőségbiztosítás módszertana
• a szakmai belső kommunikáció és a kapcsolat tartás módja
• a projekt menedzseri és külső kommunikáció és kapcsolattartás módja
• a változás kezelés eljárása
• a projekt ütemezése, ellenőrző pontjai és a mérföldkövek
• a projekt kritikus siker tényezői és kockázati pontjai
• és valamennyi, a projekt sikeres végrehajtását befolyásoló egyéb fontos információ

”

Ezt az okiratot – a szintén előírt – Projekt Indító Értekezlet-en kell aláírni.

Amikor ezt az okiratot a Beszállító/Projektvezető és a Megrendelő aláírja, akkor ez egy joghatással járó magán okirattá válik. Azaz a Megrendelő nyilatkozik, hogy elfogadta a projekt tartalmát, a határait és „végrehajtását befolyásoló egyéb fontos információk”-at. Ezt tehát nagyon nehéz módosítani, az elfogadásának és a módosításnak jogszerűen van anyagi vetülete.

Igen ám, de mi alapján dönt a Megrendelő?

Ehhez nézzük a meg a PINCE-hez tartozó – az informatikai beruházásokhoz készült, anno szintén kormányzati szabványként használt – SSADM fejlesztési módszertant.

Vegyük észre, hogy az SSADM egy megvalósíthatósági tanulmánnyal indul és tegyük fel azt a kérdést, hogy minek a megvalósíthatóságát tanulmányozza? Ez bizony a stratégia terv, aminek elkészítését az SSADM jól láthatóan nem kezeli. A „Stratégiai terv” az információs rendszerek tervezésének egy önálló eleme, amely elkészítését szintén a PRINCE menedzseli.

Megnézve a Megvalósíthatósági tanulmányt, a következőket találjuk:
„A megvalósíthatósági tanulmány egy vállalkozás vagy projekt elindítása előtt készített tanulmány, ami objektív és racionális módon feltárja a projekt erősségeit és gyengeségeit, a(z üzleti, természetes) környezet jelentette lehetőségeket és veszélyeket, a végrehajtáshoz szükséges erőforrásokat, és végső soron a siker esélyeit.^[1][2]Leegyszerűsítve a megvalósíthatóság eldöntésének két fő kritériuma a felmerülő költség és az elérendő érték.^[3] Így tehát egy jól megírt megvalósíthatósági tanulmány felvázolja az üzleti lehetőség vagy projekt történeti hátterét, leírja a terméket vagy szolgáltatást, tartalmaz számviteli kimutatásokat, az üzleti tevékenység és menedzsment részleteit, piackutatást, irányelveket, pénzügyi adatokat, beszámol a jogi követelményektől és az adóügyi kötelezettségekről is.^[1] Általában a műszaki fejlesztéseket és a projektek megvalósítását megvalósíthatósági tanulmány alapozza meg.

A megvalósíthatósági tanulmány legfőbb szerepe a döntés-előkészítésben –van. Készülhet egy vállalkozási- vagy projektötlet több változatára is. Felbontható résztanulmányokra, melyek közül nem feltétlen kell minden esetben az összest elkészíteni, létezhet például:

”

• Technikai megvalósíthatósági tanulmány
• Környezeti-ökológiai hatástanulmány
• Projektmarketing tanulmány
• Pénzügyi megvalósíthatósági tanulmány
• Kockázatokra vonatkozó tanulmány
• Fenntarthatósági tanulmány
• Földrajzi helyszínre vonatkozó tanulmány.^[4]„

Vegyük észre azt is, hogy a megvalósíthatatlan elemek esetben az SSADM az anyagot visszadobja a projektvezetésnek, hogy kenje a hajára.

Ha ekkor már elfogadott projektalapító okiratunk van, akkor a hibásan felvett „Jelenlegi helyzet” és „Stratégiai terv” tanulmányokat kezdhetjük előröl, természetesen a Megrendelő költségére.

Igen ám, de ha még nem alapítottuk meg a projektet, akkor hogy készül el a jelenlegi helyzet, stratégiai terv és a megvalósíthatósági tanulmány? Leginkább úgy, hogy ezek önálló projektek, önálló projektszervezettel. Az sem természetes, hogy ezeket ki készíti el. A jelenlegi helyzet felmérését jó ha kívülállóra bízzuk, mert erre felkészült szakemberek könnyebben észreveszik a szervezetben és a működésben már megkövesedett hibákat és pontosabban tudják meghatározni a cég innovációs képességét. (Ezt sohase a későbbi kivitelező csinálja!) Ha külsősökre bízzuk, akkor viszont nekik kell vezetni ezt a projektet is így tisztázni kell a döntéshozók és a külső-belső tagok viszonyát. A döntéshozók nyilván nem tartozhatnak a projektvezető alá, mégis szervesen a projekthez kell tartozniuk, hogy ne legyen vitatható a felelősség.

Ezt a PRINCE így oldja meg:

Tehát van egy döntőbizottság (és nagy projektek esetén egy végrehajtóbizottság a projekt felett, hogy a nagyprojektek döntőbizottságát ne terheljük a végrehajtás feladataival), aki [és csak Ő(k)] felelős minden döntésért.

Az ábrából az is látszik, hogy a projektvezetőséget három szerepkör alkotja, a projektvezető elnök irányítása mellett, de nem neki alárendelve. Miután ezek egymás mellett lévő szerepkörök, vita esetén a döntés feljebb kerül. A szervezetben pedig pontosan ki kell jelölni, hogy mely kérdésben melyik munkaköröket kell bevonni.

A jelenlegi helyzet pontos ismeretében lehet stratégiai döntéseket hozni, melyet egy önálló dokumentumban kell megfogalmazni. Erre egy ugyanilyen, de új projektszervezetet lehet felállítani, hogy az előző projekt lezárható legyen.

Felmerül az a kérdés is, hogy az ERP bevezetés projektek esetén milyen stratégiai kérdésekre lehet számítani. Ha ERP választásról és egyedi fejlesztést is igénylő bevezetésről van szó, akkor ebbe beépülhet az ERP választási alprojekt, amely ciklikusan ismétlődhet a végleges döntés meghozataláig.
A választ azonban megelőzheti néhány érdekes kérdés. Ilyen például, hogy egyedi fejlesztésre van szükségünk vagy vásároljunk egy kész rendszert. Ez nagyon fontos kérdés, de azt tudni kell, hogy az esetek 99%-ban rossz döntés lenne az egyedi fejlesztés.
A másik nagyon gyanús probléma a LINUX-Windows választás kérdése. A tapasztalat azt mutatja, hogy ez a – késhegyig menő vitát eredményező – kérdés egy egyszerű érzelmi, indulati, mondvacsinált álprobléma, amitől mindig meg kell szabadulni. A másik ilyen „stratégiai” döntés, hogy jöhet bármi csak Microsoft és SAP nem, mert ott csak a nevet kell megfizetni. Erre nem is válaszolok.
Igazán ütős kérdés azonban az, hogy a meglévő rendszert fejlesszük tovább vagy lépjünk egy kategóriát és vezessünk be egy új rendszert. Na, ez már valóban egy stratégiai kérdés. Ennek érdekessége, hogy az esetek nagy százalékában jobb és sokkal olcsóbb megoldás lenne a meglévő rendszer továbbfejlesztése, ill. az esetleges hibák kijavítása. Az új rendszer melletti döntés oka leggyakrabban a fejlesztőbe/bevezetőbe vetett bizalom megroggyanása, ami általában a meglévő rendszer kiválasztásánál elkövetett stratégiai hibára vezethető vissza, éspedig arra, hogy egy olyan rendszert választottunk, amelynek csak egy fejlesztője/bevezetője van.
Szívemnek kedves stratégiai döntés pl. az, hogy az ERP rendszer ügyviteli részében egyedi módosítást nem kérünk, hanem átvesszük a kiválasztott rendszer megoldásait. Ez nagyon jó jel, mert bizonyítja, hogy a fogadó cégnek fejlett innovációs képessége van, ami siker egyik záloga.
És így marad a gyártás, ami mindig egy jól álcázott sötét ló. Nem tévedhetünk a gyártás típusának a megítélésében! Egyszerű a helyzet, ha nincs két egyforma termékünk, mert akkor projekt alapú gyártást támogató rendszerek között kell kurkásznunk. Az is kellemes, ha kizárólag 42-es, fekete, ballábas férficipőt gyártunk, mert ekkor valóban tömegtermelünk. Az élet azonban nem ilyen kegyes hozzánk, így a köztes állapotok száma végtelen.
A legtöbbször azt célszerű megvizsgálni, hogy a cégünk tevékenységében mi hordozza a legnagyobb értéket. Ha csupa kis-sorozatú terméket gyártunk – és most mindegy, hogy ez női ruha vagy precíziós műszer – akkor értékképzést a méregdrága napidíjú művész úr vagy mérnök úr jelenti, ezért a tervezést kell támogatni és tökéletesen hidegen hagy az anyag és időnorma. BOM-ra és művelettervre ilyenkor is szükség van mert az anyagot valahogy be kell szerezni és raktározni is kell a frányaságokat, de ezeket állítsa elő a tervezőrendszer.
Klasszikus termelésirányítási rendszerre akkor sincs szükség, ha pl. bugákat öntök vagy olyan terméket állítok elő, amihez 100-200 milliós eszközök szükségesek. Ekkor a támogatandó tevékenység a gyártásütemezés, amelyet csak ritkán (gyakorlatilag sose) támogat kellő szinten egy hagyományos ERP rendszer. Ilyenkor APS rendszerekre van szükségünk, no meg pl. egy jó kis ABC (Activity Based Costing) vagy SENECA költségelemzésre, ugyanis az egyik legfontosabb kérdés, hogy kire terheljem az eszközök méregdrága állás-idejét és amortizációját. Ezeknél a megoldásoknál kemény döntés az is, hogy osztom meg a feladatokat a gyártási modul-maradvány és a 3. fél között.
Stratégiai döntést igényel az is, hogy bevezetem-e az internetes értékesítést, mert ez bizony nem csak egy új csatorna, hanem egy új üzletág is, amelyhez marketinget, gyors-reagálású raktárt és önálló értékesítést is létre kell hozni.

Az így készült stratégiai dokumentumokat adjuk át az SSADM-nek. Aki egy új projektet alapít. (Ez eltérhet a PRINCE-től, de sem a szerepkörökről sem a megvalósíthatósági tanulmányról sem a projektalapító okiratról nem szabad lemondani.) Készülni kell arra, hogy a magvalósíthatósági tanulmány visszanyúlhat a jelenlegi helyzet feltárásához, ugyanis a fejlesztőnek és bevezetőnek joga van leellenőrizni az idegenek által készített jelenlegi helyzet tanulmányt, hiszen a megvalósíthatóságért a felelősséget ő fogja vállalni.

A megvalósíthatósági tanulmány tehát egy komoly, nagy anyag, ahol az eltérő érdekszférában keletkezett anyagok biztos hátteret jelentenek a Döntő Bizottság munkájához.
Ebben az állapotban kerül aláírásra kivitelezést és bevezetést meghatározó Projektalapító okirat.

Azonban, ha az anyag nem teljes-körű és nem pontosan határozza meg az elvégzendő feladatot, akkor az erkölcsi és anyagi felelősség a Megbízót (a Döntőbizottságot!) terheli.

Tehát akkor járunk el helyesen, ha a bevezetési projekt Alapító okiratát a Megvalósíthatósági tanulmány átvétele és nagyon gondos ellenőrzése után írjuk alá.

Forrás: WIKIPÉDIA, így nincs szükség a PRINCE és SSADM kézikönyvekre, amelyeket általában nem adnak át.

_____________________________________________________________________________
@Kupán Károly (2017)                                           v1.04                                                        Kupan.Karoly@BI-Control.hu