Til Complan Network AS sin Norske Web Side. In English

Complan Network AS, etablert i 1986, er hovedkontoret til Complan Gruppen som har avdelings kontorer i Perth, Houston og Kuala Lumpur. Vårt produkt er først og fremst WinPCS - Windows Project Completion Software -  et data system for oppfølging av store bygge prosjekter. Vi utfører også konsulentjenester og er spesielt godt rustet til oppdrag innen for ferdigstillelse, overlevering og drift, men her er en liten innføring i WinPCS.

Programvaren for ferdigstillelse av store byggeprosjekter.
Denne siden er ment som en uformell og enkel forståelse i bruken av WinPCS. Den beskriver de enkleste funksjoner og dokumenter. Dog forutsettes det at brukeren har satt seg inn i nedbrytingen av prosjektet, nummereringsstrukturen og har en hvis forståelse av de aktiviteter og faser som et prosjekt må igjennom før det kan overleveres til drift.

HUSK! - WinPCS er et verktøy og er ment som en hjelp til å holde orden på de store datamengdene i et prosjekt. Det skal til enhver tid holde orden på hva som skal testes, hvordan testen skal gjøres og resultatene av denne.

Til syvende og sist er det folkene som utfører arbeidet og som avgjør kvaliteten på prosjektet.

Ved nøye utfylling og tilbakerapportering til WinPCS har prosjektet en unik mulighet til å vise fremdrift i "sann-tid". D.v.s. faktisk arbeid utført og derav hva som er utestående til en hver tid.

For å øke forståelsen til nye brukere om hvordan og hva WinPCS er, kan det være greit med en liten historikk

Historikk:
Da Phillips Petroleum startet som første utbygger på norsk sokkel, innså de svært tidlig at kravet til utstyr og materiell var annerledes enn landbaserte installasjoner. Mye arbeid ble lagt ned for å finne fram til arbeidsmetoder og til nytt utstyr med spesifikasjoner, som kunne tåle de nye utfordringene til miljø og sikkerhet.

I det hele tatt ble olje-industrien nødt til å tenke i nye baner for å redusere de mange ulykkene som preget de første offshore-installasjonene. Myndighetene begynte etterhvert å stille strenge krav til dokumentasjon og gjennomføring av prosjektene.

Da Statoil og spesielt Hydro startet sine første prosjekter ble det for alvor tatt i bruk EDB til å i- vareta oppfølgingen av byggeprosessen. Hydro brukte på den tiden store summer på et EDB system og utførte et stort nybrottsarbeide i gjennomførelsen av Oseberg-prosjektet. De innførte en helt ny arbeidsmetode med tanke på hvorledes et prosjekt skulle gjennomføres.

Investeringene og erfaringene som ble gjort den gangen,har kommet alle senere prosjekter til gode gjennom bedre kontroll og sikkerhet, med mindre personell og til lavere kostnader.
Med den rivende datautviklingen var det naturlig å lage ny programvare, som var mer brukervennlig og hadde økt kapasitet, flere funksjoner, lavere kostnader og ikke minst, lett kunne flyttes fra sted til sted.

I 1988 ble Complan engasjert av Kværner for å utvikle det første PC-DOS baserte systemet for Draugen-plattformen. Noen år senere kom Microsoft Windows operativsystemene for fullt, og det var i denne overgangsperioden at WinPCS så dagens lys. Som det første Windows-baserte systemet for denne type aktiviteter, ble WinPCS tatt i bruk på et av verdens største olje- og gass- prosjekter i Saudi Arabia i 1991/92.

Med lang erfaring fra den spede barndom i norsk oljehistorie og frem til i dag har vi utviklet WinPCS til et system som nå brukes på prosjekter over hele verden.

Prosjektene omfatter olje & gass, smelteverk, gruver, jernbaner, gjødsel-, sukker- fabrikker og andre komplekse byggeprosjekter der kravet til sikkerhet er i fokus.

Hva gjør WinPCS?
WinPCS organiserer og visualiserer nedbrytning fra systemnivå og helt ned til det enkelte utstyr med tilhørende prosedyrer for hvorledes dette utstyret skal sjekkes, testes, og sertifiseres. Fra konstruksjon og fram til drift gjennomgår et prosjekt mange faser. Kravet til testing av det enkelte utstyr vil endres fra en fase til en annen.
 

Første fase vil normalt være installasjon av det enkelte utstyr hos leverandørene eller på byggeplassen. I den siste fasen av prosjektet vil uttesting som oftest utføres på en gruppe av utstyr for å sjekke samspill, virkemåte og funksjonalitet. WinPCS tillater derfor en ubegrenset knytning mellom utstyr, grupper av utstyr og testprosedyrer, fotografier, tegninger eller andre typer dokumenter.
 

Til hvert utstyr, eller gruppe av utstyr, knyttes det opp en sjekkliste som blir skrevet ut fra WinPCS når utstyret skal sjekkes. Når kontrollen av utstyret er utført, skal status for dette registreres tilbake i WinPCS. Dette gjør det mulig for brukerne av systemet å finne ut hvilke aktiviteter som er blitt utført, er mangelfulle eller ikke påbegynte.
 

Ved hjelp av de registrerte dataene skal systemet til enhver tid reflektere faktisk status og fremdrift på alt utstyr som skal sjekkes. I tillegg skal systemet sammen med sjekklistene og prosedyrene sikre at Prosjektets krav til kvalitet og kontroll er ivaretatt gjennom hele prosjektet.

WinPCS er laget for at brukergrensesnittet skal være så enkelt som overhode mulig. Derfor er utstyr, sjekklister, områder og systemer (alle objekter) representert med et lite ikon (symbol). Disse er så presentert i et felles skjermbilde (hierarki) som viser tilhørigheten til hverandre og vil med dette gi en grei oversikt over prosjektet.
 

Rapportering av status og utskrift av sjekklister, kan gjøres på hele prosjektet eller deler av prosjektet, forutsatt at det enkelte utstyr er knyttet opp mot en overordnet prosjektstruktur. Denne strukturen kan være inndelt på forskjellige måter, enten som systemer, områder, arbeidsaktiviteter eller leverandører. På samme måte kan status også rapporteres på tegninger (Elektro, Instrument og prosess diagrammer) og andre dokumenter. Dette gjelder også dokumenter som gjelder offentlige krav og forordninger.
 

Sett fra WinPCS er en hver struktur likeverdig og derfor kan prosjektet arbeide både med OMRÅDE aktiviteter (bygging) og SYSTEM aktiviteter (uttesting) uten at det oppstår konflikt mellom disse.

Nummereringsstruktur.
Viktigheten av et godt nummereringssystem kan ikke poengteres nok, når målet er mest mulig oversikt med minst mulig feil. Husk at mesteparten av Engineering arbeidet blir utført på datasystemer som ikke alltid kommuniserer med hverandre og små avvik mellom disse kan skape mye ekstraarbeid. En organisert metode sparer alltid prosjektene for store beløp.

Nummereringsfeil som oppstår tidlig i et prosjekt uten at disse blir korrigert med en gang, er svært ofte vanskelig å endre på et senere tidspunkt. De skaper ofte usikkerhet med mye unødig tidsforbruk. Likeledes, hvis man begynner med en dårlig nummereringsstruktur, kan man risikere at den passer dårlig inn i datasystemer som er helt avhengig av logiske strukturer. I mange tilfeller må programvaren omprogrammeres for å komme rundt disse problemene med nummereringsstrukturen.

Når alle disse faktorene summeres, ser man klart at dette kan medføre betydelige økte kostnader for prosjektet på et senere tidspunkt.

Viktigheten av et godt nummereringssystem gjenspeiles også i høy grad i det arbeidet som er nedlagt i NORSOK der alle olje- og ingeniørselskaper sammen har utviklet en standardiseringsmodell til bruk på alle ny norske olje prosjekter.

Uansett prosjekt kan de samme erfaringer og retningslinjer benyttes. Det hele er kun en logisk metode hvor sunn fornuft og naturlig arbeidsmetoder settes i system.

Sjekklister
Sjekklister og prosedyrer inngår som en sentral del av et prosjekt. De skal sette rammen for de krav og spesifikasjoner prosjektet mener er nødvendig for å få en sikker god kvalitet på arbeid, utstyr og operasjoner. Sjekklister er fagspesifikke (disiplinorientert) og er ofte korte, enkle oppgaver og kontroller som vil avdekke evt. feil og mangler på utstyr eller funksjoner.

I noen tilfeller kreves det at det blir foretatt målinger (recording), spesielt med tanke på at resultatet over tid ikke avviker fra de toleranser som er satt. Denne informasjonen er viktig med hensyn til drift over tid hvor avvik kan være til skade for liv og helse. Utstyr kan korrigeres før feil oppstår.

De fleste sjekklister har idag henvisning til NORSOK standarden, dette gir en enklere og lik oppbygning av sjekklistene, som igjen kan benyttes fra prosjekt til prosjekt.
 

For andre prosjekter lages tilsvarende spesifikke sjekklister som reflekterer prosjektets behov. Måten disse sjekklistene er utformet på og det omfang de har, gir en bedre oversikt over hva som er utført og hva som gjenstår av arbeidet. Erfaringen tilsier at sjekklister ikke skal inneholde referanse til andre sjekklister, men være mest mulig selvstendige arbeidsoppgaver. Ei heller bør de være for omfattende, slik at arbeidet ikke kan bli utført innen rimelig tid.

Det er bedre med flere sjekklister på det enkelte utstyr slik at en kan prioritere, endre eller avslutte et arbeide uten å måtte vente på fullførelse av andre oppgaver. Av den grunn kan man i WinPCS knytte så mange sjekklister til utstyr som det er behov for.

Dersom sjekklistene utformes til mest mulig Ja/Nei svar, som f.eks. målinger og justeringer som er innenfor toleransekravet, kan man i prinsippet bruke WinPCS som et papirløst kontroll verktøy. Denne metoden er svært kostbesparende og benyttes i mange utenlandske prosjekter ved at de lager en liten bok med alle sjekklistene og utstyrer kontrolløren med en PIN kode som han/hun bruker ved utført sjekking og kvittering i WinPCS.

Mangler og feil (Punchlists)
Foruten sjekklistene er feilrapportene en av de viktigste dokumentene i WinPCS.
 

Det vil alltid oppstå feil og mangler i et prosjekt!
 

Derfor er det svært viktig at disse registreres nøye og knyttes logisk opp mot det utstyret eller de oppgaver som det gjelder. En god oversikt er til uvurderlig hjelp og gir prosjektet en status på hvor problemene finnes.

Har det enkelte utstyr flere uavhengige feil er det bedre med en feilmelding for hver enkelt feil.

På samme måte må alvorlige og ubetydelig feil registreres hver for seg (PA og PB). Dette gjør det lettere for prosjektet til enhver tid å se hva som er utestående og hva som evt. kan påvirke senere aktiviteter.

Som underlag til en feilmelding ved evt. skader og mangler kan digitale bilder og korrespondanse knyttes opp mot de enkelte feilmeldinger.
-----------------------------------------------------