27 ZAKAJ SO NORMATIVI, KLASIFIKACIJE IN CENIKI KLJUČNA INFRASTRUKTURA PANOGE

Programska orodja izvajajo procese. Klasifikacije, normativi in referenčne baze cen pa zagotavljajo skupni jezik, strokovno logiko in ekonomski kontekst. Brez njih se podatki ne morejo zanesljivo povezovati, primerjati in izboljševati.

Ko govorimo o digitalizaciji gradbeništva, največ pozornosti praviloma namenimo programskim rešitvam: orodjem BIM (Building Information Modeling), sistemom ERP (Enterprise Resource Planning), okoljem CDE (Common Data Environment), terenskim aplikacijam, analitičnim platformam in umetni inteligenci (AI, artificial intelligence).

Toda programska rešitev lahko kakovostno obdeluje samo podatke, ki jih razume. Vedeti mora, kaj posamezen element, delo ali vir pomeni, kako je razvrščen, s čim je povezan, kateri viri so potrebni za izvedbo, koliko jih porabimo in koliko stanejo.

Cena mora imeti tudi svoj kontekst: za kateri čas, trg, lokacijo in pogoje velja.

Če skupne podatkovne in strokovne osnove ni, vsak sistem razvije lastne šifrante, opise, normative, cenovne baze in pravila razlage. Podatki so digitalni, vendar niso nujno primerljivi ali interoperabilni.

Klasifikacije, normativi, ceniki in baze znanja so bili kot podlaga projektno-tehnološkega modela predstavljeni tudi leta 2018 (Biznis & trendi v gradbeništvu, 17. in 18. april 2018, GH Bernardin, Portorož).

Brez ustrezne baze znanja je projekte težje pripravljati, kalkulirati in voditi kakovostno ter dosledno.

Klasifikacije povedo, kaj nekaj je. Normativi povedo, kako in s katerimi viri to izvedemo. Cenovne baze povedo, koliko ti viri stanejo v določenem času in okolju.

Skupaj omogočajo povezavo:

PROJEKTNA REŠITEV
↓
STRUKTURIRAN OPIS DELA
↓
KLASIFIKACIJA
↓
TEHNOLOGIJA IN NORMATIVI
↓
VIRI IN CENE
↓
KALKULACIJA
↓
PONUDBA · PLAN · NABAVA · IZVEDBA · POKALKULACIJA

Vsaka raven odgovarja na drugo vprašanje: klasifikacija pove, kaj delo je; normativ opredeli potrebne vire; cenovna baza poda njihov strošek; kalkulacija pa oceni strošek konkretnega dela v konkretnih pogojih.

Kalkulacija ni številka, pripisana opisu. Je rezultat povezane strokovne in podatkovne infrastrukture.

1. Podatkovna infrastruktura povezuje različne procese

Klasifikacije, normativi in referenčne cene niso namenjeni enemu programu ali enemu projektu. Uporabljajo jih lahko projektant pri pripravi dokumentacije in popisa, naročnik pri oceni investicije, izvajalec pri kalkulaciji, planer pri oblikovanju aktivnosti, nabava pri izbiri virov, Inženir pri vrednotenju sprememb, upravljavec pri razvrščanju sredstev in analitik pri primerjavi projektov.

Njihova naloga ni, da vsi udeleženci delajo enako. Omogočajo, da se različne naloge lahko povezujejo in da isti strokovni pojem v različnih sistemih ohrani razumljiv pomen.

2. Klasifikacija je več kot seznam kod

Klasifikacija sistematično razvršča objekte, sisteme, gradnike, elemente, vrste del, materiale, proizvode, vire in sredstva. Omogoča njihovo enotno identifikacijo, iskanje, združevanje, primerjanje in povezovanje med sistemi.

Izraz »izolacija« je brez konteksta nejasen. Lahko pomeni toplotno izolacijo fasade ali strehe, hidroizolacijo, zvočno izolacijo, protipožarno zaščito ali izolacijo cevovoda. Klasifikacija poda strokovni kontekst, semantični parametri pa opredelijo material, debelino, funkcijo, mesto uporabe, zahtevane lastnosti in način izvedbe.

Klasifikacija podatku poda naslov. Semantika pojasni, kaj na tem naslovu dejansko obstaja.

Različni procesi lahko potrebujejo različne klasifikacije. Projektant lahko razvršča po objektih, sistemih, elementih in prostorih; izvajalec po vrstah del, tehnologijah, virih in podizvajalcih; naročnik po pogodbah in investicijskih sklopih; upravljavec pa po funkcionalnih sistemih, sredstvih in vzdrževalnih enotah.

Zato ena hierarhija ne more optimalno podpirati vseh namenov. Potrebujemo jasne definicije, trajne identifikatorje in dokumentirane povezave med različnimi klasifikacijami.

3. Normativ je strokovno izhodišče, ne predpisana resnica

Normativ je strokovna ocena virov, potrebnih za izvedbo določene aktivnosti v opredeljenih pogojih. Vključuje lahko material, delo, mehanizacijo, transport, pomožne vire, čas, produktivnost ter izgube in odpad.

Normativ za zidanje na primer ni univerzalna konstanta. Odvisen je lahko od vrste in dimenzije zidaka, načina vezave, višine dela, dostopa, velikosti ekipe, mehanizacije, zahtevnosti detajlov in organizacije gradbišča.

Razlikovati je treba tri ravni:

• Referenčni normativ je primerljivo strokovno izhodišče za prve ocene, kontrole in preverjanje kalkulacij.
• Podjetniški normativ odraža tehnologijo podjetja, njegovo opremo, organizacijo ekip, izkušnje in dejansko produktivnost. Predstavlja lahko konkurenčno znanje podjetja.
• Projektni normativ upošteva pogoje konkretnega projekta, kot so lokacija, dostop, faznost, količina, roki, omejitve in izbrana tehnologija.

Referenčni normativ je izhodišče. Konkretno kalkulacijo je treba prilagoditi tehnologiji, podjetju in pogojem projekta.

Normativ ni samo seznam številk. Povezan mora biti z aktivnostjo, rezultatom dela, pogoji izvedbe, sestavo ekipe, mehanizacijo, enotami in produktivnostjo. Tako postane tudi opis tehnološkega modela izvedbe, ki je uporaben pri kalkulaciji, planiranju virov in pokalkulaciji.

4. Cenovni podatek potrebuje kontekst

Cenik ni samo tabela vira, enote mere in cene. Da ga lahko pravilno uporabimo, moramo poznati vsaj vrsto cene, njen vir, datum, lokacijo, valuto, enoto, količino ter to, kateri stroški so vključeni.

