8 Transportscenario

I dette kapitlet vil jeg beskrive et enkelt scenario for transport, basert på den systemutviklingsmetode som ble skissert i forrige kapittel. Jeg vil forholde meg til de tre fasene: analyse og design, implementering og bruk. Hensikten med kapittelet er å simulere bruk av systemutviklingsmetoden for å få et best mulig grunnlag for å kunne vurdere Åpen-edi referansemodellen i kapittel ni. Denne simuleringen vil bety at jeg utfører analyse og designaktivitene som i henhold til kapittel fem og sju skulle vært utført av en brukergruppe. Fjerde delmål var å vurdering om bruk av Åpen-edi referansemodellen fører til nye problemer eller hindringer, denne vurderingen gjøres i hovedsak på bakgrunn av dette kapitlet. Selve vurderingen av delmålet gjøres i 9.4.

8.1 Analyse og design av et scenario for internasjonal transport

Dette avsnittet beskriver roller og informasjonspakker. Hvilke roller som benytter hvilke informasjonspakker er beskrevet ved hjelp av rollemodeller. Videre vil tilstandsoversikter bli benyttet for å beskrive en del av de rollene som identifiseres. Jeg vil begynne dette avsnittet med å skissere kort hvilke type virksomheter som er involvert og hvordan informasjonsflyten er i dagens forretningspraksis.

8.1.1 Beskrivelse av dagens situasjon

Systemutviklingsmetoden forutsetter at en brukergruppe med nødvendig erfaring og kompetanse nedsettes for å for utvikle et scenario for transportsektoren. For å få forståelse for hvordan internasjonal transport foregår per idag har jeg brukt de empiriske undersøkelsene og [COST-320] undersøkelsen. Dette har resultert i en kort beskrivelse av dagens situasjon som følger under. Scenariet vil beskrive selve vareflyten som skjer ved import/ eksport av varer. Beskrivelsen vil være uavhengig av den faktiske transportform. Transport er et omfattende område og det eksisterer mange former for spesialtransport som atomavfall, olje, eksplosiver, medikamenter, levende dyr m.m. Jeg kommer ikke til å gå inn på spesialtransport i denne beskrivelsen. Scenariet er ment som et enkelt eksempel for lett håndterlige varer, og ikke som en komplett oversikt over alle varianter og håndtering av spesialgods.

Følgende typer virksomheter er tatt med: Avsender av gods, mottaker av gods, transportør og de involverte terminaler som alle har fysisk kontakt med varen. Speditører er også med. Det er de som ordner med dokumentasjon og organiserer transporten. I tillegg opptrer de ofte som agent for andre speditører og transportører. Fortollingsspeditøren ordner med nødvendige papirer fra Tollvesenet for deklarering av gods for import/eksport. Bank håndterer betalingsformidling mellom virksomhetene.

Figur 24

Figur 24 er hentet fra [COST-320] og er et eksempel på et enkelt internasjonalt transportscenario.

Navn på de forskjellige informasjonspakkene som utveksles:
 
1. Ordre/handelsfaktura 10. Bill of lading (konnossement, kvittering fra skipsfører for at han har mottatt varer som han forplikter seg å levere på et gitt sted.)
2. Booking opplysninger/Transport instruksjon 11. Manifest, offentlig erklæring
3. Faktura 12. Lasteplan
4. Remburs / betaling av varer mot skipingsdokumenter 13. Generell deklarasjon, lossetillatelse
5. Fraktbrev 14. Losseinstruksjon
6. Ankomstmelding 15. Ankomstmelding
7. Eksportdeklarsjon 16. Importdeklarasjon
8. Ankomstmelding 17. Betaling for varer (og transport)
9. Lasteinstruksjon  
Avsender utveksler informasjon med tre aktører; bank, speditør og mottaker av varen. For avsender ser Figur 24 unødig kompleks ut. Sett fra avsender av varen ville det kunne være interessant å se om det er mulig å redusere kompleksiteten i Figur 24. En forenkling av scenariet ville kunne vært å innkapsle speditør, transportør, fortollingsspeditør og agent som en aktør. Og ved behov dekomponere denne aktøren. Et viktig poeng ved en objektorientert angrepsmåte er at hver aktør har sitt ansvarsområde, og derfor trenger de enkelte aktørene bare kjenne til de aktørene de utveksler informasjonspakker med. Ved bruk av Åpen-edi referansemodellen er det brukergruppen som beskriver et scenario som er ansvarlig for at virksomhetsmessig interoperabilitet er ivaretatt.

