25 ALI OBSTAJA ENOTNA REŠITEV ZA VSE DELEŽNIKE?

Projektant, izvajalec, Inženir, naročnik in upravljavec sodelujejo pri istem projektu, vendar nimajo enakih nalog, odgovornosti in podatkovnih potreb. Skupni projekt ne pomeni skupnih procesov.

V predstavitvah BIM-a se je več let ponavljala privlačna podoba prihodnosti:

EN DIGITALNI MODEL
↓
ENA SKUPNA PLATFORMA
↓
VSI DELEŽNIKI UPORABLJAJO ISTE PODATKE
↓
POPOLNA PREGLEDNOST IN SODELOVANJE

Projektant, izvajalec, naročnik, Inženir in upravljavec naj bi se povezali v enotnem informacijskem okolju. Vsi naj bi uporabljali isti model, informacije naj bi bile zbrane na enem mestu, spremembe pa bi se skoraj samodejno prenašale skozi celoten projekt.

Takšna vizija je prepoznala resnično potrebo: gradbeni projekti potrebujejo več skupnih podatkov, manj podvajanja in boljše sodelovanje. Težava nastane, ko iz tega sklepamo, da morajo imeti vsi udeleženci tudi enake procese, interese in informacijske rešitve.

Predstava o »enovitem modelu«, vseh podatkih na enem mestu in »popolni harmoniji vseh deležnikov« je bila že leta 2018 soočena z vprašanji o poslovnih razmerjih, nosilcih procesov, pogodbah in različnih projektnih negotovostih. Opozorjeno je bilo tudi na manjkajoči projektno-tehnološki model med produktnim BIM-modelom in poslovnimi sistemi podjetij (Biznis & trendi v gradbeništvu, 17. in 18. april 2018, GH Bernardin, Portorož).

Skupni podatki ne pomenijo skupnih procesov. Enotno informacijsko okolje je mogoče vzpostaviti tudi s povezovanjem specializiranih rešitev, ki podpirajo različne vloge in odgovornosti.

Enotna rešitev za vse strokovne, projektne in poslovne procese vseh deležnikov praviloma ni realen cilj. Lahko pa vzpostavimo skupno informacijsko okolje, v katerem specializirane rešitve uporabljajo povezane, sledljive in standardizirane podatke.

Cilj digitalizacije ni, da vsi uporabljajo isti program. Vsak deležnik potrebuje orodja, primerna svoji vlogi, podatki, ki jih izmenjujejo, pa morajo ohraniti identiteto, pomen in status.

Razlika je bistvena. Prva možnost poskuša poenotiti delo različnih organizacij. Druga omogoča njihovo sodelovanje, ne da bi morale opustiti strokovne in poslovne procese, za katere so odgovorne.

1. Zakaj je bila ideja ene platforme privlačna

Gradbeni projekti so tradicionalno razdrobljeni. Podatki so razpršeni med načrti, popisi, terminskimi plani, preglednicami, dokumentnimi sistemi, elektronsko pošto, zapisniki, poslovnimi sistemi in projektnimi portali.

Zamisel o skupni platformi je obljubljala enotno mesto dostopa, manj podvajanja, preglednejše verzije dokumentov, lažje sodelovanje in hitrejše odločanje. Skupna okolja so še danes zelo koristna za izmenjavo dokumentacije, pregledovanje modelov, koordinacijo, potrjevanje, skupne registre in komunikacijo.

Težava nastane, ko skupno informacijsko okolje enačimo z eno aplikacijo, ki naj bi podpirala vse procese vseh udeležencev. To sta različni stvari.

2. Isti projekt, šest različnih osnovnih vprašanj

Vsi deležniki sodelujejo pri istem projektu, vendar vsak odgovarja za drugačno delo.

Nadzor in Inženir sta različni vlogi, čeprav se lahko njihove naloge v posamezni organizaciji ali pogodbenem modelu deloma prekrivajo. Že iz vprašanj je razvidno, da ena podatkovna in procesna struktura ne more biti enako primerna za vse.