Cena betona lahko pomeni ceno na betonarnI, ceno z dostavo na gradbišče, ceno s črpalko, ponudbeno ali pogodbeno ceno, dejanski strošek ali zgodovinsko referenčno ceno. Te vrednosti odgovarjajo na različna vprašanja, zato morajo ostati ločene in sledljive.

Za isti vir lahko obstajajo:

• referenčna cena za oceno in primerjavo;
• dobaviteljska cena za določen proizvod, količino, datum in pogoje dobave;
• projektna cena v kalkulaciji konkretnega projekta;
• pogodbena oziroma naročena cena po dogovoru;
• dejanski strošek iz nabave oziroma računa;
• zgodovinska realizirana cena iz zaključenega projekta.

Tudi proizvodi morajo biti primerljivi po lastnostih. Dve toplotni izolaciji enake debeline se lahko razlikujeta po materialu, gostoti, toplotni prevodnosti, tlačni trdnosti, požarnem razredu in načinu vgradnje.

Cena je uporabna za primerjavo samo, če poznamo njen izvor, veljavnost in vsebino ter vemo, kaj kupujemo.

5. Klasifikacija, normativ in cena delujejo skupaj

Vsaka od teh baz je brez povezav omejeno uporabna. Klasifikacija brez normativa pove, kaj delo je, ne pa, kako se izvede in katere vire potrebuje. Normativ brez klasifikacije je težje najti, povezati s popisom in primerjati. Normativ brez cen ne omogoča ocene stroška. Cena brez opisa in klasifikacije pa ne pove zanesljivo, za kateri vir ali proizvod velja.

Pri armiranobetonski steni:

• klasifikacija opredeli konstrukcijski element, vrsto dela, material, funkcijo in lokacijo;
• strukturiran popis določi razred betona, debelino, površino, način obračuna in zahtevane lastnosti;
• normativi opredelijo beton, armaturo, opaž, delo, črpanje, mehanizacijo in produktivnost;
• cenovne baze podajo stroške virov, transporta in dobave;
• projektni pogoji upoštevajo višino, dostop, faznost, količino in zahtevnost geometrije.

Tako nastane kalkulacija, ki jo je mogoče razumeti, preveriti in prilagoditi ter uporabiti tudi pri planiranju in nabavi.

6. Skupna osnova in konkurenčno znanje

Podatkovna infrastruktura ni namenjena samo kalkulantom. Projektantu pomaga pri popisu in primerjavi variant, izvajalcu pri kalkulaciji, tehnologiji in nabavi, planerju pri produktivnosti in trajanju aktivnosti, Inženirju pri vrednotenju sprememb, naročniku pri investicijskih ocenah ter upravljavcu pri razvrščanju sredstev in spremljanju stroškov njihovega življenjskega cikla.

Smiselno je skupno upravljati terminologijo, identifikatorje, klasifikacije, enote mere, osnovne metodologije in referenčne podatke. Podjetja pa lahko ohranijo svoje tehnologije, produktivnost, prilagojene normative, nabavne cene, sestavo ekip in marže kot konkurenčno prednost.

Skupne baze zato potrebujejo jasno metodologijo, strokovno preverjanje, dokumentiran izvor in različice. Pri cenah so pomembni datum, veljavnost in lokacija; pri normativih pa uporabljeni pogoji, tehnologija in podlaga za oceno.

Primerjave med projekti morajo upoštevati kakovost in primerljivost podatkov ter varovati zaupne poslovne informacije. Primerno anonimizirani ali združeni podatki lahko pomagajo pri analizah referenčnih cen, produktivnosti in dejanskih rokov.

7. Projektno znanje se lahko izboljšuje

Po zaključku projekta lahko primerjamo načrtovane in dejansko porabljene vire, izvedene količine, čas, produktivnost in stroške. Če poznamo pogoje izvedbe in razloge za odstopanja, lahko ugotovitve uporabimo pri prihodnjih kalkulacijah in izboljševanju normativov.

Vsak projekt lahko izboljša naslednjega, če izkušnje sistematično zberemo, preverimo in povežemo s pogoji izvedbe.

Umetna inteligenca (AI, artificial intelligence) lahko pomaga pri predlaganju klasifikacij, iskanju podobnih aktivnosti in proizvodov, primerjavi planirane in dejanske porabe ter odkrivanju manjkajočih ali zastarelih podatkov.

Za uporabne predloge potrebuje urejeno semantiko, zanesljive identifikatorje, enote, datume, izvore, statuse in informacije o pogojih izvedbe. AI lahko dobro podatkovno infrastrukturo spremeni v aktivnejši sistem znanja, ne more pa nadomestiti njene strokovne kakovosti in upravljanja.

MYTHBUSTERS

Ključne ugotovitve

1. Klasifikacije, normativi in cenovne baze skupaj tvorijo strokovno in ekonomsko osnovo za povezovanje projektnih podatkov.
2. Različni procesi lahko potrebujejo različne klasifikacije, vendar morajo biti definicije in povezave med njimi jasne.
3. Referenčni normativ je strokovno izhodišče, podjetniški in projektni normativi pa upoštevajo tehnologijo, konkurenčno znanje in dejanske pogoje izvedbe.
4. Cenovni podatek potrebuje izvor, datum, lokacijo, enoto in jasno opredeljeno vsebino.
5. Pokalkulacije in preverjeni podatki iz izvedbe omogočajo postopno izboljševanje znanja, kalkulacij in prihodnjih projektov.

Zaključna misel

Klasifikacije povedo, o čem govorimo. Normativi pojasnijo, kako delo izvedemo in katere vire potrebujemo. Cenovne baze jim dajo ekonomski kontekst. Skupaj omogočajo sledljive kalkulacije, primerljive projekte in učenje iz izvedbe.

26 STANDARDIZACIJA IN INTEROPERABILNOST – NAJVEČJI NEIZKORIŠČEN POTENCIAL

Digitalizacija panoge se ne začne z eno platformo, temveč s skupnim jezikom, ki omogoča, da podatki med sistemi, deležniki in projekti ohranijo identiteto, pomen in status.

Gradbeništvu danes ne primanjkuje programskih rešitev.

Projektanti uporabljajo specializirana orodja za projektiranje in BIM (Building Information Modeling). Izvajalci imajo programe za kalkulacije, planiranje, nabavo in poslovanje. Naročniki uporabljajo dokumentne, finančne in investicijske sisteme. Inženirji vodijo situacije, spremembe, zahtevke in terminske podatke. Upravljavci pa uporabljajo registre sredstev in sisteme EAM (Enterprise Asset Management), CAFM (Computer-Aided Facility Management) ali CMMS (Computerized Maintenance Management System).

