12 ZAKAJ VEČINA PROJEKTOV DIGITALNEGA DVOJČKA PROJEKTA SPLOH NIMA

Ker smo digitalizirali dokumente in posamezne naloge, ne pa informacijskega modela projekta.

Osrednja teza

Digitalni dvojček projekta ne nastane samodejno zato, ker projekt uporablja:

  • elektronsko pošto,
  • dokumentni sistem,
  • BIM,
  • terminski plan,
  • preglednice,
  • aplikacijo za gradbišče,
  • nadzorne plošče,
  • umetno inteligenco.

Nastane šele, ko so ključni projektni procesi, podatki in odločitve organizirani v povezano celoto.

Večina projektov tega nima, ker:

  1. digitalnega dvojčka projekta nihče izrecno ne naroči;
  2. odgovornost za njegovo vzpostavitev ni določena;
  3. vsak udeleženec digitalizira predvsem svoj del procesa;
  4. projekt še vedno temelji na dokumentih in ne na povezanih podatkih;
  5. informacijski sistemi sledijo organizacijam, ne pa celotnemu projektu;
  6. projektni procesi pred digitalizacijo niso dovolj jasno opredeljeni.

Posledica ni popolnoma analogni projekt. Posledica je nekaj bolj značilnega:

Digitalno okolje z analogno logiko vodenja.

1. Projekt je poln digitalnih vsebin, vendar nima digitalne celote

Skoraj noben večji projekt danes ni popolnoma analogen. Dokumenti so v elektronski obliki, popisi nastajajo v preglednicah, terminski plani v specializiranih programih, sestanki potekajo prek spletnih platform, gradbišče se fotografira, BIM-modeli se pregledujejo v oblaku.

Na prvi pogled se zato zdi, da je projekt že digitaliziran.

Toda ko želimo dobiti celovit odgovor na vprašanje:

Kakšno je dejansko stanje projekta?

se začne ročno zbiranje podatkov:

  • iz dokumentnega sistema poiščemo pogodbo;
  • iz elektronske pošte pridobimo zadnjo odločitev;
  • iz zapisnika razberemo, kaj je bilo dogovorjeno;
  • iz preglednice pridobimo seznam sprememb;
  • iz druge preglednice finančne posledice;
  • iz terminskega programa preverimo vpliv na rok;
  • iz situacije ugotovimo, kaj je bilo obračunano;
  • iz BIM-okolja preverimo tehnično rešitev;
  • nato pa nekdo vse skupaj razloži na sestanku.

Projekt torej uporablja digitalna orodja, vendar povezovalni sloj ostaja človeški.

Največ informacij pogosto ne obstaja v sistemu, ampak:

  • v glavi vodje projekta,
  • v spominu nadzornika,
  • v osebnem arhivu projektanta,
  • v zasebni preglednici kalkulanta,
  • v elektronski pošti posameznega udeleženca.

To ni digitalni dvojček projekta. To je digitalni arhipelag: veliko koristnih otokov brez zanesljivih povezav.

2. Nihče ni naročil digitalnega dvojčka projekta

Pri pripravi projekta naročnik praviloma določi:

  • katera projektna dokumentacija mora biti izdelana;
  • kateri načrti in elaborati so potrebni;
  • ali je zahtevan BIM-model;
  • katere naloge opravlja nadzor;
  • kakšna poročila mora pripravljati izvajalec;
  • katere terminske plane mora predložiti;
  • kako se pripravljajo situacije.

Redkeje pa določi:

  • kateri podatki morajo biti povezani;
  • kateri podatek predstavlja veljavno stanje;
  • kdo vodi skupni register sprememb;
  • kako se sprememba poveže s stroški in rokom;
  • kako se evidentirajo razlogi za odločitve;
  • kdo zagotavlja enotne oznake dokumentov, postavk, aktivnosti in zahtevkov;
  • kako se napoveduje končna vrednost projekta;
  • kako bo po zaključku ohranjen projektni spomin.