I det videre arbeidet tar jeg tak i følgende typer virksomheter hentet fra Figur 24: Avsender av gods, mottaker av gods, transportør og tollvesen. I tillegg introduserer jeg en tjenesteyter som leverer geografisk informasjon til bruk ved utførelse av transportoppdrag. Jeg kommer i det videre til å foreta den forenklingen som er nevnt over, og ser på rollen transportør som en allerede sammensatt rolle. Den består av speditør, transportør, fortollingsspeditør og agent.

8.1.2 En enkel rollemodell for transport

En forenklet rollemodell for transport vil kunne bestå av de tre følgende rollene: Rollemodellen som er vist under vil være en typisk basis rollemodell ved transport.
 

 Figur 25
Jeg forutsetter her at det er avsender som sender transportinstruksjonen, og at det er avsender som skal ha fakturaen for frakt av transportør.

Vareflyten vil være som følger: Transportør henter varen hos avsender og befrakter varen selv, eller får varen fraktet helt frem til mottaker av andre.

En egen rollemodell for å forhandle seg frem til pris og leveringstidspunkt på frakt vil være av interesse. Denne rollemodellen ville vært aktuelt å benytte før en sender transportinstruksjon. Transportinstruksjonen skal sendes til den transportøren som er valgt, og derfor må det ha foregått noe aktivitet på forhånd. Jeg ser for meg at det kan lages en generell rollemodell for anbudsforespørsel og anbud. I praksis tror jeg det vil være lite hensiktsmessig å utføre denne anbudsrunden for hvert eneste transportoppdrag, derfor velger jeg å ikke beskrive den her.

8.1.3 Betalingstjenester i forbindelse med transport

Denne rollemodellen skal håndtere generell betalingsformidling. Det er i flere sammenhenger behov for betalingstjenester i forbindelse med transport. Noen av EDI-aktørene som vil kunne ha behov for betalingsformidling er som følger: Følgende rollemodell er en generalisert modell for enkel betalingshåndtering:

Figur 26

Figur 26 er vesentlig forenklet sett ut fra betalingsformidlers rolle, spesielt hvis det gjelder betalingstransaksjon på tvers av landegrenser. Det vil være behov for en mer detaljert rollemodell, men det er ikke nødvendig sett fra ut fra et transportfokus. For et transportscenario er denne kompleksiteten innkapslet.

8.1.4. Fortolling av varer

En viktig del av et internasjonalt transportscenario vil være håndteringen av dokumenter for tolldeklarering. I forbindelse med fortolling er det vanlig å benytte en fortollingsspeditør til å ta seg av dialogen med tollmyndighetene. Følgende roller og informasjonsflyt er nødvendig for å kunne foreta enkel fortolling:

Figur 27

Import og eksport håndteres forskjellig. Forskjellene ville komme tydelig frem hvis en analyserte behovene grundigere, og tok med behovene for alle land. Et viktig poeng her er at det i Norge kun er en lovlig rolleutøver av rollen tollvesen, mens det er mange som kan drive som fortollingsspeditører. For rollen tollvesen er det altså gitt hvem som skal utøve rollen.

Et eksempel på eksisterende EDI basert tolldeklareringssystem er TVINN. TVINN er det norske Toll og avgiftsdirektoratets EDI- tolldeklareringssystem, og dette scenariet for fortolling har faktisk vært i drift i Norge siden slutten av 80-tallet. Det er per våren 1996 ca. 900 næringslivsbrukere som utveksler deklarasjoner med TVINN systemet, og systemet håndterer ca. 4.4 millioner innkomne deklarasjoner på årsbasis (96 tall). De deklarasjoner som ikke behandles automatisk, ca 10 % av det totale antallet, vil generere to deklarasjonssvar: et for å informere om at deklarasjonen er gått til manuell kontroll og et for selve svaret. Derfor vil antall deklarasjonssvar være litt i underkant av 5 millioner. De 900 næringslivsbrukerne opererer på vegne av 20-25 tusen vareeiere, og det er vareeierne som får tilsendt faktura for toll og avgifter. Utsendelse av fakturaen er per idag papirbasert. Totalt flyter det altså ca 9.4 millioner tolldokumenter inn og ut av TVINN. Disse er fordelt på 900 kontaktpunkter, som igjen representerer 20-25 tusen virksomheter.