Tehnologije je veliko. Podatki pa se med udeleženci še vedno pogosto prenašajo kot PDF-dokumenti, nepovezane preglednice, prosto napisana besedila, e-poštne priloge in projektno specifični izvozi. Prejemniki jih morajo znova prebrati, razvrstiti, prepisati, preveriti in povezati s svojimi sistemi.

Tako je lahko vsak posamezni deležnik znotraj svoje organizacije dobro digitaliziran, celotna izvedbena veriga pa še vedno deluje skoraj analogno.

Digitalizirali smo posamezne otoke. Mostov med njimi še nismo zgradili.

Že leta 2018 je bila kot razvojna smer predstavljena povezava produktnega, projektno-tehnološkega in poslovnega modela ter standardizacija popisov, e-ponudb, e-situacij, naročanja, dobave in materialnega poslovanja. Poudarek je bil na lokalni vzpostavitvi sistemov, podatkovnih baz in standardiziranih postopkov, ki bi omogočili učinkovito uporabo BIM-orodij (Biznis & trendi v gradbeništvu, 17. in 18. april 2018, GH Bernardin, Portorož).

Podatek naj nastane pri viru, kjer je najbolj zanesljiv, nato pa se mora brez izgube pomena uporabiti v več procesih.

Interoperabilnost ne pomeni samo, da lahko dva sistema izmenjata datoteko. Pomeni, da preneseni podatek v drugem sistemu ohrani identiteto, pomen, enoto, status, veljavnost, odgovornost in povezave.

Prava digitalizacija ne deluje tako:

SISTEM A
↓
IZVOZ DATOTEKE
↓
ČLOVEK PREBERE IN PREPIŠE
↓
SISTEM B

Delovati mora tako:

PODATEK Z IDENTITETO
↓
NADZOROVANA IZMENJAVA
↓
DRUG SISTEM GA RAZUME IN UPORABI
↓
OHRANJENA SLED IZVORA IN SPREMEMB

Standardizacija določi skupni jezik. Interoperabilnost omogoči, da se ta jezik uporablja med različnimi sistemi.

Standard brez uporabe ostane dokument. Izmenjava brez skupnega pomena pa samo hitreje prenaša nesporazume.

1. Standardizacija določa skupni jezik

Standardizacija se pogosto razume kot priprava enotnih obrazcev ali predpisovanje ene dovoljene rešitve. Pri digitalizaciji gradbeništva pomeni predvsem dogovor o tem, kako podatke identificiramo, strukturiramo in poimenujemo, katere lastnosti in enote vsebujejo, kakšne statuse imajo, kako se povezujejo ter kdo jih ustvari in potrdi.

Standardiziran jezik omogoča, da različni udeleženci pod istim podatkom razumejo isto stvar. Oznaka postavke na primer ne sme v enem sistemu pomeniti projektantske ocene, v drugem pa pogodbene postavke, ne da bi bila ta razlika jasno označena.

Standardizacija ne določa samo oblike podatka. Določa tudi njegov dogovorjeni strokovni pomen.

2. Interoperabilnost ima več plasti

Interoperabilnost je sposobnost različnih sistemov, organizacij, strok in procesov, da si izmenjujejo podatke in jih smiselno uporabljajo. Za razumevanje je koristno ločiti več njenih plasti:

• Tehnična: ali lahko sistema vzpostavita povezavo in preneseta datoteko ali sporočilo?
• Strukturna: ali prejemnik prepozna polja, vrste podatkov, hierarhijo in obliko zapisa?
• Semantična: ali oba sistema enako razumeta pomen, enoto, klasifikacijo in status podatka?
• Procesna: ali se podatek pravilno uporabi v naslednjem procesu, na primer pri prenosu potrjene količine v situacijo?
• Organizacijska in pogodbena: ali je jasno, kdo je podatek ustvaril, preveril in potrdil, za kateri namen velja ter kdo odgovarja za njegovo uporabo?

To so različni vidiki interoperabilnosti, ne nujno zaporedne stopnje. Prava interoperabilnost se začne pri prenosu, konča pa šele pri pravilni uporabi podatka v naslednjem procesu.

3. Format in API še ne zagotavljata skupnega pomena

XML (Extensible Markup Language), JSON (JavaScript Object Notation), XLSX (Office Open XML Spreadsheet) in IFC (Industry Foundation Classes) določajo, kako je mogoče podatke zapisati in prebrati. Sami po sebi pa ne določajo, ali »količina« pomeni projektirano, ponudbeno, pogodbeno, izvedeno ali potrjeno količino.

Prav tako format sam ne pove, ali je cena ocenjena, ponudbena, pogodbena ali dejanska; ali je sprememba predlog ali že odobreno stanje; ali se površina meri bruto ali neto; in katera dela so vključena v postavko.

Podobno API (Application Programming Interface) omogoča, da en sistem od drugega zahteva ali prejme podatek oziroma sproži določeno funkcijo. Sam pa ne določa skupne klasifikacije, pomena polj, statusov, pravil preverjanja in odgovornosti.

Vmesnik poveže sistema. Skupna semantika poveže pomen podatkov.

Kakovostna izmenjava zato potrebuje kombinacijo vmesnika, podatkovnega modela, semantike, procesnih pravil in jasno določenih odgovornosti.

4. Identiteta in status morata spremljati podatek

Ista postavka lahko dobi novo oznako v razpisni preglednici, izvajalčevem sistemu, pogodbi, situaciji ali sistemu ERP (Enterprise Resource Planning). Če med temi oznakami ni sledljive povezave, je treba ob vsaki spremembi znova ugotavljati, na katero postavko, aktivnost, pogodbo ali situacijo se nanaša.

Cilj zato ni vedno ohraniti isto oznako v vsakem sistemu. Cilj je ohraniti stabilno identiteto podatka ali sledljivo povezavo med različnimi identifikatorji. To je pomembno tudi, kadar se postavka razdeli, združi ali drugače strukturira.

Poleg identitete mora podatek ohraniti tudi svoj status. Količina je lahko projektirana, pogodbena, prijavljena, izmerjena, preverjena, potrjena ali obračunana. Če se prenese samo številka, prejemnik ne ve, kaj ta številka pomeni in kako jo lahko uporabi.

Številka brez statusa je vrednost brez konteksta. Podatek mora ohraniti identiteto, pomen, izvor in stanje.

5. E-ponudba, e-situacija in merilna dokazila

Digitalna ponudba ni samo preglednica, poslana po elektronski pošti. Naročnik objavi strukturiran popis z identifikatorji, hierarhijo, opisi, enotami, količinami in pravili za izpolnjevanje. Ponudnik vrne cene ter zahtevane podatke o proizvodih, lastnostih, rokih in alternativah. Sistem lahko preveri popolnost ponudb, jih primerja in ohrani povezavo s pogodbenimi postavkami.

Tudi digitalna situacija ni samo PDF klasičnega obračuna. Uporablja pogodbeno strukturo in vsebuje izvedene količine za obračunsko obdobje, kumulativno realizacijo ter povezave do ustreznih dokazil in sprememb.

Pri tem pa je treba razlikovati med **knjigo obračunskih izmer** in situacijo. Izmere se najprej pripravijo in pregledajo; potrjene izmere so podlaga za situacijo. Digitalni sistem lahko meritve in njihovo preverjanje poveže s postopkom potrjevanja situacije, vendar to ni nujno izvedljivo ali smiselno v vseh primerih. Obsežne meritve, na primer geodetske meritve v 2D, so lahko ločeno pripravljena dokazila, povezana s količinami v obračunu.

Nadzor oziroma Inženir obravnava količine in dokazila v skladu z dodeljenimi nalogami in pogodbenimi pooblastili. Potrjeni podatki se nato uporabijo pri obračunu in finančnem spremljanju.

E-ponudba in e-situacija sta strukturirana procesa. Njuna zanesljivost je odvisna tudi od kakovostnih meritev, dokazil, preverjanja in jasno določenih odgovornosti.

Prav standardizacija popisov, e-ponudb in e-situacij je bila leta 2018 predstavljena kot pomemben del projektno-tehnološkega razvoja (Biznis & trendi v gradbeništvu, 17. in 18. april 2018, GH Bernardin, Portorož).

6. Standardizirati je treba podatkovni tok

Standardizacija končnega obrazca določa, kako je videti dokument. Digitalizacija mora določiti tudi, kdo podatek ustvari, katere lastnosti vsebuje, kako se preveri, kdo ga potrdi, kakšen status dobi in kje se uporabi naprej.

Dokument ostaja pomemben prikaz oziroma dokaz procesa. Strukturirani podatki pa omogočajo pripravo različnih obrazcev, pregledov, poročil, analiz in izvozov.

Tudi standardiziran opis del še ni samodejno strukturiran digitalni podatek. Za strojno uporabo potrebujemo identifikator, klasifikacijo, parametre, lastnosti, dovoljene vrednosti, enote, pravila merjenja in povezave z elementi, viri ter proizvodi.

Ne standardizirajmo samo videza dokumenta. Standardizirajmo pot podatka skozi projekt.

7. Standardizirati je treba skupni jezik, ne poslovnih prednosti

Standardizacija omogoča, da projektant uporablja svoje orodje, izvajalec svoj kalkulacijski in poslovni sistem, Inženir projektni informacijski sistem, naročnik pregled investicije, upravljavec pa sistem EAM. Različni sistemi lahko učinkovito sodelujejo, če se dogovorijo o identifikatorjih, klasifikacijah, lastnostih, statusih in pravilih izmenjave.

Skupna pravila pa ne zahtevajo, da podjetja razkrijejo svoje tehnologije izvajanja, organizacijo gradbišča, produktivnost, interne normative, nabavne strategije ali marže. To so lahko njihove konkurenčne prednosti.

Skupna pravila igre ne pomenijo, da morajo vsi igrati na enak način.

8. Podatkovna infrastruktura je skupni interes panoge

Posamezno podjetje lahko uredi svoje notranje procese. Skupnega jezika za naročnike, projektante, izvajalce, dobavitelje, upravljavce in programske rešitve pa ne more določiti samo.

Če vsak ponudnik razvije svoj zaprt standard, nastanejo novi podatkovni otoki. Zato skupna podatkovna infrastruktura potrebuje sodelovanje stroke, naročnikov, zbornic, javnih institucij, izobraževalnih in raziskovalnih organizacij, ponudnikov rešitev ter predstavnikov izvajalske in dobaviteljske verige.

Nacionalni podatkovni model ne pomeni ene centralne aplikacije za vse projekte. Lahko določa skupne klasifikacije, podatkovne slovarje, identifikacijska pravila, strukture transakcij, pravila merjenja, statuse in minimalne podatkovne zahteve. Različni sistemi ga lahko uporabljajo na različne načine, če njihove podatke med seboj razumemo in povežemo.

Standard potrebuje upravljavca, javno dokumentacijo, verzioniranje, strokovno recenzijo, postopek dopolnjevanja, preslikave med različicami in testne primere. Interoperabilnost pa mora biti preverljiva: ali se denimo popis prenese brez izgube hierarhije, ali postavke ohranijo sledljivo identiteto in ali druga organizacija razume status prejetih količin?

Podatkovni standard ni last ene aplikacije. Je skupna infrastruktura panoge, ki jo je treba vzdrževati in preverjati.

9. Kje začeti in kakšno vlogo ima AI

Ni treba takoj standardizirati celotne gradbene panoge. Začnemo lahko pri procesih, v katerih se isti podatki pogosto izmenjujejo, ročno prepisujejo in neposredno vplivajo na denar ali čas:

• digitalni popis in pogodbene postavke;
• e-ponudba in strukturiran prenos ponudbenih podatkov;
• izmere, dokazila in digitalna situacija;
• register sprememb s statusi, vplivi in odgovornostmi;
• podatki o proizvodih od tehnične zahteve do dobave in vgradnje;
• predaja podatkov o sredstvih upravljavcu.

Umetna inteligenca (AI, artificial intelligence) lahko pomaga pri razvrščanju opisov, predlaganju klasifikacij, povezovanju podatkov iz različnih sistemov in prepoznavanju manjkajočih lastnosti. Lahko pomaga tudi pri pretvarjanju starih dokumentov v strukturirane zapise.

AI pa ne nadomesti dogovora o tem, kaj podatki pomenijo, kateri status je veljaven in kdo je odgovoren za njihovo potrditev. Z urejeno semantiko in sledljivim izvorom so njeni predlogi zanesljivejši in lažje preverljivi.

Standardizirani in primerno anonimizirani oziroma združeni podatki lahko omogočijo tudi analize referenčnih cen, produktivnosti, dejanskih rokov in ponavljajočih se neskladij. Pri tem morajo biti določeni pogoji dostopa in uporabe, ki varujejo zaupne podatke udeležencev.

Interoperabilnost ne pospeši samo prenosa podatkov. Omogoči, da znanje iz posameznih projektov koristi tudi naslednjim.

MYTHBUSTERS

Ključne ugotovitve