Zato vsak pogodbeni udeleženec praviloma izpolni svojo obveznost:

  • projektant preda projektno dokumentacijo;
  • izvajalec preda plan;
  • BIM-izvajalec preda model;
  • nadzor pripravi poročilo;
  • kalkulant vodi stroške;
  • pravnik obravnava zahtevke;
  • dokumentarist shrani dokumente.

Vsi so opravili svoje naloge, vendar nihče ni odgovoren, da bi iz teh rezultatov nastala skupna slika projekta.

Kar ni jasno opredeljeno kot projektni rezultat, praviloma tudi ne nastane.

3. Digitaliziramo naloge posameznikov, ne projekta kot celote

Projekt je začasen, organiziran proces, v katerem sodeluje več samostojnih podjetij in strok.

Vsak udeleženec ima:

  • svoje pogodbene obveznosti,
  • svoje poslovne interese,
  • svoje informacijske sisteme,
  • svoje interne evidence,
  • svoje varnostne zahteve,
  • svoj pogled na projekt.

Projektant upravlja projektno dokumentacijo. Izvajalec kalkulacije, nabavo in organizacijo izvedbe. Nadzor količine, kakovost in potrjevanje. Naročnik pogodbe, proračun in odločitve. BIM-koordinator modele in koordinacijske postopke.

Te rešitve so lahko vsaka zase zelo kakovostne. Težava nastane na njihovih mejah.

Na primer:

  • oznaka postavke v popisu ni povezana z oznako aktivnosti v planu;
  • sprememba v dokumentnem sistemu nima enake oznake kot finančna sprememba;
  • situacija vsebuje drugačno strukturo kot pogodbena kalkulacija;
  • zahtevek ni neposredno povezan z dogodkom, planom in odločitvijo;
  • model vsebuje element, ki nima jasne povezave s pogodbenim obsegom;
  • poročilo prikazuje številko, katere izvora ni mogoče neposredno preveriti.

Vsak sistem vidi svoj del. Nihče ne vidi celote.

4. Dokumenti so postali digitalni, procesi pa so ostali analogni

Najosnovnejša digitalizacija dokumenta pomeni, da papir zamenjamo s PDF-datoteko.

Digitalizacija procesa pa pomeni, da sistem pozna:

  • kdo je sprožil postopek;
  • na kaj se postopek nanaša;
  • kdo mora ukrepati;
  • do kdaj mora odločiti;
  • katere možnosti so bile obravnavane;
  • kakšna odločitev je bila sprejeta;
  • kaj se zaradi nje spremeni;
  • kakšne so finančne in terminske posledice;
  • kateri dokumenti odločitev dokazujejo.

V praksi pogosto digitaliziramo samo vhod in izhod procesa.

Primer:

  1. izvajalec pošlje dopis;
  2. dopis se shrani v dokumentni sistem;
  3. o njem se razpravlja na sestanku;
  4. sklep se zapiše v zapisnik;
  5. projektant pripravi novo rešitev;
  6. kalkulant v preglednici oceni vrednost;
  7. planer v drugi datoteki spremeni plan;
  8. čez nekaj mesecev se pripravi aneks.

Vsak korak je lahko digitalno dokumentiran. Sam proces spremembe pa ni enotno voden.

To pomeni, da imamo veliko digitalnih dokazov, nimamo pa zanesljivega digitalnega zapisa povezav med njimi.

Digitaliziran dokument še ne pomeni digitaliziranega procesa.

5. Excel ni glavni problem

Preprost napad na Excel bi bil napačen.

Excel je izjemno uporabno orodje:

  • hitro ga lahko prilagodimo;
  • poznajo ga skoraj vsi;
  • omogoča analize in izračune;
  • primeren je za prototipe in posebne preglede;
  • pogosto zapolni vrzel, ki je drugi sistemi ne pokrivajo.

Problem nastane, ko preglednica postane trajna sistemska infrastruktura projekta.

Takrat se pojavijo:

  • več vzporednih verzij;
  • ročno kopiranje podatkov;
  • nejasen izvor vrednosti;
  • različne formule;
  • izgubljene povezave;
  • omejene pravice in revizijska sled;
  • podatki, ki jih razume samo avtor;
  • nezmožnost avtomatske uporabe podatkov drugje;
  • velika odvisnost od posameznika.