8.1.5 Integrasjon av geografisk informasjon i et transport scenario

Ny teknologi og tilgang på ny informasjon gjør at det er mulig å få beskrivelser av forskjellige transportveier. Leverandører av informasjon kan gi informasjon om den optimale transportruten for en gitt transportform på en gitt dag, avhengig av varierende betingelser. Jeg vil derfor lage en rollemodell som gjør det mulig å benytte geografisk informasjon i forbindelse med transport.

Det arbeides internasjonalt med standardisering for geografisk informasjon. Spesielt ved langtransport vil det være av stor interesse å kunne velge reiserute på basis av et informasjonssystem som tilbyr oppdatert informasjon om komplikasjoner og alternative transportveier. Geografisk informasjon knyttet sammen med oppdatert informasjon om eventuelle hindringer langs de alternative veivalg vil kunne bli en interessant del av et transportscenario. Flere transportører opererer med leveringsgaranti. Dette betyr at hvis varen kommer frem senere enn et gitt tidspunkt, så er transporten gratis. For disse transportørene vil informasjon om hindringer som uvær, stengte veier, streiker, endring i fergeforbindelser oa. være av stor interesse for å kunne levere en vare på rett sted til rett tid.

Figur 28
Figur 28 viser roller og informasjonsutveksling i en rollemodell for kjøp av geografisk informasjon

En utvidelse av denne rollemodellen vil være å ta med fakturering og betalingsformidling. Betalingsformidling er allerede laget som egen rollemodell, så det vil være nok å legge til en faktura som krav for overført informasjon fra informasjonsdistributør til informasjonskjøper. Videre kunne en sette sammen rollemodellen for betalinsformidling og geografisk informasjon, og utvidelsen ville vært utført.

8.1.6 Tilstandsoversikter

Jeg har valgt å ikke introdusere nye notasjoner knyttet til tilstandsdiagrammer. Jeg har isteden valgt å beskrive hendelser og tilstander i strukturert prosa, i form av en tabell. Jeg vil her beskrive tilstandene for rollene i rollemodellen for transport, og i rollemodellen for betalingsformidling.

 Tilstandsoversikt for rollen avsender i rollemodellen for transport
Hendelse Tilstand ved start Utfør Tilstand ved slutt
Mottar stimuli om behov for transport Initial Send transportinstruksjon Transportinstruksjon er sendt
Mottar faktura for frakt Transportinstruksjon er sendt Behandle mottatt faktura Faktura for frakt mottatt
Sender faktura for varen Transportinstruksjon er sendt Lag og send faktura for varen Faktura for varen er sendt
Sender faktura for varen Faktura for frakt mottatt Lag og send faktura for varen Ferdig
Mottar faktura for frakt Faktura for varen er sendt Behandle faktura Ferdig
Tilstandsoversikt for rollen mottaker i rollemodellen for transport
Hendelse Tilstand ved start Utfør Tilstand ved slutt
Mottar faktura for varen Initial Intern behandling Ferdig
Tilstandsoversikt for rollen transportør i rollemodellen for transport
Hendelse Tilstand ved start Utfør Tilstand ved slutt
Mottar transportbestilling Initial Intern behandling Har mottatt transportbestilling
Foreta fakturering Har mottatt transportbestilling Lag og send faktura Ferdig
Tilstandsoversikt for rollen betaler i rollemodellen betalingsformidling
Hendelse Tilstand ved start Utfør Tilstand ved slutt
Mottar stimuli om å utføre et betalingsoppdrag Initial Send betalingsoppdrag til bank Har sendt betalingsoppdrag
Mottar kvittering for betalingsoppdrag Har sendt betalingsoppdrag Intern behandling av betalingsoppdraget Ferdig
Tilstandsoversikt for rollen betalingsmottaker i rollemodellen betalingsformidling
Hendelse Tilstand ved start Utfør Tilstand ved slutt
Mottar betalingsanvisning Initial Intern behandling Ferdig
Tilstandsoversikt for rollen betalingsformidler i rollemodellen betalingsformidling
Hendelse Tilstand ved start Utfør Tilstand ved slutt
Mottar betalingsoppdrag Initial Intern behandling Har mottatt betalingsoppdrag
Send betalingsanvisning Har mottatt betalingsoppdrag Lag og send betalingsanvisning Har sendt betalingsanvisning
Send betalingskvittering Har sendt betalingsanvisning Lag og send betalingskvittering Ferdig
 Ved sammensetting av tilstandsoversikter kan det oppstå en del problemer. Noen av dem er som følger:

