In English

Tulevikumõte • 5. november 2026

102 korrust 13 kuuga. Miks me 95 aastat hiljem kiiremini ei ehita?

Äkki oleme 20 aastat digitaliseerinud ehituses valet asja?

Empire State Building kerkis 1930. aastatel kiirusega, mida on raske uskuda ka tänapäeval. Selle taga polnud ainult teistsugused standardid või lihtsam hoone. Projekteerimine, tootmine, logistika ja ehitus töötasid ühe süsteemina. Täna on meil BIM, digitaalsed tööriistad ja AI, kuid projekti eri osade vahelisi seoseid koordineerivad endiselt suuresti inimesed.

Empire State Buildingu ehitust alustati 1930. aasta märtsis. Veidi rohkem kui aasta hiljem, 1. mail 1931, avati 102-korruseline hoone. Tipphetkedel kerkis teraskonstruktsioon umbes 4,5 korrust nädalas.

95 aastat hiljem on meil BIM, pilvepõhine projektijuhtimine, parametriseeritud projekteerimine, laserskaneerimine, digitaalsed kaksikud ja nüüd AI. Ometi kasvas globaalne ehituse tootlikkus McKinsey hinnangul aastatel 2000–2022 ainult umbes 10%, samal ajal kui töötlevas tööstuses oli kasv ligikaudu 90%.

Nende kahe numbri kõrvutamisel peab muidugi olema ettevaatlik. 1930. aasta pilvelõhkujat ja tänapäeva kõrghoonet ei saa üks ühele võrrelda. Tänased hooned peavad vastama oluliselt rangematele tuleohutus-, energiatõhusus-, ligipääsetavus- ja tööohutusnõuetele ning neis on kordades rohkem tehnosüsteeme.

Ka Empire State Buildingu tööohutus oli tänapäeva mõistes vastuvõetamatu. Ehituse käigus hukkus ametlikel andmetel viis töötajat, kuigi ajaloolistes allikates leidub ka suuremaid hinnanguid. Fotodel on näha mõningaid tolle aja turvameetmeid, sealhulgas kaitsevõrke, kuid inimesed töötasid suurtes kõrgustes tingimustes, mida tänapäeva objektil ei lubataks.

Seega ei ole mõtet küsida, miks me enam täpselt nii ei ehita. Palju olulisem on küsimus, kuidas nad üldse sellise kiiruse saavutasid.

Sest vastus ei ole lihtsalt odav tööjõud, vähem regulatsioone või hullumeelselt kiiresti töötavad ehitajad. Empire State Building oli erakordselt hästi organiseeritud tootmissüsteem.

Ehitusega alustati enne, kui projekteerimine oli lõppenud

Sellise tempo puhul võiks eeldada, et kogu projekt pidi enne ehituse algust valmis olema.

Ei olnud.

Arhitekt William Lamb ja Shreve, Lamb & Harmon alustasid projekteerimist 1929. aasta sügisel. Teraskonstruktsiooni joonised valmisid 1930. aasta jaanuari keskpaigas ning ehitusplatsil algasid tööd märtsis. Projekteerimine jätkus samal ajal, kui hoone juba kerkis.

Säilinud joonistelt on näha ka revisjone. Ühele 6.–20. korrust puudutavale joonisele tehti 1930. aasta märtsist augustini 13 muudatust.

Ka hoone ise arenes projekteerimise käigus. Selle kõrgus muutus ning kuulus õhulaevade sildumismast lisandus projekti hiljem. Viimane osutus lõpuks üsna heaks näiteks sellest, et kõik nende otsused polnud sugugi geniaalsed. Mast oli tehniliselt problemaatiline ja praktikas õhulaevade vastuvõtmiseks sisuliselt kasutuskõlbmatu.

Empire State Building polnud seega projekt, kus kõik oli enne ehituse algust otsustatud ja pärast seda lihtsalt täide viidud. Tänapäeva mõistes oli see fast-track-projekt.

Oluline erinevus oli selles, kuidas projekteerimine ehitamisega seoti.

Joonise tähtaeg tuli ehitusplatsilt

