Moduler · 01
Fartøys- og flåteregister
Hvert fartøy, hver avdeling, stilling og person i ett register, med én tilgangsmodell over alt sammen.
Hva den er til for
Kravet
ISM-koden 3.2 — FOR-2014-09-05-1191Rederiet skal definere og dokumentere ansvar, myndighet og innbyrdes forhold for alt personell som leder, utfører og verifiserer arbeid som angår sikkerheten. Et register som ikke kan svare på hvem som innehar hvilken stilling om bord i dag, kan ikke understøtte det kravet.
Det meste som går galt i et skipsadministrasjonssystem, går galt her — lenge før noen åpner en arbeidsordre. En person finnes to ganger fordi to kontorer skrev navnet ulikt. En stilling står uten innehaver fordi forrige innehaver mønstret av og ingen lukket posten. En inspektør får lese et annet rederis fartøy fordi tilgangen ble gitt per bruker i stedet for per område.
NoRemarks holder ett register. Et rederi eier flåter, en flåte eier fartøy, et fartøy eier avdelinger og stillinger, og en stilling innehas av en person i en periode der begge ender er registrert. Alt annet i produktet — en jobb, en arbeidstillatelse, en hviletidsregistrering, en rekvisisjon — peker inn i det registeret i stedet for å gjenta det.
I detalj
Hva modulen gjør
- Tilgang etter område, ikke lister per bruker. En rolle gis på et område — rederiet, én flåte eller ett fartøy — skrevet som en sti, for eksempel co:acme/fl:psv/vs:far-sentinel. Legger du et fartøy inn i en flåte, får flåtens inspektør fartøyet automatisk, og du unngår feilen der noen blir glemt på vei ut.
- Delegering med sluttdato. En skipsfører som går i land i to uker, delegerer til overstyrmann i nøyaktig de to ukene. Delegeringen utløper av seg selv. Ingen står igjen med en permanent utvidet konto, og det finnes ingenting å huske å trekke tilbake.
- Uttrykkelig nekting som slår en tildeling. Noe må kunne holdes tilbake fra en person som ellers har rollen. En nektingsregel ligger over enhver tildeling, slik at svaret på «kan denne personen gjøre dette her» er én funksjon med ett resultat — og produktet spør den i stedet for å se på et rollenavn.
- Fartøyet står under oppsett til det er klart. Et nytt fartøy er ikke i drift før det har tidssone, avdelinger og en navngitt skipsfører. Sjekklisten er en del av domenet, ikke en oppstartsrutine noen følger, så et halvferdig fartøy kan ikke stille og rolig begynne å registrere lovpålagt arbeid.
- IMO og MMSI kontrolleres ved inntasting. Kontrollsifferet i IMO-nummeret verifiseres der det skrives inn. MMSI valideres og kan ikke tas av to fartøy, fordi AIS-posisjonen til feil skip på riktig side er verre enn ingen posisjon.
- Revisjonsspor med hashlenke per fartøy. Hver skriving på serveren registreres med aktør, enhet, tidspunkt og SHA-256 av forrige post. Kjeden går per fartøy, slik at en inspektør kan få historikken til ett fartøy uten å få hele flåtens.
Skjermer
Hva den legger til i appen
- Fartøysside — hva fartøyet er, hvor det er, og hva som forfaller
- Rederi, fartøy, stillinger og brukere under Administrasjon
- Tilgangsstyring: roller, tildelinger, delegeringer og nektinger
- Revisjonsloggen, lesbar i produktet og ikke i en database
Beslutningen
Ingen innføringsprosjekt
Et rederi kan legge inn sitt eget fartøy, sine egne avdelinger og sine egne folk en tirsdag ettermiddag, uten oss. Det finnes ingen etableringsavgift og ingen konsulent i loopen, fordi et register bare leverandøren kan endre, er et register som slutter å stemme etter omtrent tre måneder.
Grunnkatalogene — avdelinger og stillinger slik de faktisk heter om bord på et norsk offshorefartøy — er der å starte fra, og alt sammen kan endres eller fjernes.