3. Različne vloge potrebujejo različne informacijske modele

Projektant: model projektne rešitve

Projektant skrbi za funkcionalno in tehnično rešitev, usklajenost strok, projektno dokumentacijo, model objekta, specifikacije, projektantske količine in kakovost popisa. Njegova struktura je pogosto urejena po strokah, sistemih, objektih, etažah, prostorih, elementih, fazah in dokumentih.

Za to potrebuje orodja za modeliranje, izračune, tehnične analize, koordinacijo in pripravo dokumentacije. Njegov informacijski model ni kopija poslovnega sistema izvajalca.

Izvajalec: model proizvodnje in poslovanja

Izvajalec projekt pretvori v proces izvedbe. Potrebuje podatke o tehnologijah, delovnih sklopih, ekipah, mehanizaciji, materialih, podizvajalcih, nabavi, logistiki, produktivnosti, stroških, denarnem toku in zahtevkih.

Projekt lahko organizira po gradbiščnih fazah, tehnologijah, izvajalskih in nabavnih paketih, stroškovnih mestih, ekipah ali virih. Ta struktura ni enaka strukturi BIM-modela ali naročnikovega investicijskega proračuna.

Izvajalčevi normativi, nabavne cene, produktivnosti, podrobna kalkulacija, organizacija dela in marža so lahko njegova konkurenčna prednost. Skupni objekt zato ne pomeni skupne kalkulacije vseh udeležencev.

Inženir: model pogodbenega odločanja

Inženir spremlja razmerja med pogodbenim izhodiščem, dejansko izvedbo, spremembami, neskladji, zahtevki, roki, stroški, odgovornostmi in odločitvami.

BIM-model lahko pokaže, da je bila naprava zamenjana. Za obravnavo spremembe pa je treba vedeti, kdo jo je predlagal, zakaj je nastala, ali je bila potrjena, kakšen je njen pogodbeni in finančni status ter ali vpliva na rok ali zahtevek.

Model prikaže spremembo objekta. Inženir vodi proces, v katerem sprememba postane obravnavano in sledljivo projektno dejstvo.

Naročnik: model investicije

Naročnik potrebuje zanesljiv pregled nad odobrenim obsegom, pogodbeno vrednostjo, realizacijo, potrjenimi spremembami, odprtimi zahtevki ter napovedjo končne vrednosti in roka. Pomembno je tudi, katere odločitve ga čakajo in kakšne so posledice različnih možnosti.

Potrebuje skupno sliko investicije, ne nujno vpogleda v vse interne postopke in poslovne podatke pogodbenih partnerjev.

Upravljavec: model sredstev in operativnih procesov

Upravljavec prevzame rezultat projekta, ne njegove začasne organizacije. Zanimajo ga dejansko vgrajena sredstva, njihova identiteta in lokacija, stanje, garancije, servisni režimi, dokumentacija, zgodovina posegov in stroški življenjskega cikla.

Projektni model je zato treba povezati z registrom sredstev in sistemi za upravljanje objekta. Projektant, izvajalec in upravljavec lahko govorijo o isti napravi, vendar jo obravnavajo v različnih strukturah in za različne namene.

4. Skupno okolje ne odpravi pogodbenih meja

Projekt sestavljajo samostojne organizacije. Vsaka ima svoje pogodbe, obseg odgovornosti, pooblastila, obveznosti, poslovne interese in dokazila.

Digitalno sodelovanje ne odpravi odgovornosti naročnika, izvajalca, projektanta, Inženirja, dobavitelja ali upravljavca. Omogočiti mora, da so njihove vloge jasne, podatki sledljivi, dostop pa določen glede na odgovornost in namen.

