Intro til prosjektdatabasen #3: Digitaliseringsplan for rådgivende ingeniørbedrifter

Dette er artikkel #3 i artikkelserien “Intro til prosjektdatabasen”. I artikkel #1 tok jeg for meg hvorfor databaser bør brukes i ingeniørprosjekter, og hvorfor bruken ikke har vært større før nå. I artikkel #2 diskuterte jeg mulige databaseløsnigner.

Gjeldende praksis i ingeniørprosjekter fortrenger digitalisering.

I rådgiverbransjen for ingeniørprosjekter ansetter vi mennesker som går gjennom Norges beste ingeniørutdannelser, med en femårig mastergrad. Så binder vi alles hender og føtter for bruk av digitale verktøy. Nå skal det leveres, og det skal leveres for hånd. Eller, nå som vi har blitt “digitale”, for hånd på PC, med PDF. BIM-modellen begynner å bli et unntak, men hva med analysen? Resultater fra analysen? Hvordan deler vi og jobber med styrkeanalyser? “Nei, det tenker vi ikke så mye på. Det går sikkert fint. La oss fortsette med PDF-er.”

Så hva er problemet med PDF-er? Det eneste som kan lese en PDF er et mennneske. Et menneske med øyne, hjerne og kontekst. Leverer vi en PDF, kan kun et annet menneske lese PDF-en for å forstå hva vi mener. Så må mennesket plukke ut informasjonen igjen fra dokumentet. Leveranse på PDF påtvinger (a) at informasjonen må leses av et mennekse, og (b) at mennesket må ha rett kontekst. Dette stopper effektivt de fleste initiativer på digitalisering. Dersom jeg prøver å automatisere min arbeidsoppgave, må jeg uansett legge til manuell jobb i interaksjonen med prosjektet for øvrig.

For å komme videre, må vi ha grensesnitt for maskiner. Så lenge vi ikke har grensesnitt for maskiner, tvinger vi mennesker til å gjøre jobben manuelt. Da kommer vi ingen vei.

Dette er min plan for å endre status quo.

Hvilke ferdigheter trenger vi for å digitalisere?

Industrien besitter kompetanse på programmering hos enkeltpersoner som er langt framme. Programmeringsvennlighet i eksisterende verktøy er på full fart frem, og det har aldri vært lettere å komme i gang med Python. Med tilgang på dagens datakraft og webteknologi, har mulighetene aldri vært større.

Jeg vurderer progresjon mot digitalisering på to akser: programmering og datamodellering. I programmering legger jeg enkeltpersoners evne til å lage programvare. Med modellering refererer jeg til kvaliteten på dataen som ligger lagret.

Evne til programmering ligger på en ferdighetsstige:

1. Kjennskap til fordeler og ulemper med programmering heller enn Excel-bruk
2. Evne til scripting for personlig bruk
3. Evne til programmering som andre kan ta til bruk i programmering og scripting
4. Evne til utvikling av systemer som andre kan ta i bruk uten programmeringskompetanse

Evne til datamodellering beskrives tilsvarende:

1. Kjennskap til fordeler og ulemper ved å modellere data i dataformater heller enn Excel-tabeller
2. Evne til å bruke semantiske filformater som JSON, XML eller HDF til å lette arbeid med lasting av data, lagring av data og inspeksjon av data
3. Evne til å jobbe mot én database heller enn flere filer, for å laste data og lagre data
4. Evne til design og videreutvikling av databaseskjema, samt operasjonell drift av et databasesystem.

Prosjektdatabase.no forutsetter team som har nådd nivå 2. på evne til programmering. Gjennom et utviklingsprosjekt når vi nivå 3. på evne til programmering, og nivå 3 på evne til datamodellering. Prosjektdatabase.no tilbys som en kontinuerlig tjeneste som tar hånd om nivå 4. på evne til datamodellering.

Men hvordan gjør vi det? Svaret er som alltid, vi bygger en sten av gangen.

Steg 1: aksjonsgruppen bygger programmeringskompetanse

Bedriften må ha tre personer som er på nivå 2 på evne til programmering, der de besitter evne til å skrive Python-script for egen bruk. Vi starter på enkel programmering fordi da kan vi få nytteverdi tidlig – før vi begynner å snakke om databaser, er vi i stand til å hente nytteverdi i små prosjekter.

Fornuftige oppgaver menneskene i aksjonsgruppen kan fokusere på inkluderer:

• Kunne behandle tabeller som kommer fra Excel med programmering. Når vi allerede har data i Excel, kan vi bruke den til noe nyttig. Når vi er ferdig, går vi bare tilbake.
• Produsere visualiseringer. Programmering er svært fleksibelt til produksjon av illustrasjoner. Et eksempel på god datavisualisering basert på programmering kan vi finne hos New York Times.

Steg 2: observer hvordan utveksler vi data i team

For mange av de største prosjektene som skal bygge norsk infrastruktur er utvekslingsformen som brukes filer på fellesmappe. Hvordan jobber vi da med data? Kanskje ber vi en kollega sjekke Excel-arket som vi har oppdatert med siste data. Og vi må passe på å lage nye versjoner, så vi vet hva vi har delt. Samme strategi kan vi bruke med filer. Lagre nye filer, og si ifra.