Konstruktsiooni planeerimisel seoti omavahel hetk, millal arhitektilt või insenerilt oli informatsiooni vaja, millal pidid valmima tööjoonised, millal detail pidi minema tootmisse, millal see pidi objektile jõudma ja millal see püstitati.

Loogika töötas füüsilisest ehitusest tagurpidi.

Kui terasdetail pidi konkreetsel kuupäeval Manhattanil paika minema, pidi see enne seda objektile jõudma. Enne transporti pidi detail olema tehases valmis. Enne tootmist pidid olemas olema tööjoonised. Ja enne tööjooniseid tuli teha vajalik projekteerimisotsus.

Paigaldamise hetk määras seega ära, millal informatsiooni vaja oli.

See võib tunduda elementaarne, aga tegelikult muudab see kogu projekti juhtimise loogikat. Projekteerimise väljund ei ole sellises süsteemis lihtsalt valmis joonis. Projekteerimise väljund on õigel ajal tehtud otsus, mis võimaldab järgmisel tegevusel alata.

Vale informatsioon on probleem. Aga tootmise jaoks on probleem ka täiesti õige informatsioon, mis saabub nädal aega liiga hilja.

Ka hoone ise oli projekteeritud korduma

Kiirust ei saavutatud ainult hea projektijuhtimisega. Osa keerukusest eemaldati juba hoone disainist.

Empire State Building oli suur, aga tema bürookorruste põhiloogika kordus. Keskse trepi-, lifti- ja tehnosüsteemide ala ümber paiknes suhteliselt standardne büroopind. Hoone muutus kõrguse kasvades väiksemaks, kuid suur osa konstruktsioonist, fassaadist ja ehitusprotsessist kordus korruselt korrusele.

See võimaldas ehitusel saavutada rütmi.

Kui brigaad oli sama töö kümneid kordi läbi teinud, ei olnud järgmine korrus enam uus projekt. See oli järgmine kordus tuttavas protsessis.

Ka suur osa detaile valmistati ette väljaspool objekti. Eesmärk oli tuua objektile võimalikult valmis komponent, mitte hakata seda seal alles kohandama.

Siin on tänapäevaga võrreldes oluline erinevus. Me oleme harjunud mõtlema, et tehnoloogia peaks aitama meil keerukust paremini hallata. Empire State Building saavutas osa oma tootlikkusest hoopis sellega, et keerukust teadlikult vähendati.

Standardiseerimine polnud ehituse kõrvalprodukt. See oli osa tootmissüsteemist.

Terast ei toodetud lattu

Empire State Buildingu teraskonstruktsioon koosnes kümnetest tuhandetest detailidest. Need valmistati tehastes ette, märgistati ning saadeti objektile järjestuses, mis vastas nende paigaldamise vajadusele.

Keset Manhattanit polnud võimalik ladustada nädalaid ette saabuvat terast. Liiga palju materjali objektil oleks tootmist kiirendamise asemel aeglustanud.

Seetõttu polnud eesmärk saada materjal võimalikult vara kohale. Eesmärk oli saada õige detail õigel ajal õigesse kohta.

See nõudis, et projekteerimine, tootmine, transport ja paigaldus töötaksid sama rütmi järgi.

Ka teiste materjalide puhul vaadati tarneahelat palju kaugemale kui ehitusplatsi värav. Arvestati tarnijate tootmisvõimsuse ja transpordiga. Kivi puhul tähendas see näiteks karjääri tootmisvõimsust, maismaatransporti, sadamat, laevaliiklust, töötlemist ja lõpuks Manhattanile jõudmist.

Tänapäeval kasutaksime selle kohta tõenäoliselt mõisteid tarneahela juhtimine, täppisajastatud tarned ja lean construction.

Nemad tegid seda paberil.

Ehitusplats ise oli väike tehas

Ka objekti sisemine logistika projekteeriti tootmise osana.

Materjale ei saanud 102-korruselises hoones lihtsalt maha laadida ja loota, et keegi leiab neile hiljem õige koha. Hoonesse rajati ajutisi tõste- ja transpordisüsteeme. Säilinud fotodel on näha isegi 72. korrusele rajatud väikest tööstusraudteed materjalide horisontaalseks liigutamiseks.