Transparentnost skupnega projekta ne pomeni popolne transparentnosti poslovanja vsakega deležnika. Izvajalec lahko varuje podrobno kalkulacijo, nabavne cene in marže; projektant interne metode in knjižnice; naročnik pa svoje finančne omejitve in interne scenarije.

5. En vir podatkov ne pomeni ene številke za vse namene

Za vsak pomemben podatek mora biti jasno, kateri zapis velja, kdo ga je potrdil, iz katerega sistema prihaja, za kateri namen velja in na kateri datum se nanaša.

Za isto postavko lahko obstajajo projektantska ocena, ponudbena cena, pogodbena cena, izvajalčev strošek, nabavna cena, potrjena realizacija, dejanski strošek in napoved končne vrednosti. Nobena od teh vrednosti ni nujno napačna: vsaka odgovarja na drugo vprašanje.

Podobno lahko obstajajo pogodbeni rok, izhodiščni terminski plan, aktualni izvedbeni plan izvajalca, napoved zaključka in potrjeno podaljšanje roka.

Enoten vir podatkov ne pomeni ene številke za vse namene. Pomeni, da so pri vsaki vrednosti jasni njen pomen, izvor, status in datum.

6. Kaj mora biti povezano in kaj mora ostati ločeno

Projekt potrebuje skupne referenčne podatke: identiteto projekta, strukturo objektov in lokacij, veljavne dokumente, pogodbeni obseg, identifikatorje postavk, ključne mejnike, statuse pregledov, potrjene količine, spremembe, neskladja, zahtevke, odločitve in revizijsko sled.

Ti podatki morajo biti dostopni udeležencem, ki jih potrebujejo za svojo vlogo. Pri vsakem zapisu morajo biti razvidni predmet, veljavna različica, status, odgovorna oseba in naslednji potrebni ukrep.

Ločeno pa lahko ostanejo interni strokovni in poslovni podatki posameznih organizacij. Pravilna arhitektura torej povezuje skupne projektne informacije, hkrati pa upošteva lastništvo podatkov, dostopne pravice in poslovno zaupnost.

7. Ena platforma je koristna, če podpira skupne procese

Skupno informacijsko okolje oziroma CDE (Common Data Environment) lahko zelo dobro podpira izmenjavo veljavnih dokumentov, pregledovanje modelov, koordinacijo, potrjevanja, obravnavo vprašanj, skupne registre, komunikacijo in revizijsko sled.

Lahko ponudi tudi enoten uporabniški pogled na podatke iz več specializiranih sistemov. To pa ne pomeni, da mora ista platforma izvajati projektantske izračune, izvajalčevo kalkulacijo, nabavo, računovodstvo, podrobno terminsko planiranje in vzdrževanje sredstev.

Ko en sistem poskuša enako podrobno podpirati vsa ta področja, pogosto nastane široka, a plitva rešitev. Uporabniki zato izvažajo podatke v preglednice, vodijo vzporedne evidence ali uporabljajo dodatna orodja.

Enoten uporabniški pogled je mogoč. Enoten procesni sistem za vse udeležence pa praviloma ni.

8. Povezati moramo tri različne modele

Za razumevanje projekta potrebujemo najmanj tri povezane modele:

• Produktni model opisuje objekt: elemente, geometrijo, sisteme, lastnosti in prostorske odnose. Njegovo glavno orodje je BIM (Building Information Modeling).
• Projektno-tehnološki model opisuje nastajanje objekta: dela, tehnologije, popise, količine, normative, vire, terminski plan, izvedbo, spremembe in situacije.
• Poslovni modeli deležnikov opisujejo njihove pogodbe, prihodke, stroške, nabavo, računovodstvo, vire in poslovne rezultate. Med njihovimi orodji so sistemi ERP (Enterprise Resource Planning).

Za delovanje projekta potrebujemo nadzorovane povezave med modeli. Različni modeli niso težava; težava nastane, kadar med njimi ni jasnih povezav ali kadar jih poskušamo na silo združiti.

