Sammanfattning

Examensarbetet har i huvudsak utförts hos Telia Promotor i Göteborg. Vissa praktiska moment har utförts hos SysTeam Applications i Huskvarna. Syftet med examensarbetet var att utvärdera de principer som finns för säker koppling mellan ett affärssystem och Internet, samt att undersöka de affärsmässiga möjligheterna som sådana kopplingar kan erbjuda.

De principer för koppling mellan affärssystem och Internet som redovisas är Remote Data Access, Remote Function Access och Remote Presentation Access. En av dessa principer, Remote Presentation Access har implementerats, i och med att SysTeam Applications affärssystem JD Edwards WorldSoftware kopplades till Internet. De produkter som användes för att åstadkomma detta var IBM Host On-Demand och Advanced Transition Technologies ResQ!net.

Ett flertal metoder för att realisera säker kommunikation över Internet redovisas bl.a. kryptering och tunnling. I implementationen ovan användes en produkt som heter TeamWare Intranet Security Server. Denna skapar en säker kanal i form av en tunnel mellan en användare på Internet och WorldSoftWare.

Arbetet är utfört av

Patrick Werner

Patrick.N.Werner@telia.se

Telia Promotor AB

Lilla Bommen 1

411 04 Göteboeg

tel arb : 031-7712422

tel : mobil 0706-652323

Abstract

The master thesis work has mainly been carried out at Telia Promotor in Gothenburg. Some of the practical parts have been carried out at SysTeam Applications in Huskvarna. The purpose of this thesis work has been to evaluate the principles available for constructing secure connections between corporate systems and the Internet, and to explore the business opportunities such connections can provide.

The principles for connecting corporate systems and the Internet that are presented are Remote Data Access, Remote Function Access and Remote Presentation Access. One of these principles was practically evaluated, thus SysTeam Applications corporate system JD Edwards WorldSoftware was connected to the Internet. The principal then used was Remote Presentation Access. The products used for this implementation were IBM Host On-Demand and Advanced Transition Technologies ResQ!net.

Several methods enabling secure communication over the Internet are presented eg. encryption and tunnelling. In the implementation a product called TeamWare Intranet Security Server was used. This product creates a secure channel between a user on the Internet and WorldSoftWare.

Förord

Examensarbetet har i huvudsak utförs på Telia Promotor AB i Göteborg på initiativ av Harald Carlsson. Arbetet genomfördes i syfte att skapa kunskap om affärssystem och dess integrationsmöjligheter mot Internet. Därför skulle en mindre förstudie av affärssystemsmarknaden göras, och en praktisk tillämpning i form av en koppling mellan ett kommersiellt affärssystem och Internet implementeras. Denna praktiska tillämpning utfördes hos SysTeam Applications i Huskvarna.

Erland Jonsson vid institutionen för datorteknik på Chalmers Tekniska Högskola har varit examinator och Daniel Siverbo på Telia Promotor har varit handledare.

Jag vill tacka alla anställda på Telia Promotor för deras hjälp och givande uppslag under arbetets gång. Speciellt vill jag nämna min handledare Daniel Siverbo för hans lugna sätt att analysera undertecknads vilda idéer, Magnus Broback för hans obrutna entusiasm, samt Jan Bäckström på SysTeam för ovärderlig hjälp.

1 Inledning *

1.1 Bakgrund — från löpning till Internet *

1.2 Syfte *

1.3 Avgränsningar *

1.4 Metod *

1.5 Några centrala begrepp *

1.6 Rapportens uppbyggnad *

2 Affärssystem *

2.1 Vad är ett affärssystem? *

2.1.1 Funktion *

2.1.2 Teknik *

2.1.3 Kommunikation *

2.2 Marknaden för affärssystem *

3 Säkerhet *

3.1 Kryptering *

3.1.1 Symmetrisk kryptering *

3.1.2 Asymmetrisk kryptering *

3.2 Autentisering *

3.3 Auktorisering *

3.4 Tunnling *

3.5 SSL *

3.6 Smartkort *

3.7 Riskanalys *

4 Metoder för koppling mellan affärssystem och Internet *

4.1 Varför affärssystem och Internet? *

4.2 Klassificering av affärssystem med avseende på Internetkoppling *

4.2.1 Affärssystemets egenskaper *

4.2.2 Syftet med Internetkopplingen *

4.3 Principiell uppbyggnad av koppling mellan Internet och affärssystem *

4.4 Remote Data Access *

4.5 Remote Function Access *

4.6 Remote Presentation Access *

5 Befintliga affärssystem *

5.1 ASW *

5.1.1 Företaget *

5.1.2 Integration *

5.2 BAAN *

5.2.1 Företaget *

5.2.2 Integration *

5.3 JD Edwards- One World *

5.3.1 Företaget *

5.3.2 Integration *

5.4 Movex *

5.4.1 Företaget *

5.4.2 Integration *

5.5 Oracle Applications ver. 11 *

5.5.1 Företaget *

5.5.2 Integration *

5.6 SAP R/3 *

5.6.1 Företaget *

5.6.2 Integration *

5.7 Scala ver. 5 *

5.7.1 Företaget *

5.7.2 Integration *

 

6 Ett praktiskt exempel — WorldSoftWare och Internet *

6.1 Beskrivning och klassificering av WorldSoftWare *

6.2 Uppgift *

6.3 Avgränsningar *

6.4 Diskussion *

6.5 Lösning *

6.5.1 Integration med Host On-Demand och ResQ!net *

6.5.2 Säkerhet *

7 Slutsatser och rekommendationer *

8 Internetadresser *

9 Referenser *

Appendix A- Test av tidsprestanda för olika Host On-Demand klienter.

Appendix B- En grafisk presentation av den tekniska lösningen.

Appendix C- Beskrivning av implementation.

Appendix D- Förkortningar.

  1. Inledning
    1. Bakgrund — från löpning till Internet
    2. Problemet med att göra hemlig information tillgänglig för ett antal utvalda personer över ett medium som kan nyttjas av alla, är antagligen lika gammalt som människan själv. Redan Caesar visste att skydda meddelanden han sände mellan sina arméer med hjälp av kod. Transportmediet i Caesars fall var en löpare som sprang med en bit pergament, och koden var i detta fall det berömda Caesar-chiffret. I dagens samhälle är arméerna företagskoncerner eller företagsnätverk och det är minst lika viktigt(nåja) att informationen inte faller i oriktiga händer, men samtidigt är det lika viktigt att de som informationen är ämnad för verkligen får tillgång till denna. Det är om transporten av denna affärskritiska information som denna rapport handlar om. Dagens näringsliv använder sig dock inte av löpare utan väljer att transportera informationen över Internet.

      Företag idag har nästan uteslutande något sorts datorsystem för att lagra, behandla och systematisera affärskritisk information. Dessa system har funktioner för att underlätta arbetet t.ex. lönehantering, hantering av reskontra, lagerhållning men en även mer avancerade funktioner kan förekomma. Eftersom tempot i affärslivet ständigt ökar och konkurrensen likaså finns det ständigt ett intresse hos näringslivet att öka sin effektivitet och att minska sina kostnader. Ett sätt att göra detta är göra utvald information direkt tillgänglig på Internet. På detta vis vinns flera administrativa fördelar samtidigt som tid sparas och risken för fel minskas. Det finns alltså stora konkurrens-fördelar att vinna. Varför görs då inte detta?

      Problemet är samma som på Caesars tid, nämligen mediet. Caesar oroade sig för illvilliga barbarer som lurade i buskarna, dagens företag oroar sig för att meddelandet skall bli uppsnappat eller ändrat under dess väg via Internet. Även om Internet inte är ett lika osäkert medium som antikens Rom, finns det faktiskt inga garantier för att ett meddelande som sänts verkligen kommer fram eller för vilken väg meddelandet tar.

      Ett ytterligare problem är (och var) att det är av yttersta vikt att båda parter i kommunikationen är säkra på vem som sitter i andra änden av kanalen. Caesar löste detta med hjälp av caesar-chiffret i kombination med ett personligt sigill, och samma teknik används än idag om än i lite mer avancerad form. Chiffret kan idag heta 3DES och sigillet är numera ett elektroniskt sigill t.ex. MD5.

      De ovan nämnda problemen håller numera på att lösas. Rapporten handlar om de lösningar som finns och de som komma skall.

    3. Syfte
    4. Syftet med detta examensarbete är att utvärdera de principer som finns för säker koppling mellan ett affärssystem och Internet. En av dessa principer kommer sedan att implementeras på ett kommersiellt affärssystem för att verifiera de antaganden som tidigare gjorts.

      Denna implementation skall påvisa ett sätt till att möjliggöra tillträde till företags lokala affärssystem för utvalda personer via Internet. Detta tillträde skall ske på ett säkert sätt, både för kund och för företag.

      De affärsmässiga möjligheterna för kopplingar mellan affärssystem och Internet skall undersökas, och en mindre förstudie av affärssystemsmarknaden skall genomföras. Detta för att ge Telia Promotor beslutsunderlag för sin satsning inom området.

    5. Avgränsningar
    6. Rapporten är fokuserad på den nordiska marknaden och de här dominerande affärssystemen. Vidare omnämns endast affärssystem som kan hantera medelstora och stora företag. Medelstora och stora företag är definierade som företag med 50-5000 anställda.

      Vilket affärssystem som väljs i tillämpningsfasen beror till stor del på vilka möjligheter som erbjuds. Metoden för koppling mellan Internet och affärssystem kommer att väljas utifrån det valda systemets egenskaper. Om kopplingen utförs hos något annat företag än Telia Promotor, så får hänsyn tagas till detta företags behov, både avseende integration och säkerhet.

    7. Metod
    8. Examensarbetet gick till så att jag först bedrev en studie om affärssystem där tidningar, rapporter, böcker och speciellt Internet användes som källor. Detta för att sätta sig in i ämnet och för att underlätta framtida informationssökning. Sedan har kontakt tagits med kända auktoriteter på området. Av dessa kan Sören Janstål på DPU Data Research AB nämnas. I samråd med dessa auktoriteter och personal på Promotor, har sedan ett antal affärssystem bedömts som marknadsledande och valts ut för närmare studium. Därefter tog jag kontakt med tillverkarna av dessa affärssystem, eller, i de fall då tillverkaren inte fanns tillgänglig, deras lokala partner. Dessa kontakter användes för att skapa en djupare bild av de affärssystem som valts ut.

      Parallellt med detta arbete har även de principer som finns för att kommunicera med externa processer undersökts. De metoder som finns för att göra denna kommunikation säker har genomgåtts. Speciellt beaktas de metoder som Telia Promotor har erfarenhet av.

      Tillämpningsfasen inleddes med att jag tog kontakt med ett antal affärssystemsleverantörer. Dessa kontakter syftade till att få tillgång till ett affärssystem, eftersom Telia Promotor inte hade tillgång till ett sådant. Valet föll till slut på SysTeam Applications som är JD Edwards partner i Sverige. I samråd med Jan Bäckström och Anders Carlberg på SysTeam Applications definierades vad som skulle göras. Uppgiften blev att koppla ett JD Edwards WorldSoftware system till Internet. Eftersom detta system skulle användas av SysTeam Applications internt, fick deras behov styra valet av säkerhetslösning.

    9. Några centrala begrepp
    10. I den mån tekniska termer med dataanknytning används har de konventioner som ställts upp av Svenska datatermsgruppen [SWEDAT] brukats. Det kan dock vara på sin plats att reda ut några för rapporten fundamentala begrepp redan vid detta tidiga stadium. Förekommande förkortningar redovisas i appendix C.

      Affärssystem — ett system som används inom ett företag eller koncern för att systematisera, planera, lagra och behandla affärskritisk information som t.ex. lager, löner, redovisning, reskontra, rapportgenerering med mera. Även stöd för mer avancerade funktioner kan finnas som t.ex. MPS (Master Production Schedules). En mer utförlig beskrivning av affärssystem ges i kapitel 2.

      Webbkoppling — en informationskanal mellan ett affärssystem och Internet.

      Webbklient — det program som används för att kunna få tillgång till Internet och då speciellt World Wide Web (WWW). De mest kända webbklienterna är Microsoft Internet Explorer och Netscape Navigator. I denna rapport används Internetklient och webbklient synonymt.

    11. Rapportens uppbyggnad

    Examensarbetet har varit uppdelat i två delar, en undersökande och en tillämpad del. Denna uppdelning återspeglas även i rapporten. Den undersökande delen syftar till att ge läsaren förståelse för de begrepp och metoder som används då man vill koppla ett affärssystem till Internet på ett säkert sätt. Den tillämpade delen syftar till att testa en av de metoder som presenterats i den teoretiska delen.

    Rapporten börjar med ett inledningskapitel där syfte och metod m.m. genomgås. Därefter återges examensarbetets undersökande del i kapitel två t.o.m. fem. Kapitel två innehåller en allmän beskrivning av vad som kan kallas för ett affärssystem och en beskrivning av marknaden för affärssystem. Kapitel tre behandlar vanliga säkerhetsbegrepp som kryptering, autentisering och auktorisering. Även vissa metoder för att realisera dessa begrepp presenteras, t.ex. smartkort. Kapitel fyra inleds med en kort motivering till varför det är önskvärt att koppla sitt affärssystem till Internet. Därefter presenteras en klassificering av affärssystem med avseende på möjlighet till Internetkoppling. Kapitel fyra innehåller också en beskrivning av de principer som kan användas för att koppla ett affärssystem till Internet. Det femte kapitlet innehåller en översiktlig genomgång av några av de på marknaden ledande affärssystemen med avseende på möjlighet till Internetkoppling och företagssituation. Kapitel fem avslutar den undersökande delen.

    Rapportens andra del behandlar examensarbetets tillämpade moment som innebär att en koppling mellan affärssystemet JD Edwards WorldSoftware och Internet tillverkas. Målet är att en demo skall utvecklas som på något sätt utför inhämtning och skrivning av data till ett affärssystem. Det sjätte kapitlet innehåller en beskrivning av affärssystemet WorldSoftWare med avseende på Internetkoppling (gränssnitt odyl.). Kapitlet innehåller även en diskussion om vilken princip för Internetkopplingen som skall användas. Själva integrationen med säkerhetslösning, beskrivs här endast ytligt. Mer detaljerad information angående detta hänvisas till appendix C.

    .

  2. Affärssystem
  3. Ordet affärssystem kan användas om så gott som alla administrativa system som finns. Det finns ingen entydig definition på vad som är ett affärssystem. En uppsjö av benämningar existerar och alla betyder ungefär samma sak, men skiljer sig från varandra i detaljer. Det är därför nödvändigt att klargöra vad som menas med affärssystem i just denna rapport. I detta kapitel klargörs detta och en kortfattad beskrivning av marknaden för affärssystem ges.

    1. Vad är ett affärssystem?
    2. De flesta företag inom dagens näringsliv har något slags datorstöd för deras verksamhet. Det kan vara allt från att datorn används för att understödja löneadministration, till avancerat MPS-stöd där datorn tas till hjälp vid planering av materialflöden och processtyrning. Det är numera vanligt att datorstödda administrativa hjälpmedel innehåller en mängd funktioner till stöd för hela verksamheten. Det finns en mängd olika benämningar på sådana datorstödda administrativa hjälpmedel t.ex. OLF, ERP eller affärssystem. I denna rapport kommer termen affärssystem uteslutande att användas.

      Figur 1. Tre funktionsområden som i denna rapport definierar ett affärssystem.

      För att klargöra vad som menas med ett affärssystem i denna rapport definieras tre funktionsområden som kan sägas vara minsta gemensamma nämnare (se figur 1) för de system som tas upp. Därmed är det inte sagt att affärssystemen inte kan ha fler funktionsområden, men dessa tas inte i beaktande. Anledningen till att detta inte görs är att det är svårt att motivera webbkopplingar till en del av dessa funktionsområden. Det är exempelvis svårt att motivera varför funktioner för Quality Management skall vara tillgängligt via Internet.

      Definition:

      Ett affärssystem är en programvara som används för att stödja och/eller styra flera av ett företags processer. Affärssystemet stödjer eller styr processer från minst tre funktionsområden. De tre funktionsområdena är försäljning och logistik, tjänster, och ekonomi.

      1. Funktion