Zato bistvo ni:

Excel je slab.

Bistvo je:

Preglednica je dobra za analizo. Ni pa dobra zamenjava za skupni podatkovni model projekta.

Enako velja za elektronsko pošto. Je odlično komunikacijsko orodje, vendar zelo slabo okolje za upravljanje stanja sprememb, odgovornosti in projektnih odločitev.

6. Na projektu obstaja več vzporednih resnic

Na neurejenem projektu lahko istočasno obstaja:

  • pogodbena vrednost;
  • vrednost potrjenih situacij;
  • vrednost evidentiranih sprememb;
  • vrednost še nepotrjenih zahtevkov;
  • interna napoved izvajalca;
  • ocena Inženirja;
  • proračunska evidenca naročnika;
  • predlog vrednosti prihodnjega aneksa.

Vse te številke so lahko legitimne. Problem ni, da se razlikujejo.

Problem je, če ni jasno:

  • kaj posamezna vrednost pomeni;
  • na kateri datum se nanaša;
  • katere elemente vključuje;
  • kdo jo je potrdil;
  • iz katerih podatkov je izračunana;
  • kakšen status ima;
  • kako je povezana z rokom in obsegom.

Digitalni dvojček projekta ne ustvarja ene umetno poenostavljene številke.

Omogoča pa, da je vsaka številka:

  • pravilno poimenovana;
  • časovno umeščena;
  • vsebinsko razložena;
  • povezana z izvorom;
  • primerljiva z drugimi stanji.

Enotna resnica projekta ne pomeni ene same številke. Pomeni enotno razumevanje pomena posameznih številk.

7. Manjkajo skupni identifikatorji

Digitalnega dvojčka projekta ni mogoče zgraditi samo z zbiranjem datotek. Potrebne so povezave.

Za to pa morajo imeti ključni elementi enotne oznake oziroma identifikatorje:

  • projekt;
  • pogodba;
  • WBS;
  • postavka popisa;
  • terminska aktivnost;
  • sprememba;
  • zahtevek;
  • neskladje;
  • negotovost;
  • odločitev;
  • dokument;
  • situacija;
  • element objekta.

Brez njih sistem ne more zanesljivo vedeti, da:

  • zapisnik govori o določeni spremembi;
  • sprememba vpliva na tri postavke popisa;
  • te postavke pripadajo dvema aktivnostma;
  • aktivnosti vplivajo na mejnik;
  • sprememba je vključena v zahtevek;
  • zahtevek je del napovedi končne vrednosti.

Človek lahko te povezave rekonstruira iz vsebine dokumentov. Sistem jih brez kakovostne semantike in identifikacije težko uporablja.

To je eden od razlogov, da lahko projekt vsebuje na tisoče datotek, vendar še vedno nima strojno razumljive slike projekta.

8. Nejasni procesi se ne digitalizirajo – samo hitreje razmnožujejo

Pred uvedbo informacijskega sistema bi morali vedeti:

  • kako nastane sprememba;
  • kdo jo lahko predlaga;
  • kdo oceni tehnični vpliv;
  • kdo oceni strošek;
  • kdo oceni vpliv na rok;
  • kdo sprejme odločitev;
  • kateri statusi obstajajo;
  • kdaj sprememba postane pogodbena;
  • kako se prenese v popis, plan in situacijo.

Če tega ne določimo, programska oprema ne more ustvariti urejenega procesa.

Največkrat se zgodi eno od dveh:

  1. nejasen postopek se samo preseli v digitalno okolje;
  2. sistem vsakemu udeležencu omogoči, da postopek vodi po svoje.

Rezultat je več elektronskih evidenc, ne pa večja urejenost.

Tehnologija ne more povezati procesa, ki ga organizacija ni opredelila.

Ta ugotovitev je pomembna tudi za AI. AI lahko išče, primerja in opozarja, vendar ne more sam določiti, kateri od petih nasprotujočih si podatkov predstavlja pogodbeno veljavno stanje.

9. Digitalizacija se začne prepozno