1. Standardizacija določi skupni podatkovni jezik, interoperabilnost pa omogoči njegovo uporabo med sistemi, organizacijami in procesi.
2. Format ali programski vmesnik še ne zagotavljata, da bodo sistemi enako razumeli pomen, status in odgovornost podatka.
3. Podatki morajo ohraniti stabilno identiteto ali sledljivo povezavo med identifikatorji tudi, kadar se strukture med sistemi razlikujejo.
4. Digitalna ponudba in situacija sta strukturirana procesa, ki zahtevata ustrezna dokazila, preverjanje in jasno določene odgovornosti.
5. Skupni standardi omogočajo sodelovanje specializiranih rešitev, ne da bi podjetja opustila svoje procese ali razkrila konkurenčne prednosti.

Zaključna misel

Digitalizirana panoga nastane, ko lahko podatki potujejo skozi izvedbeno verigo brez izgube identitete, pomena, statusa in odgovornosti. Standardizacija ustvari skupni jezik, interoperabilnost pa ga poveže z delom različnih udeležencev.

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.

24 DIGITALIZACIJA OBJEKTA, PROJEKTA IN PANOGE NISO ISTA STVAR

BIM (Building Information Modeling) opisuje digitalni model objekta. Digitalni dvojček projekta povezuje njegovo nastajanje. Standardizacija in interoperabilnost omogočata sodelovanje celotne izvedbene verige.

Objekt je rezultat. Projekt je proces. Panoga je ekosistem, v katerem morajo podatki ohraniti svoj pomen.

Izraz digitalizacija gradbeništva uporabljamo zelo široko.

Z njim opisujemo:

• izdelavo BIM-modela;
• elektronsko projektno dokumentacijo;
• 360-stopinjsko spremljanje gradbišča;
• digitalne popise in situacije;
• terminsko planiranje;
• e-ponudbe in e-naročila;
• podatkovne baze;
• umetno inteligenco (AI – Artificial Intelligence);
• upravljanje objektov.

Vse to so deli digitalizacije gradbeništva, vendar ne rešujejo istega problema.

Digitalizacijo pogosto presojamo predvsem po tem, ali ima projekt BIM-model, skupno podatkovno okolje (CDE – Common Data Environment) ali napredno terensko aplikacijo. Tako lahko digitalizacijo objekta zamenjamo za digitalizacijo projekta, obe pa za digitalizacijo celotne panoge.

Posledica je lahko nenavaden položaj:

• objekt je zelo podrobno digitalno modeliran;
• projekt se še vedno vodi s preglednicami, elektronsko pošto in sestanki;
• vsak deležnik iste podatke znova prepisuje v svoj sistem;
• vsak nov projekt ponovno izumlja strukture, oznake in načine izmenjave.

Projekt je na prvi pogled digitaliziran, vendar digitalizacija ne seže skozi celotno izvedbeno verigo. Za razumevanje digitalizacije gradbeništva moramo zato ločiti tri ravni: objekt, projekt in panogo.

Digitalizacija objekta, projekta in panoge so tri povezane, vendar samostojne dimenzije. Vsaka ima druge uporabnike, podatke, procese in cilje.

Najpreprosteje:

OBJEKT

Kaj gradimo?

↓

Digitalni model objekta (BIM); če je povezan z dejanskim stanjem in operativnimi procesi, lahko postane digitalni dvojček objekta.

PROJEKT

Kako, kdaj, za koliko in s katerimi odločitvami gradimo?

↓

Digitalni dvojček projekta in projektno spremljanje ter obvladovanje (Project Controls).

PANOGA

Kako različni deležniki in sistemi izmenjujejo podatke?

↓

Standardizacija, semantika in interoperabilnost.

Ali še bolj jedrnato:

Objekt je rezultat gradnje. Projekt je proces njegovega nastajanja. Panoga je ekosistem organizacij, pravil in podatkovnih tokov, v katerem se projekti izvajajo.

1. Tri ravni digitalizacije

Te tri ravni niso samo različne tehnološke rešitve. Razlikujejo se tudi po:

• nosilcih odgovornosti;
• poslovnih interesih;
• življenjskem ciklu podatkov;
• potrebni stopnji skupnosti oziroma zaupnosti;
• načinu ustvarjanja vrednosti.

2. Digitalizacija objekta

Digitalizacija objekta obravnava predvsem fizični rezultat projekta.

BIM-model lahko objekt opiše kot zbirko strukturiranih elementov:

• sten;
• plošč;
• konstrukcij;
• prostorov;
• cevi;
• kanalov;
• naprav;
• opreme;
• infrastrukturnih elementov.

Za elemente lahko določa:

• geometrijo;
• lokacijo;
• material;
• dimenzije;
• tehnične lastnosti;
• prostorske odnose;
• pripadnost sistemu;
• povezano dokumentacijo.

Digitalni model objekta zato odlično podpira:

• projektiranje;
• prostorsko koordinacijo;
• odkrivanje kolizij;
• vizualizacijo;
• pripravo tehničnih prikazov;
• izračun količin modeliranih elementov;
• preverjanje izvedene geometrije;
• podporo prefabrikaciji;
• pripravo podatkov za upravljanje.

Njegovo osnovno vprašanje je:

Kaj je objekt in iz česa je sestavljen?

Po zaključku gradnje se lahko projektni model razvije v model izvedenega stanja. Če ostane povezan z dejanskim stanjem in operativnimi procesi, lahko postane del digitalnega dvojčka objekta.

Toda tudi zelo kakovosten model objekta sam po sebi ne pove:

• katera vrednost je pogodbena;
• katere spremembe so bile odobrene;
• zakaj se je rešitev spremenila;
• kdo je sprejel odločitev;
• kako sprememba vpliva na rok;
• koliko je bilo izvedeno in priznano;
• koliko bo projekt stal ob zaključku.

To niso predvsem vprašanja objekta. To so vprašanja projekta.

3. Digitalizacija projekta

Projekt ni samo zbirka dokumentov in tudi ni samo BIM-model.

Projekt je začasen in organiziran proces, v katerem različni deležniki:

• določajo obseg;
• prevzemajo obveznosti;
• načrtujejo čas in vire;
• izvajajo dela;
• preverjajo kakovost;
• obračunavajo izvedbo;
• obravnavajo spremembe;
• rešujejo neskladja;
• vlagajo zahtevke;
• sprejemajo odločitve.

Digitalizacija projekta mora zato povezovati najmanj:

• pogodbeni obseg;
• digitalni popis;
• kalkulacije in cene;
• terminski plan;
• dejansko napredovanje;
• digitalne situacije;
• spremembe;
• neskladja;
• zahtevke;
• negotovosti;
• odgovornosti;
• projektne odločitve;
• napoved končne vrednosti in roka;
• revizijsko sled.