Moderna affärssystem är så gott som uteslutande uppbyggda i moduler, där köparen själv (eller som oftast, med hjälp av en konsult) kan bestämma vilken funktionalitet den eftersträvar. Denna funktionsmodulära uppbyggnad gör att ett modernt affärssystem är mycket flexibelt. Alla moduler är integrerbara även efter det att systemet är implementerat hos köparen. Detta innebär att systemet går enkelt att bygga ut om köparens behov skulle förändras.

Alla affärssystem har ett basutbud som utgörs av de för företag grundläggande administrativa uppgifterna. Detta basutbud kan användas av i stort sett alla företag, oberoende av bransch. De funktioner som typiskt ingår i ett sådant basutbud är:

Det kan förekomma att andra funktioner också ingår i ett visst basutbud men detta varierar beroende på tillverkare. Vissa tillverkare inriktar sig mot specifika branscher och inkluderar därför fler funktioner t.ex. MPS-stöd ifall tillverkningsindustrin är den målgrupp man vill attrahera. Alla större tillverkare har dock allt utöver basutbudet i moduler och varje enskild köpare får skapa sig en egen profil genom att införskaffa lämpliga moduler. Detta beror på att dessa stora tillverkare inte vill avgränsa marknaden för sina system genom att låta köparen betala för funktionalitet de inte behöver. För att åskådliggöra modultänkandet redovisas (figur 2) en del av affärssystemet Maconomys moduluppbyggnad.

Figur 2. Del av affärssystemet Maconomys moduluppbyggnad.

Maconomy Bas utgör som namnet antyder basutbudet i Maconomy. Denna modul innehåller funktioner för redovisning, budgetering, kund- och leverantörsreskontra samt ett artikelsystem med möjlighet att fakturera. Maconomy Bas ingår sedan integrerat i Maconomys två huvudmoduler, Maconomy Handel och Maconomy Uppdrag. Dessa moduler innehåller, utöver alla funktioner i Maconomy Bas, funktioner mer specifika för ett handelsföretag resp. tjänsteföretag. Ju fler moduler som sedan inkluderas, desto mer branschspecifikt blir affärssystemet.

      1. Teknik
      2. Det som skiljer affärssystem idag åt, är i första hand de betingelser under vilka affärssystemen kan fungera. De är ofta ganska lika till det yttre, då de har grafiskt användargränssnitt (GUI) som fungerar enligt den de facto-standard som används av Apple Macintosh och Microsoft. Tittar man under ytan är det ganska mycket som skiljer dem åt.

        Klient-server

        En klar trend är att använda sig av klient-server[KLISER] modellen då det gäller att fördela arbetet i systemet. Kortfattat innebär klient-server modellen att ett flertal användarterminaler (klienter) delar på en gemensam server som innehåller gemensamma resurser. Klienterna får sedan fråga servern efter den information de behöver. Man skiljer på tunna och feta klienter. En fet klient gör mycket arbete själv och anropar endast servern då den behöver information som är gemensam för alla klienterna. En tunn klient har endast till uppgift att tillhandahålla gränssnittet mot användaren samt att fråga servern efter information. Servern får sedan göra allt arbetet och sedan skicka tillbaka den efterfrågade informationen. Fördelen med detta förfarande är att all kapacitetskrävande databearbetning förflyttas från klienten till servern, som har högre prestanda. En annan fördel är att kommunikationen i nätverket minimeras, då endast frågor och svar skickas mellan klienten och servern. Det finns även uppgradering- och driftfördelar, då det räcker med att installera och underhålla programvara på servern, istället för på alla klienterna. I affärssystemsbranschen går utvecklingen mot tunna klienter, men det är stor variation i hur "tunna" klienterna är, dvs. hur mycket arbete som utförs av klienten.

        Plattformar

        När det gäller vilka operativsystem som affärssystemen kan använda så är det stor variation, både för klient och för server. Alla de stora operativsystemen finns representerade. Ett flertal av affärssystemen har flera olika plattformar att välja mellan medan en del bara kan köras på en.

        Databaser

        Alla affärssystem lagrar sin information i en databas. Den helt dominerande databastypen är relationsdatabasen[RELDBS). I en relationsdatabas är all information lagrad i tabeller. Fördelen med att lagra informationen i en relationsdatabas är att det finns ett standardiserat sätt för att extrahera information genom att beskriva villkor och relationer mellan tabellerna som ingår i relationsdatabasen. Detta standardiserade verktyg kallas SQL[STQULA] (Structured Query Language). Med hjälp av SQL är det lätt att både få ut eftersökt information, och att infoga ny information på rätt plats. Alla stora databastillverkare finns representerade, och de flesta affärssystem är kompatibla med ett flertal olika databaser.

        Utveckling

        Det är naturligtvis varierande vilka utvecklingsmiljöer och vilka programspråk som affärssystemtillverkarna har valt till sina system. Vanligast är att man valt något av de vanligaste programspråken t.ex. C++ eller Visual Basic, men det finns även en del exempel på att Java har används. Det finns en trend mot att gå ifrån dessa tredje generationens programspråk, för att utveckla egna fjärde generationens programspråk (4GL). Skillnaden på ett 4GL och ett 3GL är att ett 4GL mer liknar ett mänskligt språk.

        Exempel: Pseudokod (3GL) för att finna de personer som heter "Snake Plisken" en tabell

        for i in 1..tabell.last loop

        if i.name ="Snake Plisken"

        return i;

        endif;

        end loop;

        En söksträng på ett 4GL språk för utföra samma uppgift

        FIND ALL RECORDS WHERE NAME IS "Snake Plisken"

        Utvecklingen av egna 4GL-verktyg har gjort att det är enklare att utveckla egna funktioner i affärssystemet. En del tillverkare inkluderar en utvecklingsmodul i sina affärssystem så att köparen själv kan skapa funktioner ifall behov skulle uppstå.

      3. Kommunikation

Kommunikation till, från och mellan affärssystem är en fundamental del av deras funktionalitet. Det finns funktioner för kommunikation hos så gott som alla moderna affärssystem. Electronic Data Interchange (EDI) är ett begrepp som är nära förknippat med kommunikation företag emellan. I nästa stycke beskrivs kortfattat EDI och dess inverkan på affärssystemen.

EDI

EDI[EDIREF] innebär att affärssystem kan kommunicera direkt med varandra med begränsad mänsklig inblandning. EDI är egentligen ett samlingsnamn för en mängd metoder som finns för datakommunikation. Det behöver inte vara en standard, utan det räcker med att man är överens med den andra parten om hur överföringen skall ske. Det är dock vanligast att man håller sig till en standard. EDI kan definierats så här:

Elektronisk utväxling av strukturerade, standardiserade meddelanden mellan två applikations-system i datorer utan manuell inblandning, där applikationssystemen direkt kan tolka och bearbeta meddelandedata.

Av de standarder som finns är EDIFACT den mest förekommande (bortsett från bilindustrin som har en snarlik standard, ODETTE). Det organ som står för fastställandet av dessa EDI standarder är lite förvånande FN som sedan mitten på 70-talet har varit aktiva inom området. EDIFACT är den enda standard som är godkänd av FN, ISO, CEN och SIS/ITS.

EDIFACT består av ett par hundratal standardiserade meddelanden som används för olika ändamål t.ex. order eller fakturering. Dessa meddelanden kan liknas vid elektroniska blanketter som genereras automatiskt av t.ex. ett affärssystem. Meddelandet sänds sedan till mottagaren, där det automatiskt tas om hand och tolkas. EDI används i stor utsträckning i industrin, bl.a. till automatiska betalningar och CAD-ritningsöverföring.

Notera att standarden inte säger något om hur meddelandet skall transporteras. Detta är helt upp till de parter som skall kommunicera. Det vanligaste transportprotokollet som används idag är X.400[X400RF] men ett EDIFACT-meddelande kan även bifogas i ett e-brev.

De flesta moderna affärssystem stöder EDI på ett eller annat sätt, antingen genom att programvara inkluderas från början eller att det finns ett väldefinierat gränssnitt för annan EDI-programvara. Detta innebär att affärssystemen både kan tolka och skicka EDI-meddelanden utan mänsklig inblandning.

    1. Marknaden för affärssystem

I detta avsnitt ges en översiktlig bild av marknaden för affärssystem. Informationen som redovisas kommer i huvudsak från regelbundna samtal med Sören Janstål[SÖRDPU] som driver ett företag som heter Data Research DPU AB. Data Research DPU AB arbetar med utvärderingar av affärs- och ekonomisystem och Sören Janstål har genom sitt arbete fått en god överblick av affärssystemsmarknaden. Om inget annat anges, är det denna referens som avses. Noterbart är att detta avsnitt behandlar marknaden för affärssystem och inte marknaden för Internetkopplingar mot affärssystem.

Marknaden för affärssystem har på senare år fördubblats årligen. Detta beror i huvudsak på två saker; en ökande oro inför år 2000 samt införandet av en gemensam europeisk valuta (ecu). Även om Sverige väljer att inte gå med i Europeiska Monetära Unionen (EMU) så kommer alla företag ändå behöva möjlighet till att hantera den gemensamma valutan (ecu). Detta ställer nya krav på affärssystemen, som i vissa fall skrevs innan EU-inträdet. De företag som har affärssystem som inte klarar av att hantera ecu:n, har få alternativ förutom att byta affärssystem. Det samma gäller "år 2000 problemet". Få, om några, äldre generationens affärssystem är förberedda för milleniumskiftet. Som exempel kan nämnas att alla affärssystem som körs på operativsystemet DOS kommer behöva bytas ut innan år 2000 eftersom dessa inte kommer att klara av milleniumskiftet. Allt fler företag förväntas bli medvetna om dessa problem. Detta gör att marknaden förväntas öka med 50-70% årligen fram till år 2000, med en topp 1999. Därefter väntas marknaden stagnera. De affärssystem som nu marknadsförs är både år 2000 och EMU säkrade.

Marknaden är mycket fragmenterad med många små aktiva parter. Eftersom det är mycket kapitalkrävande att utveckla affärssystem, så förväntas det att de små aktörer som inte har moderna system kommer att slås ut. Vinnarna är de system som är moderna och vars leverantörer har kapital för att ständigt kunna utvecklas. Det finns en klar tendens[HESDPU] när det gäller användarnas krav på sitt affärssystem. De vill ha ett grafiskt menybaserat gränssnitt, klient-server teknik och vill köra i Windows NT miljö. Det är detta som affärssystemstillverkarna har att rätta sig efter, även om det finns initiativ som pekar åt andra arkitekturer tex. NC.

Som tidigare beskrivits så är de flesta affärssystem moduluppbyggda. Detta för att inte kunden skall betala för funktionalitet som den inte behöver. Detta hindrar dock inte tillverkarna från att marknadsföra sig mot vissa branscher. Som exempel kan Intentia nämnas, som tillverkar Movex och marknadsför sig hårt mot livsmedelsbranschen.

Då det gäller de svenska tillverkarna av affärssystem så är det i huvudsak två faktorer som kommer att påverka deras utveckling i framtiden. För det första kommer de att bli allt mer tjänstorienterade, istället för som tidigare produktorienterade. Detta beroende på att deras produkter inte kommer till sin rätt om inte hela företagets verksamhet anpassas till affärssystemet. Detta förändringsarbete kräver stora insatser, och det finns en klar tendens som pekar på att själva implementeringsarbetet av systemen blir kortare, samtidigt som leverantörens engagemang hos kunden blir längre. Denna trend borde vara en möjlighet för de svenska leverantörerna, eftersom de har arbetet på detta sätt under en längre tid.

Den andra trenden är en förändring av de stora leverantörernas fokus på marknaden. Från att ha fokuserat på stora kunder, börjar de bli allt mer intresserade av mindre och medelstora företag. Denna marknad är den samma som de svenska leverantörerna verkar på, och dessa leverantörer kommer märka av en hårdnande konkurrens.

Enligt Sören Janstål så kan de affärssystem som idag finns på den nordiska marknaden rangordnas så här, med avseende på nuvarande marknadsposition och framtidsmöjligheter. Tillverkaren anges inom parentes:

SAP R/3 (SAP AG)

BAAN (BAAN)

Oracle Applications (Oracle)

Movex (Intentia)

JD Edwards (JD Edwards)

ASW/400 (IBS)

IFS Applications (IFS)

Concorde XAL (Damgaard Data)

Jeeves (Jeeves)

Prosit Objects (WM data)

Scala (Scala)

Agresso (Agresso)

VISMA Business (Visma ASA)

IM*ESS (IMI)

AdeEKO+ (Enator Adedata)

Maconomy (Maconomy)

Lawson (Lawson Software)

Pyramid(PyramidSoftware)

 

Ett flertal av ovanstående system har valts ut för närmare studium (se kap 5). Dessutom har några ytterligare system valts. Detta beroende på att Telia Promotor har viss erfarenhet av dessa system.

  1. Säkerhet
  2. Då det är önskvärt att affärssystemen skall kunna kommunicera med sin omvärld, är det oundvikligt att säkerhetsproblem uppstår. Samtidigt som man vill att systemet skall vara tillgängligt för omvärlden, vill man begränsa tillgängligheten till ett fåtal personer. Det är också av yttersta vikt att meddelanden inte försvinner, blir ändrade eller avlyssnade under transporten mellan systemen. Dessutom är det inte säkert att man vill att alla resurser i systemet skall vara tillgängliga utifrån, utan bara en del.

    I detta kapitel behandlas några av de metoder[PFLEEGER] som finns för skicka information på Internet på ett säkert sätt. Dessa metoder är generella i den mening att de är oberoende av vad som skickas, och är således tillämpbara även för affärssystem.

    1. Kryptering
    2. Kryptering är en metod för att överföra känslig information över ett osäkert medium (t.ex. Internet) på ett säkert sätt. De båda parterna som skall kommunicera kommer överens om hur informationen skall krypteras och dekrypteras. Den metod de enas om kallas för ett kryptosystem. Vid kryptering resp. dekryptering används en nyckel. Denna nyckel beskriver hur informationen skall förvanskas eller återvinnas. En krypteringsnyckel är en nyckel som används vid kryptering, och en dekrypteringsnyckel används vid dekryptering. Man skiljer på symmetrisk och asymmetrisk kryptering.

      1. Symmetrisk kryptering
      2. Vid symmetrisk kryptering är krypteringsnyckel och dekrypteringsnyckel lika. Denna nyckel är unik för varje par av parter som vill kommunicera. Det är därför av fundamental betydelse att nyckeln hålls hemlig för alla utom de två inblandade parterna. Så länge denna hemlighet är bevarad existerar en tvåvägs kommunikationskanal mellan de båda parterna, och båda parter kan vara säkra på vem det är de kommunicerar med (mer om autentisering i kap 3.1.2).

        Metoden med symmetrisk kryptering innehåller några svagheter, som till stor del har med nycklarna att göra. Ett problem (förutom det uppenbara i att någon kommer på vilken nyckel som används) är att varje nytt kommunikationspar måste ha en ny unik nyckel. Enligt Pfleeger krävs det n*(n-1)/2 nycklar i ett system som har n användare. Man inser att det lätt blir ett ohanterligt stort antal nycklar. Ett annat problem är själva överföringen av nya nycklar. Om den andra parten är på andra sidan jorden, finns det naturligtvis risk att någon snappar upp nyckeln på väg dit. Ett sätt att lösa överföringen av nya symmetriska nycklar är att använda asymmetrisk kryptering (se nedan) för överföringen och sedan då nyckeln är överförd, växla till symmetrisk kryptering.

        Den vanligaste symmetriska krypteringsmetoden[SYMKRY] idag är DES (Data Encryption Standard). DES är utvecklad av IBM och har varit standard sedan slutet på 70- talet. Metoden har en 56 bitar lång nyckel och bygger på en 16 cykler lång serie av substitutioner och permutationer av indata. Metoden har på senare tid visat sig vara osäker, inte minst då EFF i juli —1998 knäckte ett DES —meddelande på 56 timmar. Ett säkrare alternativ till DES är IDEA som har en nyckellängd på 128 bitar.

      3. Asymmetrisk kryptering

      Då man använder sig av asymmetrisk kryptering så är krypteringsnyckel och dekrypteringsnyckel olika. Krypteringsnyckeln är publik dvs. vem som helst kan få tillgång till den. Om X vill skicka något till Y, så krypterar X meddelandet med Y’s publika nyckel och skickar det till Y. Y dekrypterar sedan meddelandet med sin hemliga dekrypteringsnyckel. Följden blir, till skillnad från fallet med symmetrisk kryptering, att flera parter kan skicka krypterade meddelanden till samma adress och använda samma krypteringsnyckel. Adressaten (som naturligtvis håller sin nyckel hemlig) är den enda som kan dekryptera meddelanden.

      En populär asymmetrisk krypteringsmetod är RSA som bygger på det faktum att det är mycket svårt att finna två primtalsfaktorer till väldigt stora tal. En vanlig nyckellängd är 1024 bitar, men 2048 är också förekommande.

    3. Autentisering
    4. All kommunikation bygger på att man vet vem man kommunicerar med. Vad man säger, är beroende av vem man kommunicerar med. Autentisering är att klargöra om en part (person eller dator) är den som den uppger sig vara. Det finns tre generella metoder för autentisering som baserar sig på en användares ägodel, kunskap eller personligt attribut.

      En användares ägodel kan vara ett smartkort (se kapitel 3.6) eller nyckel (en vanlig nyckel, inte att förväxla med en krypteringsnyckel). Denna läses av vid autentiseringen och om t.ex. smartkortet är korrekt och matchar (personen får ofta ange någon slags personlig kod t.ex. PIN) den personen som säger sig använda det, anses personen som identifierad.

      Kunskap som är unik för en användare är ett av de mest populära sätten för autentisering. Detta i form av ett lösenord kombinerat med att användarnamn. Problemet med lösenord är att om inte lösenorden väljs med omsorg, så är de lätta att knäcka med en sk. uttömmande sökning.

      Användning av personliga attribut är en metod som grundar sig på de egenskaper som skiljer individer åt t.ex. signatur eller fingeravtryck. Detta läses av en för ändamålet specifik läsare och jämförs sedan med ett referensmått som sedan tidigare finns lagrat. Om referensmåttet stämmer överens med det avlästa så anses personen som identifierad.

      Utöver dessa generella metoder finns det metoder som faller in under flera av ovanstående kategorier. Digitala signaturer är en metod som i sin bästa form erbjuder att meddelanden skickas så att de är omöjliga att förfalska, förändra eller återanvändas samtidigt som sändarens identitet är garanterad. Metoden (i denna form) bygger på asymmetrisk kryptering i kombination med en tidstämpel.

      Vanlig symmetrisk kryptering (se 3.1.1) är annars en bra metod för autentisering under förbehåll att krypteringsnyckeln fortfarande är hemlig. Det är ju bara en person som känner till den gemensamma nyckeln som kan kryptera något som motparten kan dekryptera.

      Den mest kända metoden för digital signering idag är MD5[MD5REF]. Metoden tar ett givet meddelande och skapar ett för meddelandet unikt hash-värde på 128 bitar. RSA rekommenderar[MD5RSA] dock att MD5 inte används i tillämpningar där kollisioner inte får förkomma.

    5. Auktorisering
    6. Ur säkerhetssynpunkt är det naturligtvis bäst om användare bara har tillgång till de resurser som de absolut behöver. Användarens synpunkt är lika självklart att alla resurser skall vara lätt tillgängliga. Detta är det stora dilemmat inom datasäkerhet; att väga tillgänglighet mot säkerhet.

      Auktorisering är tilldelandet av behörighet att använda resurser till en identifierad användare. Varje användare har vissa rättigheter och dessa tilldelas automatiskt av operativsystemet, oftast som en följd av en autentisering. Eftersom operativsystemets säkerhetsmekanismer ligger utanför denna rapports område, behandlas endast de säkerhetsmetoder som finns för extern åtkomst av system. En vanlig metod för att reglera extern åtkomst är att använda sig av brandväggar.

      Brandväggar

      En brandvägg är en maskin som kontrollerar kommunikationen från ett internt nätverk till exempelvis Internet. Alla som vill in eller ut från nätverket måste således passera (se figur 3) brandväggen. Denna kontrollerar alla passerande meddelanden enligt av ägaren till nätverket uppställda kriterier, t.ex. kan endast data som kommer från vissa IP-adresser tillåtas passera. Utöver att kontrollera in- och utgående trafik, loggas också alla försök till passage igenom brandväggen, även nekade. Denna information kan sedan användas för att upptäcka intrångsförsök.

      En brandvägg som sorterar bort data från okända datorer kallas för filtrerande router. All data som skickas över Internet delas upp i paket av fix längd. Först i varje paket kommer ett pakethuvud som bl.a. anger varifrån paketet kommer. En filtrerande router läser av detta pakethuvud och sorterar bort oönskade paket.

      Figur 3. En brandväggs placering i ett lokalt nätverk.

      En annan sorts brandvägg är en proxy gateway. En proxy gateway skyddar program på det lokala nätverket mot otillåtna externa anrop genom att först kontrollera om anropet är tillåtet, sedan anropa programmet och returnera resultatet. Följden blir att en extern användare inte får direkt kontakt med ett program utan hänvisas till en proxy gateway, som sedan förmedlar och kontrollerar informationsflödet mellan parterna. En proxy gateway anses vara säkrare än en filtrerande router eftersom den inte bara kontrollerar pakethuvudet utan hela paketet.

    7. Tunnling
    8. Tunnling innebär att man skapar en säker kanal (en tunnel) för kommunikation över ett osäkert medium t.ex. Internet. Den säkra kanalen skapas med hjälp av stark kryptering, stark autentisering och digital signering. Allt detta utförs av en tunnelserver och är helt transparent för användaren. Flera nätverk kan kopplas ihop via tunnelservers och skapa ett virtuellt privat nätverk (VPN-nät).

      Ett VPN-nät är helt osynligt för användaren, så det märks ingen skillnad om en dator står på andra sidan jorden eller i huset bredvid.

      Figur 4. Skillnaden i nätverksarkitektur med eller utan användande av tunnelteknik.

      En tunnelserver har också de funktioner som en brandvägg har dvs. den kontrollerar in och utpasserande trafik till ett nät.

      En av fördelarna med att använda sig av VPN-nät är att företag som tidigare hyrde fasta förbindelser, nu kan använda sig av det betydligt billigare Internet som kommunikationsmedel. Det är dessutom lättare att skapa och infoga nya nät till ett VPN-nät än till ett fast.

    9. SSL
    10. Secure Sockets Layer (SSL) är ett protokoll utvecklat av Netscape, för att erbjuda privat kommunikation över Internet. SSL använder sig av ett symmetriskt krypto med 40, 56 eller 128 bitars nyckel. Det är i de kortare nyckellängden som SSL har sin begränsning. På grund av USA´s strikta exportregler får inget krypto med längre nyckel än 56 bitar exporteras.

      När detta skrivs så är 40 bitars SSL krypto vanligast. Ett 40 bitars symmetriskt krypto är inte säkert nog för att vara acceptabelt för tex. Internethandel (vilket inte hindrar det från att användas). 128 bitars versionen av SSL anses fullgod.

      Ett internetdokument som kräver SSL inleds enligt konvention med https:// istället för http://.

    11. Smartkort
    12. Ett smartkort[SMKREF] är ett kort i kreditkortsformat som har en mikroprocessor och ett antal minnesceller anslutna. Smartkortet skiljer sig från ett traditionellt magnetkort, då det har möjlighet att utföra enkla operationer och välja vilken information som skall göras tillgänglig till vem. Dessutom så kan ett smartkort lagra mer information än ett magnetkort. De huvudsakliga användningsområdena för smartkort är som elektroniskt ID (EID), elektronisk plånbok och elektroniskt patientkort. Det är främst i sin funktion av elektroniskt ID som smartkort är av relevans för denna rapport.

      Då smartkortet skall användas för autentisering lagras personlig information tillsammans med en publik och en privat nyckel i ett s.k. certifikat. Detta certifikat är utfärdat av en betrodd tredje part (eng. Trusted Third Party eller TTP) kallad Certification Authority (CA). Certification Authority står som garant för att det certifikat som de utfärdat är unikt. Certifikatet brukar även innehålla en personlig kod som måste anges för att kortet skall kunna användas. Denna kod kan antingen vara en PIN kod eller ett traditionellt lösenord. En av smartkortets fördelar är att det kan välja vilken information på kortet som skall göras tillgänglig, och för vilka denna information skall göras tillgänglig. Detta har till följd att t.ex. den privata nyckeln kan döljas för alla, inklusive ägaren. En smartkortsläsare kan dock beordra smartkortet läsa nyckeln för att på så sätt verifiera en användares identitet. Notera att den hemliga nyckeln inte lämnar kortet, utan att all databehandling av nyckeln utförs av mikroprocessorn på smartkortet. Smartkortsläsare är inte så vanliga idag, men väntas ingå som standard i datorutrustning inom en snar framtid.

    13. Riskanalys