9. Primer: obravnava spremembe fasadnega sistema

Ista sprememba sproži različne naloge:

• Projektant spremeni tehnično rešitev, model, zahtevane lastnosti in dokumentacijo.
• Izvajalec preveri tehnologijo, pridobi ponudbe ter oceni vpliv na nabavo, stroške in izvedbo.
• Inženir preveri razlog in pogodbeni status ter obravnava stroškovni in terminski vpliv.
• Naročnik presodi vpliv na proračun, rok, kakovost in cilje investicije ter sprejme odločitev v okviru svojih pooblastil.
• Upravljavec preveri posledice za vzdrževanje in stroške v življenjskem ciklu.

Vsi obravnavajo isto spremembo, vendar ne opravljajo iste naloge. Skupni naj bodo identifikator spremembe, njen predmet, veljavna dokumentacija, status, odločitev in potrjene posledice. Podrobna izvajalčeva kalkulacija, naročnikovi interni scenariji, projektantove delovne variante in upravljavčeva interna strategija pa lahko ostanejo ločeni.

Različni procesi se morajo srečati pri isti sledljivi projektni odločitvi.

10. Interoperabilnost poveže specializirane rešitve

Različni procesi ne pomenijo nepovezanih informacijskih silosov. Interoperabilnost omogoča, da projektant objavi strukturiran popis, izvajalec ga uporabi v kalkulaciji, ponudbena struktura postane pogodbena, identiteta postavke pa se ohrani v situaciji.

Omogoča tudi, da potrjena realizacija preide v finančno spremljanje, sprememba ostane povezana z elementom, postavko, planom in odločitvijo, podatki o vgrajenem proizvodu pa se prenesejo v register sredstev.

Za to potrebujemo klasifikacije, enotne identifikatorje, podatkovne slovarje, dogovorjene statuse, standardizirane strukture, vmesnike, validacijo in sled prenosa podatkov.

Enotnost moramo iskati v podatkovnem jeziku in pravilih izmenjave, ne v prisilni uporabi ene aplikacije.

11. Vloga umetne inteligence in BIM-a

Umetna inteligenca (AI, artificial intelligence) lahko pomaga prepoznavati podobne zapise, predlagati klasifikacije, povezovati modelne elemente s postavkami, primerjati dokumente in registre ter opozarjati na manjkajoče povezave ali neusklajene statuse.

Ne more pa sama odločiti, kateri interni poslovni podatek mora postati skupen, ali projektantska rešitev samodejno spreminja pogodbo ali ali zaznano odstopanje pomeni zahtevek. Pri takih vprašanjih ostajajo ključni pooblastila, pogodbeni postopki in strokovna presoja.

BIM je pomembno izboljšal razumevanje objekta, koordinacijo in izmenjavo modelov. Kritično vprašanje je pretirana obljuba, da lahko skupni model objekta sam postane poslovni, pogodbeni, stroškovni, terminski in upravljavski model vseh udeležencev.

MYTHBUSTERS

Ključne ugotovitve

1. Deležniki istega projekta imajo različne naloge, odgovornosti in informacijske potrebe.
2. Projektant, izvajalec, Inženir, naročnik in upravljavec potrebujejo različne strokovne in poslovne modele.
3. Skupno okolje mora povezovati dogovorjene projektne podatke, hkrati pa upoštevati vloge, dostopne pravice in poslovno zaupnost.
4. En vir podatkov ne pomeni ene številke za vse namene; pomen, izvor, status in datum vsake vrednosti morajo biti jasni.
5. Interoperabilnost med specializiranimi rešitvami je primernejši cilj od zahteve, da vsi uporabljajo isti program.

Zaključna misel

Različni deležniki ne potrebujejo istega informacijskega sistema, potrebujejo pa skupni podatkovni jezik, jasne odgovornosti in povezane sisteme, da njihovi procesi tvorijo en obvladovan projekt.