Njeno osnovno vprašanje je:

Kaj je dogovorjeno, kaj se dejansko dogaja, zakaj se stanje spreminja in kaj pričakujemo do zaključka projekta?

Digitalni dvojček projekta zato ne opisuje samo rezultata, temveč tudi:

• izhodišče;
• aktualno stanje;
• odstopanja;
• vzroke;
• posledice;
• odprte odločitve;
• možen prihodnji razvoj.

BIM lahko pokaže, da se je element spremenil. Digitalni dvojček projekta mora pokazati, zakaj se je spremenil, kdo je spremembo odobril ter kakšne so njene finančne, terminske in pogodbene posledice.

4. Digitalizacija panoge

Gradbena panoga ni en projekt in ni eno podjetje.

Je mreža:

• naročnikov;
• projektantov;
• izvajalcev;
• podizvajalcev;
• Inženirjev;
• dobaviteljev;
• proizvajalcev;
• upravljavcev;
• javnih institucij;
• ponudnikov informacijskih rešitev.

Vsak udeleženec ima:

• svoje notranje procese;
• svoje informacijske sisteme;
• svoje podatkovne strukture;
• svoje poslovne interese;
• svoje odgovornosti;
• svoje konkurenčne podatke.

Digitalizacija panoge zato ne pomeni, da vsi uporabljajo isti program. Pomeni, da lahko različni sistemi in organizacije izmenjujejo skupne podatke, ne da bi se pri prenosu izgubili:

• identiteta;
• pomen;
• enota mere;
• status;
• veljavnost;
• izvor;
• odgovornost;
• povezava z drugimi podatki.

Za to potrebujemo:

• klasifikacije;
• podatkovne slovarje;
• standardizirane identifikatorje;
• pravila merjenja;
• standardizirane podatkovne strukture;
• interoperabilne formate;
• dokumentirane vmesnike;
• standardizirane poslovne transakcije.

Mednje sodijo na primer:

• digitalni razpisni popis;
• e-ponudba;
• e-naročilo;
• e-dobava;
• digitalna situacija;
• podatki o proizvodih;
• predaja podatkov o sredstvih.

Njeno osnovno vprašanje je:

Kako isti podatek potuje skozi izvedbeno verigo, ne da bi ga moral vsak udeleženec ponovno razlagati in prepisovati?

5. Digitalizirana podjetja še ne pomenijo digitalizirane panoge

Podjetja lahko zelo uspešno digitalizirajo svoje notranje poslovanje.

Izvajalec lahko poveže:

• kalkulacije;
• nabavo;
• skladišče;
• stroške;
• gradbišča;
• sistem za načrtovanje virov podjetja (ERP – Enterprise Resource Planning);
• poslovno analitiko.

Projektant lahko poveže:

• projektiranje;
• BIM;
• dokumentacijo;
• projektantske kontrole;
• interne baze znanja.

Naročnik lahko digitalizira:

• investicijsko načrtovanje;
• pogodbe;
• plačila;
• portfelj projektov.

Toda če si med seboj še vedno izmenjujejo:

• neenotne preglednice;
• PDF-predračune;
• prosta besedila;
• različne šifre;
• ročno prepisane situacije;
• neprimerljive podatke,

panoga kot celota še ni zares digitalizirana.

Vertikalna digitalizacija podjetij ne zagotavlja horizontalne digitalizacije izvedbene verige.

Podjetje je lahko digitalno zelo zrelo, njegovo sodelovanje z okoljem pa je še vedno skoraj povsem ročno.

Podobno je lahko posamezen projekt dobro povezan, vendar zahteva veliko enkratnih rešitev:

• lastne klasifikacije;
• posebne izvoze;
• ročne preslikave;
• projektne podatkovne slovarje;
• integracije po meri.

Projekt lahko deluje dobro, vendar je treba na naslednjem projektu velik del povezav znova vzpostaviti. To pomeni, da imamo kakovostno projektno rešitev, ne pa še infrastrukture panoge.

Znaki slabo digitalizirane panoge so:

• vsak naročnik zahteva drugo strukturo popisa;
• vsak projekt uporablja druge oznake;
• vsak Inženir uporablja drugačen obrazec situacije;
• dobaviteljski podatki se prepisujejo ročno;
• BIM-elementi se na vsakem projektu drugače povezujejo s popisom;
• zaključeni projekti niso primerljivi;
• programske integracije so vedno projekt po meri.

Digitalizirana panoga omogoča, da rešitev, razvita na enem projektu, postane uporabna tudi na naslednjih.

6. Tri različne smeri podatkovnih tokov

Za razumevanje digitalizacije panoge je koristno razlikovati tri smeri.

Vertikalni tok – znotraj organizacije

Povezuje procese posameznega podjetja.

Pri izvajalcu na primer:

PONUDBA

↓

KALKULACIJA

↓

NABAVA

↓

IZVEDBA

↓

DEJANSKI STROŠKI

↓

POKALKULACIJA

Tu nastajajo konkurenčne prednosti podjetja.

Horizontalni tok – med udeleženci projekta

Povezuje:

NAROČNIK ↔ PROJEKTANT ↔ GLAVNI IZVAJALEC ↔ PODIZVAJALCI ↔ DOBAVITELJI

Tu potrebujemo skupne identifikatorje, statuse in standardizirane transakcije.

Vzdolžni tok – skozi življenjski cikel

Povezuje:

NAČRTOVANJE → PROJEKTIRANJE → GRADNJO → PREDAJO → UPRAVLJANJE → REKONSTRUKCIJO

Tu morajo podatki ohraniti pomen skozi različne faze, organizacije in programske rešitve.

Digitalizacija panoge mora omogočiti vse tri tokove, ne da bi odpravila legitimne razlike med udeleženci.

7. Primer: ista naprava na treh ravneh

Vzemimo klimatsko napravo.

Na ravni objekta

BIM-model določa:

• lokacijo;
• geometrijo;
• dimenzije;
• priključno moč;
• pretok;
• povezavo s kanali;
• tehnične lastnosti.

Odgovarja na vprašanje:

Kaj je naprava in kam je umeščena?

Na ravni projekta

Projektni podatki določajo:

• postavko popisa;
• zahtevano specifikacijo;
• projektantsko potrditev;
• izbranega dobavitelja;
• pogodbeno ceno;
• rok dobave;
• terminsko aktivnost;
• izvedeno montažo;
• preizkus in zagon;
• morebitno spremembo;
• situirano vrednost.

Odgovarjajo na vprašanje:

Kako je bila naprava naročena, potrjena, vgrajena in obračunana?