Terase püstitamise järel liikusid järgmised brigaadid samas suunas. Ühel kõrgusel tehti konstruktsiooni, allpool järgnesid teised tööd. Hoone hakkas toimima vertikaalse tootmisliinina.

Sellise süsteemi kiirus ei sõltu ainult sellest, kui kiiresti üks töötaja oma ülesande teeb.

Kui neljatunnise töö alustamiseks tuleb viis päeva oodata otsust, ei muuda projekti oluliselt kiiremaks see, kui tehnoloogia vähendab töö enda kolmele tunnile. Projekt võidab ühe tunni. Viis päeva jäävad alles.

Empire State Buildingu süsteem oli üles ehitatud nii, et järgmine tegevus saaks alata võimalikult kiiresti. Informatsioon, materjal ja inimesed pidid jõudma õigesse kohta selleks hetkeks, kui neid vaja oli.

Kõik ei läinud sugugi plaani järgi

Oleks eksitav kirjeldada Empire State Buildingut projektina, kus erakordse planeerimise tõttu probleeme ei tekkinud.

Juba vana Waldorf-Astoria hotelli lammutamine osutus keerulisemaks kui eeldati. Hoone oli tugevamalt ehitatud, kui arvati, ning lammutamine võttis rohkem aega ja raha.

Vundamenditöödel tuli tegeleda maa-aluse veega ning esialgne lahendus ei töötanud soovitud viisil.

Projekt ise muutus. Õhulaevade sildumismast oli halb otsus. Jooniseid revideeriti.

Ja ometi ei lagunenud kogu tootmissüsteem iga probleemi tekkides koost.

See eristus on oluline. Väga kiire projekt ei pea olema projekt, kus midagi ei muutu. Ta peab olema projekt, kus muudatuse ja järgmise vajaliku tegevuse vahele ei teki ebaproportsionaalselt pikka viivitust.

Mida me sellest tänapäeva ehitusse üle võtta ei saa

Empire State Building ei tõesta, et 1930. aastal osati paremini ehitada.

Tänapäeva hoone on teine toode.

Kõrghoones on nüüd keerukad ventilatsiooni- ja jahutussüsteemid, sprinklersüsteemid, suitsueemaldus, hooneautomaatika, läbipääsusüsteemid, IT, energiatõhususe ja akustika nõuded, ligipääsetavus, sertifitseerimine ja terve rida süsteeme, mida 1931. aasta hoones sellisel kujul ei olnud.

Ka tööohutuse ja töötajate õiguste arvelt ei saa ega tohigi tootlikkust tagasi võita.

Lisaks on tänapäeva projekt organisatsiooniliselt palju killustatum. Ühe hoone taga võib olla kümneid ettevõtteid, kellel kõigil on oma leping, vastutus, kindlustus, protsess ja tarkvara.

Sellel killustatusel on põhjus. Spetsialiseerumine võimaldab meil lahendada palju keerulisemaid probleeme.

Aga selle hind on koordineerimine.

Empire State Building vähendas seda hinda vähemalt kolmel viisil: hoone oli tugevalt standardiseeritud, projekti juhtimine oli väga tsentraliseeritud ning projekteerimine, tootmine, logistika ja ehitus olid seotud üheks ajaliselt juhitud süsteemiks.

Me ei saa ega taha neist esimest kahte tänapäeval täielikult taastada.

Kolmanda puhul on olukord teine.

Oleme digitaliseerinud kõik süsteemi osad

Arhitekt töötab BIM-is. Projektidokumentatsioon on pilves. Ajagraafik on digitaalne. Ülesanded ja probleemid on digitaalsed. Eelarve on digitaalne. Hanked on digitaalsed. Tootjatel on oma süsteemid.

Ühe füüsilise elemendi kohta võib seetõttu eksisteerida informatsioon korraga kuues kohas.

Võtame ukse.

BIM-mudelis on ta objekt.
Joonisel graafiline element.
Spetsifikatsioonis rida.
Hankes toode.
Ajagraafikus osa paigaldustegevusest.
Koosolekuprotokollis võib sama uksega olla seotud lahendamata küsimus.

Inimene saab aru, et kõik need asjad räägivad samast uksest.