Digitalni dvojček projekta bi moral nastajati že med:

  • pripravo investicije;
  • projektiranjem;
  • izdelavo popisa;
  • oblikovanjem pogodbenega obsega;
  • pripravo razpisa;
  • izdelavo izhodiščnega terminskega plana.

V praksi se resnejša informacijska ureditev pogosto začne šele:

  • po podpisu pogodbe;
  • ob začetku gradnje;
  • ko nastanejo prve večje spremembe;
  • ob prvem resnem zahtevku;
  • ko naročnik ugotovi, da nima zanesljive napovedi vrednosti;
  • ob zamudi;
  • pred revizijo ali sporom.

Takrat je treba za nazaj povezovati podatke, ki so nastajali brez skupne strukture.

To je drago, počasno in nikoli popolnoma zanesljivo.

Najboljši trenutek za vzpostavitev projektnega informacijskega modela je pred začetkom projekta. Drugi najboljši trenutek je čim prej – ne šele takrat, ko projekt že potrebuje dokazovanje preteklosti.

10. Projektni podatki nimajo jasnega lastnika

Za vsak ključni podatek bi morali biti znani:

  • lastnik podatka;
  • odgovorna oseba za vsebino;
  • vir podatka;
  • pravila potrjevanja;
  • čas veljavnosti;
  • dostopne pravice;
  • način spremembe;
  • mesto uporabe.

V praksi pa so odgovornosti pogosto razpršene.

11. Sistem je pogosto vezan na podjetje, projekt pa na začasno skupnost

Dokumentni sistem naročnika je lahko odličen za naročnika. ERP izvajalca je lahko odličen za izvajalca. Projektantsko okolje je lahko odlično za projektanta.

Toda projekt živi med njimi.

To povzroča temeljno dilemo:

  • projekt potrebuje skupne informacije;
  • udeleženci pa delujejo v ločenih organizacijah in pogodbenih razmerjih.

Zato digitalnega dvojčka projekta ni mogoče razumeti kot popolno združitev vseh internih podatkov.

Potrebna je premišljena ločitev:

Skupni projektni podatki

  • pogodbeni obseg;
  • potrjene količine;
  • spremembe;
  • terminski mejniki;
  • odločitve;
  • situacije;
  • neskladja;
  • skupne negotovosti;
  • zahtevki in njihovi statusi.

Interni podatki posameznih udeležencev

  • izvajalske kalkulacije;
  • interne nabavne cene;
  • marže;
  • produktivnosti;
  • kadrovski podatki;
  • interne presoje in scenariji.

Digitalni dvojček projekta ne zahteva, da vsi vedo vse. Zahteva pa, da so skupne informacije opredeljene, povezane in dostopne upravičenim udeležencem.

12. Uspeh se meri po uvedbi orodja, ne po kakovosti odločanja

Digitalizacijski projekt se pogosto razglasi za uspešnega, ko:

  • je platforma nameščena;
  • so uporabniki registrirani;
  • je BIM-model naložen;
  • so dokumenti preneseni;
  • je izdelana nadzorna plošča;
  • je izvedeno usposabljanje.

Toda pravo vprašanje bi moralo biti:

  • Ali hitreje sprejemamo odločitve?
  • Ali poznamo aktualno napoved končne vrednosti?
  • Ali lahko spremembo sledimo od vzroka do finančne in terminske posledice?
  • Ali se podatki vnašajo enkrat in uporabljajo večkrat?
  • Ali je mogoče preveriti izvor posameznega kazalnika?
  • Ali se je zmanjšala odvisnost od osebnih preglednic?
  • Ali projekt po zaključku ustvarja uporabno znanje?

Če na ta vprašanja ne moremo odgovoriti pritrdilno, smo verjetno digitalizirali orodje, ne pa projekta.

Število uporabnikov, datotek ali BIM-modelov ni merilo digitalizacije projekta. Merilo je kakovost projektnih informacij in odločanja.

13. Projekt se po zaključku ponovno razstavi

Tudi projekt, ki med izvedbo doseže določeno stopnjo informacijske urejenosti, po zaključku pogosto razpade na:

  • arhiv dokumentacije;
  • končni obračun;
  • projektno dokumentacijo izvedenih del (PID);
  • ločene arhive udeležencev;
  • podatkovne baze, do katerih projektna ekipa nima več dostopa;
  • osebne datoteke nekdanjih članov ekipe.