För att kunna avgöra vilka metoder som skall användas för att säkerställa säkerheten hos Internetkopplingen, är det naturligtvis nödvändigt att göra en bedömning av de risker som förekommer. Lösningen kommer att bero på vilka hot man anser vara av störst dignitet. Enligt Pfleeger bör det utföras en riskanalys på alla företag som på något sätt öppnar upp sina datorsystem mot omvärlden. Denna riskanalys får sedan ligga till grund för framtagandet av en dokumenterad säkerhetspolicy.

Vid en riskanalys görs en bedömning av vilka risker som finns, hur stor sannolikhet det är för att ett visst säkerhetsbrott skall inträffa, samt vilka skador (läs kostnader) som ett eventuellt säkerhetsbrott skulle innebära. Dessa parametrar får sedan utgöra grunden för en beräkning av en årlig kostnad för varje enskilt säkerhetsbrott. Denna siffra jämförs sedan med kostnaden för vad det skulle kosta för att skydda sig mot samma säkerhetsbrott i ett år. På detta sätt kan man skapa sig en egentlig bild av hur mycket man tjänar/förlorar per år på den säkerhetslösning man valt. Man kan dessutom bilda sig en uppfattning om vilka besparingar som säkerhetsinvesteringar innebär. Dessa investeringar har annars en tendens till att bli rena kostnader som är svåra att koppla till någon intäkt. Metoden har dock vissa svagheter. Det kan vara mycket svårt att göra en uppskattning av hur ofta ett visst säkerhetsbrott inträffar. Dessutom kan metoden leda till den falska förespeglingen att man vet precis hur mycket pengar man investerar i varje år. De beräkningsresultat som erhålls är naturligtvis inget annat än kvalificerade gissningar och de enda kostnaderna som kan verifieras är i regel de som är förknippade med inköp av hård- och mjukvara. De minskade utgifter som dessa investeringar ger är ofta svåra att verifiera i efterhand.

Då riskanalysen är avslutad påbörjas arbetet med att sammanställa en säkerhetspolicy. En säkerhetspolicy skall svara på följande frågor:

Upprättandet av en säkerhetspolicy är ett dynamiskt arbete som fortgår kontinuerligt. Eftersom utvecklingen går fort, krävs det att man regelbundet ser över säkerhetspolicyn och gör de förändringar som behövs. Den viktigaste av ovanstående frågor är den som adresserar ansvarsfrågan. Det är mycket vanligt att säkerhetspolicyn framarbetas som ett projekt. När detta projekt är avslutat, så finns det ingen som tar ansvar för att säkerhetspolicyn implementeras. Minst en ansvarig för implementering och uppföljning krävs om de direktiv man enats om skall få någon verkan.

