En viktig begrensning er at empiri knyttet til faktisk bruk av interorganisatoriske systemer basert på Åpen-edi referansemodellen ikke har vært tilgjengelig. Vurderingen og konklusjonene må derfor ses på med dette som utgangspunkt. Videre vil jeg presisere at vurderingen også bygger på de tillegg og konkretiseringer jeg har foretatt. De steder tillegg og konkretiseringer forårsaker problemer blir dette nevnt eksplisitt.
Målsettinger for Åpen-edi referansemodellen ble presentert i kapittel 1.1, og er som følger:
Ved å benytte Åpen-edi referansemodellen slipper EDI-aktørene å bruke bilaterale avtaler og den enkelte EDI-aktør trenger ikke selv analysere og designe scenariene.
Deler eller hele utøvelsen av en rolle kan delegeres. Dette er i prinsippet ikke noe nytt siden en allerede ved dagens bruk av EDI har kunnet outsource for eksempel faktureringstjeneste slik Tollpost-Globe har gjort. Det at Åpen-edi referansemodellen setter det i system, og tar det med som en del av den vanlige bruken er nytt, og det oppfatter jeg som en forbedring som gjør det lettere å ta i bruk EDI. Delegering av roller kan påvirke innføringshastigheten i positiv retning fordi, den enkelte EDI-aktør kan velge å bare implementere deler av en rolle, og dermed kan en slippe enklere unna problemer med tilpassing av interne rutiner og datasystemer.
Tilpasninger av rutiner og datasystemer må utføres. Hos både Tollpost-Globe og Forlagssentralen er EDI-løsningene tett integrert med resten av logistikksystemet. I [COST-320] undersøkelsen svarte 35% av respondentene som utvekslet over 1000 meldinger per måned at de introduserte nye logistikksystemer samtidig med innføringen av EDI.
Avhengig av omfanget av tilpasninger knyttet til interne rutiner og datasystemer, tror jeg det er mulig å hurtig ta i bruk interorganisatoriske systemer som baserer seg på Åpen-edi referansemodellen. En viktig forutsetningen er at det ikke er andre momenter i vurderingen som gjør at interorganisatoriske systemer som baserer seg på Åpen-edi ikke lar seg realisere.
Formelle scenariobeskrivelser og standard programvarebibliotek skal brukes som kilde for en Åpen-edi system generator som skal implementere interne interorganisatoriske systemer. Ved bruk av gode CASE-verktøy og utstrakt gjenbruk av standard programbiblioteker kan en kanskje redusere prisen noe, men jeg tror ikke vesentlig prisreduksjoner i forhold til dagens EDI-løsninger er mulig. Et viktig kostnadselement for den enkelte EDI-aktør er tilpassingen til interne rutiner og datasystemer.
Ansvaret for at virksomhetsmessig interoperabilitet blir ivaretatt er lagt til den brukergruppen som beskriver scenariene. Åpen-edi referansemodellen forholder seg til problemet kontekstavhengig bruk og presentasjon av data som om det er løst ved bruk av scenariobeskrivelsene. Dette tror jeg ikke er tilfelle. Både [Hanseth91] og [Gasser] mener at en ikke uten videre er sikret en felles forståelse av hva dataene står for, og hvordan de brukes. Det vil ikke være nok å se på datamodeller og attributtnavn, når en skal integrere informasjon fra forskjellige kilder; en må se på hvordan informasjonen faktisk brukes. Og selv om en vet dette vil en i følge [Hanseth91] ha problemer fordi hvordan informasjon brukes endres over tid. Jeg tror bruk av Åpen-edi referansemodellen fører oss i retning av mindre problemer knyttet til virksomhetsmessig interoperabilitet, men jeg tror ikke problemet vil forsvinne.
Scenariene er ment å være mest mulig generelle og globale. En ulempe vil være at dette kan lede til at de enkelte aktørene må tilpasse sin forretningspraksis til det som er mulig i henhold til begrensninger i scenariene. For å få en håndterlig funksjonalitetsmengde må en standardisere måten å drive forretningsvirksomhet på [Hørlück93]. Denne standardisering av forretningspraksis er kanskje eneste måten en kan greie å oppnå stor grad av virksomhetsmessig interoperabilitet på, men det er ikke i overensstemmelse med intensjonen til Åpen-edi referansemodellen. (Problemstillinger knyttet til dette punktet er tatt opp i 7.3.1.)
Ut fra problemområdene som er nevnt i dette avsnittet, tror jeg ikke det er mulig å oppnå teknologisk og virksomhetsmessig interoperabilitet.
Lover, regler og handelsavtaler.
Ved å benytte Åpen-edi referansemodellen
slipper EDI-aktørene å bruke bilaterale avtaler og den enkelte
EDI-aktør trenger ikke selv analysere de juridiske forhold. Den
jus som det er nødvendig å forholde seg til ligger beskrevet
i scenarioattributtene. Dette punktet mener jeg taler til fordel for Åpen-edi
referansemodellen. (Jus ble blant annet tatt opp i kapittel 7.2.4 og 7.5.)
Problemer ved innføringen av EDI.
Jeg har ingen empiri om innføringsproblemer å
støtte meg til, men jeg tror at kompleksiteten i løsningen
vil bli høyere enn i de fleste av dagens EDI-løsninger, og
dette tror jeg kan føre til problemer ved innføring. Behov
for ny kompetanse og tilpassing av interne rutiner og systemer taler for
at det fremdeles vil være problemer knyttet til innføring.
Disse problemene vil påvirke utbredelse i negativ retning. Kompleksitet
er vurdert som eget punkt under. De vanligste problemene ved innføring
av EDI, var ifølge respondentene i [COST-320] undersøkelsen:
tekniske problemer, oppgitt av 55%, og grensesnitt mellom EDI-løsningen
og internt system, oppgitt av 35%. Jeg har påpekt spesielt, i kapittel
7.3.1, at Åpen-edi referansemodellen ikke tar nok hensyn til problemer
knyttet til grensesnitt mellom EDI-løsningen og interne rutiner
og datasystemer.
Teknisk utstyr og datakommunikasjon.
Jeg tror tilgang på teknologi og teknologiske tjenester
kommer til å bli bedre og bedre, samtidig som prisen per enhet datakraft
og kommunikasjon vil gå ned. Implementering av interorganisatoriske
systemer som baserer seg på Åpen-edi vil i stor grad benytte
teknologi og teknologiske tjenester. Den generell IT-utviklingen ser ut
til å dekke opp for dette behovet, dette taler til fordel for utbredelse
av Åpen-edi referansemodellen.
Organisatorisk modenhet.
Jeg tror kompetansebehovet vil være stort for brukere
og driftspersonell. Dette er knyttet til kompleksitet, og at den enkelte
EDI-aktør foretar valg på et tidlig stadium om hvilke typer
forretningstransaksjoner han ønsker å delta i. EDI-aktøren
må ha forståelse for de organisatoriske og strategiske endringer
innføringen av et interorganisatorisk system som verktøy
for virksomheten kan gi, og ikke bare ha kompetanse på de teknologiske
områdene. Åpen-edi referansemodellen tillater å sette
bort deler av eller hele rolleutførelsen til andre enn den faktiske
EDI-aktør som er rolleansvarlig. Ved å delegere utførelsen
av roller vil krav til egen kompetanse blant annet når det gjelder
drifting og vedlikehold reduseres. (Kompetanse er tatt opp i kapittel 7.3)
Kompleksitet i et interorganisatorisk system.
Metrikker for kompleksitet ble satt opp i kapittel 4.7.
Disse gjelder for hele det interorganisatoriske systemet og er ikke knyttet
til en enkelt EDI-aktør. Jeg har vurdert kompleksiteten til et interorganisatorisk
system som baserer seg på Åpen-edi referansemodellen som følger:
De tre neste punktene er tett knyttet til hverandre og derfor velger jeg å slå sammen vurderingen av dem til en sammensatt vurdering. Disse tre punktene er igjen sterkt påvirket av kompleksiteten.
Redesign av scenarier og de teknologiske tjenestene blir ivaretatt uten at EDI-aktøren trenger være involvert i selve redesign prosessen. EDI-aktøren trenger bare forholde seg til redesign av sitt eget interne interorganisatoriske system. Hvis en programvareleverandør leverer nødvendig programvare til EDI-aktøren så er også versjonshåndtering av selve den programvaremessige delen av det interne interorganisatoriske systemet ivaretatt. De interne rutiner ol. må vel og merke tilpasses ved innføring av nye versjoner. Med den ansvarsfordeling som er skissert over ligger ikke ansvaret for interoperabilitet hos den enkelte EDI-aktør. For den enkelte EDI-aktør vil dette være en lettelse, men det er ikke sikkert at denne ansvarsfordelingen er ønskelig.
Alle typer forretningstransaksjoner skal kunne beskrives og implementeres ved bruk av Åpen-edi referansemodellen. Dette vil si at det ikke er en enkelt brukergruppe en ønsker å nå. Det er mulig dette vil føre til behov for samme kritikk som EDIFACT har fått i [UN-Rapport]. Denne kritikken er diskutert i kapittel to, og går i hovedsak ut på følgende (kritikken er knyttet til EDIFACT):
Administrasjon og koordinering av interorganisatoriske
systemer.
Ved bruk av dagens EDI så har erfaring vist at
det er nødvendig med en styringsstruktur for å designe og
oppnå utbredelse av interorganisatoriske systemer. Når det
gjelder Åpen-edi referansemodellen er det litt usikkert om behovet
er tilsvarende. Jeg tror bruk av standard scenariobeskrivelser vil kunne
føre til at koordineringsbehovet blir vesentlig mindre. Koordineringsbehovet
har i stor grad vært knyttet til utvikling av implementasjonsguider,
valg av teknisk infrastruktur, og avtaleverk. Mye av disse tre elementene
er inkludert i scenariene og standard teknologiske tjenester. Den enkelte
EDI-aktør må velge hvilke roller m.m. han ønsker å
kunne utøve, resten av koordineringen skal være ivaretatt.
For å oppnå utbredelse må noen markedsføre Åpen-edi referansemodellen. Dette har vært en av de viktige oppgavene knyttet til utøver av administrasjon og koordinering. Siden koordineringsbehovet er blitt mindre tror jeg det vil virke positivt inn på utbredelse. Det at det per i dag ikke er definert en markedsføringsmekanisme som skal sørge for utbredelse synes jeg ikke skal veie tungt. Dette er en oppgave som relativt lett kan aktiviseres på et seinere tidspunkt. (Administrasjon av design ble behandlet i 7.2 og utbredelse i 8.3.1.)
Jeg tror at det svakeste punktet ved referansemodellen er forutsetningen om å kunne foreta en automatisk generering av et internt interorganisatorisk system, med utgangspunkt i formelle beskrivelser av scenarier. Jeg tror deler av et scenario kan genereres med utgangspunkt i formelle beskrivelser, men for eksempel tilpasninger til den enkelte EDI-aktørs interne forretningspraksis, i form av andre datasystemer og rutiner, tror jeg ikke vil kunne gjøres automatisk. Videre tror jeg at virksomhetsmessig interoperabilitet, spesielt knyttet til kontekstavhengig bruk og presentasjon av data, ikke lar seg løse ved bruk av generiske scenariobeskrivelser og standard teknologiske tjenester.
Utviklingen av standardiserte scenarier vil komme til å foregå relativt langt fra de som blir de potensielle brukerne. Brukernes individuelle forretningspraksis vil ikke kunne bli tatt tilstrekkelig tatt hensyn til, og skreddersøm av scenarier vil ikke være mulig innenfor retningslinjene i referansemodellen. En bør ha klart for seg hvilken målgruppe scenariene utvikles for. Siden et mangfold av forretningspraksiser skal fungere sammen i et interorganisatorisk system, tror jeg det blir vanskelig å lage generelle scenarier som dekker alle forretningspraksiser. I følge [Cavaye] og [Hørlück95] er brukermedvirkning ved utvikling av interorganisatoriske systemer sentralt for å oppnå utbredelse. Manglende brukermedvirkning tilsvarer noe av den kritikken som utviklingen av EDIFACT-standarden er blitt utsatt for i [UN-Rapport].
EDI-aktørene må ikke på samme måte som før gjennom prosessen med å forstå den jus som er knyttet til bruk av interorganisatoriske systemer, fordi scenarioattributtene som beskriver jus er analyser og modellert av en brukergruppe. Jeg tror det er viktig at den jus som et interorganisatorisk system bygger på er synlig for brukeren, og brukeren må ha kompetanse om hvordan hans valg ved bruk er knyttet til jus.
Ved bruk av Åpen-edi referansemodellen og tilhørende tjenester, vil alle EDI-aktører være mulig å finne i rolle repository. Dette oppfatter jeg som en klar fordel. Videre skal en kunne søke etter mulige handelspartnere ut fra hvilken rolle en ønsker at de skal fylle i utøvelsen av et scenario.
Redesign av scenarier og de teknologiske tjenestene blir ivaretatt uten at EDI-aktøren trenger være involvert i selve redesign prosessen. EDI-aktøren må bare sørge for at hans eget interne interorganisatoriske system håndterer en versjon som gjør han attraktiv som handelspartner. Hvis en programvareleverandør leverer nødvendig programvare til EDI-aktøren så er også versjonshåndtering av selve den programvaremessige delen av det interne interorganisatoriske systemet løst. De interne rutiner ol. må vel og merke tilpasses ved nye versjoner. Denne oppgavefordelingen mellom utvikler og bruker av programvare er ikke ny, selv om dimensjonene er litt annerledes. Staubo Elektro-maskin benytter programvare levert av Tollpost-Globe. Tollpost-Globe står for utvikling og versjonshåndtering. Sett fra Staubo Elektro-maskin blir all versjonshåndtering bortsett fra de interne rutinene håndtert av Tollpost-Globe. Jeg tror at for de fleste EDI-aktører vil dette være en forenkling, men en må være villig til å tilpasse interne rutiner til de nye versjonene av det interorganisatoriske systemet.
Et problem knyttet til syntese er at det kan oppstå behov for scenarioattributter ved sammensetting av rollemodeller som det ikke var behov for i de enkelte basis rollemodellene. Dette er et problem som er knyttet til den metode jeg har valgt. Hvis dette problemet skal unngås, tror jeg en må lage scenarier som ikke baserer seg på en metode hvor mindre scenarier blir satt sammen til et større. En stor ulempe med ikke å bruke tilsvarende metode som det jeg har brukt er at en må utvikle flere scenarier, hvor en enkelt EDI-aktør bare kan utøve roller fra et scenario. Hvis en EDI-aktør utøver roller fra to scenarier, har man tilsvarende problem med scenarioattributter som det jeg fikk i min metode. I henhold til Åpen-edi referansemodellen skal en EDI-aktør kunne utøve flere roller, jeg tror derfor en må prøve å finne løsninger på problemet med nye scenarioattributter, og ikke avvise fremgangsmåten med sammensetting av rollemodeller.
Når det gjelder utbredelse så er jeg usikker på om alle potensielle EDI-aktører er interessert i å benytte åpne standarder. Det kan være mange grunner for å ikke være deltaker i et åpent marked. Tollpost-Globe oppfatter sin tette kundebinding som en stor fordel, og blant annet av den grunn bruker de fremdeles proprietære formater.
Første mål: Det skal hurtig og kostnadseffektivt la seg gjøre å ta i bruk interorganisatoriske systemer som baserer seg på Åpen-edi referansemodellen. Avhengig av omfanget av tilpasninger knyttet til interne rutiner og datasystemer, tror jeg det er mulig å hurtig innføre interorganisatoriske systemer som baserer seg på Åpen-edi referansemodellen. En viktig forutsetningen er at det ikke er andre momenter som gjør at Åpen-edi ikke lar seg realisere. Mitt bakgrunnsmaterialet for å kunne komme med konkrete kostnadsestimater er ikke tilstrekkelig, men jeg tror prisnivået blir omtrent som prisene på dagens EDI-løsninger.
Andre mål: Åpen-edi referansemodellen skal sikre at interorganisatoriske systemer som baserer seg på internasjonale standarder skal kunne spille sammen både teknologisk og virksomhetsmessig. Ut fra understående problemområder, tror jeg ikke det er mulig å oppnå teknologisk og virksomhetsmessig interoperabilitet.
Jeg tror bruk av referansemodellen vil resultere i faktorer som påvirker utbredelse i både positiv og negativ retning, men jeg tror det er for mange sentrale negative faktorer til at stor utbredelse vil være mulig å oppnå.
Positive faktorer:
Jeg tror at andre og tredje mål ikke vil være mulig å nå, og at forutsetningen om automatisk generering av interne interorganisatoriske systemer ikke er mulig å realisere på en hensiktsmessig måte. Denne konklusjonen er i overensstemmelse med blant annet følgende referanser: [Hanseth91] og [Gasser] mener at en ikke uten videre er sikret at forskjellige brukere har en felles forståelse av hva data står for, og hvordan de brukes. EDI standarder har blitt utviklet for å ivareta mangfoldet av forretningspraksiser, dette leder videre til problemstillingen om hvordan bruk av EDI vil standardisere forretningsprosesser [Hørlück93]. Utbredelse av informasjonsinfrastrukturer påvirkes av; kompleksiteten i aktør-nettverket, utbredelse krever kontinuerlig redesign og mengden av eksisterende brukere konserverer informasjonsinfrastrukturen og bremser for redesign [Hanseth95].
Det er i forbindelse med Åpen-edi referansemodellen tidligere laget noen eksempler på bruk av formelle beskrivelsesteknikker, disse eksemplene inngår som dokumenter til SC30 arbeidet. Ingen av disse eksemplene har satt utarbeidelsen av formelle scenariobeskrivelse inn i tilsvarende sammenheng som det jeg har gjort i denne oppgaven, med først å skissere en systemutviklingsmetode for deretter å foreta en simulering av bruk. Diskusjon av systemutviklingsmetode og simulering av bruk opp mot andre kilder, er ikke blitt gjort tidligere. Videre vil jeg spesielt nevne at tilvalgsmodellen for design av informasjonspakker er ny, og at det ikke tidligere er benyttet en objektorientert formell beskrivelsesteknikk for å beskrive scenarier.
Anbefaling
Problemdomenet som Åpen-edi referansemodellen er
ment å løse, har trolig ikke én fasitløsning.
Jeg oppfatter Åpen-edi referansemodellen å være ambisiøs
i sitt krav om virksomhetsmessig og teknologisk interoperabilitet. Utviklingen
av Åpen-edi referansemodellen oppfatter jeg som en top-down prosess
hvor en tar for seg de overordnede problemer og forsøker å
modellere disse.
Jeg tror behovet for å kunne samhandle elektronisk vil kreve en form for standarder for teknologisk og virksomhetsmessig interoperabilitet. Så lenge utgangspunktet for å drive forretningsvirksomhet er at forskjellige virksomheter må forholde seg til forskjellig lovverk, og at forretningspraksiser varierer, er det vanskelig å lage en global standard. Jeg tror ikke at alle målene til referansemodellen er mulig å nå, men allikevel vil jeg anbefale at arbeidet med Åpen-edi referansemodellen fortsetter, men fokus må endres til å være pragmatisk. I første omgang bør en se om deler av Åpen-edi referansemodellen er mulig å realisere isolert.
Med utgangspunkt i de problemer og erfaringer som jeg har gjort i denne oppgaven ville det være av stor interesse å ta tak i følgende temaer: