Tilsyn med næringsmidler som importeres

Aspekter ved prosjektet

Av hovedfagstudentene:
André Hoddevik
Elisabeth Strand
Even Harket
Irene Driveklepp
Marianne Johansen
Avdeling for forvaltningsinformatikk
Universitetet i Oslo, Våren 1995

FORORD

Denne oppgaven er en del av databasekurset FI 2-3.

Det er første gang dette kurset holdes, og vi er fem studenter som tar kurset. I tillegg til pensumlitteratur og eksterne forelesere har vi også tilegnet oss en del materiale fra SNT.

Bakgrunnen for prosjektet er at vi skulle praktisere det vi tidligere hadde av kunnskap, i tillegg til det nye pensumet. Faget Forvaltningsinformatikk i seg selv er praktisk rettet i forhold til andre universitetsfag.

Prosjektet er tilknyttet Statens Næringsmiddeltilsyns (SNT) arbeid med å utvikle et saksbehandlings- og informasjonssystem til bruk i Det offentlige næringsmiddelstilsyn (ONT). SNTs nye system skal bestå av moduler for arkiv og saksbehandling, laboratorie- og inspeksjonssystem, kjøttkontroll og importkontroll. Vår oppgave har vært å komme med innspill til modul for importkontroll i forbindelse med det pågående prosjektet "Tilsyn med næringsmidler som importeres" i regi av SNT.

Dag Sjøberg har hele tiden vært vår faglige veileder, og gitt oss tips under arbeidet. SNT har i sakens anledning, engasjert Gerhard Skagestein som ekstern konsulent i prosjektet. Han er også en av våre forelesere på kurset.

Lennart Johanson er SNTs prosjektleder og har stilt seg til disposisjon for våre henvendelser.

Vi vil takke Dag Sjøberg og Lennart Johanson for alle råd, og all oppmuntring underveis.

Oslo, 6. juni 1995

Innhold

I Problemstilling
II Metode
     Objektorientert analyse
III Kravspesifikasjon
1 Innledning
2 Det offentlige næringsmiddeltilsynet
3 Om importkontrollsystemet
     3.1 Målsetning med systemet
     3.2 Hva skal edb-systemet handle om?
     3.3 Hva skal edb-systemet brukes til?
     3.4 Systemdefinisjon
     3.5 Importkontrollsystemets omgivelser
4 Datamodeller
     4.1 Importsystemets to hoveddeler
     4.2 Registreringsdatabase
     4.3 Erfaringsbase
5 Brukergrensesnitt - et eksempel
6 Opplæring
7 Teknologi
8 Noen juridiske betraktninger
     8.1 Kort om Norge, EØS og EU
     8.2 To lover å ta hensyn til i systemutviklingen
9 Oppsummering av åpne spørsmål og usikkerhetsmomenter
IV Evaluering av eget arbeid
V Litteraturliste

I Problemstilling

Oppgaven vi fikk utlevert, var delt i fire spørsmål, som denne rapporten er resultatet av.

Svar på spørsmålene, er fordelt utover de forskjellige kapitlene.

Vi har utledet en problemstilling utfra de fire spørsmålene:

Hvilke opplysninger behøves, hvor skal disse være tilgjengelige og lagres, og hvilken formaliseringsgrad skal det være på dataene. Er det mulig med en fullautomatisering av eksisterende manuelle rutiner? Dette skal en se i sammenheng med at det skal foretas en importkontroll på en rasjonell og effektiv måte, samtidig som effekten blir størst mulig.

Vi tolker dette som om vi skal finne ut hvilke opplysninger som er relevante, og unngå dobbeltregistrering av disse. Om det skal skje en sentralisert eller desentralisert lagring og tilgjengelighet, og hvor langt kan man erstatte kontrollørens beslutninger med en datamaskin.

Avgrensning

Løsningene på disse oppgavene er nedfelt i en datamodell, og i ren tekst i rapporten. Vi ønsket også å utferdige en prototyp, men tekniske og tidsmessige begrensninger hindret dette. Vi har likevel kommet med et utkast til grafisk brukergrensesnitt.

Vi har lagt stor vekt på datamodellen, og hva slags opplysninger som er relevante for systemet. Det vi har fått liten tid til, er å vurdere hvilke opplysninger som burde formaliseres og hvilke rutiner som kan automatiseres.

II Metode

Objektorientert analyse

Vi har tatt utgangspunkt i objektorientert analyse. Betegnelsen objektorientert uttrykker at objekter brukes som de grunnleggende beskrivelseselementer, og at disse settes i sentrum. Modellene som blir utformet, er uavhengig av den rådene teknologien. Styrken ved metoden er at den er velegnet til å beskrive både virkeligheten og edb-systemet.

Soft Dialectis er en av mange objektorienterte metoder. Vi valgte denne på bakgrunn av at to av oss har brukt den tidligere.

Når vi startet prosjektet, var det viktig for oss, så raskt som mulig, å få innsikt i hvordan importkontrollen fungerte. Til dette brukte vi rike bilder fra Soft Dialectics-metoden. Rike bilder er en teknikk til å skaffe seg det nødvendige overblikk forholdsvis raskt. Et rikt bilde er en tegning uten formelle symboler og regler, der vi prøver å fokusere på vesentlige forhold i situasjonen. En kan velge å ha fokus på det statiske eller det dynamiske. I første omgang laget vi rike bilder med fokus på det statiske, for å få et overblikk over dagens situasjon.

Etter det rike bildet, setter en opp en systemdefinisjon, som stadig kan endres etter som nye vesentlig ting dukker opp. En systemdefinisjon er en kortfattet og presis beskrivelse av en edb-løsning uttrykt i naturlig språk. Vi beskriver i sammenheng hva edb-systemet skal inneholde informasjon om, hva systemet skal kunne, hvor det skal brukes, og hvilke betingelser som gjelder for utviklingen av systemet.
Ut fra systemdefinisjonen sorterer vi objekter i klasser, og ser på strukturen til klassene, og dynamikken mellom objektene. Dette resulterer i en datamodell.

Vi bestemte oss for å bruke datamodeleringsmetoden NIAM. Det står for Nijssen`s Information Analysis Methodology. To av oss har brukt denne metoden i tidligere prosjekter.

Det stod mellom denne metoden, eller et ER (Entity Relationship) diagram. Valget falt på NIAM da vi følte at vi fikk tegnet klarere inn den informasjonsflyten som SNT var interessert i å modellere.

Argumentet som talte imot å bruke denne metoden, er at den ikke er så utbredt og akseptert i næringslivet. Her står ER sterkere. Vi syns det likevel var på sin plass å bruke NIAM, den går mer i detaljer og er godt kjent innen universitetsmiljøet. I dokumentene fra SNT var det brukt en dialekt av ER. Vi valgte likevel NIAM fordi denne var best kjent i gruppen.

Ut fra modellen og systemdefinisjonen gjør en så en analyse av anvendelsesområdet, og lager en fullstendig funksjonsliste. Anvendelsesområdet består av edb-systemet, brukerne og måten brukerne anvender edb-systemet på. Funksjonslisten er en liste over ressurser som stilles til rådighet for brukerne, og nyttiggjør modellkomponenten i utførelsen av arbeidsoppgaver.

Denne kan en gjøre vurderinger av gjennom en prototyp, før en ender opp med en endelig funksjonsliste. En ser også på grenseflater både mot bruker og andre systemer. Grenseflater sier noe om hvordan skjermbildene skal se ut, og hva slags tilknytninger en skal ha til andre systemer.

Avslutningsvis tar en med alle erfaringer en har fått hittil i prosjektet, og sette opp et analysedokument, eller en kravspesifikasjon til systemet. Kravspesifikasjonen må inneholde informasjon som alle personer som skal utvikle og bruke systemet, trenger for å planlegge og utføre sitt arbeid. En god spesifikasjon letter kommunikasjonen mellom alle disse samarbeidspartnere.

Vi har brukt deler av denne metoden i vårt arbeid. Den har vært til god støtte for fremdriften og gjort det enklere å ta fatt på oppgavene. Kravspesifikasjonen som det var ønskelig å komme frem til, er langt fra komplett. Vi har kun kommet med momenter som kan gå inn i en eventuell kravspesifikasjon.

III Kravspesifikasjon

1 Innledning

Dette er en samling av momenter til kravspesifikasjon for importkontrollsystemet. Vi har ikke hatt den tiden vi ønsket til å jobbe med stoffet, så det vi presenterer her er dermed ikke helt fullstendig.

Vi vil si noe om hva som er målsetningene for det fremtidige edb-systemet før vi kommer inn på datamodellene for "registreringsbasen" og "erfaringsbasen". Datamodellene utgjør hoveddelen av arbeidet vårt. Vi vil også se på noen juridiske betraktninger rundt spørsmålet om oppretting av et importørregister. Til slutt vil vi komme inn på diskusjoner som kan være aktuelle i det videre arbeidet.

Selv om dette ikke ble så omfattende som vi først ønsket det, håper vi at noen av delene kan være til hjelp eller gi noen ideer til prosjektgruppen hos SNT.

For fullstendig oppsett av kravspesifikasjon henviser vi til Statskonsults generelle kravspesifikasjon og kravspesifikasjon utviklet av Senter for Industriforskning (SIFO). Disse kan gi ideer til godt dokumenterte kravspesifikasjoner.

2 Det offentlige næringsmiddeltilsynet

Det offentlige næringsmiddeltilsynet (ONT) er et forvaltningsorgan som blant annet skal forvalte næringsmiddellovgivningen og yte service til brukere av næringsmiddeltilsynet. ONT består av to statlige instanser, Statens næringsmiddeltilsyn (SNT), Fiskeridirektoratets kontrollverk (FD) og 83 kommunale eller interkommunale tilsyn (KNT). KNT og FD er det utøvende tilsynsapparat på næringsmiddelområdet.

SNT

SNT skal bl.a. samordne alt offentlig tilsyn av næringsmidler og være et kompetanseorgan for det offentlige næringsmiddeltilsyn. Det skal sørge for at det utøvende næringsmiddeltilsyn har best mulig vilkår for å gjennomføre sine oppgaver på en ensartet og hensiktsmessig måte.

FD

Fiskeridirektoratet er Fiskeridepartementets fremste rådgivende og utøvende organ i fiskeri-, havbruk- og havmiljøspørsmål. Som fagorgan har direktoratet fått delegert en lang rekke forvaltningsoppgaver. Direktoratets hovedoppgave er planmessig å arbeide i næringen og slik at fiskeressursene på lang sikt gir et optimalt økonomisk utbytte. Fiskeridirektoratet har hovedkontor i Bergen og 6 distriktskontor langs norskekysten.

KNT

De 82 kommunale næringsmiddeltilsyn er geografisk spredt utover hele landet, og har ca. 600 ansatte. KNT skal i hovedsak ha førstelinjetjeneste mot forbrukerne, næringsmiddelindustri etc.. Mange kommuner betrakter KNT som sitt kompetansesenter og har derfor tillagt KNT en rekke andre oppgaver utover næringsmiddeltilsyn. Dette kan for eksempel være oppgaver innen miljøvern, miljørettet helsevern (kommunehelseloven), innen fiskeoppdrett og i forbindelse med serverings- og skjenkebevillinger med videre.

Kommunenes ansvar for næringsmiddeltilsyn har ført til utbygging av KNT som et desentralisert forvaltnings- og kontrollsystem som kjenner de lokale forhold godt nok til å ta effektive beslutninger.

Forholdet mellom SNT og KNT

De lokale KNT utøver sin virksomhet etter delegasjon fra SNT. SNT er det organ som over budsjettene fordeler penger til lokale næringsmiddeltilsyn. Budsjettet er imidlertid kun et rammebudsjett, der KNT selv kan bestemme hvordan pengene skal benyttes på mest hensiktsmessig måte. Det har vært SNTs politikk å gi de kommunale næringsmiddelstilsyn så stor handlefrihet som mulig. Denne uavhengigheten som KNT har, må vektlegges i utformingen av det nye systemet. Bakgrunnen for at KNT har en slik uavhengig rolle, er at SNT nylig har fått det samordnende ansvaret for næringsmiddelkontrollen. Det vil si at KNT har vært uavhengige organer i lang tid før SNTs overtagelse. Dessuten har KNT flere pålagte oppgaver enn det SNT har instruksjonsmyndighet over. SNT er redd for at en strammere styring av de lokale virksomheter vil føre til misnøye i KNT. Det blir lagt vekt på at virksomhetene skal integreres, ved at de får tilgang til de samme systemer og den samme informasjonen. Det er allikevel ikke SNTs hensikt å fjerne ansvar og selvbestemmelsesretten i de lokale organer. De lokale virksomheter er avhengig av å kunne justere ressurser i forhold til egne behov. Dette vil si at behovene ved hos ulike KNT kan variere betraktelig. Et fundamentalt problem er at SNT som statlig organ har kontroll over kommunalt organ. SNT er allikevel forsiktige med å bruke denne kontrollen på grunn av prinsippet om kommunalt selvstyre. Dette prinsippet kan sies å ha grunnlovsrang.

3 Om importkontrollsystemet

Fra 1995 har staten overtatt ansvaret for importkontrollen av næringsmidler. Begrunnelsen for endringen er behovet for at SNT samordner og effektiviserer kontrollen - samt å oppfylle forpliktelser som følger av EØS-avtalen og eventuell utvidelse av denne.

Formålet for importkontrollsystemet er altså å samordne og effektivisere tilsynet med næringsmidler som importeres. Tilsyn med næringsmidler som importeres deles i:

• kontroll av næringsmidler ved grensekontrollstasjoner

• spesielle overvåkningsprogram av importerte produkter på markedet

• tilsyn med importvirksomheter

Etter dagens system blir det foretatt en 100% dokumentkontroll, og en noe mindre identitets- og fysisk kontroll ved grensekontrollen. En ønsker å effektivisere ved å erstatte dagens system med et system for sortering av partier og utrekning (basert på en risikovurdering) av varepartier som skal undersøkes ved grensekontroll. Kontrollen må baseres på stikkprøver, og varer med ukjent kvalitet bør selvfølgelig kontrolleres oftere enn kvalitetsprodukter fra anerkjente produsenter. Videre bør man ikke kaste bort ressurser på å kontrollere varer som allerede er kontrollert på en tilfredsstillende måte, for eksempel i et annet land, eller i et annet KNT. Importkontrollen må også tilfredsstille de formelle krav som følger av EØS-avtalen.

Ved å utveksle informasjon mellom de forskjellige kontrollstasjonene, samt aktivt ta i bruk opplysninger fra overvåkningsprogram og meldesystemer kan en samordne tilsynet bedre. Når en i tillegg tar i bruk et edb-system for å lette denne samordningen kan en sammen med de endrede arbeidsrutinene få til en effektivisering.

Importkontrollsystemet skal brukes av SNT, KNT og på sikt ønsker en også at importørene skal involveres. KNT vil bruke det som et verktøy i arbeidet, mens SNT først og fremst vil bruke det for årsstatistikker, og til å informere - spesielt om saker som haster.

3.1 Målsetning med systemet

• Harmonisere og ressursoptimalisere tilsynet med næringsmidler som importeres.

• Integrere vesentlige deler av tilsynet med importerte næringsmidler med øvrig næringsmiddeltilsyn ved at deler av dagens grensekontroll erstattes med tilsyn med importvirksomheter og tilsyn i markedet ellers.

• Oppfylle nasjonale forpliktelser på bakgrunn av internasjonale avtaler

3.2 Hva skal edb-systemet handle om?

Edb-systemet skal handle om kontroll av importerte varer. Det skal danne basis for sortering og utrekning av varer som skal kontrolleres ved de forskjellige grensekontrollene. Systemet skal blant annet inneholde en erfaringsbase som er en samling av bearbeidet erfaringer dokumentert i andre system.

3.3 Hva skal edb-systemet brukes til?

Systemet skal være til hjelp for de som jobber i importkontrollen. For grensekontrollstasjonene skal det kun være et verktøy for å hjelpe de ansatte med "synsing" i forhold til kontrollen av varene. Det skal gjøre det enklere å sortere ut varer som skal kontrolleres, og etter en manuelt oppsatt matrise skal det kunne foretas automatisk utrekning av aktuelle varer. Det skal også kunne registrere hvilke type kontroll en vare skal gjennom. For SNT skal det være et statistikkverktøy, samt at det skal kunne brukes til å formidle informasjon.

3.4 Systemdefinisjon

Systemdefinisjonen i SNTs dokument, "Kravspesifikasjon for saksbehandlings- og informasjonssystem", slik vi forstår den, ligger både i innledningen og i oppramsingen av de generelle kravene til systemet. Det er altså ikke utformet en egen selvstendig systemdefinisjon. Det er derfor på sin plass med en egen systemdefinisjon for denne nye delen av systemet, som er i ferd med å utvikles.

Bakgrunnen for systemet er at den skal sikre forbrukerne næringsmidler av riktig kvalitet, og forhindre import av sunnhetsskadelige eller helsefarlige næringsmidler.

Systemet skal betjenes av faste ansatte som i dag jobber med de manuelle rutinene. Det er ikke krav til forkunnskaper i edb, til hverken kontorpersonalet, kontrollørene, juristene, saksbehandlerne, laboratoriepersonalet, informasjonskonsulentene eller lederen. Systemet skal administrere importkontrollen med spesielt utvelgelse av høyrisikogrupper og ellers oppfylle de generelle kravene i EØS-avtalen. Det forventes at det skjer en modernisering av eksisterende edb-løsning, og man skal velge optimal løsning for lagring av informasjon. Det skal automatiseres, så langt dette er mulig. Systemet skal støtte overvåking av importkontrollen, og sikre at kontrollen blir utført på en rasjonell og effektiv måte.

3.5 Importkontrollsystemets omgivelser

Systemet for importkontroll er en del av det totale systemet som utvikles for ONT. Systemene importkontrollsystemet skal kommunisere med er arkiv- og saksbehandlingssystemet, laboratorie- og inspeksjonssystemet og kjøttkontrollsystemet, (Kravspesifikasjon, høringsutkast, 1993). Et av SNTs mål er å integrere de ulike systemene innenfor næringsmiddeltilsynets virksomhet, slik at man utnytter ressurser og kapasiteten maksimalt, og oppnår en effektiv og tilstrekkelig kontroll av næringsmidler. Det er også aktuelt med elektronisk datautveksling til og fra samarbeidende institusjoner i inn- og utland.

4 Datamodeller

4.1 Importsystemets to hoveddeler

Importkontrollsystemet består av to hoveddeler. Det er registreringsdatabasen og erfaringsdatabasen. Registreringsdatabasen inneholder data hentet fra handelsdokumentene. 80-90% av handelsdokumentene er tilgjengelig i elektronisk form fra TVINN. En rekke små importører er imidlertid ikke tilknyttet TVINN, noe som innebærer at det også må være mulig å registrere data manuelt ved de enkelte grensekontrollstasjonene. Vi vil ikke her gå nærmere inn på modellering/programmering av de manuelle registreringsrutinene, men forutsetter at data registrert manuelt er de samme som er tilgjengelig fra TVINN.

Formålet med registreringsdatabasen er å samle inn data fra handelsdokumentene med tanke på sortering/utrekning, og å danne utgangspunkt for statistikk.

Hensikten med erfaringsdatabasen er å danne grunnlag for en risikovurdering, av de enkelte produkter. Disse risikovurderingene skal anvendes ved sortering og utrekning gjennom prosedyrer for sammenligning med de ulike opplysningene vi henter ut fra handelsdokumentet i registreringsbasen

4.2 Registreringsdatabase

Vi har satt opp en modell over data tilgjengelig fra TVINN. Modellen er basert på en gjennomgang av hvilke poster i det elektroniske handelsdokumentet som er påkrevd utfylt hos tolletaten (Toll- og avgiftsdirektoratet 1993). Vi har ikke tatt med alle påkrevd utfylte poster, men gjort en vurdering av hva som er relevant ut fra SNTs oppgaver. Dette innebærer at vi ikke nyttiggjør oss hele den datamengden vi har tilgang til. Poster som vi ikke har tatt med i modellen, men som kan være interessante er: avsender/eksportør (post 2), antall kolli (post 6), deklarant/representant (post 14) og varens lagringssted (post 30) . Hvorvidt disse eller andre poster skal være med i den endelige modellen vil måtte avgjøres av om brukerne finner informasjonen disse inneholder relevant.

Selve modellen har to entiteter; sak og produkt. Sak har attributtene journalnummer (løpenummer + grensekontrollstasjonens identitetsnummer), importørens enhetsregisternummer, antall vareposter, ekspedisjons- og deklarasjonstype og transportmåte ved grensen. Produkt har attributtene tariffnummer og landkode. I figur 1 er de forskjellige attributtene markert med ringer som er små og har tynne linjer. Samtlige attributter har data med høy formaliseringsgrad.

Figur 1. Datamodell av registreringsdatabasen

Modellen er laget ut fra følgende tankegang: De lokale grensekontrollstasjonene mottar handelsdokumenter elektroniske fra TVINN (80-90%) eller på papir fra speditør/importør (10-20%). De papirbaserte dokumentene tastes inn ved grensekontrollstasjonen. Når grensekontrollstasjonene mottar handelsdokumentet tilordnes dette et journalnummer (løpenummer + grensekontrollstasjonens identitetsnummer). Dette nummeret identifiserer entydig den enkelte sak eller importhendelse. For vær sak hentes det ut informasjon fra post 1 (Deklarasjon), 5 (Vareposter), 8 (Mottaker) og 25 (Transportmåte ved grensen) i handelsdokumentet. Vær sak kan inneholde fra ett til mange produkter. Listen over hvilke produkter som importeres i den enkelte sak vil bestå av opplysninger hentet fra post 33 (Tariffnummer) og 34a (Kode opprinnelsesland). Hvert produkt kan inngå i en eller flere saker. Vi får dermed et mange-til-mange forhold, noe vi har forsøkt å løse gjennom begrepsdannelsen importliste.

Importlisten består av journalnummer og tariffnummer. Dette danner utgangspunktet for generering av statistikk over den totale importen av næringsmidler. Når det gjelder behov for statistikk ønsker SNT blant annet oversikter over hvor mange forsendelser, hvor mange vareslag og hvilke vareslag (etter tariffnummer) som kommer til landet. Vi antar at dette ikke er en uttømmende liste over statistikkbehovene (SSB vil kanskje ha mer?), og at en må ta høyde for at flere opplysningstyper skal være med i den endelige modellen. På bakgrunn av denne usikkerheten har vi ikke tatt stilling til på hvilke måte eller fra hvilke tabeller det er hensiktsmessig å hente ut statistikkgrunnlag.

4.3 Erfaringsbase

Erfaringsbasen vil i hovedsak måtte gjenspeile modellen av våre tilgjengelige input-data (figur 1). Hensikten med erfaringsbasen er jo å akkumulere informasjon som skal benyttes i kontroll av innkommende handelsdokumenter Ò en kontroll som nødvendigvis begrenses til data tilgjengelig fra handelsdokumentet.

Problemstillingen for modellering av erfaringsbasen blir ut fra dette å finne faktorer som kan ha betydning for utvelgelse av produkter/forsendelser i den informasjonen man har tilgang til innen den offentlige næringsmiddelkontrollen.

Ser en på SNTs modell for tilsyn med næringsmidler finner en at det er minst syv ulike kilder til informasjon innen næringsmiddeltilsynet (SNT 1995b). Disse er resultater fra identitetskontroll, fysisk kontroll, vanlig virksomhetstilsyn, lokale og statlige overvåkningsprogram, ulike meldesystemer og de ulike instansers faglige vurderinger. I tillegg har vi åpnet for en kobling til Brønnøysund og Enhetsregisteret. Om ønskelig kan en her få opp mer informasjon om importørene enn det handelsdokumentet gir.

Figur 2. Utgangspunkt for modellering av erfaringsdatabase

De ulike informasjonskildene inneholder i dag data med forskjellig formaliseringsgrad (mye fritekst), og det benyttes ikke standardiserte meldingsskjemaer for formidling av denne informasjonen. Dette innebærer at det er svært vanskelig å tenke seg en automatisert bearbeiding av den tilgjengelige informasjonen. Det arbeides imidlertid nasjonalt med å standardisere klassifisering av bransjer, tilsyn i virksomheter, matvarer, analysetyper og i kjøttkontrollen (SNT 1995a). Internasjonalt arbeides det i EUs IDA-program med standardisering av informasjon på tvers av landegrensene. Enkelte IDA-prosjekt er relevante for kontroll av næringsmidler (ANIMO, SHIFT, RAPEX). Framdriften i dette arbeidet vil være styrende for graden av automatisering i et framtidig importkontrollsystem basert på erfaringsdatabasen.

Per i dag er imidlertid situasjonen slik at de enkelte informasjonselementene må bearbeides av personell tilknyttet ONT lokalt eller sentralt. En erfaringsbase må derfor gi fagpersonale rask tilgang til oppdatert og relevant informasjon på en oversiktlig måte.

Til å begynne med bør erfaringsbasen være en ren tekstdatabase, der det kan være mulig å søke i fritekst. Hvordan en videre skal legge opp søkestrategien for å få tak i relevant informasjon på mest mulig effektiv måte kommer ikke vi nærmere innpå i denne rapporten. En tekstdatabase bør være et utgangspunkt samtidig som en følger med på hva som skjer i inn- og utland når det gjelder formalisering av denne type data. På sikt kan en ha som mål å få til en database med formalisert informasjon, som dermed kan være til mer effektiv hjelp for de ansatte. Vurderingen av innholdet bør ligge hos personalet, men til i større grad edb systemet kan være til hjelp, til raskere og mer effektivt kan en få unna kontrollene ved grensekontrollstasjonene.

5 Brukergrensesnitt - et eksempel

Systemets skal ha et grafisk brukergrensesnitt og SNT har valgt Windowsløsning. De stiller blant annet krav til enkelhet, "on-line hjelp" og mulighet for å generere ulike rapporter.

I Importkontrollsystemet vil brukerne bruke systemet i to typer oppgaver. Den første er registrering av handelsdokumenter som ikke kommer elektronisk via TVINN. Den andre er manuell utrekning for kontroll. Denne vil kunne genereres lister på grunnlag av erfaringsdatabasen over objekter som bør kontrolleres. Her stilles det også krav til et enkelt brukergrensesnitt, slik at kontrollørene selv kan finne aktuelle kontrollkriterier. Vi har laget et utkast til et slikt grafisk skjermbilde som ikke er utfyllende, men viser hvordan SNT kan bestemme kriterier for manuell kontroll.

Figur 3. Et mulig skjermbilde for manuell utrekning av saker til kontroll.

Først må kontrolløren under "Grensebehandling" angi om landet er en del av EØS-området eller om det er et tredjeland. Dette påvirker bl.a hvilke land utrekning kan berøre. Her vil det komme en liste over land med spesielle meldinger om landene og som kontrollørene må være på vakt overfor. Videre kan man se på spesielle "Produkt" basert på LANGUAL-kode. Kontrolløren kan sortere på "Importør" som basere seg på Importørregisteret (jf. avs. 8.0). Til slutt kan "Antall vareposter" være et godt sorteringskriterium hvis det er for eksempel. er ønskelig å kontrollere containere med mange ulike produkter.

I skjembildet kan kontrolløren kombinere de ulike kriterier eller la de stå blankt. Når valgene er gjort vil man kunne få en liste over saker/objekter som kan være aktuelle å kontrollere.

6 Opplæring

Siden det ikke kreves spesiell edb-kompetanse eller tekniske forkunnskaper av brukerne, skal brukergrensesnittet være enkelt og forstå. Det kreves imidlertid en grunnleggende opplæring av SNTs og KNTs personale. Opplæringen i ONT skal omfatte alle brukerne av det nye systemet. Selv om det er definerte krav til brukergrensesnittets kompleksitet, må brukerne forstå hvilken kapasitet systemet innehar. Et system kan godt ha et enkelt brukergrensesnitt, selv om det er et avansert system med store ressurser. Opplæringen skal bidra til å utnytte systemet maksimalt, slik at bruken av systemet gir den effektivitetsgevinst som er ønskelig.

Det er viktig at systemeierne på et tidlig tidspunkt bruker ressurser på opplæring. En viktig suksess faktor er at det foregår brukeropplæring før og under igangsettingen av systemet. Det er viktig at opplæringen bidrar til en sikker og kortvarig overgangsperiode fra det gamle til det nye systemet. God opplæring kan også bidra til en entydig og effektiv bruk av systemet. Entydig bruk innebærer her at alle brukerne benytter like prosedyrer for samme sak i systemet.

Opplæringen bør også inneholde aspekter for sikkerhet, etikk og ansvar. Det er viktig at hver enkelt bruker forstår hvorfor man har strenge sikkerhetsrutiner både for innsyn, tilgang og bruk av ulike programområder. Det vil si at det må forklares hvorfor det er viktig med sikkerhet. Et annet viktig hensyn som bør komme i betraktning, er at opplæring ved siden av å være et ledd til øket forståelse av systemet, også kan være et aspekt (sammen med mye annet) til å fjerne motstand fra ansatte over en endret arbeidssituasjon. En kan tenke på opplæring som en motivasjonsfaktor for de ansatte. Dette må sees i sammenheng med det samarbeid som har vært mellom de ansatte og systemeierne tidligere i prosjektet.

Det burde være ut i fra ovennevnte være i SNTs interesse å legge forholdene til rette for at brukerne på en effektiv måte kan ta i bruk det nye systemet. Opplæringen kan gi store økonomiske besparelser for bedriften/virksomheten over lang sikt. For det første vil brukerne være i stand til å benytte systemets ressurser på en effektiv og kostnadsbesparende måte, og for det andre kan opplæringen bidra til at overgangen til det nye systemet blir mindre smertefullt. Det er om å gjøre at det blir minst mulig støy når systemet skal implementeres, og systemet skal settes i ordinær drift. Totalt kan SNT spare store ressurser ved å ta hensyn til konsekvensene av behovet for tilstrekkelig opplæring. Kostnadene ved opplæring vil sannsynligvis være lavere enn den nytte opplæringen vil ha for bedriften.

7 Teknologi

Det kom frem på et møte med SNT, at man med det nye systemet ønsket å gå over til Lotus Notes. Dette er en type gruppevare som er i vinden for tiden. Her har man store og nye muligheter til å distribuere informasjon.

Et problem som kanskje ligger i bakgrunnen, er at den tidligere leverandøren av programvare Ò Miklas Ò sitter inne med mye kunnskap om SNT som den potensielle Lotus Notes-leverandøren Cinet, ikke har.

Miklas har utviklet spesialtilpassete programmer til SNT, som de har brukt i årevis. Det er underveis skjedd oppdateringer og "flikking" på det opprinnelige programmet. Men nå følte SNT at det var tide med en utskiftning av hele programpakken, da det lignet på et lappeteppe. Det var også et argument at man ønsket å gå over til grafisk brukergrensesnitt.

Det var også snakk om at Miklas var interessert i å hjelpe SNT med implementering av det nye systemet ved hjelp av Lotus Notes.

Gruppevare går ut på å gjøre det mulig for personer og samarbeide på tvers av tid og sted. Den skal brukes til kommunikasjon, diskusjonsgrupper, fildeling og utveksling av data og informasjon.

Fordelene med Lotus Notes, er at den har en utmerket måte å distribuere og replikere informasjon på. Det er ikke nødvendig at man har et sentralt lagringssted, lagringen kan skje på hver enkelt tilsyn landet rundt. Dermed oppdaterer hvert enkelt tilsyn selv sin egen base, og ordner selv med innhenting av informasjon fra andre baser. Lotus Notes kan også bidra til at man får felles brukergrensesnitt. Slik at en ansatt fra et tilsyn i landet, kan kommet til et annet tilsyn, og bruke systemet uten mere opplæring.

Om SNT har bestemt seg for Lotus Notes eller ikke, er litt uklart. Men ved denne vurderingen er det også fruktbart å vurdere andre liknende programmer som allerede er på markedet, eller som i nær fremtid vil komme. Vi tenker her spesielt på Microsoft Exchange, Novell Groupware og Netscape ( som tidligere bare har rette seg mot Internettet).

Microsoft og Novells produkter vil ikke være på markedet før ved årskifte. Disse vil da kanskje være mindre aktuelle. Netscape har imidlertid blitt lansert som et alternativ til Notes for distribusjon av data. Et eksempel på dette er at en i PC world Norge (27.04.95), gått så langt som å stille spørsmålet om Netscape slår ut Notes. Dette er gruppevare som er basert på "internt Internett".

Lotus har hatt en ledene rolle på gruppevaremarkedet, siden de var først ute og dermed har vært med på å sette standarden for gruppevarekonseptet.

Ved Institutt for Informatikk hadde man høsten 1994 et prosjekt hvor avdeling for systemarbeid så på gruppevarekonseptet, og spesielt på Lotus Notes. Man brukte studenter på IN 160 (Edb og samfunn) til å gjøre undersøkelser i forskjellige bedrifter som hadde implementert Lotus Notes. Ut ifra disse undersøkelsene ble det avdekket en del feil og mangler i bruk av produktet.

Det største tekniske problemet var å integrere forskjellige deler av Notes med andre programpakker. En annen ting med programmet var at det var ikke så selvinstruerende som leverandøren hevdet. Man brukte i mange tilfeller en avansert programpakke som en tekstbehandler, faks eller filbehandler.

8 Noen juridiske betraktninger

8.1 Kort om Norge, EØS og EU

Utgangspunkt for systemet er som tidligere nevnt samordning og effektivisering av importkontrollen samt oppfyllelse av forpliktelser Norge har som følge av EØS-avtalen.

Vetrinærkontrolldirektivet (89/662/EØF) er i dag ikke en del av EØS avtalen. Dette medfører at EU behandler Norge som et tredjeland i forhold til grensekontroller. Vi har forutsatt i vårt arbeid at dette direktivet vil bli en del av EØS-avtalen. Norge blir da en yttergrense til EU, og følgelig ikke et 3. land. Dette medfører at kontroll med import fra EU-land vil nedbygges og erstattes blant annet av garantier om kontroll på produksjonsstedet. Norge må følge EUs retningslinjer i forhold til kontroll av 3. land (jf. Tredjelandsdirektivet (90/675/EØF)).

Vetrinærkontrolldirektivet omhandler kun animalske produkter. Norges importkontroll omfatter Û til forskjell fra EUs Û også øvrige næringsmidler. For å unngå logiske brister i det norske importkontrollsystemet, vil Importkontrollsystemet gjelde både animalske og ikke-animalske næringsmidler.

8.2 To lover å ta hensyn til i systemutviklingen

Ved utvikling av system for importkontroll vil det være enkelte regler som utviklingsprosjektet bør ta hensyn til (kfr. Dag Wiese Schartum, 1993).

Hensikten med dette er å gjøre SNT oppmerksom på lover som kan berøre systemutviklingen. Avgjørelse om hvorvidt lovene faktisk vil komme til anvendelse overlates til SNT. Hvis SNT må ta hensyn til disse lovene vil de følgelig ha fordeler av å samarbeide med de respektive organer på et tidlig tidspunkt.

Lov om offisiell statistikk og Statistisk Sentralbyrå av 16. juni 1989 med forskrifter

Loven er ment å ivareta Statistisk Sentralbyrås interesser omkring opplysninger som gir muligheter for etablering av statistikk for generell kunnskap, som kan belyse ulike forvaltningsordninger og samfunnsforhold. Ikke bare Importkontrollsystemet, men hele det nye saksbehandlingssystemet for ONT vil kunne generere opplysninger som innbefattes av denne loven.

Etter lovens þ 3.2, annet ledd skal statsorganer og landsomfattende kommunale organisasjoner gi forhåndsmelding til Statistisk sentralbyrå dersom det planlegges å opprette eller endre et større administrativt datasystem. Videre i statistikksforskriften þ1.1, annet ledd, presiseres uttrykket "større [...] datasystem" til "datasystemer som enten er eller er ment å skulle bli landsomfattende, eller som dekker en større del av landet". Saksbehandlingssystemet for ONT vil bli plassert blant annet hos alle KNT, og de som er grensekontrollstasjoner vil få tilgang til Importkontrollsystemet.

I følge statistikkforskriften þ1.1 er aktuelle opplysninger "opplysninger som organisasjoner i statsforvaltningen og landsomfattende kommunale organisasjoner samler inn og oppbevarer på en slik måte at opplysningene kan hentes frem til bruk i organets eller organisasjonens virksomhet".

I tillegg har Statistisk Sentralbyrå en forslagsrett for å sikre statistiske hensyn. Eksempler på forslag vedrørende administrative systemer som kan fremmes ut fra hensyn til statistikk er, i følge statistikkforskriften þ1.4

"[...]

• hvilke opplysninger det bør inneholde
• definisjon av enheter, kjennemerker, klassifikasjoner etc.
• systemopplegg
• datakontroll
• hvilke opplysninger som skal overføres til Statistisk Sentralbyrå og tidspunkt for overføringen".

Hvis SNT vurderer det slik at de blir berørt av ovennevnte lov vil dette selvfølgelig kunne legge føringer på det nye saksbehandlingssystemet som det kan være viktig å få avklart på et tidlig tidspunkt. Vi anbefaler at SNT avklarer lovens relevans i forhold til saksbehandlingssystemet generelt og Importkontrollsystemet spesielt.

Lov om personregistre m.m. av 9. juni 1978 med forskrifter

I det følgende vil vi gjøre noen betraktninger omkring et mulig register over godkjente importører (Importørregister). I dag foregår en godkjenning av importører lokalt hos de lokale KNT. Et register over godkjente importører bør være tilgjengelig for alle. Dette vil kunne bidra til bedre sortering og utrekning for kontroll.

Hvilke opplysninger dette registeret skal inneholde er fortsatt noe uavklart. Det vil kunne være oversikt over ulike sertifikater som importørene er påkrevd, hvilke type varer (i Langual-kode) en importør har tillatelse til å importere samt mulighet for å gi importører "anmerkninger" ved regelovertredelser. Dette vil kunne øke kontrollmuligheten overfor de importører som ikke følger dagens "spilleregler" og det vil være god ressursbruk å kunne sile ut for kontroll. Siden den norske personregisterloven omfatter juridiske personer, vil den gjelde ved et register som skissert over, med importører som registrerte enheter.

I forskrifter til Personregisterloven þ 2 gjøres en oppramsing av fritak fra konsesjonsplikt. Et tiltenkt Importørregister vil generelt ikke kunne fritas for konsesjonsplikt etter denne forskriften. Hvis registeret skal kunne inneholde opplysninger om importører som kan påvirke sortering og utrekning utover basisopplysninger som er tilgjengelig fra Enhetsregisteret vil det måtte søkes konsesjon hos Datatilsynet.

I prl. þ 3.2 heter det at Datatilsynet skal "gir råd og veiledning om spørsmål om personvern og datasikring til dem som planlegger å opprette personregistre". SNT bør avklare hvilke opplysninger et slik register bør og kan inneholde. Samtidig vil det anbefales som god strategi å kontakte Datatilsynet på et tidlig tidpunkt for å avklare eventuelle problemer med et Importørregister som skissert over.

9 Oppsummering av åpne spørsmål og usikkerhetsmomenter

Som tidligere nevnt har vi ikke hatt så god tid til dette prosjektet. Etterhvert som vi har jobbet med stoffet har stadig nye problemstillinger og spørsmål dukket opp. Dette punktet vil fungere som en oppsummering av tidligere diskusjoner i tillegg til spørsmål/tema vi ikke har kommet noe særlig innpå. Dette er ideer som har kommet frem på møtene vi har hatt med SNT, og interne diskusjoner i gruppen.

Lagring

Vi har så vidt kommet inn på spørsmålet om lagring. Det er ønskelig at grensekontrollen utveksler informasjon og at alle har tilgang til erfaringsbasen. I diskusjonene vi har hatt, har vi ikke kommet nevneverdig inn på hvordan dette skal løses teknisk sett. For å sikre korrekt oppdatering kan det være et poeng at dataene er lagret lokalt hos de enkelte KNT, men at alle har tilgang på dette gjennom en type distribuert database. Et annet alternativ som SNT selv har vært inne på er å bruke Lotus Notes som et kommunikasjonsverktøy og informasjonssystem (se under punkt 7.0 Teknikk). Dette er selvfølgelig viktig, men vi har ikke prioritert spørsmålet i vår oppgave, da dette er noe som først kommer inn litt senere i systemutviklingen.

Få til samarbeid med tolletaten om innlegging av data?

Slik systemet fungerer i dag kommer mesteparten av informasjonen via TVINN fra tolletaten, (se punkt 4). Det er likevel en del manuell innlegging av opplysninger for SNT fordi tolletaten ikke har ressurser til å få saker registrert hurtig nok. Det er i dag ikke mulig å overlate denne inntastingen til tolletaten fordi det vil være for lang tid å vente for SNT. En hadde spart mye arbeid ved å få gjort noe med denne delen av systemet.

Hvordan plukke ut aktuelle containere?

Grunnen til at SNT ønsker et nytt system, og at det skal være edb-basert er for å effektivisere arbeidet ved grensekontrollen. Det som tar tid og ressurser er å åpne en ny container. Et viktig satsingsområde er dermed å få antall containere som skal til kontroll ned på et minimum, og likevel kunne sikre en tilstrekkelig kontroll. Importør er knyttet til container, men alle andre attributter i datamodellen vår er knyttet til type vare (se punkt 4). Dersom en får til en sortering som kan ta hensyn til begge kriteriene vil en kunne effektivisere kontrollen.

Hver post på en faktura er en vare. Det mest vanlige er at det er en, to eller tre varer pr. container, men det kan også i noen tilfeller være opp til 200. Dersom en fortsatt må sjekke hver eneste container har en ikke vunnet noe på det nye systemet. Hvordan plukke ut aktuelle containere? - det blir et viktig spørsmål å få svar på.

Et eksempel på hvordan en kan gjøre dette:

Container 1	Container 2
100 %	10 %
50 %	1 %
10 %	Dropper denne, tar første
1 %	containeren istedenfor

En teller antall tariffnummer per container, og får dermed en viss type utrekning av containere. Containere som inneholder varer som har 100% utrekning skal selvfølgelig kontrolleres uansett hvor stort varepartiet er, også varer med 50%. For containere med varer som har 1% utrekning, kan en vurdere om en vil stoppe containeren eller la den være. En må se på kostnadene ved å åpne en ny container. Inneholder containeren også andre varer som skal til kontroll kan det være grunn til å ta den ut, men er alle andre varer i containeren i orden kan en kanskje la varer med 1% utrekning gå forbi. Det bør likevel være en viss utrekning også for denne type containere for å hindre at det skal bli spekulering i å "skjule" dårligere produkt blant varer med god kvalitet.

Gruppering av langualkoder under tolltariffnummer

I handelsdokumentene som kommer via TVINN er alle varer tildelt et posisjonsnummer i tolltariffen. Formålet med tolletatens tildeling av tariffnummer er beregning av avgifter. Inndelingen er derfor forholdsvis grov (åttesifret kode), og ikke spesielt tilpasset næringsmiddeltilsynets behov. For å bøte på dette har næringsmiddeltilsynet tidligere forsøkt å innføre et eget kodeverk kalt SEDON. Dette kodeverket har ikke svart til forventningene - blant annet på grunn av for lav detaljeringsgrad og inkonsistens - og man har derfor sett etter nye løsninger. Valget har falt på langualsystemet for klassifisering av matvarer. Dette klassifiseringssystemet er relativt omfattende; det benytter mange dimensjoner, og det finnes mange nøkkelord langs hver dimensjon. I praksis brukes systemet ved at man oppgir populærbetegnelsen for de vanligste matvarene og får opp nøkkelordsekvensene ut fra dette (SNT 1995a).

Sett i forhold til tolltariffen er langualsystemet langt mer detaljert og dermed mer egnet til næringsmiddeltilsynets bruk. Så langt det er mulig vil det derfor være ønskelig å benytte LANGUAL-kode i intern kommunikasjon i ONT. Dette betyr blant annet at prøveresultater vil være relatert til LANGUAL-kode. Når vi utfører kontroll opp mot handelsdokumentene må vi imidlertid forholde oss til tolltariffen. Dette innebærer at det må lages et pekersystem fra LANGUAL-kode til tolltariffnummer.

I praksis vil en overgang til LANGUAL-kode for eksempel bety at vi med en 100% utrekningsfrekvens av et produkt oppgitt i LANGUAL-kode vil måtte stoppe alle produkter i samme tolltariffposisjon for identitetskontroll. Ved identitetskontrollen kan vi imidlertid forholde oss til LANGUAL-kode igjen slik at det bare er den aktuelle produkttypen som tas videre til fysisk kontroll. Dette innebærer en klar forbedring i forhold til dagens system.

Datautveksling med andre systemer i inn og utland

Det er interessant for ONT å utveksle informasjon med andre i samme bransje. Dette er spesielt viktig i forhold til oppbygning av en erfaringsdatabase. Per i dag er de fleste system som ONT kommuniserer med basert på fritekst, dette gjelder blant annet SHIFT, RAPEX og ANIMO, (se punkt 4). Dette gjør at utveksling av informasjon ikke er så enkelt. En må foreta en tolkning av materialet som kommer inn, og kan ikke bruke informasjonen direkte. Men dette er saker som det jobbes med, både i Norge og utlandet. En ønsker i så stor grad som mulig å standardisere for å lette utvekslingen av informasjon. Når det gjelder utveksling av dokument er EDIFACT- standarden inne i bildet. Med tanke på hvordan utviklingen vil bli innen dette området, bør ONT være åpen for å ta i bruk standarder som måtte komme. På sikt vil en kunne overlate mer til systemet, og dermed bli mindre personavhengig når det gjelder synsing. Om dette er et skritt i riktig retning eller ei, kommer an på hvordan en velger å bruke systemet.

Tekniske løsninger

Et dilemma er hvordan en skal få utnyttet ressursene både hos MIKLAS og CINET, uten å komme i konflikt. Det er en viktig diskusjon, samtidig er det vanskelig å ta opp valg av teknologi på et så tidlig tidspunkt. Det blir enklere når en vet hvilket system en ønsker, (se punkt 7).

Informasjonsflyt

Slik systemet fungerer i dag er det ikke noen særlig kommunikasjon mellom de ulike grensekontrollstasjonene. Dette ønsker en selvsagt å gjøre noe med, men det er ikke helt klart hvordan dette skal gjøres. En skiller på hva SNT trenger informasjon om, og hva de ulike kontrollstasjonene har behov for. Det viktigste er vel at kontrollstasjonene kommuniserer godt seg i mellom, samtidig som KNT rapporterer til SNT når det er noe spesielt som alle trenger å vite raskt og helst samtidig. En kan også diskutere hvor ofte en skal informere og hvordan dette skal skje. Skal en automatisere eller hente inn informasjon når en trenger det? SNT heller mot det siste, men det er noe som kan diskuteres etter som systemet kommer på plass, (se punkt 3.0)

Modellering av grensekontrollstasjonene

Det er i dag 15 grensekontrollstasjoner plassert rundt i landet. SNT er ikke helt fornøyd med organiseringen av disse. En ønsker et system der de forskjellige grensekontrollen har forskjellige oppgaver. For eksempel tre kontroller som tar i mot varer fra tredjeland (utenfor EU) og en som tar i mot kjøtt. Dersom avtale med EU går i orden skulle dette gå greit. Problemet er ikke-animalske varer, spesielt sukkertøy og helsekost. EU har ikke noe regelverk på dette området. KNT trenger ikke mye utstyr for å kontrollere sukkertøy, så dette er noe en lett kan foreta ved flere stasjoner. En ønsker helsekostvarer inn til et sted. Per i dag prøver en å sende helsekost varer til ulike mottak for å se hvor det går lettest gjennom. Dette er et problem i dag på grunn av lite utveksling av informasjon. Stasjoner som kontrollerer ikke-animalske produkter kan en kalle kompetansesenter, dette for ikke å komme i konflikt med eventuelt regelverk fra EU.

Kan en ha en "svarteliste" over aktører?

Dette har vi diskutert under punkt 8.0, og kommet frem til at det vanskelig kan gjøres uten å måtte søke datatilsynet om konsesjon.

Vareprøver

Kontroll av vareprøver krever store ressurser ved grensekontrollen. Det er vanskelig å vite om det dreier seg om en vareprøve eller et ekte parti. Hvordan få arbeidet med vareprøvene inn i systemet? SNT ønsker ikke å gi forhåndsgodkjenning.

Kommunikasjon med tolletaten

All kontakt med tolletaten foregår via telefon, faks og post, hvorfor er det ikke elektronisk kommunikasjon? Kunne for eksempel e-post gitt en mer effektiv utveksling av informasjon? Eller kanskje er SNT fornøyd slik systemet fungerer i dag?

Sortering - utrekning

Dette er begrep ONT opererer med i forhold til importkontrollsystemet. Vi har også brukt det i vår rapport. Det kan likevel diskuteres om begrepene er gode. Illustrerer de det ONT ønsker å uttrykke? Det tok litt tid før vi skjønte hva de egentlig betydde, men med litt tid så gikk det greit. Vi har ikke diskutert noe særlig om andre uttrykk kan være bedre. Et forslag er det likevel om systematisering og rangering istedenfor sortering og utrekning. For det er jo det vi egentlig gjør. Vi systematiserer varetyper som kommer inn til grensekontrollstasjonene og ut fra en rangeringsliste går de forskjellige produktene til utrekning.

IV Evaluering av eget arbeid

Gruppen består av 5 studenter, som tidligere har jobbet sammen i andre prosjekter, og som omgås nesten daglig i studiesituasjonen. Flere av medlemmene i gruppen er også sammen en del på fritiden.

Prosjektet skiller seg ut fra tidligere samarbeidsoppgaver. Dette er det første systemutviklingsprosjektet vi har deltatt sammen i. Tre av oss har tidligere, ved studier ved Institutt for Informatikk, deltatt i lignende prosjekter med andre studenter. En av oss, har også i et jobbforhold, utviklet en egen database. Et par studenter hadde ikke noe systemutviklingserfaring fra før, men disse viste seg å være en viktig ressurs i gruppen likevel. De satt seg raskt inn i metodene som ble valgt. Spørsmål fra disse om metoden, bidro til å bedre forståelsen for alle parter.

Ved starten av semesteret, ble vi gjort oppmerksomme på at det ville være en stor obligatorisk oppgave som del av faget FI 2-3. Det var en ulempe at oppgaven ble tilgjengelig så sent, noe som de ansvarlige beklaget. Vi angrep likevel oppgaven med en gang, og syntes den var spennende. Det var en del materiale som vi måtte sette oss inn i, både fra SNT og diverse lærebøker, for å friske opp kunnskapene om metoden. Fra starten på prosjektet, jobbet vi kontinuerlig og måtte benytte en del helger. Men vi følte at vi hadde progresjon i arbeidet, og fikk gjort en del før siste møte hos SNT 18 mai. Etter dette møtet ble det dessverre et opphold på et par uker, i forbindelse med andre eksamener og oppgave innlevering. Dette beklager vi, men det var nødvendig.

Vi delte gruppen inn etter forskjellige oppgaver som dukket opp underveis. Det ble også gjort en del på egenhånd. Vi valgte en kontaktperson utad til SNT, og en som ansvarlig for layouten av rapporten. Men ellers ble de andre rollene, som møteleder og referent, tatt på rundgang.

Ved valget av metoder og fremgangsmåter, var det få av oss, som hadde bakgrunn i de samme systemutviklingsmetodene. Det ble derfor en del diskusjoner før vi ble enig om, hvilken metode vi ville bruke. De situasjonene som kanskje var mest opphetet, var under datamodelleringen, som kanskje viser et sunnhetstegn i gruppen. Det som virker frustrerende, er at man ikke alltid kan dokumentere all jobb som ligger bak en slik modellering. Under modelleringen av registreringsbasen, ble det i tillegg også diskutert denne i forhold til erfaringsbasen. Denne siste basen fikk vi ikke fullt ut modellert. Vi føler derfor at tiden ikke strakk til, men at vi har lært mye.

En negativ side under arbeidet med datamodelleringen, var all den tiden vi brukte til å diskutere ren datamodelleringsteori. I stede for å være uenig om hvordan man ville løse dette riktig i den metoden vi valgte, burde vi heller lage en egen vri e.l.

En annen ting som tidsfaktoren begrenset oss i, var intervjuene og studiene av dagens situasjon. Det var også en del potensielle konflikter som vi ikke var kjent med. Vi måtte lage en database uten menneskelige faktorer, og som er ganske kunstig etter skandinavisk systemutviklingsteori. Vi måtte også ta med en del forutsetninger, og fikk i oppgave å lage det optimale systemet, uten tanke på fysiske eller økonomiske begrensninger.

Men en tidsperspektiv på ca 6 uker, hvor to uker gikk bort til andre fag, må vi si oss fornøyd. Dette var lærerikt og vi følte at det var så reelt som mulig. Vi fikk den støtte vi ønsket oss, og det meste av det materialet vi forespurte.

Om bruk av verktøy

I begynnelsen av arbeidet antok vi at vi skulle lage en prototyp av Importkontrollsystemet ved hjelp av tilgjengelig verktøy på Forvaltningsinformatisk laboratorium (FILAB). Dette medførte at vi brukte en del tid på å prøve ut verktøy, som viste seg vanskelig å bruke. Ideen var å bruke et modelleringsverktøy for å lage datamodeller, for deretter å generere SQL-kode til Personal Oracle 7 database (gratisprogramvare hentet via Internett) og endelig bruke Access som grensesnitt mot Oracle. Grunnen til dette var at det ville gi oss erfaring i å kombinere ulike programmer og se forholdet mellom dem i praksis. Dette viste seg noe problematisk.

Modelleringsverktøyet vi først hadde tilgjengelig var "The Information Base Modeling System" IBMS (gratisprogram hentet via Internett). Resultatet av modellene vi lagde fikk vi ikke generert til SQL-kode for Oracle. Vi fant ikke ut om dette var feil i Oracle eller IBMS. Vi antar at det kunne være begrensninger ved programmene som var gratisprogramvare. Dette medførte mye tidsspille på et produkt som vi altså ikke brukte. Vi prøvde deretter enkel bruk av MacNiam for å lage datamodeller. Her fikk vi heller ikke generert kode som Oracle ville godta.

Etter en stund ble modelleringsverktøyet "Modelator" tilgjengelig på FILAB og denne brukte vi mot Access for å prøve ulike datamodeller. I løpet av arbeidet ble datamodellen mindre og behovet for kraftige modellverktøy redusert. Det var et relativt komplekst "bilde av verden" vi skulle forstå for å lage et system for importkontrollen. Etter samtaler med SNT avgrenset vi oss fra å lage en prototyp for Importkontrollen. Det var viktigere å mene noe om forutsetningene for, og omgivelsene til, systemet enn å lage en prototyp. For å illustrere noe bruk av Importkontrollsystemet har vi imidlertid laget et tenkt skjermbilde ved hjelp av Access (jf. kap. 5).

For å sluttført arbeidet vårt har vi følgelig ikke brukt mange programmer. Vi har allikevel brukt mye tid på å vurdere og prøve forskjellige verktøy med utgangspunkt i at vi skulle lage en prototyp. Dette har vist oss at det er tidkrevende å finne passende verktøy. For vårt vedkommende ville det vært tidsbesparende å gjøre dette på et senere tidspunkt - når vi var sikre på om vi skulle lage en prototyp.

V Litteraturliste

Lov om personregistere m.m av 9. juni 1978 nr. 48. med forskrifter gitt av justisdepartementet 21.des.1979 og 10. mars 1981.

Lov om offisiell statistikk og Statistisk Sentralbyrå av 16. juni 1989, nr. 52

Mathiassen L, A. Munk-Madsen, P.A. Nielsen, J. Stage.(1993) Objektorientert Analyse, Marko: Aalborg

PC-World Norge (Ekspress).Netscape slår ut notes? Nr8. 1995 PC WORLD NORGES NYHETSBULLETIN (se side 1 og 14).

Schaefer, H (1986). Grunnleggende ideer om kvalitessikring under kravspesifikasjonsfasen. Senter for industriforskning.

Schartum, D.W. (1993). Rettssikkerhet og systemutvikling i offentlig forvaltning. Universitetsforlaget: Oslo

Skagestein, G (1991). Data i Fokus. Dataorientert systemutvikling i teori og praksis. Universitetforlaget: Oslo.

SNT (1993a).IT-strategi dokument for informasjonssystemer i det offentlige næringsmiddeltilsyn. Høringsutkast 22. mars 1993.

SNT (1993b).Kravspesifikasjon for saksbehandlings- og informasjonssystem i det offentlige næringsmiddeltilsyn. Høringsutkast 22. mars 1993.

SNT (1995a).Prinsipper for klassifisering og koder i det offentlige næringsmiddetilsyn. Forslag 20. februar 1995.

SNT (1995b). Saksliste for møte i prosjektgruppen "Tilsyn med næringsmidler som importeres" tirsdag 25.april.

Statskonsult (1991). Statens generelle kravspesifikasjon for edb-støttet saksbehandling og ledelse. Generelle krav til edb-støttet saksbehandling og ledelse. Dokument 1.

Toll- og avgiftsdirektoratet.(1993). Tolldeklarering, Innførsel. Veileder for tolldeklarering av varer ved innførsel. Utgitt av Toll- og avgiftsdirektoratet, februar 1993.