De specifika problem som är förknippade med en Internetkoppling mot ett affärssystem är unika för varje installation. Det enda som kan sägas är att om affärskritisk information kommer i fel händer, eller ändras på ett otillbördigt sätt kan konsekvenserna bli ofantliga. Det är därför av yttersta vikt att säkerhetspolicyn återspeglar dessa krav på stark auktorisering, autentisering och kryptering.

  1. Metoder för koppling mellan affärssystem och Internet
  2. Detta kapitel inleds med en kort motivering om varför det är önskvärt att koppla sitt affärssystem till Internet. Sedan redovisas tre för rapporten centrala principer (4.2-4.4) angående anpassning av datorprogram till Internet. Dessa principer är tillämpbara på affärssystem. De principer[SÄKPRI] som redovisas har tagits fram av adj. Prof. Amjad Umar vid Rutger universitetet i New Jersey, USA. Om inget annat anges, är det denna referens som avses.

    1. Varför affärssystem och Internet?
    2. Ett affärssystem är i grund och botten ett verktyg som är tänkt att skapa ett ekonomiskt mervärde för ett företag. Det är en stor investering som är svår att härleda direkt till ökad vinst eller sänkta kostnader. Det är därför önskvärt att få detta affärssystem att bereda så mycket nytta som möjligt, för så många som möjligt.

      E-commerce och elektronisk handel är två termer som ligger i tiden. Den elektroniska handeln har ökat lavinartat de senaste åren, och kraven från både kunder och leverantörer om ökad tillgänglighet via Internet likaså. Dessa krav i sig är anledning nog för att göra sin verksamhet Internetanpassad, men de stora fördelarna ligger i det minskade administrativa arbete som behövs. Om en kund, via Internet, tittar direkt i lagerförteckningen, får prisuppgift och väljer att placera en order direkt i affärssystemet så har en säljare besparats från en rutinmässig uppgift. Denna säljare kan istället göra vad denne är bäst på; att ha kundkontakt och skapa en relation som uppmanar till gott affärssamarbete. Affärssystemet genererar sedan automatiskt en faktura och skickar sedan iväg denna till kundens affärssystem som i sin tur skickar ett betalningsmeddelande till banken. Internet banar väg för det papperslösa samhället.

      Det är vanligt att företag finns på flera orter och använder samma affärssystem. För att detta skall fungera så krävs det en ansenlig mängd samordning då det gäller organisation och utrustning. Dessutom måste man hyra kommunikationsförbindelser för att kommunikationen skall vara säker. Om man istället kopplade sina affärssystem till Internet, så skulle man inte ens vara beroende av att ha samma affärssystem. En internetläsare är helt oberoende av operativsystem och affärssystem. Med hjälp av tunnelteknik (beskrivs närmare i kap 3.4) kan man använda Internet istället för hyrda förbindelser och på så sätt minska sina kostnader.

      Finns det då inga nackdelar med att koppla sitt affärssystem till Internet? Det finns det naturligtvis, och nackdelarna är av sådan natur att de inte bör tas lätt på. Främst är det säkerhetsproblem. Om man gör sitt affärssystem tillgängligt för allmänheten, hur hindrar man konkurrenter från att läsa affärshemligheter? Det finns lösningar på dessa problem (se kap 3.1-3.3) som är fullt tillräckliga för att kunna uppnå fullgod säkerhet.

    3. Klassificering av affärssystem med avseende på Internetkoppling
    4. De metoder som används vid konstruktion av kopplingar mellan affärssystem och Internet är naturligtvis beroende på affärssystemets egenskaper. Utöver dessa egenskaper så är också syftet med Internetkopplingen nödvändigt att ta i beaktande vid val av metod.

      1. Affärssystemets egenskaper
      2. Affärssystem kan, enligt Amjad Umar, delas in i tre kategorier beroende på hur tillgängliga de är i sin uppbyggnad. Med tillgänglighet avses här, hur lätt det ät att utvinna information utan att använda affärssystemets eget användargränssnitt.

        Ett lättillgängligt affärssystem har väl definierade gränssnitt så att all funktionalitet i affärssystemet kan nås utifrån. Lagrad information är väl strukturerad (i praktiken en relationsdatabas) och därmed nåbar utifrån.

        Ett tillgängligt affärssystem har endast gränssnitt till vissa funktioner. Lagrad information är tillgänglig utifrån, med vissa begränsningar.

        Ett svårtillgängligt affärssystem har inga gränssnitt för extern åtkomst och all information och funktionalitet är organiserad på ett sätt som endast tillverkaren förstår. Det enda sättet att utvinna information är via affärssystemets eget användargränssnitt.

      3. Syftet med Internetkopplingen

      Anledningen till att man vill koppla sitt affärssystem till Internet kommer naturligtvis att påverka vilken metod som används. Vad vill man kunna göra via Internet? Vill man bara kunna läsa lagerstatus eller vill man kunna placera en order? Valet av metod bör återspegla det man vill göra med sitt affärssystem. Alla tänkbara uppgifter kan placeras i följande två kategorier:

      Läsoperationer, där man endast vill läsa information t.ex. lagerstatus.

      Läs- och skriv operationer, där man både vill läsa och skriva information t.ex. om man vill placera en order efter att ha fått en prisuppgift.

    5. Principiell uppbyggnad av koppling mellan Internet och affärssystem
    6. En av fördelarna med att koppla sitt affärssystem till Internet är att man då kan använda sig av en Internetklient (internetläsare) som gränssnitt till användaren. Detta är praktiskt om nätverket är utspritt och alla användare inte har samma hård- och/eller mjukvara. Internetklienten är, via Internet, ansluten till en Internetserver som har till uppgift att förmedla alla kontakter med Internet. Eftersom alla kontakter som Internetklienten har med sin omvärld går via Internetservern, är det nödvändigt att skapa en koppling mellan Internetservern och affärssystemet, ifall klienten och affärssystemet skall kunna kommunicera. Denna koppling kallas för Internet gateway (för affärssystem). Den principiella uppbyggnaden för kopplingen mellan affärssystem och Internetklienter åskådliggörs i figur 5.

      Figur 5. Den principiella uppbyggnaden för koppling mellan affärssystem och Internet.

      Beroende på affärssystemets egenskaper och syftet med internetkopplingen (se kap 4.2) väljs sedan den metod för dataöverföring som Internet gatewayen skall använda. De tre metoder som kan användas av Internet gatewayen är remote data access, remote function access och remote presentation access. Dessa metoder beskrivs närmare i kapitel 4.4 — 4.6.

    7. Remote Data Access


    8. Remote Data Access (RDA) är en metod som bygger på att extrahera informationen direkt ur affärssystemets databas utan att använda affärssystemets funktionalitet. Detta förutsätter att systemet är lätt tillgängligt, men i detta fall är kravet på tillgänglighet begränsat till informationslagringen. Informationen måste vara väl strukturerad t.ex. i en relationsdatabas.

       

       

      Figur 6. Internetkoppling med hjälp av Remote Data Access (RDA)

      RDA bygger på att information hämtas direkt i affärssystemets databas (se figur 6). En Internetklient begär information t.ex. lagersaldo genom att användaren gör ett menyval. Klienten meddelar sedan detta till en Internet gateway (som i detta fall kallas database gateway), som sedan ansvarar för inhämtandet och returnerandet av information.

      En vanlig metod för att göra detta är remote SQL. Remote SQL innebär att en SQL-söksträng (se kap 2.1.2) genereras utanför affärssystemet (i detta fall i database gateway) och skickas direkt till affärssystemets relationsdatabas. Databasen bearbetar sedan söksträngen och returnerar resultatet direkt, utan att på något sätt använda sig av affärssystems funktioner eller gränssnitt.

      Fördelen med denna metod är att det är väldigt lätt att utvinna information om man bara vet hur databasen är organiserad. Det finns väl dokumenterad och utprovad programvara för ändamålet. Metoden är även transparent för användaren, dvs. användaren beter sig likadant oavsett var den befinner sig.

      Nackdelarna är flera. De funktioner som redan finns i affärssystemet kan inte användas utan måste skrivas om. Detta beroende på att metoden helt ignorerar affärssystemet i sig, utan söker informationen direkt i databasen. En annan nackdel är att man inte får någon kontroll på hur mycket information som begärs. Det finns inget sätt (förutom intuitivt) att förutsäga hur mycket information som kommer att returneras för en viss SQL-söksträng. Detta kan leda till stor belastning på nätverket.

    9. Remote Function Access
    10. Remote Funktion Access (RFA) är en metod som bygger på att Internetklienten anropar funktioner som redan finns i affärssystemet. Detta kräver att dessa funktioner är förberedda och lätt åtkomliga, dvs. att affärssystemet är lätt tillgängligt. En Internetgateway används för att ta emot anrop från Internetklienten. Internetgateway anropar sedan lämplig funktion hos affärssystemet. När sedan affärssystemet har behandlat anropet, returneras resultatet till Internetklienten via Internetgateway.

       

      Figur 7. Internetkoppling med hjälp av Remote Function Access (RFA)

      Det är även möjligt att anropa affärssystemsfunktioner direkt från Internetklienten. Netscapes internetläsare innehåller ett verktyg som heter Internet Inter-ORB Protocol (IIOP). Detta verktyg används för att anropa CORBA objekt (se nedan) direkt från internetläsaren. Detta förutsätter dock att affärssystemet är designat som ett eller flera CORBA objekt, vilket inte är särskilt vanligt idag.

      En av de vanligaste metoderna för att anropa externa funktioner är Remote Procedure Call (RPC). Ett RPC innebär att ett anrop sker till en extern funktion och att denna exekverar lokalt för att sedan returnera resultatet (i fall det finns något att returnera).

      Fördelen med RFA är att all den funktionalitet som redan finns i affärssystemet återanvänds. Man behöver inte skriva nya funktioner som t.ex. är fallet om RDA (se kap 4.4) används. Dessutom så blir både affärssystem och Internetkoppling mer överskådligt i och med att de organiseras på ett objekt orienterat sätt. Den enda nackdelen är egentligen att det ställs höga krav på affärssystemet med avseende på dess organisation och struktur. I framtiden kommer detta problem att minska, eftersom alla affärssystemstillverkare idag har insett fördelarna med ett strukturerat tillvägagångssätt då de utvecklar nya affärssystem.

       

      CORBA

      CORBA (Common Object Request Broker Architecture) är utvecklat av OMG och syftar till att göra kommunikation mellan olika program i ett nätverk oberoende av lokala egenheter som t.ex. operativsystem eller hårdvara. Den grundläggande komponenten i CORBA[CORREF] är en Object Request Broker (ORB) som innehåller beskrivningar av alla funktioner som finns tillgängliga. Funktionerna i sig finns i program och kan vara spridda över hela nätverket. Dessa funktioner utgör CORBA objekt. Om ett program vill anropa en funktion hos något annat program, anropas detta via ORB. Funktionen exekverar sedan och returnerar resultatet. Fördelen med detta förfarande är att funktionen får exekvera lokalt och att alla funktioner har ett universellt gränssnitt i ORB.

      Microsoft har en egen lösning som har samma syfte som CORBA. Denna lösning kallas DCOM och används i alla Microsofts produkter som tillverkas idag.

    11. Remote Presentation Access

    Remote Presentation Access (RPA) är en metod som används då affärssystemet är att betrakta som svårtillgängligt. Det enda sättet att komma åt information i ett svårtillgängligt affärssystem är genom dess redan befintliga användargränssnitt. Detta gränssnitt är, liksom affärssystemet, i regel gammalt och stödjer ofta inte ens mus utan är helt tangentstyrt. RPA bygger på att tangenttryckningar (och eventuella musrörelser, om dessa stöds) simuleras för att på så sätt åstadkomma önskad händelse i affärssystemet. Att på detta sätt lura affärssystemet att tro att dess egentliga gränssnitt används kallas terminal emulering eller screen scraping. Terminal emulering bygger på att affärssystemet använder sig av terminaler som gränssnitt mot användaren. Vanliga terminaltyper är Digitals VT100 och IBM’s 3270. En terminal emulator placeras ofta i Internet gateway (se figur 8) men kan även köras direkt från Internetklienten. När sedan den eftersöka informationen returneras så tolkas denna i terminal emulatorn som sedan låter Internet gatewayen omvandla informationen så att klienten kan tolka den.

     

    Figur 8. Internetkoppling med hjälp av Remote Presentation Access (RPA).

    RPA används uteslutande då varken RDA eller RFA kan användas. Metoden är mycket inflexibel eftersom den kräver att affärssystemets gränssnitt inte ändras. Om detta sker måste hela kopplingen med terminal emulator göras om. Dessutom är metoden långsam p.g.a. att terminal emulering är processorkrävande. Metoden används dock i ganska stor utsträckning eftersom det är den enda lösningen tillgänglig om affärssystemet är för gammalt. Det finns en mängd väl utprövade terminal emulatorer kommersiellt tillgängliga.

  3. Befintliga affärssystem

Detta kapitel kommer att ge en översiktlig bild av sju av de mer dominanta affärssystemen idag. Systemen presenteras i bokstavsordning. De aspekter som denna genomgång avser adressera är:

Urvalet av vilka system som här tas upp har skett i samråd med personal på Telia Promotor samt Sören Janstål, DPU Data Research. Informationen nedan har inhämtats från telefonsamtal med personal från tillverkare/lokala representanter, trycksaker utgivna av tillverkare/lokala representanter samt från en rapport[OVUMRP] utgiven av OVUM. OVUM är en internationellt erkänd konsultfirma som arbetar med att producera tekniska och ekonomiska utvärderingar, främst inom dator- och IT-branschen. Alla affärssystemstillverkare som här nämns finns representerade på Internet. Mycket information har hämtats från dessa internetkällor.

Den information som här presenteras är den officiella information som finns tillgänglig. Under denna rapports sammanställning har det med största tydlighet framkommit att denna information inte alltid stämmer överens med verkligheten, i synnerhet då det gäller införandet av nya versioner och vad dessa innehåller. Det hör också till vanligheterna att en ny version släpps, utan att för den skull allt som utlovats är färdigutvecklat (t.ex. gränssnitt mot externa system). Man bör därför inte anta att det som här i nämns existerar i verkligheten. Informationen i detta kapitel bör ses som en redovisning av vilka mål som tillverkarna har. Målen brukar uppnås, men inte vid den tidpunkt som tillverkarna anger.