Selve sammensetting av tilstandsoversikter gjøres i forbindelse med implementering av det interne interorganisatoriske systemet.

8.1.7 Informasjonspakker

Identifiseringen av de aktuelle informasjonspakkene ble foretatt samtidig som rollemodellen ble beskrevet. Informasjonspakkene er en sentral del av rollemodellene. Og det er naturlig å beskrive roller og samspillet mellom rollene samtidig som en identifiserer informasjonspakkene. Den detaljerte beskrivelsen av informasjonspakkene vil foregå ut fra strukturen for informasjonspakker som er beskrevet i forrige kapittel.

For å kunne svare på de spørsmål jeg ønsker å besvare i oppgaven trenger jeg ikke her å gå i detalj når det gjelder innholdet i informasjonspakkene. Dette fordi strukturen som allerede er beskrevet er viktigere enn konkrete attributter og syntaks. Problemområder som kontekstavhengighet ved bruk av data, mulighet for usymmetrisk koding og dekoding m.m. vil gjelde uavhengig av konkret innhold i informasjonspakker.

8.1.8 Scenarioattributter

Scenarioattributtene vil i henhold til [DIS] være knyttet til den enkelte rollemodell. Eksempler på scenarioattributter er: Et problem knyttet til syntese er at ved sammensetting av rollemodeller kan det oppstå behov for scenarioattributter som det ikke var behov for i de enkelte basis rollemodellene. En kan tenke seg at rollen tollvesen ikke skal kunne settes sammen med rollene betalingsformidler eller transportør. Denne restriksjonen lar seg ikke uttrykke i dagens beskrivelsesstruktur fordi scenarioattributtene gjelder kun innenfor de enkelte rollemodellene. Det er ikke laget scenarioattributter som gjelder for de situasjoner som oppstår når en setter sammen rollemodeller. Dette kan bli et problem ved bruk av syntese.

8.2 Implementering av interorganisatoriske systemer


Den enkelte EDI-aktør kan i denne fasen sette sammen roller fra forskjellige rollemodeller til en sammensatt rolle. Fasen består av tre sentrale aktiviteter, og disse aktivitetene er beskrevet mer tførlig i kapittel sju.
  1. Programvareleverandører lager programvarebibliotek som kan benyttes av en Åpen-edi systemgenerator. -- Jeg forutsetter at en eller flere leverandører har utviklet de programvarebibliotek som er nødvendig for å kunne implementere et transport scenario.
  2. En EDI-aktør velger hvilke roller og på hvilken måte han skal utøve disse rollene -- EDI-aktøren former ved disse valgene sitt interne interorganisatoriske system
  3. EDI-aktøren velger en programvareleverandør. En Åpen-edi systemgenerator levert av en programvareleverandør genererer et internt interorganisatorisk system på basis av leverandørens programvarebibliotek og EDI-aktørens valg fra punktet over.
Ved å sette sammen rollemodellene for transport, betalingstjenester, fortolling og geografisk informasjon vil vi kunne lage en sammensatt rollemodell som vist i Figur 29. De enkelte rollemodellen for betalingstjenester, fortolling og geografisk informasjon er avgrenset med stiplede rektangler. De rollene som fremkommer Figur 29 er eksempler på hva en EDI-aktør kan velge at sitt interne interorganisatoriske system skal dekke av funksjonalitet.

Figur 29

I denne sammensatte rollemodellen er informasjonspakkene fra basis rollemodellen for transport merket med * og fet skrift.

I Figur 29 benyttes rollemodellen for betaling to ganger for å utføre betalingsformidling med to forskjellige sett EDI-aktører. Avsender av gods mottar en faktura for frakt og initialiserer da et scenario basert på rollemodellen for betaling. Tilsvarende skjer når faktura for vare blir sendt til mottaker av vare, mottakeren initialiserer et scenario basert på rollemodellen for betaling. Dermed er scenariet aktivt igjen, men i en ny instans og med nye EDI-aktører som utøver de forskjellige rollene.

Det er viktig å huske at tilstandsoversiktene til de sammensatte rollene som er vist i Figur 29 vil ved bruk av automatisk generering bli til et kartesisk produkt. For rollen avsender vil det gi følgende regnestykke (produktet av antall tilstander de forskjellige rollene den sammensatte rollen består av) :

