Bevezetés
Egy nagy nemzetközi generálkivitelező cég helyi leányvállalata elvállalta egy japán szerszámgyártó csarnok tervezését és kivitelezését. A beruházó japán, a generálkivitelező magyar, a tervezők angolok és franciák, a kivitelezők pedig különböző kelet-európai cégek vegyesen.
A lendületes indulás után a projekt majdnem vakvágányra futott: az FTP összeomlott, a levelezőszerver nembírta a sok csatolmányt, az alvállalkozók elavult tervekből dolgoztak, és még a nyelvi nehézségekis akadályozták az építési munkát. Szerencsére lett megoldás… Szerencsére lett megoldás…
A legfőbb problémák
#1: Az adatok megtalálása
Az egyik nagy probléma az volt, hogy óriási adatállománnyal dolgoztak, rengeteg tervet kezeltek a projekten belül, ráadásul minden tervnek több revízióját. Ennek volt ugyan egy központi FTP tárolója, de a tervek nem voltak megfelelően rendszerezve, és egy helyettesítés során a tervek rendezéséért felelős kollégák nagyon nehezen találták a szükséges fájlokat. Sokszor azt sem vették észre, amikor új terv került feltöltésre. Ez nem meglepő: próbáljuk meg kiszúrni az 5. mélységű mappában a 600 pdf és dwg közt megbúvó új fájlt.
#2: Nyelvi akadályok
A másik óriási probléma az volt, hogy a japán megrendelő projektmenedzser kollégái közül sokan egyáltalán nem beszéltek angolul, ami komoly kihívás elé állította a menedzsment csapatot a generál oldaláról.
#3: Információ áramlás
A nagy építési projekt természetéből adódó óriási információáramlásra a menedzsment nem volt felkészülve. A szokásos emailes kommunikáció irányba indultak el, ami óriási káoszhoz vezetett. A szokásos emailes kommunikáció irányba indultak el, ami óriási káoszhoz vezetett.
A következő eset többször is megtörtént a projekt során:
Az épület már kivitelezés alatt állt, de a kivitelező kollégáknak feltűnt egy hiba a terven. Telefonáltak a felettesüknek, aki telefonált a felettesének, aki telefonált a felettesének, aki felhívta a tervezőirodát.
A tervezőiroda kollégája elkészítette a javítást, és elküldte a felettesének. A felettese elküldte a generálnak. A generál adminisztrátora elindította a cégen belüli jóváhagyást: elküldte a projekt vezetőnek, ő tovább a műszaki ellenőrnek, ő tovább a pénzügyre.
Valamiért a pénzügy visszadobta: a terven megint javítani kellett valamit. De közben a cég adminisztrátora véletlenül már elküldte a kivitelezésen dolgozó kollégáknak, akik azt hitték, hogy ez már a friss, jóváhagyott terv, és elkezdtek belőle dolgozni.
Tudjuk, hogy amikor egy alvállalkozó rossz tervből dolgozik hetekig, annak nagyon súlyos következményei vannak: a kivitelező vállalkozó így óriási kártcsinált (önhibáján kívül) azzal, hogy nem jóváhagyott tervvolt a kezében. Ők maguk nem tudták ellenőrizni a terveket, egész egyszerűen követték a standard ügymenetet: tudták azt, hogy amikor az adminisztrátortól kapnak egy tervet, akkor nekik azt ki kell nyomtatni, és lehet belőle dolgozni.
Nem sokkal később, miután kiderült, hogy elégettek néhány százezer eurót, a kapkodás miatt még a levelezőszervert is túlterhelték, ami leállt a rengeteg csatolmány miatt. Emiatt mindenkit felengedtek az FTP szerverre, ami pedig nem volt felkészítve a terhelésre, és az is összeomlott.
Egy rémálommá vált a projekt a kivitelezés kellős közepén, mindenki túlórázott, a határidő pedig nagyon szorított.
Ekkor jöttünk mi a képbe.
A megoldás
A generálkivitelező egyik kollégája már hallott a myPlan.cloud szoftverről, felvették velünk a kapcsolatot egy csütörtöki napon, és kértek egy prezentációs időpontot a lehető leghamarabb. Következő hétfőn bemutattuk a szoftvert a vezetőségnek és a szakmai csapatnak, és mindannyiunk számára világossá vált, hogy pontosan erre van szükségük. Egyetlen hiányosságba akadtunk bele: a japán nyelv nem volt a támogatottak közt.
Megoldás az adatok megtalálására
A szoftver sajátossága, hogy a terveket egyszer kell feltölteni egy közös felületre, és azok annak függvényében látszanak, hogy kinek mihez van jogosultsága. A másik nagyon fontos tulajdonsága a myPlan-nek, hogy a revíziókat a szoftver a dokumentumok alá rendezi be, így akár laikusok számára is nagyon könnyen böngészhetővé válik a projekt akkor is, ha ez egy nagy, sokmilliárdos projekt, és egy tervhez sok revízió tartozik.
Megoldás a nyelvi akadályokra
A myPlan rendszer jelenleg 15 nyelven tud, anyanyelvi szinten. A japán nyelv hiányosságát nagyon könnyen és gyorsan orvosoltuk: hétfőn, a prezi után elküldtük a fordítóirodánknak az angol nyelvi fájlokat, ők pedig szerda délután visszaküldték ugyanazt japánul, majd mi két kattintással importáltuk a nyelvet. A fordítások tehát nem a Google Translate által történnek, hanem egy neves fordítóiroda hivatásos anyanyelvi tolmácsai által. Amikor meghívták a japán alvállalkozót, neki már rögtön japánul érkezett az első email, tehát mindenki a saját anyanyelvén tudja használni a szoftvert, az első pillanattól fogva. Nagyon örült az ügyfelünk az egyik újabb fejlesztésünknek: van egy gomb, amivel a kézzel bevitt szövegeket automatikusan lefordítja a program (például mappanevek, vagy hozzászólások). Természetesen ez utóbbi soha nem lesz nyelvtanilag pontos fordítás, de arra kiváló, hogy a dokumentációban eligazodjunk, és még akkor is megértsük egymást, ha nem beszélünk közös nyelvet.
Megoldás az információ áramlásra
A myPlan része egy egészen egyedi jóváhagyási rendszer, ami bármilyen jóváhagyási workflow-t képes lefedni. Úgynezett jóváhagyási szinteket lehet beállítani, és ezekhez a szintekhez embereket rendelni. Megadhatjuk, hogy az adott szinten belül minimum hány szereplő jóváhagyása szükséges ahhoz, hogy a szint teljesüljön, és mehessen tovább a jóváhagyási folyamat a következő szintre. A szereplők a megfelelő pillanatban értesítéseket is kapnak a jóváhagyási teendőikről. Az ügyfelünknek pontosan erre volt szüksége: amikor a pénzügy visszadobja a tervet, akkor mindenki nagyon egyértelműen lássa, hogy a terv elutasításra került, és a tervező, miután megnézni ennek az okát (megjegyzés mellett még bele is lehet firkálni a tervekbe), már el is kezdhet dolgozni a javításon.
A terepen dolgozó kivitelező kollégák kezébe olyan tervek kerültek ezentúl, aminek a sarkán van egy QR kód. Ezt a QR kódot ha a kollégák bármilyen okostelefonnal, akár applikáció nélkül beszkennelik, akkor rögtön látnak egy piros, sárga, vagy zöld képernyőt.
- Zöld: ez a legfrissebb revízió és jóvá is van hagyva.
- Sárga: bár ez a legfrissebb revízió, de még nincs jóváhagyva.
- Piros: a revízió el van utasítva, vagy van újabb – vagy mindkettő egyyszerre.
By clicking on the small arrow icon other details can be viewed that are not sensitive information from business point of view. Például ha elavult revízió van a kolléga kezében, akkor rögtön meg tudja nézni, hogy melyiket kell keresnie.
Konklúzió
A myPlan.cloud rendszert beüzemelni néhány perc volt, a dokumentációt feltöltötte és közben rendbe rakta egy talpraesett admin kolléga – egyetlen nap alatt. A nagyjából 80 projektrésztvevőnek gyakorlatilag egyik napról a másikra világossá vált, hogy mi a feladata és miből lehet dolgozni. Hibás tervkezelésből adódó veszteség nem volt többet.
Az ügyfelünk visszajelzése szerint az egyik legnagyobb pozitív csalódás az volt, hogy a kollégákat nem kellett képzésre küldeni: kivétel nélkül mindenki azonnal tudta használni a szoftvert, miután megnézte az egy órás ismertető videót. És ez nem csak az irodában dolgozó tevezőkre volt igaz, hanem az esetleg informatikailag kevésbé képzett kollégákra is.
A szerszámgépgyártó üzem kivitelezése rendben befejeződött.