Information angående integrering har medvetet givits med sparsamhet. Detta beroende på att de flesta gränssnitt under utveckling och därmed informationen föränderlig. Istället ges hänvisningar till var information i framtiden står att finna. Dessa platser är troligtvis mindre föränderliga än den information som står där.

    1. ASW
      1. Företaget
      2. ASW tillverkas av International Business Solutions (IBS) med säte i Solna. IBS grundades 1970 och var då en avdelning för informationssystem i företaget PA Consulting. 1983 köptes IBS ut av dess chefer på PA Consulting. 1986 börsnoterades IBS på Stockholms fondbörs. Företaget expanderade kraftigt under de första femton åren (ca 50% per år) för att stabilisera sig i mitten på nittiotalet.

        IBS har under hela sin existens varit fokuserad på AS/400 som plattform för sina system. Företaget är nära knutet till IBM (som tillverkar och utvecklar AS/400) och är IBM´s största partner för mjukvara i Europa. Utvecklingen av ASW följer utvecklingen av AS/400 och företaget har inga planer på att erbjuda sin produkt i andra miljöer förrän efter år 2000. Företagets fokus på AS/400 gör att marknaden ser lite annorlunda ut för IBS än för konkurrerande tillverkare. Marknaden för AS/400 baserade system är oerhört fragmenterad, och fastän IBS är en av de allra största aktörerna på denna marknad så har de bara en marknadsandel på 2%. IBS fokuserar sina säljansträngningar på stora, distribuerade organisationer inom distribution, logistik och tillverkning.

        IBS utveckling beror, och kommer att bero på vilka strategiska val IBM gör för AS/400 plattformen. IBS kommer att fortsätta ha AS/400 som huvudplattform (server), och det är då naturligt att ASW´s utveckling följer AS/400. Kommande versioner kommer troligtvis ha sin bas i IBM´s San Fransisco projekt som innebär utveckling av ett multi-plattform klient-server verktyg för applikationsutveckling. ASW kan levereras med Windows 95/NT eller Internet klient. Som databas kan endast IBM DB2 användas.

        IBS implementerar oftast sina system själva, men i de fall där partners är inblandade så är det alltid en IBS anställd som leder projektet. IBS tar också på sig att anpassa ASW till varje kunds specifika behov, något som deras konkurrenter helst överlåter till partners.

      3. Integration

      ASW erbjuder goda möjligheter till integration. Det finns färdiga API:er för Remote Function Access. Enligt IBS så är det också möjligt att kommunicera direkt med databasen med hjälp av ODBC. Detta kräver dock kunskap om databasens uppbyggnad. Då ASW körs på AS/400 så är också ett 5250 gränssnitt tillgängligt för terminalemulering. ASW klassificeras som tillgängligt.

       

       

       

    2. BAAN
      1. Företaget
      2. Baan Company NV grundades 1978 av två bröder, Jan och Paul Baan. Företaget utvecklade till en början informationsystem och arbetade uteslutande i UNIX miljö. I slutet på 1980-talet var de ledande på marknaden för utveckling i UNIX. Baan Company NV var de som först introducerade begreppet ERP system, där ett datorsystem får styra hela värdekedjan i ett företag eller koncern. Det första ERP systemet från Baan kallades för Triton 1.0 och släpptes på marknaden 1990. Ytterligare tre versioner Triton utvecklades och släpptes innan Baan IV släpptes 1996. Den senaste versionen, BaanERP skulle släppts andra kvartalet 1998, men har blivit försenat. De första kommersiella implementationerna av BaanERP kan förväntas komma i början på 1999.

        Företaget hade likviditetsproblem 1993 och gick då med förlust. Den stora vändpunkten kom 1994 då Baan Company NV fick en order från Boeing som gick ut på att leverera ett system som täckte in hela Boeings organisation. 1995 kom 24 % av Baan Company NV´s inkomster från Boeing. Företaget inriktar sig mot stora kunder och på helhetslösningar. Andra kunder som kan nämnas är bl.a. Daimler-Benz, Ford, Philips och ABB. Moderbolaget sysslar numera nästan enbart med stora internationella affärer, och överlåter implementering, mindre affärer och service till återförsäljare eller partners. I Sverige representeras Baan Company NV främst av Baan Nordic och Ernst & Young.

        Baan har av tradition fokuserat sig på tillverkningsindustrin. 1997 var andelen system som såldes till tillverkningsindustrin 60 procent. På senare år har dock Baan Company NV insett nyttan i att ha konkurrenskraftiga finansiella verktyg att erbjuda sina kunder. Baan Finance är en modul som har blivit allt mer populär, även bland tjänste- och handels företag. Denna modul har alltid funnits, men har inte varit konkurrenskraftig mot de affärssystem som har fokus på finansiella tjänster. Numera är dock Baan Finance fullt jämförbart med sina konkurrenter, och har haft vissa säljframgångar. Baan Finance kan köras inkluderat i ett större Baansystem (t.ex. BaanERP), eller som enskilt programpaket. Baan Finance är den del av BaanERP som mest kan liknas till det som i denna rapport kallas för ett affärssystem. BaanERP innehåller betydligt mer. Värt att notera är att BaanERP inte har någon modul för "human resources", vilket så gott som uteslutande förekommer hos dess konkurrenter. BaanERP är förberett både för EMU och år 2000.

      3. Integration

      BaanERP är, till skillnad från tidigare versioner av Baan system, helt uppbyggt enligt objekt-orienteringens alla principer. Alla moduler kan integreras, oberoende av version. Baan kallar denna arkitektur för "Common Component Architecture"[BNVCCA] (CCA). I CCA presenteras gränssnitten mellan moduler, och även mot omvärlden, som Business Object Interfaces (BOI). Med hjälp av dessa BOI kan man således få tillgång till delar av den funktionalitet som finns BaanERP. Baan tillhandahåller ett verktyg för att kunna utnyttja dessa gränssnitt som heter BaanConnection. Detta verktyg innehåller stöd för att integrera DCOM, CORBA eller andra applikationer mot BaanERP via BOI. BaanERP är därmed lämpligt för integration med hjälp av RFA (se kap. 4.5) och kan klassificeras som tillgängligt.

      De två andra metoderna för integration (RDA och RPA) är inte att rekommendera. RPA rekommenderas inte för att gränssnittet innehåller för mycket information och inte är terminalbaserat. RDA är olämpligt på grund av att en skrivning till BaanERP innebär en skrivning till ett stort antal tabeller i databasen. Metoden kräver därmed ingående kunskap om databasens struktur, och missar man en tabell blir databasen inkonsistent (dvs. man kan få olika svar på samma fråga, beroende på var i systemet man frågar). Detta är naturligtvis oacceptabelt. Om man endast önskar att hämta information från BaanERP, är naturligtvis RDA ett alternativ.

      BaanERP skall kunna levereras med en Internetbaserad klient som kan köras i en Internetläsare. Denna klient syftar dock endast till att användas i ett intranät och inte över Internet. Baan har inte utvecklat några säkerhetslösningar för de fall då BaanERP skall kommunicera med något annat än det lokala nätverket, vare sig över Internet eller via något annat medium. Detta är något som Baan lämnar till den som vill utnyttja BaanERP på detta vis.

      När detta skrivs existerar varken BOI (för extern åtkomst), BaanConnection eller den Internetbaserade klienten.

    3. JD Edwards- One World
      1. Företaget
      2. JD Edwards & Company grundades 1977 av Edward McVaney och två kollegor. Edward McVaney blev företagets förste styrelseordförande och VD, och är det fortfarande idag. Företaget är inte börsnoterat vilket är ovanligt, med tanke på storleken på dess senaste ERP system, JD Edwards- OneWorld. JD Edwards & Company har under 70- och 80-talet vuxit till ett av de främsta företagen för utveckling av system anpassade för AS/400 plattform. För närvarande konkurrerar företaget med tre produkter, på tre olika marknadssegment (se tabell nedan)

        Produkt

        Marknad

        JD Edwards- One World

        Mycket stora organisationer

        JD Edwards- World Software

        Medelstora och stora företag

        Genesis (endast USA)

        Mindre privata eller offentliga organisationer

        World Software är den produkt som har funnits längst och kan enbart köras i AS/400 miljö. Den modernaste produkten är OneWorld som stödjer flera plattformar, t.ex. AS/400, UNIX och Windows NT. Genesis behandlas inte här, då den inte finns (eller kommer att finnas) i Europa. Även om JD Edwards & Company uppger att 92 % av tidigare WorldSoftware-kunder uppgraderade till nyare versioner, så är det tänkt att OneWorld skall ta över mer och mer. Detta innebär att marknadsfokus förflyttas mot större företag eller koncerner och hela vertikala marknader. Noterbart är att OneWorld och WorldSoftware kan dela på samma filstruktur, och därmed har viss kompatibilitet. JD Edwards & Company var tidiga med att utnyttja modern teknologi och det är först då detta skrivs som konkurrenterna börjar komma i kapp. OneWorld som släpptes 1996, ansågs då vara marknadsledande på den tekniska sidan.

        JD Edwards & Company implementerar själv de system som de säljer. Även support och utbildning sköts i huvudsak av moderbolaget. De har även ett antal internationella partners för implementering och applikationsutveckling. De mest välkända av dessa partners är bl.a. Arthur Andersen, Ernst & Young och Coopers & Lybrand. I Sverige representeras JD Edwards & Company i huvudsak av SysTeam och IBM. Företaget har dock som mål att så mycket implementationsarbete som möjligt skall allokeras till partners.

        Bland de kunder som JD Edwards & Company har kan nämnas Shell Oil, Elektrolux, Volvo Penta och Gillette.

      3. Integration

OneWorld använder sig av fem nivåers klient-server, vilket får anses vara anmärkningsvärt. Denna modell kallas Configurable Network Computing[JDECNC] (CNC). De fem nivåerna är :

Detta förfarande gör att det erbjuds goda möjligheter till integrering, och JD Edwards har varit medvetna om detta när de designat systemet. Systemet har goda gränssnitt till både databas och intern funktionalitet och kan kategoriseras som lättillgängligt. Ett unikt särdrag är att OneWorld erbjuder, förutom vanlig RDA i form av ODBC (endast läsning), ett gränssnitt som tillåter skrivning till databasen, något som annars brukar vara omöjligt då databasen brukar vara för komplicerad. Detta gränssnitt heter JDEBase. Detta gränssnitt ser till att alla tabeller som skall uppdateras blir det, något som annars brukar vara ett problem då databasen är komplex.

Det gränssnitt som rekommenderas av JD Edwards är dock JDENet. Detta gränssnitt gör OneWorlds affärslogik tillgänglig för omvärlden, dvs. metoden är RFA. JD Edwards har föredömligt lagt ut hela detta gränssnitt[JDEAPI] på Internet, så att det finns lätt tillgängligt. OneWorld skall inom kort vara tillgängligt via COM, CORBA och MQ-series. Dessutom kommer OneWorld att kunna kommunicera med konkurrentsystemet SAP R/3 via SAP ALE/Idoc.

OneWorld kan idag levereras med en webbklient, men denna är avsedd för intranät, och inte för extern access över Internet. Det finns inga åtgärder vidtagna för att göra informationsutbyte med Internet säkert.

 

 

    1. Movex
      1. Företaget
      2. Intentia grundades 1984 och hade redan då som mål att konkurrera internationellt. Företaget var ett av de första att inse fördelarna med att sälja förändringsarbete samtidigt som man säljer affärssystem. Konceptet var att kombinera programvaruexpertis med kunskap om affärsprocesser. Detta koncept ser till alla affärsprocesser som en del av en leverantörskedja. Intentia rekryterar både IT kompetens och unik branschkompetens inom sina fokuseringsbranscher. Dessa fokuseringsbranscher är främst inom tillverknings- och distributionsbranschen. Intentia är Europas tredje och världens åttonde största affärssystemstillverkare[INTPLA]. Företaget växer snabbt både organiskt och ekonomiskt, även i relation till sina konkurrenter.

        Intentia har tagit till sig av kritiken om affärssystemstillverkares långa och oberäkneliga implementeringstider och tagit fram en metod för att på ett så snabbt och effektivt sätt kunna utföra sina uppdrag. Denna metod kallas för Implex.

        Företaget finns för närvarande representerat i över 40 länder. De lokala representanterna kallas för Movex Business Partners och arbetar i de flesta fall uteslutande med Movex. En Movex Business Partner har ensamrätt på sin egen marknad.

        Nyligen släpptes Movex ver. 11 som kan erbjudas helt i Java. Detta är ganska unikt för branschen. Anledningen till att hela systemet i princip översatts till Java är att Intentia vill komma ifrån problemen med olika hårdvarukonfiguration i olika delar av kundföretag. Systemet kan köras på antingen OS/400 eller NT servermiljö. På klientsida erbjuds bara Microsoft som alternativ (Windows NT/95/98).

      3. Integration

      Intentia hänvisar till öppna API:er då det gäller integration. Direkt databasaccess är möjligt , men inget de rekommenderar. API:erna består av två delar, klient interface och Movex interface. Det är klient interface som är designade för att användas av tredjeparts utvecklare. Movex API är det gränssnitt där kommunikationen mellan klient och server sker. Movex är klassificerat som tillgängligt. API:erna är utvecklade i C/C++, Active X eller Java och använder kommunikationsprotokollen SNA och TCP/IP.

      Movex är ett av de få affärssystem som har egna initiativ tagna i säkerhetshänseende. Kommunikationen via Movex/Klient API kan krypteras med ett 32 till 448 bitars krypto. Av juridiska skäl används endast 40 bitar som standard.

    2. Oracle Applications ver. 11
      1. Företaget

Oracle grundades 1977 av Larry Ellison, och är av tradition främst ett databasutvecklingsföretag. I databasbranschen är Oracle dominerande, och var de första att inse relationsdatabasens potential. Eftersom databaser alltid varit Oracles främsta arbetsområde, har utvecklingen av ERP system fått stå tillbaka, och det är först på 1990- talet som ERP system nämns i företagets affärsplan. Detta har inneburit både för- och nackdelar. Eftersom Oracle kom ganska sent in på affärssystemsmarknaden, så har de kunnat bygga på relativt moderna tekniker, utan att behöva ta hänsyn till en redan befintlig kundbas. En av nackdelarna är att Oracle har haft svårt att se vilka av dessa moderna tekniker som är här för att stanna.

Företaget hade stor nytta av de UNIX kunskaper som utvecklandet av databaser hade givit, och var i början av 1990-talet marknadsledande för UNIX baserade affärssystem. Denna position reducerades 1994 till en andraplats då SAP gick förbi, och denna plats innehar Oracle då detta skrivs.1997 hade Oracle Applications en marknadsandel på 13%. Oracle Applications är idag inte ett enbart UNIX baserat, utan kan köras på ett flertal plattformar. Ett särdrag är att Oracle Applications version 11 enbart kan använda NT- eller en webbläsarklient. Detta är en följd av Oracles stora satsning på NC[ONCREF] (Network Computer). En NC är ett alternativ till det vanligare PC (Personal Computer). Istället för att ha en dator med hårddisk som exekverar (delvis) lokalt vilket ofta är fallet då PC används, så använder man en dator som utför väldigt lite arbete, utan överlåter detta åt en server. Fördelarna med NC är främst underhållsmässiga. Det råder stor oenighet om huruvida NC kommer att bli något annat än en övergående trend.

Oracle både installerar och utvecklar Oracle Applications själva, men har beroende på hög arbetsbelastning valt att låta partners sköta delar av implementationsarbetet. Det finns även ett samarbete kallat CAI (Cooperative Application Initiative) som går ut på att skapa ett nätverk av tredjeparts utvecklare, som har gemensamt att de alla utvecklar applikationer som kompletterar Oracle Applications funktionalitet.

Liksom sina huvudkonkurrenter har Oracle valt att fokusera på vertikala marknader. De kunder som har behov som inte kan uppfyllas inom dessa vertikala marknader hänvisas till partners eller CAI medlemmar.

De referenskunder som använder Oracle Applications i Sverige är:

Oracle Applications kan levereras med webbklient. Dessutom har Oracle tagit fram tre speciella webbmoduler som är till för att på ett intuitivt sätt kunna utföra vissa relativt enkla tjänster mot Oracle Applications via Internet. De tre modulerna är Oracle Webb- Kund, Leverantör och Anställda. Det finns inga steg tagna för att göra kommunikationen mellan dessa moduler och affärssystemet säker.

      1. Integration