Hvis utvekslingen av informasjonspakker gjøres i den rekkefølgen som Figur 29 viser, ville en fått følgende regnestykke (summen av antall tilstander de forskjellige rollene den sammensatte rollen består av): Åpen-edi referansemodellen tillater å sette bort deler av eller hele rolleutførelsen til andre enn den faktiske EDI-aktør som er rolleansvarlig. En kan se for seg muligheten for å sette bort hele problemområdet med implementasjon, drifting og versjonshåndtering av programvare til en tjenestetilbyder. De enkelte små og mellomstore bedrifter kan da for eksempel benytte en standard internett-browser for å nå sine applikasjoner som ligger på en server hos en tjenestetilbyder. Denne tjenestetilbyderen har tilrettelagt for å drifte interne interorganisatoriske systemer for flere små og mellomstore bedrifter. Konkret i et transportscenario vil en transportør kunne sette opp en slik internett-tjeneste og tillate at små og mellomstore bedrifter kobler seg opp over Internett og gjennomfører en påloggingsprosedyre før de får tilgang til egne data hos tjenestetilbyderen.

Posten lettgods driver for tiden og utvikler et WEB-grensesnitt (World Wide Web) til sine logistikkløsninger. Dette vil være en enklere variant enn det som er skissert over, men dreiningen går i samme retning. Transportøren gjør nødvendig programvare tilgjengelig for kunden ved hjelp av standard infrastruktur. Ansvar for drift, vedlikehold og versjonshåndtering ligger hos leverandøren. Kunden trenger kun programvare for å få presentert applikasjonens brukergrensesnitt.

8.3 Det interorganisatoriske systemet tas i bruk

Dette avsnittet vil være en gjentakelse av avsnitt 7.4, siden jeg hverken har installasjoner eller prototyper å vise til.

8.3.1 Diskusjon

Jeg har foreløpig ikke diskutert hvem som skal informere om og markedsføre Åpen-edi referansemodellen, slik at det blir mange nok EDI-aktører i det åpne markedet til at det er interessant å være deltaker. Det er i [DIS] ikke skissert hvordan dette skal foregå. Det kan se ut som om EDI-aktørene og leverandørene selv må benytte markedskreftene til å få andre til å ta i bruk Åpen-edi referansemodellen. Store offentlige aktører vil kunne bli pålagt å benytte Åpen-edi referansemodellen for informasjonsutveksling, dette kan føre til stor utbredelse.

En instansisert rolle kjenner kun de rollene som den utveksler informasjonspakker med. Den som utvikler det interne interorganisatoriske systemet bør ha oversikt over alle rollene i den sammensatte rollemodellen. Avhengig av bruksområde vil det muligens oppstå behov for en form for sertifisering av de interne interorganisatoriske systemene, og/ eller leverandørene av systemene. Det vil være mye jus som blir nedfelt i datasystemer og formelle beskrivelser, og disse bør kvalitetssikres på et eller annet vis.

8.4 Oppsummering

Jeg har i dette kapittelet vist hvordan Åpen-edi referansemodellen og OOram kan brukes til å beskrive scenarier. Jeg har diskutert problemer og løsninger i de forskjellige fasene som ble beskrevet i forrige kapittel.

Scenarioattributter er knyttet til den enkelte rollemodell. Dette fører til at sammensatte rollemodeller ikke har noen restriksjoner på hvem som kan utøve roller fra forskjellige rollemodeller. En kan tenke seg at rollen tollvesen ikke skal kunne settes sammen med rollene betalingsformidler eller transportør. Denne restriksjonen lar seg ikke uttrykke i dagens beskrivelsesstruktur. En kan imidlertid se for seg at utøver av rollen tollvesen har behov for transport, og ønsker å kunne utøve rollene avsender og mottaker av varer. Dette vil være fullt tillatt.

Den utøvende rollen vil være det eksterne grensesnittet for det interne interorganisatoriske systemet. Dette fører til at håndhevelsen av scenarioattributter, og forretningslogikk knyttet til utveksling av informasjonspakker, må ligge i den implementerte rollen. Dette kan være grunnlag for å vurdere om scenarier skal beskrives ved hjelp av roller, informasjonspakker og scenarioattributter som tre likestilte begreper, eller om en skal vurdere andre muligheter som løser de problemene som er diskutert over.

Tilbake til innholdsfortegnelsen