Objekt ostane.

Povezave med odločitvami, spremembami, stroški, roki in posledicami pa se izgubijo.

Zato organizacija naslednji projekt začne skoraj od začetka. Ponovno:

  • išče primerljive cene;
  • ocenjuje produktivnosti;
  • oblikuje postopke;
  • rešuje podobna neskladja;
  • ponavlja že znane napake;
  • ponovno odkriva uspešne rešitve.

To je sistemska izguba projektnega spomina.

Cilj ni le več sledljivosti na posameznem projektu, ampak tudi organizacijsko učenje in prenos znanja med projekti.

14. Kako prepoznamo, da projekt digitalnega dvojčka nima

Uporaben je kratek praktični test:

Projekt verjetno nima digitalnega dvojčka projekta, če:

  • za isti podatek obstaja več nepovezanih evidenc;
  • nihče ne more takoj pojasniti aktualne vrednosti projekta;
  • finančni in terminski vplivi sprememb se ocenjujejo ločeno;
  • register sprememb ni povezan s popisom, planom in odločitvami;
  • stanje zahtevkov se ugotavlja iz elektronske pošte;
  • zapisniki predstavljajo glavni sistem projektnega odločanja;
  • ključne preglednice razume samo njihov avtor;
  • podatki se ročno prepisujejo med sistemi;
  • iz nadzorne plošče ni mogoče priti do izvornega podatka;
  • po odhodu ključnega člana ekipe izgine pomemben del razumevanja projekta;
  • po zaključku ostanejo dokumenti, ne pa uporabna zbirka projektnega znanja.

To ne pomeni, da je projekt nujno slabo voden. Pomeni pa, da je njegova kakovost močno odvisna od posameznikov in njihove sposobnosti ročnega povezovanja informacij.

15. Digitalni dvojček ni stanje »imaš ali nimaš«

Stopnja 0 – Digitalni dokumenti

Dokumenti so v elektronski obliki, vendar večinoma nepovezani.

Stopnja 1 – Digitalni registri

Spremembe, zahtevki, negotovosti, neskladja in odločitve se vodijo strukturirano, vendar še vedno ločeno.

Stopnja 2 – Povezan projektni model

Popis, plan, situacije, spremembe, odločitve in dokumenti so med seboj povezani.

Stopnja 3 – Aktivno projektno spremljanje

Sistem izračunava odstopanja, opozarja na odprte procese ter pripravlja napovedi roka in vrednosti.

Stopnja 4 – Project Intelligence

Umetna inteligenca analizira dokumente, podatke in izkušnje preteklih projektov ter pomaga:

  • odkrivati neskladja;
  • pojasnjevati vzroke;
  • primerjati scenarije;
  • ocenjevati negotovosti;
  • pripravljati strokovne podlage za odločanje.

AI ne ustvari digitalnega dvojčka. Uporaben postane šele, ko ima na voljo dovolj kakovosten projektni kontekst.

Vsak projekt lahko začne z bistvenimi elementi:

  • enotnim popisom;
  • izhodiščnim planom;
  • digitalnimi situacijami;
  • registrom sprememb;
  • registrom odločitev;
  • povezavo med finančnimi in terminskimi posledicami;
  • jasno revizijsko sledjo.

16. Kaj mora naročnik narediti drugače

Naročnik mora pred začetkom projekta opredeliti:

Kaj želi vedeti

  • dejansko stanje obsega;
  • finančno stanje;
  • terminsko stanje;
  • odprte spremembe;
  • negotovosti;
  • potrebne odločitve;
  • napoved končne vrednosti in roka.

Katere procese mora projekt voditi

  • spremembe;
  • situacije;
  • zahtevke;
  • neskladja;
  • negotovosti;
  • potrjevanje;
  • odločanje;
  • poročanje.