Oracle Applications är utvecklat under ganska unika premisser, då Oracle själva också utvecklar databasen. Detta har fått till följd att databasens gränssnitt är väldigt väl utvecklat, och att det finns s.k. stored procedures som gör det möjligt att både läsa och skriva till databasen, oavsett dess komplexitet. Dessutom finns det för CAI medlemmar, öppna API:er att tillgå om man vill utnyttja den funktionalitet som redan finns i Oracle Applications. Oracle Applications klassificeras som lättillgängligt.

 

 

 

    1. SAP R/3
      1. Företaget
      2. SAP grundades 1972 av fem ingenjörer anställda på IBM i Tyskland. Ett projekt som IBM hade på att utveckla ett realtids ekonomi- och materialflödes system för ICI, resulterade i att dem fem ingenjörerna tillförskaffade sig rättigheterna till det system som skulle utgöra grunden för SAP’s första system. Sedan dess har företaget växt på ett formidabelt sätt och SAP har med sitt system SAP R/3 en marknadsandel[SAPCOP] på 36%. Denna marknadsandel gör SAP till den överlägset största aktören på marknaden. Även ekonomiskt har det gått enastående, speciellt sedan R/3 släpptes 1992. Som ett exempel på SAP’s ekonomiska resultat kan nämnas att vinsten ökade med 59% under de första nio månaderna 1998 till 2,4 miljarder DM(!), enbart på SAP R/3. SAP’s största marknad är Tyskland, som är världens tredje största mjukvarumarknad. Europa har traditionellt sett varit den världsdel som SAP säljer mest i, dock har försäljningen i Nordamerika ökat på senare tid. Under det första halvåret 1998 stod Europa och Nordamerika för 90% av SAP’s försäljning, och de båda världsdelarna bidrog med ungefär hälften var. SAP säljer förutom R/3, också stordatorsystemet R/2[SAPR/2]. 1997 genererade R/2 en vinst på ca 110 miljoner DM.

        SAP insåg tidigt att det var viktigt med lokal representation, och är därför väl representerade i de flesta länder. Detta är en filosofi som skiljer sig från vissa konkurrenter, som gärna låter sig representeras av partners. I mitten på nittiotalet var SAP tvungna att frångå sin princip av egen lokal representation på grund av att de helt enkelt inte hann med att tillgodose den efterfrågan som fanns efter R/3. När SAP’s ledning insåg detta, inledde de nära samarbete med lokala partners, under förbehållet att de tillhandahöll personal dedicerad helt till R/3, både säljare, implementatörer och support. SAP utbildade sedan denna personal, och ansåg sig därigenom ha säkrat kvaliteten hos sina lokala partners. De flesta implementationer utförs numera av dessa lokala partners. SAP har fått mycket kritik för sina dyra och tidsödande implementationer och har på senare tid vidtagit åtgärder för att minska ner dessa. SAP är bland de dyrare ERP-systemen om man ser till ren mjukvarukostnad, och anser sina höga implementationskostnader vara hämmande.

        När R/3, som är ett klient-server system, började utvecklas, var det en förändring i strategi för SAP som låg bakom. Företaget hade tidigare enbart arbetat i stordatormiljö. R/3 var tänkt att köras i AS/400 miljö, men svårigheter i utvecklingsarbetet gjorde att det blev UNIX. Numera kan R/3 även köras i AS/400, NT och stordatormiljö. R/3 är uppbyggt enligt klassisk klient-server modell, och har fått kritik för sin centraliserade uppbyggnad. Kritikerna har, med visst fog, hävdat att denna organisation medför stora underhållskostnader. Det har dock visat sig att de kunder som valt R/3 räknat med dessa kostnader, utan att låta dessa hindra dem. R/3 har rykte om sig att vara ett robust och prestandasäkert system som med tiden blivit världsledande med avseende på funktionalitet inom områdena ekonomi, logistik, tillverkning och personal. SAP har, liksom sina främsta konkurrenter, valt att inrikta sig på vertikala[SAPVER] marknader.

        R/3 kan levereras med webbklient avsedd för Intranät. Denna klient är dock en nedbantad version, som endast ger tillgång till delar av R/3’s funktionalitet. Klienten kan användas med Internet som medium, men liksom de flesta andra tillverkare av affärssystem, utvecklar SAP inte själva några säkerhetslösningar. Däremot har de ett certifieringssystem, där andra företag[SAPCER] kan utveckla produkter som kompletterar SAP, bland annat säkerhetslösningar. Certifieringen innebär att SAP har testat och godkänt produkten, samt att SAP har bidragit med utbildning om R/3.

      3. Integration

      R/3 erbjuder stora möjligheter till RFA integration. SAP har definierat ett gränssnitt som kallas för BAPI[SAPBAP] som är tillgängligt via ett flertal metoder. R/3 erbjuder dock inte något stöd för RDA eller RPA och kan därmed klassas som tillgängligt.

      BAPI kan anropas[SAPCAL] på flera sätt. R/3 kommer stödja DCOM och CORBA från och med version 4.0. För R/3 på Windows NT eller 95 finns BAPI i form av ActiveX kontroller och C++ klass bibliotek. För övriga operativsystem så finns BAPI tillgängligt som Java klass bibliotek. Det finns även stöd för RFC och Borland Delphi.

       

       

    2. Scala ver. 5
      1. Företaget
      2. Scala Business Solutions NV är ett företag som skiljer sig från mängden, både i hur företaget utvecklats över åren, och i dess sätt att göra affärer. Företaget grundades 1978 i Sverige men hette då Beslutsmodeller. Efter ett tag bytte företaget namn till Scala International och den första Scala produkten presenterades 1988. Företaget insåg tidigt möjligheterna i de nya marknaderna som öppnades upp då Sovjetunionen föll samman, och expanderade snabbt. Till skillnad mot de flesta andra internationella affärssystemstillverkare så ville Scala inte själva expandera utomlands, utan valde att skaffa sig lokala partners i de länder de ville expandera till. Då expansionen i Östeuropa gick mycket bra bildades Scala ECE 1993 av europeiska finansiärer för att ansvara för distribution av Scalas produkter i just Östeuropa. Scala Internationals expansion fortsatte och 1996 visade det sig att ledning och finansiella rutiner inte hade utvecklats i samma takt som företaget. Detta ledde till stora finansiella problem. Samtidigt hade Scala ECE utvecklats på ett bra sätt och 1997 valde Scala International och Scala ECE att gå samman till Scala Business Solutions NV med säte i Wien. Scala Business Solutions väntas gå med vinst från och med 1998.

        Scalas produkter har utvecklats i Sverige och har sin största kundbas i Europa. Detta har fått till följd att produkterna är väldigt flexibla då det gäller valutakonvertering och språk (till skillnad från system som utvecklats i Nordamerika, där sådana behov inte uppstår förrän systemens skall säljas på andra kontinenter). Företaget har haft som policy att låta den lokala partnern utveckla den lokala versionen med moderföretagets produkt som utgångspunkt. När denna lokala version är färdig har denna införlivats i originalprodukten. Detta tillvägagångssätt är ganska unikt i affärssystems-branschen.

        Scala Business Solutions inriktar sig liksom de flesta andra tillverkare på vertikala marknader, men har utvecklats från att ha fokus på mindre och medelstora företag till att nu rikta in sig mot större kunder. Företaget ser sina främsta konkurrenter i SAP, Baan, Oracle och JD Edwards men har funnit en egen nisch då de inriktar sig på att komplettera dessa system i stora koncerner. Stora koncerner är ofta geografiskt utspridda, ibland över flera kontinenter. Dessa koncerner har ofta ett gemensamt affärssystem som alla de stora avdelningarna använder. Om t.ex. huvudkontoret ligger i USA så använder alla USA avdelningar ett system, medan avdelningar i Europa kan välja att ha ett annat system. Scala Business Solutions har valt att fokusera på de avdelningar där det blir för dyrt att installera ett större system t.ex. SAP R/3. Företaget har också den fördelen att det genom sin flexibla språk- och valutahantering kan vara en god lösning för avdelningar som verkar över landgränser. Scala används bland annat av ABB, Pepsi, Samsung, Siemens, Sony och Coopers & Lybrand.

        Systemet (Scala 5) kan levereras med webb- eller Windows 95/NT klient. Som servermiljö kan NT eller Novell användas. Klienterna är feta i den mening att mycket arbete utförs av klienten istället för på servern. Webbklienten är dock tunn och körs i en webbläsare.

      3. Integration

Scala 5 är uppbyggt kring Microsofts COM arkitektur och använder sig av Microsoft produkter för att kommunicera med omvärlden (t.ex. Internet Information Server och Microsoft Transaction Server). Öppna COM API:er (ActiveX) är under utveckling och kommer att börja släppas i början på 1999. De funktioner som först kommer är de för OrderEntry, externa kunder och kundunderhåll (ca 200 stycken). Målet är att ca 2500 funktioner skall göras tillgängliga på detta sätt.

Liksom de flesta andra affärssystem så är databasen omöjlig att skriva direkt till utan god kunskap om dess struktur. Scala 5 kan därmed klassas som tillgängligt.

Det finns idag inga funktioner för att kommunicera med Internet på ett säkert sätt.

  1. Ett praktiskt exempel — WorldSoftWare och Internet
  2. I detta kapitel presenteras en praktisk tillämpning av de principer som redovisats i kapitel tre och fyra. Det affärssystem som används heter WorldSoftWare och är utvecklat av JD Edwards. Målsystemet (WorldSoftWare) innehas av konsultföretaget SysTeam Applications i Huskvarna och används för närvarande inte i det dagliga arbetet. SysTeam anser dock att de nuvarande system som används snart kommer att ha tjänat ut, och avser inom kort att migrera från dessa till WorldSoftWare. Uppgiften var att göra WorldSoftWare´s funktionalitet tillgänglig från Internet.

    1. Beskrivning och klassificering av WorldSoftWare
    2. WorldSoftWare är föregångaren till JD Edwards OneWorld som tidigare beskrivits (se kapitel 5.4) och är liksom OneWorld ett ERP system. Målsystemet körs i AS/400 miljö och har inget grafiskt användargränssnitt, utan använder sig av 5250 terminaler för presentation av information. Det finns en möjlighet att få tillgång till ett grafiskt användargränssnitt (Windows 95/NT), då i form av terminal emuleringar. Dessa emuleringar är skapade av ett program som heter GUI/400 som tillverkas av Seagull .

      Databasen är integrerad med affärslogiken på ett komplicerat sätt, vilket får till följd att varje skrivning till gränssnittet leder till ett flertal skrivningar i databasen. Detta gör WorldSoftWare olämpligt för direkt databaskommunikation (RDA). Det finns heller inga öppna API för att göra dess funktionalitet tillgänglig utifrån (RFA). Dessa faktorer gör att målsystemet klassificeras som svårtillgängligt.

    3. Uppgift
    4. SysTeam Applications har länge upplevt sitt system för tidrapportering som inflexibelt och långsamt. Konsulter som vill tidrapportera men som inte befinner sig i SysTeams lokaler, använder ett vanligt modem och kopplar sig mot företagets lokala nätverk, via allmänna telefonnätet. Tiden rapporteras i ett system som heter SysTid, vilket även används för rapportering av reseersättning, traktamente m.m. Metoden anses otillräcklig på grund av att den är långsam och att det saknas en direkt koppling till de centrala ekonomisystemen.

      Det finns en önskan hos SysTeam att förbättra sina rutiner för extern tidrapportering, samtidigt som man vill migrera från SysTid till WorldSoftWare. Internet är ett önskvärt medium, då detta medium är tillgängligt för alla med ett modem och ett telefonurtag. Uppgiften är således att föreslå en lösning till tidrapportering via Internet, samt att implementera denna hos SysTeam.

    5. Avgränsningar
    6. Eftersom det upplevs som irriterande med långa väntetider vid tidrapportering så skall lösningen vara så snabb som möjligt. Ingreppet (dvs. installation) på klientsidan skall också minimeras. Dessutom skall det förutsättas att användaren utnyttjar en långsam Internetförbindelse tex. ett modem uppkopplat mot Internet, via det allmänna telefonnätet. Dessutom skall säkerhetsnivån hos webbkopplingen återspegla det behov som SysTeam anser sig ha.

    7. Diskussion
    8. Vilken av de principer som genomgås i kap 4.4-4.6 är då mest lämpad för att göra målsystemet tillgängligt via Internet? Direkt databaskommunikation (RDA) är olämpligt på grund av att en skrivning till WorldSoftWare´s databas innebär en skrivning till ett stort antal tabeller i databasen. Metoden kräver därmed ingående kunskap om databasens struktur. Detta är naturligtvis oacceptabelt, både för tillverkare och tredjepartsutvecklare. Om man endast önskar att hämta information från WorldSoftWare, är naturligtvis RDA ett alternativ.

      Återanvändning av WorldSoftWares affärslogik i form av Remote Function Access (RFA) hade varit önskvärt, men inga gränssnitt finns utvecklade. WorldSoftWare använder sig inte av någon gränssnittsstandard i form av CORBA eller DCOM. Utvecklandet av sådana gränssnitt skulle naturligtvis vara möjligt, men knappast inom ramen för ett examensarbete (i alla fall inte detta). Således får RFA stryka på foten.

      Den återstående principen för integration, Remote Presentation Access, är tillämpbar och väljs enligt uteslutningsmetoden. WorldSoftWare utnyttjar 5250 terminalgränssnitt mot sina användare. Det finns ett flertal kommersiella produkter som kan emulera 5250 terminaler till någon form av Internetgränssnitt. Ett exempel på en sådan produkt är IBM Host On-Demand (HOD). HOD är en produkt som konverterar 5250 terminaler till Java applets, som laddas ner i en Internetläsare och exekverar lokalt hos användaren. Då Java appleten genereras varje gång en uppkoppling görs, kommer man ifrån en del av den inflexibilitet som RPA vanligen innebär. Det är fullt möjligt att ändra gränssnittet i målsystemet utan att för den skull få något merarbete i form av att HOD måste konfigureras om.

    9. Lösning
    10. En grafisk presentation av den föreslagna lösningen återges i appendix B. De tekniska detaljerna i implementationen presenteras i appendix C.

      1. Integration med Host On-Demand och ResQ!net