Na ravni panoge

Skupna podatkovna infrastruktura omogoča:

• razvrstitev naprave v klasifikacijo;
• standardiziran opis zahtevanih lastnosti;
• primerljivo ponudbo različnih dobaviteljev;
• e-naročilo;
• podatke proizvajalca;
• digitalno dobavnico;
• standardizirano predajo upravljavcu;
• povezavo z registrom sredstev.

Odgovarja na vprašanje:

Kako različne organizacije in sistemi vedo, da govorijo o isti vrsti naprave in istih lastnostih?

Ista naprava torej nastopa v treh različnih, vendar povezanih informacijskih kontekstih.

8. Digitalna zrelost objekta in projekta nista isto

Projekt ima lahko:

• kakovosten BIM-model;
• redne koordinacije;
• avtomatizirano odkrivanje kolizij;
• 360-stopinjske posnetke;
• oblake točk;
• privlačne nadzorne plošče.

Hkrati pa:

• spremembe niso vodene v strukturiranem registru;
• terminski plan ni aktualen;
• situacije se obdelujejo v nepovezanih preglednicah;
• odločitve so razpršene po zapisnikih;
• zahtevki niso povezani z vzroki in vplivi;
• napoved končne vrednosti ni zanesljiva.

Tak projekt je lahko zelo digitaliziran na ravni objekta in slabo digitaliziran na ravni projektnega vodenja. To ni protislovje.

Digitalna zrelost objekta in digitalna zrelost projekta sta različni lastnosti.

Velja tudi obratno. Projekt lahko kakovostno uporablja:

• digitalni popis;
• strukturiran terminski plan;
• digitalne situacije;
• registre sprememb in neskladij;
• upravljanje zahtevkov;
• revizijsko sled odločitev;
• metodo pridobljene vrednosti (EVM – Earned Value Management);
• napoved končne vrednosti,

čeprav BIM-model ni osrednji vir podatkov.

To je lahko smiselno pri projektih:

• z manj kompleksno geometrijo;
• pri katerih je glavni izziv pogodbeno in terminsko obvladovanje;
• pri določenih vrstah vzdrževanja;
• pri katerih model ne prinaša sorazmerne koristi.

To ne pomeni, da je BIM nepotreben. Pomeni pa:

Digitalizacije projekta ne določa posamezna tehnologija, ampak obseg ključnih projektnih procesov, ki jih dejansko obvladujemo s podatki.

9. Tri ravni niso zaporedne stopnice

Digitalizacije objekta, projekta in panoge ne smemo razumeti kot preprosto zaporedje:

NAJPREJ OBJEKT → NATO PROJEKT → NATO PANOGA

Razvijati jih je treba vzporedno. Možne so različne kombinacije:

Zato tudi kakovostni standardi sami po sebi niso dovolj. Potrebujejo:

• programsko podporo;
• vključitev v pogodbene procese;
• usposobljene uporabnike;
• kakovostne podatke;
• dejansko uporabo na projektih.

10. Kje je mesto CDE-ja?

CDE je predvsem skupno informacijsko okolje posameznega projekta.

Povezuje:

• dokumente;
• projektne podatke;
• BIM- in terenske podatke;
• procese pregledovanja;
• statuse;
• odgovornosti;
• revizijsko sled.

Zato je CDE osrednja infrastruktura digitalizacije projekta. V njem lahko živijo oziroma se povezujejo tudi podatki o objektu.

Toda CDE posameznega projekta še ni digitalizacija panoge.

Da se podatki lahko prenašajo med različnimi CDE-ji, naročniki, projekti, podjetji, dobavitelji in operativnimi sistemi, potrebujemo standardizacijo in interoperabilnost na širši ravni.

CDE povezuje informacije na projektu. Standardi omogočajo, da se podatki povezujejo tudi med projekti in organizacijami.

11. Panoga ne potrebuje ene platforme, temveč skupna pravila

Pogosta napačna reakcija na razdrobljenost je zahteva:

Potrebujemo en skupni sistem, ki ga bodo uporabljali vsi.

Takšna rešitev bi morala hkrati optimalno podpirati:

• projektiranje;
• kalkulacije;
• nabavo;
• izvedbo;
• pogodbeno upravljanje;
• obračun;
• vzdrževanje;
• poslovanje podjetij;
• javne evidence.

To ni realno in tudi ni zaželeno. Različni udeleženci potrebujejo specializirane rešitve.

Digitalizirana panoga zato ne temelji na eni aplikaciji, ampak na skupnih pravilih, ki različnim aplikacijam omogočajo sodelovanje.

Analogija je preprosta: za učinkovito komunikacijo ni treba, da vsi uporabljamo isti telefon. Potrebujemo pa skupne komunikacijske protokole.

V gradbeništvu so takšna skupna pravila:

• podatkovni modeli;
• klasifikacije;
• enotni identifikatorji;
• standardizirane transakcije;
• dogovorjeni statusi;
• vmesniki;
• pravila validacije.

Standardizirati je smiselno:

• skupni jezik podatkov;
• osnovne podatkovne strukture;
• formate izmenjave;
• pravila merjenja;
• statuse;
• način dokazovanja izvora in veljavnosti;
• skupne poslovne transakcije.

Ni pa smiselno poenotiti:

• tehnologije izvajanja;
• organizacije gradbišča;
• produktivnosti ekip;
• notranjih kalkulacij;
• nabavnih strategij;
• marž;
• poslovnih modelov;
• konkurenčnih metod podjetij.

Standardizacija mora ustvarjati skupna pravila igre, ne pa odpravljati strokovne in poslovne konkurence.

Podjetja morajo tekmovati z znanjem, produktivnostjo, tehnologijo, organizacijo in inovacijami. Ne bi pa smela izgubljati časa s ponovnim prepisovanjem in razlaganjem osnovnih skupnih podatkov.

12. Digitalizacija panoge se začne pri transakcijah

Panoga se ne povezuje samo z modeli in dokumenti. Povezuje se predvsem z vsakodnevnimi transakcijami:

• povpraševanjem;
• ponudbo;
• pogodbo;
• naročilom;
• dobavo;
• potrditvijo;
• situacijo;
• računom;
• spremembo;
• predajo podatkov.

Če so te transakcije nestrukturirane, mora vsak prejemnik podatke ponovno prebrati, razumeti, razvrstiti, prepisati, preveriti in povezati s svojim sistemom.

Digitalna ponudba ni zgolj PDF, poslan po elektronski pošti. Njena vrednost nastane, ko se strukturirani podatki lahko uporabijo v naslednjih korakih:

POVPRAŠEVANJE

↓