Katere povezave so obvezne

  • popis ↔ pogodba;
  • popis ↔ situacija;
  • popis ↔ terminski plan;
  • sprememba ↔ odločitev;
  • sprememba ↔ strošek;
  • sprememba ↔ rok;
  • zahtevek ↔ dogodek;
  • neskladje ↔ ukrep;
  • poročilo ↔ izvorni podatki.

Kdo je odgovoren

  • za sistem;
  • za posamezne podatke;
  • za potrjevanje;
  • za kakovost;
  • za arhiviranje;
  • za prenos znanja po zaključku.

Šele nato se izbira programska arhitektura.

Najprej informacijski model projekta, nato programska orodja.

Primer iz prakse: ena sprememba, deset različnih sledi

Na projektu se spremeni tehnična rešitev fasade.

Sprememba se pojavi:

  1. kot vprašanje izvajalca;
  2. v elektronski pošti projektantu;
  3. kot točka zapisnika;
  4. v novi risbi;
  5. v BIM-modelu;
  6. v ponudbi izvajalca;
  7. v preglednici sprememb;
  8. v terminskem planu;
  9. v mesečnem poročilu;
  10. pozneje v aneksu in situaciji.

Vsi dokumenti obstajajo.

Kljub temu pogosto ni mogoče z enim pogledom ugotoviti:

  • kaj je bil prvotni razlog;
  • katere alternative so bile obravnavane;
  • kdo je rešitev potrdil;
  • kolikšna je bila prvotna in potrjena vrednost;
  • kako sprememba vpliva na kritično pot;
  • ali je že vključena v pogodbo;
  • ali je že obračunana;
  • katera dokumentacija je zdaj veljavna.

To je popoln primer razlike med:

digitalno dokumentirano spremembo

in

digitalno vodeno spremembo.

MYTHBUSTERS

MIT 1

Naš projekt je digitalen, saj vse dokumente vodimo elektronsko.

REALNOST

Elektronski dokumenti še ne pomenijo povezanih projektnih podatkov in procesov.

💡 KLJUČNA MISEL

Digitalni arhiv hrani dokumente. Digitalni dvojček povezuje njihov pomen in posledice.

MIT 2

Digitalni dvojček projekta nastane z uvedbo ustrezne programske opreme.

REALNOST

Najprej je treba določiti procese, podatke, odgovornosti in povezave. Orodja jih lahko šele nato podprejo.

💡 KLJUČNA MISEL

Neurejenega projekta ni mogoče urediti samo z novo aplikacijo.

MIT 3

Glavni problem projektov je uporaba Excela in elektronske pošte.

REALNOST

Glavni problem je, da preglednice in pošta nadomeščajo skupni podatkovni model ter organizirane procese odločanja.

💡 KLJUČNA MISEL

Problem ni orodje. Problem je, ko začasno orodje postane trajni sistem projekta.

MIT 4

Če vsak udeleženec kakovostno vodi svoj del, bo povezan tudi celoten projekt.

REALNOST

Kakovostni posamezni sistemi lahko še vedno ustvarjajo nepovezane informacijske silose.

💡 KLJUČNA MISEL

Vsota digitaliziranih delov še ni digitalni projekt.

Ključne ugotovitve članka

  1. Večina projektov nima digitalnega dvojčka, ker ta ni opredeljen kot naročeni rezultat projekta.
  2. Projekti pogosto digitalizirajo dokumente in posamezne naloge, ne pa povezav med obsegom, časom, stroški, izvedbo in odločitvami.
  3. Največja ovira niso Excel, elektronska pošta ali pomanjkanje aplikacij, ampak nejasni procesi, podatkovna odgovornost in informacijski silosi.
  4. Digitalni dvojček projekta ne zahteva ene aplikacije, zahteva pa enotne identifikatorje, dogovorjene procese in sledljive povezave.
  5. Vzpostaviti ga je treba že med pripravo in projektiranjem, ne šele ob prvih večjih spremembah ali sporih.
  6. Digitalizacija mora preživeti tudi zaključek projekta in ustvariti uporaben projektni spomin.

Zaključna misel

Večina projektov digitalnega dvojčka nima zato, ker je vsak udeleženec digitaliziral svoj del, nihče pa ni digitaliziral projekta kot celote.

Komentarji so onemogočeni.