Host On-Demand

Host On-Demand är en terminal emulator som kan konvertera bl.a. 5250 terminalgränssnitt till körbar Javakod (applet). HOD skall installeras på samma dator som en webbserver exekverar på. Installationsprogrammet kan fås att konfigurera webbservern så att HOD´s publiceringsbibliotek publiceras i webbservern. I publiceringsbiblioteket finns bl.a. de filer som utgör de olika klienter man kan välja mellan.

HOD är uppbyggt av ett flertal delar som alla utför olika saker. Vissa av dessa delar används inte i denna tillämpning, då deras användningsområde faller utanför de avgränsningar som ställts upp. Dessa delar behandlas inte här. De delar som är relevanta beskrivs nedan.

Servern är den del som tillhandahåller administratörens gränssnitt, de olika klienternas gränssnitt samt ett antal stödsystem som är osynliga för användaren. Både administratörens och de olika klienternas gränssnitt nås via en Internetläsare (administratörens gränssnitt kan väljas till att endast vara tillgänglig lokalt genom att inte tillåta kommunikation på serverport 8989. Detta görs i brandväggen.). Administratörsgränssnittet används bl.a. för att skapa användare och användargrupper. För varje användare eller användargrupp kan man sedan definiera sessioner mot ett eller flera målsystem (dock endast ett målsystem per session). Administratörsgränssnittet tillhandahåller även andra funktioner, tex. felsökning och servicekontroller.

Redirectorn gör det möjligt för de olika klienterna att nå olika telnet servers (målsystem), även om dessa inte residerar på samma maskin som HOD. Det stöd för kryptering (SSL) som HOD erbjuder, handhas av Redirectorn.

Klienter med varierande egenskaper. Eftersom dessa egenskaper är väsentliga för lösningens prestanda, redovisas de relevanta klienterna mer utförligt nedan. Funktionaliteten för de olika klienterna är dock den samma. Alla klienter tillåter att man definierar sessioner. Detta sker på samma sätt som i administratörsgränssnittet. Man kan dock inte skapa grupper eller gruppspecifika sessioner på användarnivå. En sessionsdefinition innehåller bl.a. följande information:

Sessioner startas även från klienten.

HOD har tre för uppgiften relevanta klienter, Cached client, Download client och Function On-Demand client. De olika klienterna representerar olika tillvägagångsätt i kommunikationen mellan HOD och användare. De tre klienterna testades med avseende på tidsprestanda (se appendix A).

Cached client innebär att hela klienten laddas ned i diskcacheminnet första gången klienten används. Nästa gång klienten skall användas, tittar HOD om några förändringar av klienten har skett. Om inte laddas klienten från cacheminnet, annars så hämtas huvuddelen från cacheminnet och resten (förändringarna) från HOD servern. Följden av detta förfarande blir att klienten blir mycket snabb om man bortser från första gången den används. Det är således olämpligt att använda sig av denna klient om man inte använder samma maskin varje gång. Sitter man vid samma maskin varje gång man använder HOD, så är klienten ett gott val.

Download client innebär att hela klienten laddas ner varje gång den skall användas. När uppkopplingen bryts så får man ladda ner hela klienten igen, nästa gång man skall använda den. Klienten är den långsammaste av de tre (se appendix A).

Function On-Demand client innebär att funktioner laddas ner efterhand som de behövs, t.ex. laddas 5250 emulatorn ner på en gång medan filtransport funktioner kanske aldrig laddas ner. Detta får till följd att startförfarandet blir snabbare än för de andra klienterna. Denna klient är avsedd att användas över långsamma förbindelser.

Det finns fler klienter att välja mellan, men ingen av dessa har någon tillämpbarhet då de inte passar in under de avgränsningar som uppställts.

Kommunikationen mellan målsystemet och HOD klienten sker enligt 5250 standard över Telnet-protokollet. Java appleten som laddas ner då klienten startas, konverterar sedan informationen så att den kan ses i en Internetläsare.

ResQ!net för Host On-Demand

ResQ!net är en separat programvara utvecklad av Advanced Transition Technologies som skapar ett grafiskt användargränssnitt till de terminaler man önskar emulera. Det går även att modifiera de skärmbilder som skapas genom att t.ex. lägga till flervalmenyer, tryckknappar odyl. ResQ!net installeras på samma maskin som HOD servern ligger på. Figur 9 visar på skillnaden i utseende hos en klient då ResQ!net används.

Figur 9. Bilden visar skillnaden i utseende för en session mot målsystemet då ResQ!net (nederst) används.

      1. Säkerhet

Med integrationslösningen ovan, så kan vem som helst försöka logga in på HOD servern, eller lyssna av den trafik som passerar mellan HOD klient och server. Dessutom ligger målsystemet öppet för telnet trafik, via HOD servern. För att säkra upp denna trafik, och för att stänga ute obehöriga användes en säkerhetsprodukt som heter TeamWare Intranet Security Server (TWISS) [TWISSX]. Denna produkt skapar en säkerhetstunnel (se kap 3.4) för all IP trafik som skickas igenom den. Denna tunnel är således tillräcklig för att fylla det behov som finns i denna uppgift.

TWISS sköter både autentisering och kryptering. Programvaran stödjer DES, 3DES eller Blowfish sessionskrypton och använder sig av RSA 1024 bitars krypto för autentisering. Det är även möjligt att använda smartkort för autentisering

TWISS består av en server och ett antal klienter. Servern placeras innanför brandväggen, och måste ligga på en egen maskin som har en publikt åtkomlig IP adress. Denna maskin måste därför ha två nätverkskort, så att den även kan ha en lokal IP adress in mot det lokala nätverket. Det är också säkerhetsmässigt fördelaktigt att skilja det publika och privata nätet åt fysiskt.

TWISS administreras från administratörsgränssnittet på servermaskinen (TWISS kan även administreras på andra sätt, men dessa tas inte upp här). I administratörsgränssnittet finns funktioner för att administrera användare och grupper, tilldela dessa grupper rättigheter samt loggar av olika slag. Även krypteringsnycklar genereras och distribueras med hjälp av administratörs-gränssnittet.

Klienterna residerar på användarens datorer och är mycket små (<1 MB). Klienten installeras på ett intuitivt sätt men kan inte användas förrän den aktiverats dvs. erhållit den asymmetriska nyckel som används för autentisering. Denna nyckel placeras i en så kallad distributionsfil då användaren skapas i servern och skyddas av ett lösenord. Distributionsfilen skall sedan på lämpligaste (säkraste) sätt distribueras till användaren. Detta kan tex. göras med hjälp av en diskett. När användaren sedan fått tillgång till distributionsfilen är det enkelt att aktivera klientprogramvaran med hjälp av det lösenord som filen tilldelades då den skapades. När denna sedan är installerad och aktiverad så handhas klienten på samma sätt som vilket annat program som helst. Aktivering sker endast första gången man kör programmet. Därefter måste man logga på med hjälp av ett av användaren själv angivet lösenord.

Varje användare kan (i servern) definieras så att den antingen tilldelas en lokal IP adress dynamiskt, eller att den alltid finns på samma fasta lokala IP adress. Antalet lokala IP adresser som finns tillgängliga (och därmed också antalet samtidiga användare av krypteringstunneln) anges också i servern. När en användare efter uppkoppling tilldelats en lokal IP adress, är det som om användarens dator sitter på det lokala nätet.

Klientprogramvaran känner själv av om de IP adresser som man försöker få tillgång till i tex. en Internetläsare, är de som skall nås via tunneln (dvs. är adresser på det lokala nätet). Är de inte det så används inte tunneln. Användaren kan således öppna tunneln när denna startar datorn och sedan arbeta som vanligt. Tunneltrafiken sker helt transparent för användaren.

Detaljerna i implementeringen av säkerhetslösningen redovisas i appendix C.

  1. Slutsatser och rekommendationer

En koppling mellan ett WorldSoftware system och Internet har implementerats.

Metoden för integration mot Internet som valdes utifrån målsystemets egenskaper var Remote Presentation Access. Denna metod beskrivs i litteraturen som långsam och inflexibel. Den implementation som gjorts visar att det går att göra en RPA lösning som är flexibel och som har acceptabla svarstider. Att lösningen skulle vara särskilt processorkrävande har det inte heller funnits några belägg för. Snarare har belastningen på Internet och den egna Internetuppkopplingen varit begränsande.

Däremot kan man hävda att som metod för integration överhuvudtaget, tex. för integration mot andra stödsystem, så är metoden relativt oanvändbar. Speciellt om man som i detta fall använder sig av terminalemulering. Det finns dock i den utvärderade programvaran (IBM Host On-Demand) möjlighet att via ett antal Java klasser (Java Host Access Class Library) komma åt den information som finns i terminaldataströmmen, och möjligen skulle denna metod vara användbar i ett mer generellt scenario. Denna möjlighet har dock inte testats.

Då det gäller Telia Promotors framtida affärsmöjligheter på området finns det en del att säga. Eftersom de flesta affärssystemleverantörer har Internet kapacitet för sina produkter och inte vill ta på sig uppgiften att göra denna access säker, finns det ett behov att fylla. Leverantörerna har insett behovet av att tredjeparts utvecklare ges enkel och kraftfull tillgång till affärslogik i form av öppna API:er för att kunna komplettera deras system, när kunden har behov som inte täcks av leverantörernas verksamhetsområde. Här finns det möjligheter för Telia Promotor.

Rekommendationer

  1. Internetadresser
  2. Här listas Internetadresser som är relevanta, men inte referenser i denna rapport.

    Advanced Transition Technologies hemsida: http://www.resqnet.com/

    Baan´s hemsida: http://www.baan.com

    Concorde´s hemsida: http://www.ibm.se/concorde/

    IBM Host On-Demand : http://www.software.ibm.com/enetwork/hostondemand/

    Intentias (Movex) hemsida: http://www.intentia.com/

    Introduktion till smartkort : http://www.smartcard.co.uk/tech1.html

    JD Edwards hemsida: http://www.jdedwards.com/

    Object Management Group : http://www.omg.org/

    Oracles hemsida: http://www.oracle.com

    SAP AG’s hemsida: http://www.sap.com

    Scala´s hemsida: http://www.scala.se

    Seagull´s hemsida: http://www.seagullsw.com/

    SysTeam´s hemsida: http://www.systeam.se

    TeamWare´s hemsida: http://www.teamware.com

    WM data´s hemsida: http://www.wmdata.se/intro.htm

     

     

     

     

     

     

  3. Referenser

Om du skickar ett email till Sören Janstål (email) kan du få resterande bilagor och en MS PowerPoint presentation av rapportinnehållet.


ERP market, just this minute

Hämta faktainsamlingsformulär/ checklista för utvärdering av affärs- och ekonomisystem utan kostnad.

Lämna din egen bedömning av någon programvara eller system och erhåll marknadsanalys och checklista utan kostnad!

Lämna din egen bedömning av en IT leverantör och erhåll marknadsanalys och checklista utan kostnad!

Data Research DPU
för utvärdering av IT - Informationsteknologi och Data Produkter


[ Beställning | Mer info | Förslag ny utvärdering ]
[ Konsulttjänster | Utbildning | Priser | Distributionslista ]
[ Kontakt ]

Tillbaka till Data Research DPU startsida.


Data Research DPU ab - Torsvikssvängen 34, SE-181 34 Lidingö, Sweden - Telefon 070-727 67 95 Skype: sjanstal, SkypeIN: 08-559 25 900 - Kontakt (email)



Ataio

Plats nr 5 för sponsor/s


Plats nr 9 för sponsor - Ledig (s)


Metodika