Az alapprobléma

Az építőipar exponenciálisan fejlődik szinte minden régióban a világon. Ugyanakkor a beruházók egyre magasabb és magasabb követelményeket támasztanak a minőség, a rendelkezésre álló idő és a források tekintetében. Ezek a körülmények újfajta kihívások elé állítják az iparági szereplőket. Ezen túlmenőnen viszont az építőipar az egyik legkevésbé digitalizált iparág a McKinsey 2016-os tanulmánya szerint.

Minden építőipari beruházási projekt jó kooperációt igényel a különböző szakágak (építészet, villamosság, gépészet, stb.) és a különböző szereplők (beruházó, tervező mérnökök, kivitelezők, műszaki ellenőrök, jövőbeli bérlők) között. A műszaki ellenőrök fontos szerepet játszanak, hogy a beruházás elérje a kitűzött minőségi, időbeli és forrásbeli céljait (akár a beruházó, a jövőbeli bérlő vagy akár a hatóság megbízásából teszi mindezt).

Egy beruházás életciklusa magas szinten így néz ki:

A műszaki ellenőrzés a kivitelezés fázisában erősen támaszkodik az emberi erőforrásokra, a mérnöki tudásra és tapasztalatra. A mérnökök napjainkig korlátozottan voltak ellátva olyan integrált digitális eszközökkel, amely az ellenőrzési tevékenységüket hatékonyabbá tette volna. A műszaki ellenőrökkel folytatott beszélgetések során valamint a beruházásokon szerzett tapasztalatok alapján a legtöbb probléma az alábbi három területen jelentkezett.

1. a hiba azonnali rögzítése, kiegészítve multimédiás csatolmányokkal és a pontos helyszín megjelölésével
2. eljuttatni a hibát a megfelelő felelőshöz
3. a hibákat kezelni a teljes életciklusuk alatt

A fenti nehézségek további problémákat okoznak:

1. félreértések a felek között és emiatt felesleges iterációk
2. késések a beruházásban a nem megfelelő információ áramlás miatt
3. felesleges adminisztráció miatti erőforrás pazarlás

A megoldás

Az alapprobléma mentén merült fel, hogy hozzunk létre egy olyan digitális megoldást, amely egyszerre oldja meg az első fejezetben részletezett nehézségeket. Megvizsgáltuk a piacot és arra jutottunk, hogy van igény olyan megoldásra, ami egyszerűen és hatékonyan tudná megoldani ezen problémákat. Több ötlet is felmerült a megoldásra végül egy mobil alkalmazás és egy weben is elérhető felület kombinációja mellett tettük le a voksunkat. A mobil alkalmazás elsősorban a helyszíni tevékenységet támogatja a lehető legegyszerűbben, míg a webes felületen egy számítógép nagyobb képernyőjét kihasználva átláthatóbb rendszerben lehet áttekinteni és kezelni a projekteket és hibajegyeket.

A mobil alkalmazás megvalósításánál a legfőbb cél az egyszerűség volt. A műszaki ellenőröknek jellemzően nehéz terepen, sokfelé figyelve kell végezniük a tevékenységüket. Ezért nem jó egy olyan alkalmazás, amelynek a kezelése két kezet és nagy odafigyelést igényel:

1. fénykép készítésével egyből lehet hibajegyet rögzíteni, ehhez diktálással megjegyzést fűzni, valamint egyszerűen megadni a hiba helyét.
2. egyből hozzá lehet rendelni egy felelőst
3. gyorsan lehet szűrni különböző előre beállított szűrésekkel a projektre rögzített hibákat

Egyrészt alternatívaként másrészt kibővített funkcionalitással egy webes felület:

1. részletes riport készítése
2. előrehaladási jelentés
3. adminisztráció
4. rendszer karbantartási funkciók

Megvalósítás

A megvalósítást a probléma elemzésével kezdtük meg. Ehhez segítségül hívtunk további az építőipari műszaki ellenőrzésben nagy tapasztalattal bíró mérnök kollégákat. Az ő feladatuk volt, hogy az alapprobléma kifejtése mentén összeállítson egy igény halmazt, amely alapján az szoftver fejlesztő kollégák ki tudják dolgozni a megoldás műszaki megvalósításának módját. Ennek az első lépésnek az eredménye volt egy több mint 130 elemű funkció lista, ami koncepció szintjén vázolta az elképzeléseinket.

Mivel a megoldás mobil hangsúlyos, ezért ehhez tervezésben, felhasználói élményben és mobil fejlesztésben is járatos szakembert hívtunk a csapatunkba. Az elvárás az volt, hogy a funkció lista alapján érjünk el jó felhasználói élményt, az egyszerűséget szem előtt tartva. A webes felület esetében ugyanez volt az elvárás. Ezzel igyekeztünk biztosítani, hogy már a tervezés során feltárásra kerüljenek az esetleges ellentmondások vagy ellentétes igények a mobil és a webes felület között (pl. a mobil számára egy adott kiszolgáló típus lenne jobb a webesnek pedig másik, vagy az adatmodellben az egyiknek egy fajta struktúra lenne optimálisabb a másik felületnek pedig egy bonyolultabb). Ennek egy jó példája volt, hogy a mobil telefonos alkalmazásnál – hiába van jó mobil telefonos lefedettség – sok esetben az építkezési helyszíneken nem elérhető (árnyékolás vagy kiépítettlenség miatt) használható internet kapcsolat. Így a mobil alkalmazásnál a központi rendszerrel való kommunikációt optimalizálni kell (azaz a szükséges minimális adattartalomra kell szűkíteni úgy, hogy a funkcionalitás ne szenvedjen kárt). A jellemzően jó sávszélességű internet eléréssel rendelkező webes felületnél ez az optimalizáció kevésbé fontos.

A fejlesztés során a nagy kihívás volt, hogy a három tevékenység (mobil fejlesztés, webes frontend és a backend) párhuzamosan tudjon haladni. Ezt a párhuzamosságot bonyolította, hogy az felhasználói élmény és az egyszerűség mentén kellett végig egyensúlyozni.

A tesztelés során a belső teszteléseken túl bevont mérnökök vizsgálták a megoldást élő projekteken, amelynek révén a kiinduló listához képest egy még hosszabb fejlesztési lista állt elő, többek között a terv dokumentációk dinamikus változása, a jelentés generálás, valamint a tablet optimalizáció kapcsán.

A jövőben még több helyszíni tesztet fogunk végezni, hogy kialakítsuk a 2. verzió újabb funkcióinak listáját.