Filer på fellesmappe til utveksling av data er i praksis en liten database. Den er bare svært manuell. Vi kan kun finne data dersom vi kjenner rett filnavn. Og dersom vi vil ha tilgang på mer data, må vi finne alle filene. Vi huske på hvor vi finner all informasjonen.

Filer på fellesmappe som utvekslingsmodell har imidlertid utfordringer:

• Hvordan holder vi styr på nye versjoner, oppdateringer, og informasjon om hva som er gjeldende versjon?
• Hvordan holder vi orden på koblinger mellom forskjellig data?
• Kan forskjellige personer modellere data på samme vis, eller må alle oversette data til “sitt format”?

Disse utfordringene drev fram utvikling på databaser og databasesystemer. En database er en samling data som kan utvides når vi får inn ny data. Et databasesystem gjør databasen tilgjengelig, så vi alltid kan spørre den om informasjon.

Steg 3: aksjonsgruppen samhander gjennom database

Her kommer Prosjektdatabase.no inn. Det er ikke lett å vite hvordan man bør starte med databasebruk. Flere valg må tas, og utfordringer møtes:

• Hvilken database skal vi bruke?
• Hvordan kjører vi den? Har vi kontroll på backup? Hva om maksinen krasjer, med alt vi har av verdifull data?
• Hvordan modellerer vi versjonering i databasen?
• Hvordan oppdaterer vi data?
• Kan vi lagre resultater i databasen?

Hvordan bør du ta stilling til disse utfordringene? Med prosjektdatabase.no slipper du ta stilling til operasjonell drift, og

Steg 4: aksjonsgruppen tar i bruk eget verktøy i nytt prosjekt

Når aksjonsgruppen i steg 3 er i stand til å gjøre samhandling mellom personer med databasen, er grunnlaget for samhandling mellom prosjekter lagt.

Databasen trenger å være designet til å være fleksibel. Det vil da være mulig å plugge inn funksjonalitet i en database. I et prosjekt utvikles det en sofistikert måte for å tilgjengeligjøre resultater. Denne er det ønskelig å ta i bruk i neste prosjekt. Med databasen som en plattform å bygge videre på, trenger vi kun å koble oss på en ny database, og legge dataen rett sted.

Databasen gir en standardisert mekanisme for å hente ut data, og å legge inn data. Denne er det mulig å bruke fra forskjellige programmerinsspråk, eller manuelt via et spesiallaget verktøy som dbeaver – som lar oss se på innholdet ved å navigere visuelt, eller Prosjektdatabase.no, som lar oss navigere i og visualisere resultater.

Ved å standardisere data inn og/eller data ut, har vi et verktøy vi kan overføre til neste fase. Og når vi har én komponent som snakker med databasen, er det strømlinjeformet å lage et nytt verktøy som videre behander data vi allerede har tilgang til.

Oppsummert: gjennom å standardisere data inn og/eller data ut med en database, gjør vi det mulig å koble verktøy på nye prosjekter. Vi kan da ta med oss verktøyene videre, og bruke de igjen i neste prosjekt.

Steg 5: aksjonsgruppen forbedrer og deler

Aksjonsgruppen besitter nå kompetanse til å gjøre inkrementell forbedring. Bedriften kan nyttiggjøre seg kompetansen på to måter:

1. Aksjonsgruppen bygger opp egne verktøy og prosesser, og blir gradvis mer effektiv
2. Aksjonsgruppen deler erfaringer, verktøy og prosesser med andre i bedriften.

Punkt 1. vil være selvdreven. Punkt 2. krever mer oppmerksomhet, og kan for eksempel gjennomføres ved at når aksjonsgruppen er klar, splittes den i to, og deler kunnskapen med nye mennesker.

Veien videre

Veien videre vil alltid være opp til de som jobber i prosjektet. For dem, har jeg imidlertid noen ønsker:

• En mer meningsfull arbeidsdag der mennesker kan gjøre menneskelige vurderinger, og maskiner holde styr på maskinelt bokholderi.
• At vi i prosjektet kan levere kontinuerlig, der vi på ethvert tidspunkt kan trekke ut resultatene vi ønsker, uten å ha en ekstra fase på slutten av prosjektet med rapportering der vi (forhåpentligvis ikke) legger merke til noe vi skulle gjort noe med for lenge siden.
• At vi i prosjektet kan gjøre parameterstuder med et funksjonskall; for variasjon over denne parameteren vil jeg ha en oversikt over alle resultater, og kunne spørre om resultater og sammenlikne på tvers av analyser.
• At vi i prosjektet kan gjøre effektiv gjenbruk mellom prosjekter, der prosedyrer for design vi har bygget oss opp over et tiår er tilgjengelig for oss i hvert nye tilfelle.

Er du interessert, men vet ikke helt hvor du skal starte? Ta kontakt på Prosjektdatabase.no.

Teodor

Du har nå lest artikkel 3 i artikkelserien “Intro til Prosjektdatabasen”. Artikkel #1 og artikkel #2 er allerede publisert.