ISTE POSTAVKE IN IDENTIFIKATORJI

↓

PONUDBENE KOLIČINE IN CENE

↓

PRIMERJAVA PONUDB

↓

IZBOR

↓

POGODBENA STRUKTURA

Enako velja za digitalno situacijo:

POGODBENI POPIS

↓

IZVEDENA KOLIČINA

↓

PREVERJENA KOLIČINA

↓

POTRJENA SITUACIJA

↓

RAČUN IN FINANČNO SPREMLJANJE

Prav standardizacija takšnih procesov je bila že v predstavitvi iz leta 2018 izpostavljena kot pomembnejši nacionalni razvojni izziv: standardizacija popisov, e-ponudb, e-situacij ter procesov naročanja, dobave in porabe (Biznis & trendi v gradbeništvu, 17. in 18. april 2018, GH Bernardin, Portorož).

13. Od posameznega projekta do organizacijskega in panožnega znanja

Dobro digitaliziran projekt ustvari veliko več kot objekt.

Ustvari tudi podatke o:

• cenah;
• normativih;
• produktivnosti;
• spremembah;
• neskladjih;
• zahtevkih;
• dobaviteljih;
• tehnoloških rešitvah;
• dejanskih rokih;
• uspešnosti odločitev.

Če so podatki strukturirani in primerljivi, lahko organizacija iz njih ustvarja znanje za prihodnje projekte.

Če so tudi panožno standardizirani, lahko nastanejo:

• referenčne baze cen;
• primerjalne analize;
• boljši normativi;
• kakovostnejše projektantske rešitve;
• boljši razpisni modeli;
• objektivnejše ocene investicij;
• boljša podpora javnim politikam.

Če pa vsak projekt uporablja povsem drugo strukturo, se znanje izgubi v dokumentih in individualnih izkušnjah.

Digitalizacija panoge pomeni tudi sposobnost, da vsak zaključen projekt poveča skupno znanje, ne samo količine arhiviranih datotek.

14. Vloga umetne inteligence na treh ravneh

Umetna inteligenca na vsaki ravni uporablja drugačen kontekst.

Na ravni objekta

Pomaga lahko pri:

• prepoznavanju elementov;
• kontroli modela;
• zaznavanju kolizij;
• primerjavi modela in dejanskega stanja;
• analizi senzorskih podatkov.

Na ravni projekta

Pomaga lahko pri:

• kontroli popisa;
• analizi kalkulacij;
• spremljanju terminskega plana;
• prepoznavanju sprememb;
• analizi zahtevkov;
• povezovanju odločitev;
• napovedovanju stroškov in rokov.

Na ravni panoge

Pomaga lahko pri:

• semantičnem povezovanju podatkov;
• klasifikaciji;
• primerjavi projektov;
• analizi cen in produktivnosti;
• prepoznavanju panožnih vzorcev;
• prenosu znanja med projekti.

Umetna inteligenca na nobeni ravni ne more zanesljivo nadomestiti manjkajoče podatkovne infrastrukture.

AI lahko premosti nekatere semantične razlike. Ne more pa dolgoročno nadomestiti skupnega jezika, kakovostnih identifikatorjev in jasnega lastništva podatkov.

15. Zakaj je razmejitev pomembna za razvojno politiko

Če digitalizacijo gradbeništva enačimo samo z BIM-om, bodo ukrepi usmerjeni predvsem v:

• modele;
• programsko opremo za projektiranje;
• koordinacijo;
• modelne zahteve;
• BIM-kompetence.

Vse to je potrebno. Toda brez razvoja projektne in panožne ravni ostanejo spregledani:

• stroškovno inženirstvo (Cost Engineering);
• projektno spremljanje in obvladovanje (Project Controls);
• digitalni popisi;
• digitalne situacije;
• standardizacija sprememb;
• terminsko spremljanje;
• podatkovni modeli;
• klasifikacije;
• normativi;
• ceniki;
• interoperabilnost;
• procesi celotne izvedbene verige.

Osrednji namen Jesenske šole je zato širši od razprave o posamezni tehnologiji. Gre za to, da ob digitalnem modelu objekta postavimo tudi stroškovno inženirstvo, projektno spremljanje in obvladovanje ter digitalni dvojček projekta, hkrati pa pripravimo izhodišča za skupno podatkovno infrastrukturo panoge.

16. Kako ugotovimo, katera raven manjka?

Digitalizacija objekta

• Ali imamo zanesljiv digitalni opis projektirane oziroma izvedene rešitve?
• Ali so elementi, lastnosti in prostorski odnosi urejeni?
• Ali model podpira konkretne procese?

Digitalizacija projekta

• Ali poznamo aktualni obseg, rok in stroške?
• Ali so spremembe, neskladja in zahtevki povezani?
• Ali vemo, kdo mora sprejeti katero odločitev?
• Ali lahko vsako pomembno številko povežemo z izvorom in statusom?

Digitalizacija panoge

• Ali lahko podatke iz razpisa neposredno uporabi ponudnik?
• Ali se potrjeni podatki prenesejo v pogodbo, situacijo in račun?
• Ali dobaviteljski podatki ohranijo identiteto?
• Ali so podatki primerljivi med projekti?
• Ali mora vsak nov projekt ponovno ustvariti lastne klasifikacije in preslikave?

Projekt je digitalno zrel šele, ko zna odgovoriti na vprašanja vseh treh ravni v obsegu, ki ga zahteva njegova kompleksnost.

MYTHBUSTERS

Ključne ugotovitve

1. Objekt, projekt in panoga so tri povezane, vendar različne ravni digitalizacije.
2. BIM-model opisuje objekt; digitalni dvojček objekta pa zahteva tudi povezavo z dejanskim stanjem in operativnimi procesi.
3. Digitalni dvojček projekta povezuje pogodbeni obseg, čas, stroške, izvedbo, spremembe, zahtevke in odločitve.
4. Digitalizacija panoge omogoča izmenjavo podatkov med organizacijami brez izgube identitete, pomena in statusa.
5. Panoga potrebuje skupne podatkovne standarde in transakcije, ne ene platforme ali poenotenih notranjih procesov podjetij.

Zaključna misel

Digitalni model objekta nam pomaga opisati, kaj gradimo. Digitalizacija projekta pokaže, kako objekt nastaja, koliko stane in zakaj se spreminja. Standardizacija in interoperabilnost pa omogočata, da podatki brez izgube pomena potujejo med vsemi, ki pri tem sodelujejo.

BIM digitalizira oziroma modelira objekt. Digitalni dvojček projekta povezuje proces njegovega nastajanja. Standardizacija in interoperabilnost digitalizirata sodelovanje panoge.