Arvuti jaoks võivad need olla kuus täiesti erinevat asja.

Kui ukse tulepüsivus muutub, tekib uus revisjon. Võib tekkida uus ülesanne. Võib olla vaja muuta tellimust. Võib muutuda tarneaeg ja selle kaudu paigalduskuupäev.

Füüsilises hoones juhtus üks asi.

Digitaalses projektis juhtus viis asja viies süsteemis.

Nende vahelise seose peab leidma inimene.

Võib-olla oleme digitaliseerinud valet kihti

Viimased paarkümmend aastat oleme teinud tohutu hüppe selles, kuidas ehitusinformatsiooni luua, säilitada ja jagada.

Aga suuresti oleme digitaliseerinud olemasoleva töökorralduse.

Paberjoonisest sai digitaalne joonis. Kaustast sai pilvekaust. Paberprotokollist digitaalne protokoll. Seinal olevast graafikust digitaalne Gantt. Probleemide nimekirjast digitaalne ülesannete nimekiri.

Need on kõik paremad tööriistad.

Aga Empire State Buildingu näide tõstatab teise küsimuse: kas meil on tekkinud digitaalne süsteem, mis mõistab nende asjade omavahelisi sõltuvusi?

Kui projekteerimisotsus muutub, peaks süsteem teadma, millist füüsilist elementi see puudutab. Millised teised lahendused sellest sõltuvad. Kas midagi on juba tellitud. Millal seda objektil vaja on. Milline tegevus ootab selle taga. Ja kellelt on vaja järgmist otsust.

1930. aastal hoidsid sellist süsteemi koos inimesed, graafikud, telefonid, paber ja väga tugev keskne juhtimine.

2026. aastal hoiavad seda üllatavalt suures osas endiselt koos inimesed.

AI mõte ei ole teha sama protsessi lihtsalt natuke kiiremini

Franklinit alustades vaatasime palju praktilisemat probleemi. Projektides on tuhandeid jooniseid, dokumente, versioone ja otsuseid ning projektijuhtidel kulub liiga palju aega sellele, et leida õige informatsioon ja aru saada, mis muutus.

Sealt on üsna loomulik jõuda AI-ni, mis oskab projekti dokumente lugeda, võrrelda ja neist infot leida.

Aga see lahendab ainult osa probleemist.

Kui AI teeb joonise koostamise kaks korda kiiremaks, aga joonisel oleva muudatuse mõju peab endiselt inimene viiest süsteemist kokku otsima, oleme automatiseerinud ühe tegevuse. Me ei ole muutnud tootmissüsteemi.

Järgmine samm on, et süsteem teab, et BIM-is olev uks, joonisel olev uks, hankes olev uks ja ajagraafikus olev tegevus on seotud sama füüsilise objektiga.

Siis ei pea inimene küsima, mis muutus. Süsteem saab muutuse ise tuvastada, kontrollida selle mõju ja tuua välja, mida tuleb järgmisena teha.

Sealt edasi saab osa tegevustest juba automaatselt käivitada: suunata küsimuse õigele inimesele, kontrollida seotud lahendusi, uuendada ülesandeid ja jälgida, et otsus jõuaks õigeks ajaks sinna, kus seda füüsilises ehituses vaja on.

See on juba midagi muud kui AI-assistent dokumentide kohal. See on osa projekti koordineerimisest.

Empire State Building saavutas erakordse kiiruse osaliselt sellega, et muutis keerulise projekti võimalikult korratavaks ja juhtis ülejäänud keerukust väga tugevalt integreeritud organisatsiooniga. Seda mudelit ei saa tänapäeva ehitusse lihtsalt tagasi tuua ja mitmel põhjusel ei peakski.

Tehnoloogia annab aga võimaluse proovida midagi muud: säilitada tänapäeva hoone keerukus, ohutus ja spetsialiseerumine, kuid vähendada nende koordineerimise hinda.

Meil on juba digitaalsed joonised, mudelid, ajagraafikud ja ülesanded. Järgmine samm on süsteem, mis saab aru, kuidas need omavahel seotud on ja suudab järjest suurema osa nende koordineerimisest ise ära teha.

Seda me Frankliniga ehitada proovime.