FITS-julkaisuja 20/2003. Tavaraliikenteen telematiikka-arkkitehtuuri Loppuraportti

FITS-julkaisuja 20/2003 Tavaraliikenteen telematiikka-arkkitehtuuri Loppuraportti

FITS-julkaisuja 20/2003 Tavaraliikenteen telematiikka-arkkitehtuuri Loppuraportti

ISBN 951-723-881-9 FITS-julkaisuja Helsinki 2003

Julkaisija KUVAILULEHTI Julkaisun päivämäärä Tekijät (toimielimestä: toimielimen nimi, puheenjohtaja, sihteeri) Jani Granqvist (VTT), Harri Hiljanen (VTT), Antti Permala (VTT), Pasi Mäkinen (CGE&Y), Valtteri Rantala (CGE&Y) ja Aki Siponen (CGE&Y) Julkaisun laji Toimeksiantaja Liikenne- ja viestintäministeriö Toimielimen asettamispäivämäärä Julkaisun nimi Tavaraliikenteen telematiikka-arkkitehtuuri. Loppuraportti Tiivistelmä Kansallinen järjestelmäarkkitehtuuri on tavoitearkkitehtuuri, jonka avulla liikenne- ja viestintäministeriö tukee liikennetelematiikan kansallista kehitystä, arvioi yksittäisten hankkeiden hyödyllisyyttä ja arkkitehtuurin noudattamista. Tavaraliikenteen telematiikka-arkkitehtuuri on osa liikenne- ja viestintäministeriön FITSohjelman horisontaalista hankealuetta Liikennetelematiikan palvelujen edellytysten kehittäminen. Arkkitehtuurin tavoitteena on antaa organisaatioille mahdollisuus parantaa kilpailukykyään markkinoilla tehokkaamman toiminnan, monipuolisemman palvelutarjonnan tai paremman yhteensopivuuden muodossa. Arkkitehtuuri kuvaa toimijoiden välisten järjestelmien avoimia rajapintoja sitoutumatta tiettyihin teknologioihin ja puuttumatta yritysten sisäisiin järjestelmiin. Yritys voi verrata nykyistä toimintaansa kansalliseen käsitykseen tavoitetilasta lähtökohtana oman toiminnan, toimijakohtaisen arkkitehtuurin tai yksittäisen järjestelmän kehittämiselle. Aikatähtäin on vähintään 10 vuotta ja keskeisiltä osiltaan arkkitehtuuri on ikuinen. Tavaraliikenteen telematiikka-arkkitehtuurin näkökulmana on tavaran ja siihen liittyvien tietojen kulkeminen lähettäjältä logistiikkaketjun läpi aina vastaanottajalle asti. Arkkitehtuuri keskittyy tavaroiden kuljettamiseen suoranaisesti liittyviin prosesseihin ja näiden prosessien tietovirtoihin. Arkkitehtuuri kattaa eri kuljetusmuodot sisältäen tie-, raide-, vesi- ja ilmakuljetukset. Arkkitehtuuri on kuvattu kuljetusmuotoriippumattomasti siten, että prosessikomponenteista voidaan koota erilaiset tosielämässä esiintyvät kuljetusketjut. Arkkitehtuuriin on määritelty tavaran lähettäjän, vastaanottajan, logistiikkapalveluiden tuottajien ja julkishallinnon roolit. Kuvatut tavaraliikenteen prosessialueet ovat suunnittelu, ohjaus, toimitus sekä seuranta ja jäljitys. Tietovirrat käsittävät tavaratilauksen, kuljetussopimuksen, kuljetustilauksen, lähetysluettelon ja kuormanerittelyn ohjaustietoja, seuranta- ja muita tietoja. Looginen arkkitehtuuri sisältää tieto-objektien ja näistä johdettujen tietopalveluiden kuvauksen ja tietojärjestelmäpalveluiden kuvauksen. Tietomalli on kuvattu relaatiokaaviona. Relaatiokaavio kuvaa tietojoukot ja niiden väliset pysyvät suhteet. Tutkimuksessa on tarkasteltu nykytilanteen puutteita ja tarpeita kuvattuun tavoitetilaan nähden. Esille nousi kolme kehittämisaluetta: tietoinfrastruktuurin kehittäminen, tunnistuksen kehittäminen ja prosessien kehittäminen. Eurooppalaisen KAREN-arkkitehtuurin alueen 8 kuvaukset käsittelevät maantieliikenteen osalta samaa ongelma-aluetta. KAREN-arkkitehtuurikuvauksia on käytetty tarkistuslistana sekä toimintojen että tietovirtojen osalta. Avainsanat (asiasanat) telematiikka, arkkitehtuuri, logistiikka, tavaraliikenne, prosessit, standardointi, viitekehys, kehittäminen Muut tiedot Sarjan nimi ja numero FITS-julkaisuja 20/2003 Kokonaissivumäärä 123 Kieli suomi Jakaja VTT Rakennus- ja yhdyskuntatekniikka ISSN Hinta Kustantaja Liikenne- ja viestintäministeriö ISBN ISBN 951-723-881-9 Luottamuksellisuus julkinen

The publisher DESCRIPTION Date of publication Authors (from body, name, chairman and secretary of the body) Jani Granqvist (VTT), Harri Hiljanen (VTT), Antti Permala (VTT), Pasi Mäkinen (CGE&Y), Valtteri Rantala (CGE&Y) ja Aki Siponen (CGE&Y) Type of publication Assigned by Ministry of Transport and Communications Date when body appointed Name of the publication Transport telematics-architecture. Final Report Abstract The national architecture system is a reference architecture through which the Ministry of Transport and Communications supports the national development of the transport telematics, estimates the usefulness of the individual projects and monitors how the architecture is followed. The freight transport telematics architecture is a part of the horizontal project area of the FITS programme Prerequisites for ITS services. The objective of the architecture is to provide the opportunity to improve the organisation s competitive ability on the market in the form of more efficient operations, a more versatile service supply or better compatibility. The architecture describes open interfaces between the actors without binding them to specific technologies and without intervening in the internal systems of companies. An organisation can compare its present operations with a national vision of the target conditions as a starting point for development of its operations, actor-specific architecture or individual systems. The time horizon is at least 10 years and the central parts of the architecture are eternal. The viewpoint of the architecture is the freight and related information flowing through the logistics chain from sender to receiver. The architecture focuses on the processes that are directly related to the transport of goods and on the information flows of these processes. The architecture covers the different modes of transport including road, rail, water and air. The architecture has been described independent of transport mode so that the process components can be collected in actual transport chains. The architecture contains role definitions for the sender, the receiver, the logistics service providers and the public administration. The described process areas of the freight transport are planning, management and control, supply chain operations, and tracking and tracing. The information flows comprise management data, track and trace data and other data related to the goods order, transport agreement, transport order, dispatch note and load specification. The logical architecture contains the description of information objects and the information services that are based on these as well as the description of information system services. The data model has been described as an entity-relationship diagram. This relationship scheme represents the data groups and the permanent relations between them. The study identifies the deficiencies and needs of the present situation compared to the future vision. Three areas for development were defined: information infrastructure, identification and processes. The descriptions of area 8 of the European KAREN architecture describe the same problem area for road transport. The KAREN architecture descriptions have been used as a checklist for both functions and data flows. The study has been granted European Community financial aid in the field of Trans-European Networks - Transport. Keywords Telematics, architecture, logistics, goods transportation, processes, standardisation, framework, development Miscellaneous Serial name and number FITS publications 20/2003 Pages, total 123 Distributed by VTT Building and Transport Lanquage Finnish ISSN Price ISBN ISBN 951-723-881-9 Confidence status Public Published by Ministry of Transport and Communications

ESIPUHE Tavaraliikenteen telematiikka-arkkitehtuuri on osa liikenne- ja viestintäministeriön käynnistämä FITS-ohjelman läpikulkevaa horisontaalista hanketta Liikennetelematiikan palvelujen edellytysten kehittäminen. Työ on jatkoa tavaraliikenteen telematiikka-arkkitehtuurista laaditulle esiselvitykselle. Työ käynnistyi alkusyksyllä 2002 ja on nyt päättynyt ylätason arkkitehtuurikuvauksen osalta. Tavaraliikenteen telematiikalla tarkoitetaan lähetys-, kuljetus-, terminaali-, ja vastaanottotoiminnoissa sekä näiden toimintojen suunnittelussa ja ohjaamisessa tarvittavan tiedon tuottamista, käsittelyä ja välittämistä tieto- ja tiedonsiirtotekniikkaa hyödyntäen. Tavaraliikenteen telematiikka-arkkitehtuuri kuvaa tavarankuljetuksen yleisen prosessin. Näkökulmana on tavaran ja siihen liittyvien tietojen kulkeminen lähettäjältä logistiikkaketjun läpi aina vastaanottajalle asti. Prosessi on kuvattu kuljetusmuotoriippumattomasti siten, että prosessikomponenteista voidaan koota erilaiset tosielämässä esiintyvät kuljetusketjut. Keskeistä kuvauksessa on tavarankuljetukseen liittyvien tietovirtojen sekä tietojen, niiden syntymisen ja omistajuuden mallintaminen. Tutkimuksessa on tarkasteltu nykytilanteen puutteita ja tarpeita kuvattuun tavoitetilan prosessiin nähden ja muodostettu näistä priorisoidut kehittämissuunnitelmat. Tutkimuksen on tehnyt työryhmä, jossa ovat olleet mukana Cap Gemini Ernst & Youngista Pasi Mäkinen, Valtteri Rantala ja Aki Siponen sekä VTT Rakennus- ja yhdyskuntatekniikasta Jani Granqvist, Harri Hiljanen ja Antti Permala. Tutkimusraportin ovat tarkastaneet yli-insinööri Seppo Öörni liikenne- ja viestintäministeriöstä ja tutkija Mikko J. Lehtonen VTT:ltä. Työtä on ohjannut ohjausryhmä, johon kuuluivat liikenne- ja viestintäministeriöstä Lassi Hilska ja Helena Vänskä, Henric Bladh (Danzas), Kari Litja (Logistiikkayhdistys), Mikko Melasniemi (Teollisuus ja työnantajat), Sven-Gustaf Lindroos (EAN Finland), Pertti Pietikäinen (SKAL), Markku Tilli (AIM Finland), Hannu Vaarama (Vikingline), Sirkka-Liisa Holmberg (VR Cargo), Klaus Katara (Kaupan keskusliitto), Pekka Rautiainen (EP-Logistics Oy), Ilkka Tirkkonen (Kiitolinja), Juha Boman (TNT Finland). Selvityksen tekemiseen on saatu Euroopan unionin liikenteen perusrakenteen kehittämiseen tarkoitettua TEN-T (Trans-European Networks-Transport) -rahoitusta. Helsingissä maaliskuussa 2003 Lassi Hilska Liikenneneuvos, yksikön päällikkö 5

SISÄLTÖ ESIPUHE...5 TIIVISTELMÄ...9 1 JOHDANTO...13 1.1 Projektin lähtökohdat...13 1.2 Arkkitehtuurityön eteneminen...14 1.3 Liitynnät muihin liikennetelematiikan arkkitehtuurihankkeisiin...14 1.3.1 Liikennetelematiikan kansallinen järjestelmäarkkitehtuuri TelemArk...14 1.3.2 Eurooppalainen liikennetelematiikan puitearkkitehtuuri KAREN...15 1.3.3 Muut hankkeet ja tutkimukset...15 2 ARKKITEHTUURIN TAUSTA JA TAVOITTEET...17 2.1 Tavaraliikenteen telematiikka-arkkitehtuurin visio...17 2.2 Arkkitehtuurin tavoitteet ja rajaus...18 2.3 Logistiikan trendejä...19 2.4 Ulkomaisia esimerkkitapauksia...20 3 ARKKITEHTUURIN RAKENNE JA KÄYTTÖ...21 3.1 Prosessien kuvaus...21 3.2 Tietojen kuvaus...25 3.3 Tietojärjestelmäpalvelujen kuvaus...25 3.4 Tietovarastojen kuvaus...25 3.5 Arkkitehtuurin tulkinta...25 3.6 Arkkitehtuurin soveltamisen käyttötapaukset...27 3.6.1 Tavaraliikenteen telematiikan palveluja toteuttava organisaatio...27 3.6.2 Arkkitehtuurin omistaja, liikenne- ja viestintäministeriö...29 4 PROSESSIKUVAUKSET...31 4.1 Arkkitehtuurin soveltamisalue ja prosessikartta...31 4.2 Pääprosessien tietovirrat...37 4.3 Roolit ja toimijat...39 4.4 Osaprosessien yksityiskohtaiset kuvaukset...40 4.4.1 Toimitusketjun suunnittelu...41 4.4.2 Toimituksen suunnittelu...43 4.4.3 Toimitusketjun ohjaus prosessi...44 4.4.4 Toimitusketjun seuranta...45 4.4.5 Lähetys...46 6

4.4.6 Kuljetus... 47 4.4.7 Välikäsittely... 50 4.4.8 Vastaanotto... 51 4.4.9 Viranomaistoiminnot... 54 4.5 Johtopäätöksiä... 55 5 LOOGINEN ARKKITEHTUURI... 56 5.1 Tietoarkkitehtuuri... 56 5.1.1 Tietomalli... 56 5.1.2 Reaalimaailman käsitteet ja tietomalli... 62 5.1.3 Seurantatiedon luonteesta... 66 5.1.4 Tieto on ennustetta tai faktaa... 67 5.1.5 Prosessikomponentit ja tietomalli... 68 5.1.6 Tietovirtojen tietojoukot... 68 5.1.7 Tietojen luottamuksellisuudesta... 68 5.2 Tietojärjestelmäpalvelut... 69 5.2.1 Tietojärjestelmäpalveluiden integraationäkymä (hajautuskaavio)... 69 5.2.2 Tietojärjestelmäpalveluiden määritykset... 70 5.2.3 Prosessien käyttämät tietojärjestelmäpalvelut... 73 5.3 Tietopalvelut... 75 5.3.1 Tietopalveluiden määritykset... 75 5.3.2 Tietopalveluiden kokonaiskuva / ydinkohdemalli... 76 6 KEHITTÄMISSUUNNITELMA... 79 6.1 Prosessien puutteet ja kehittämistarpeet... 79 6.1.1 Yleistä... 79 6.1.2 Tärkeimmät puutteet ja kehittämistarpeet... 81 6.1.3 Kaikkia prosesseja koskevat... 82 6.1.4 Toimitusprosessi... 85 6.1.5 Suunnittelu... 87 6.1.6 Ohjaus... 88 6.1.7 Seuranta ja jäljitys... 89 6.2 Kehittämisohjelmat... 90 6.2.1 Kehittämisohjelmien koostaminen... 90 6.2.2 Tietoinfrastruktuurin kehittäminen... 91 6.2.3 Tunnistamisen kehittäminen... 92 6.2.4 Prosessien kehittäminen... 93 7 ARKKITEHTUURIN YLLÄPITO JA KEHITTÄMINEN... 96 7.1 Toimintaympäristön muutokset... 96 7.1.1 Vaatimusten ja tavoitteiden muuttuminen... 96 7.1.2 Arkkitehtuurin rajauksen muuttuminen... 96 7.1.3 Muutokset toimijoissa... 97 7

7.1.4 Toimintoprosessien muuttuminen...97 7.2 Teknologian muutos...97 7.2.1 Teknisten edellytysten parantuminen...97 7.2.2 Uudet standardit...98 7.3 Arkkitehtuurin jalkauttaminen...98 7.3.1 Tiedotus...98 7.3.2 Koulutus...99 7.3.3 Kansainvälinen arkkitehtuurityö...99 7.3.4 Ohjaus...99 7.3.5 Esitutkimuksessa osoitetut arkkitehtuurityön jatkovaiheet...99 LÄHDELUETTELO...101 LIITTEET Liite 1. Yritys- ja asiantuntijahaastattelut Liite 2. Työpajoihin osallistuneet henkilöt Liite 3. Kokonaisprosessin prosessikuvaus Liite 4. Tietovirtojen kuvaukset Liite 5. Prosessikomponenttien käyttämät tietojoukot Liite 6. Prosessin tietovirtojen tietojoukot Liite 7. Tietojärjestelmäpalveluiden hajautuskaavio Liite 8. Puutteiden ja kehittämistarpeiden priorisointi työpajassa 14.1.2003 käsitellyt lausumat 8

TIIVISTELMÄ Tavaraliikenteen telematiikka-arkkitehtuuri on osa liikenne- ja viestintäministeriön käynnistämää FITS-ohjelman läpikulkevaa horisontaalista hanketta Liikennetelematiikan palvelujen edellytysten kehittäminen. Liikennetelematiikan eurooppalainen puitearkkitehtuuri KAREN kuvaa tieliikenteen telematiikan kahdeksan toiminnallista aluetta, joista yksi käsittelee tiekuljetusten ja kaluston hallintaa. KAREN-arkkitehtuurin pohjalta on Euroopan maissa kehitetty ja kehitetään kansallisia puitearkkitehtuureja. Suomessa puitearkkitehtuurien kehitys on tehty kahdessa vaiheessa: TETRA-ohjelmaan kuuluneessa tutkimuksessa Liikennetelematiikan kansallinen järjestelmäarkkitehtuuri TelemArk kuvattiin telemaattiset palvelut henkilöliikenteen osalta ja tavaraliikenteen osalta ne on kuvattu Tavaraliikenteen telematiikka-arkkitehtuurissa. Tavaraliikenteen telematiikka-arkkitehtuuri on KARENarkkitehtuurin tieliikenteen kuljetusten ja kaluston hallinta -osuutta laajempi, sillä se kattaa kaikki kuljetusmuodot. Arkkitehtuurilla tavoitellaan tehokkuutta Tavaraliikenteen telematiikalla tarkoitetaan lähetys-, kuljetus-, välikäsittely-, ja vastaanottotoiminnoissa sekä näiden toimintojen suunnittelussa ja ohjaamisessa tarvittavan tiedon tuottamista, käsittelyä ja välittämistä tieto- ja tiedonsiirtotekniikkaa hyödyntäen. Arkkitehtuurin tavoitteena on antaa organisaatioille mahdollisuus parantaa kilpailukykyään markkinoilla tehokkaamman toiminnan, monipuolisemman palvelutarjonnan tai paremman yhteensopivuuden muodossa. Arkkitehtuuri kuvaa toimijoiden välisten järjestelmien avoimia rajapintoja sitoutumatta tiettyihin teknologioihin ja puuttumatta yritysten sisäisiin järjestelmiin. Tavaraliikenteen telematiikan arkkitehtuuri keskittyy tavaroiden kuljettamiseen suoranaisesti liittyviin prosesseihin ja näiden prosessien tietovirtoihin. Näkökulmana on tavaran ja siihen liittyvien tietojen kulkeminen lähettäjältä logistiikkaketjun läpi aina vastaanottajalle asti. Prosessit on kuvattu kuljetusmuotoriippumattomasti siten, että prosessikomponenteista voidaan koota erilaiset tosielämässä esiintyvät kuljetusketjut. Keskeistä kuvauksessa on tavarankuljetukseen liittyvien tietovirtojen sekä tietojen, niiden syntymisen ja omistajuuden mallintaminen. Visio Tavoitetilassa, kun tavaraliikenteen telematiikka-arkkitehtuurissa määritellyt asiat on toteutettu:

Yksilöityjen ja tunnistettujen lähetysten, tuotteiden, kuljetuspakkausten ja kuljetusvälineiden sijainnista, sisällöstä sekä olosuhteista voidaan kerätä tietoja reaaliaikaisesti ja hallitusti. Kerätty tieto kyetään yhdistämään suunnitelmatietoon ja jalostamaan tarkoituksenmukaiseen muotoon hyödynnettäväksi prosessin eri osissa sekä jakelemaan tehokkaasti ja ajantasaisesti prosessin toimijoille. Keräämällä, jalostamalla ja jakelemalla tietoa tehokkaasti organisaatiot kykenevät tehostamaan tavarankuljetuksen prosessia, alentamaan operatiivisia kustannuksiaan ja parantamaan logistiikkapalvelujen tarjontaa. Arkkitehtuurin aikatähtäin on vähintään 10 vuotta ja keskeisiltä osiltaan arkkitehtuuri on ikuinen. Tämä tarkoittaa sitä, että arkkitehtuurin kuvaa toimintaa ja toiminnan tarpeita ideaalitilanteessa. Arkkitehtuuri on ohjausväline Arkkitehtuurin tulee ennen kaikkea olla ohjaava ja mahdollistava; se antaa lähtökohdat toimialakohtaisten ja liikennemuotokohtaisten (osa-)arkkitehtuurien kehittämiselle ja se ohjaa alan toimijoita arkkitehtuurin mukaiseen kehittämiseen. Kansallinen järjestelmäarkkitehtuuri on tavoitearkkitehtuuri, jonka avulla liikenne- ja viestintäministeriö tukee kansallista kehitystä liikennetelematiikan alueella, arvioi yksittäisten hankkeiden hyödyllisyyttä ja arkkitehtuurin noudattamista. Yritykset puolestaan voivat verrata nykyistä toimintaansa kansalliseen käsitykseen tavoitetilasta lähtökohtana oman toiminnan, toimijakohtaisen arkkitehtuurin tai yksittäisen järjestelmän kehittämiselle. Toimialan globaalisuus, kansainvälisen standardointi- ja harmonisointikehityksen nopea eteneminen ja toimijoiden runsaus tuovat haasteellisuutta tavaraliikenteen telemaattisten palvelujen kehittämiseen. Arkkitehtuurin laatiminen saattaa helpottaa erityisesti pkyritysten liittymistä osaksi tavaraliikenteen laajenevia tietoverkostoja. Arkkitehtuurin toteutukseen vaikuttaa kuitenkin merkittävästi myös se, kuinka valmiita alan osapuolet ovat sitoutumaan arkkitehtuurin kehittämiseen ja käyttämiseen. Tavaraliikenteen telematiikan arkkitehtuuri tukee erityisesti organisaation yleisen toimintakonseptin ja järjestelmäarkkitehtuurin käsittelyä ja kehittämistä, mutta antaa myös rajoitetusti suuntaviivoja yksittäisille järjestelmille. Arkkitehtuurissa on kuvattu tavarankuljetuksen prosessi Toimijoiden osalta arkkitehtuuriin sisältyy lähettäjän, vastaanottajan ja logistiikkapalveluiden tuottajien ja julkishallinnon roolit. Kuvatut tavaraliikenteen prosessit ovat Suunnittelu, Ohjaus, Toimitus sekä Seuranta ja jäljitys. 10

Toimitus-prosessissa kuvataan tavaran fyysiseen kuljettamiseen liittyvät toiminnot Lähetys Kuljetus Välikäsittely Vastaanotto-ketjussa. Näistä osaprosesseista voidaan Kuljetus- ja Välikäsittely-prosesseja eri tavoin yhdistelemällä rakentaa erilaisia toimitusketjuja kuvaavat prosessit. Osaprosessien rajapinnat on määritelty niin, että rajapinnassa vaihtuu vastuu kuljetettavasta tavarasta. Ohjaus-prosessin osat liittyvät erittäin kiinteästi vastaaviin Toimitus-prosessin osiin, joten Ohjaus-prosessissa noudatetaan samaa osaprosessijakoa kuin Toimitusprosessissa. Lisäksi Ohjausprosessissa on mukana Toimitusketjun ohjaus. Suunnittelu- sekä Seuranta ja jäljitys -prosesseissa kuvataan sekä logistiikkapalvelujen tuottajan (kuljetusoperaattorin tai välikäsittelyoperaattorin) prosessit että koko toimitusketjusta vastuullisen operaattorin prosessit. Materiaali- ja tietovirrat on erotettu omiin prosesseihinsa: Materiaalivirta kulkee Toimitus-prosessissa toimijalta seuraavalle ja materiaalivirtaa vastaava tietovirta (lähetysluettelo / kuormanerittely) vastaavasti Ohjaus-prosessissa toimijalta seuraavalle. Tämän ohjausprosessissa kulkevan lähetyksen tietoja sisältävän tietovirran lisäksi prosessin peräkkäiset toimijat vaihtavat ohjaustietoja: he tekevät keskenään ohjaussopimuksen, jotta materiaalivirran luovutus ja haltuunotto toimijoiden kesken voidaan hoitaa hallitusti. Koko prosessin toimimisen kannalta on keskeisen tärkeää, että lähetysluettelotietovirran tiedot ovat oikeita. Tässä on lähettäjällä suuri vastuu; syntyyhän valtaosa tiedosta Lähetys-prosessissa. Suunnittelu-, Ohjaus- sekä Seuranta ja jäljitys -prosessit ovat hierarkkisia: niissä on selkeästi olemassa sekä koko toimitusketjusta vastaavan toimijan osuus että yksittäisistä palveluista (kuljetusketjun etapeista ja välikäsittelypalveluista) vastaavan toimijan osuus. Näitä kahta roolia käyttämällä on pyritty erottamaan kuljetuskaluston käytön optimointiin keskittyvä toimija (logistiikkapalveluoperaattori) ja koko kuljetuksen optimointiin keskittyvä toimija (toimitusketjuoperaattori) toisistaan. Pääprosessien väliset tietovirrat on luokiteltu niiden sisällön mukaan reaalimaailman käsitteillä kuvattuna. Tietovirrat on luokiteltu tavaratilauksen ja kuljetussopimuksen tietoja sisältäviin. Nämä ovat pääosin tavarankuljetuksen prosessialueeseen ulkopuolelta tulevia tietovirtoja. kuljetustilauksen tietoja sisältäviin tietovirtoihin. lähetysluettelon ja kuormanerittelyn tietoja sisältäviin tietovirtoihin ohjaustietoja sisältäviin tietovirtoihin. Usein ohjaustiedot ovat prosessin / toimijan sisäisiä tietovirtoja. seurantatietoja sisältäviin tietovirtoihin. muihin (luokittelemattomiin) tietovirtoihin. 11

Tietojärjestelmien tiedot ja toiminnallisuus on kuvattu palveluarkkitehtuurina Looginen arkkitehtuuri sisältää tietoarkkitehtuurin, tietojoukkojen ja näistä johdettujen tietopalveluiden kuvauksen, ja tietojärjestelmäpalveluiden kuvauksen. Looginen arkkitehtuuri kuvaa rakenteen, joka täyttää käsitteellisen arkkitehtuurin määrittelemät ja mallintamat tarpeet; tarkoituksena on tuoda arkkitehtuurissa käsitteellisellä tasolla (prosesseissa) kuvatut asiat tasolle, jolla voidaan määritellä ne erillisiksi eri tietojärjestelmin toteutettaviksi kokonaisuuksiksi. Teknologiaratkaisuihin ei oteta kantaa, vaan kuvataan kokonaisratkaisun toiminnalliset ja tiedolliset osat. Tietoarkkitehtuurissa kuvataan tietojoukot, niiden keskinäiset suhteet ja niiden suhteet prosessin tietovirtoihin sekä reaalimaailman käsitteisiin, kuten lähetysluetteloon. Lisäksi on hahmoteltu tietojoukkojen tiedon luottamuksellisuustasoja sekä ennakkotiedon ja toteutumatiedon suhdetta. Tavoitetilan vision toteutumiselle on keskeisen tärkeää seurantatiedon kerääminen ja käsittely. Seurantatietoa on kaikki kerätty sisältö-, sijainti-, olosuhde- ja tapahtumatieto. Tietomalli on rakennettu niin, että sisältötiedon avulla saadaan minimoitua tallennettavan sijainti-, olosuhde- ja tapahtumatiedon määrä. Sisältötietoa on tarpeen kerätä vain pistekohtaisesti niistä pisteistä, joissa sisältöön voi tulla muutoksia. On huomattava, että sisältötietoa on kerättävä kaikilta seurantayksikkö-tasoilta: kuljetusvälineestä, kuljetusyksiköstä ja kollista. Tavoitetilaan on vielä matkaa Tutkimuksessa on tarkasteltu nykytilanteen puutteita ja tarpeita kuvattuun tavoitetilaan nähden. Esille nousi kolme kehittämisaluetta: tietoinfrastruktuurin kehittäminen, tunnistuksen kehittäminen ja prosessien kehittäminen. Haastattelujen ja työpajojen yhteydessä kartoitettiin ne asiat, jotka tällä hetkellä puuttuvat kokonaan tai joita täytyy kehittää arkkitehtuurityön kuvaaman tavoitetilan saavuttamiseksi. Prosessikohtaiset puutteet ja kehitystarpeet yhdistettiin kehittämisohjelmiksi. Usein kyseessä on yhteisen tahtotilan löytäminen ja sitoutuminen sen toteuttamiseen. Lisäksi haettiin sopivia vastuutahoja ja muita kehittämisohjelmien aloittamiseen ja toteuttamiseen osallistuvia tahoja. 12

1 JOHDANTO 1.1 Projektin lähtökohdat Tavaraliikenteen telematiikka-arkkitehtuuri -tutkimus on jatkoa keväällä 2002 tehdylle Tavaraliikenteen telematiikka-arkkitehtuurin esiselvitykselle 1. Tutkimus on osa FITS-ohjelman läpikulkevaa horisontaalista hanketta Liikennetelematiikan palvelujen edellytysten kehittäminen. Hanke on jatkoa TETRA-ohjelman hankkeille 7 (Kaikki liikennemuodot kattava liikenteen tietojärjestelmä), 8 (Liikennetelematiikan palveluiden edellytysten kehittäminen) ja 9 (Arkkitehtuuri- ja standardointityö). TETRA-ohjelmaan kuuluneessa tutkimuksessa Liikennetelematiikan kansallinen järjestelmäarkkitehtuuri TelemArk kuvattiin yksitoista henkilöliikenteen telemaattista palvelua. Ohjelmassa tehtiin myös ehdotus arkkitehtuurin tärkeimmistä standardeista rajapinnoista liikennetietojen välittämiseen. Arkkitehtuurista saaduissa lausunnoissa ja arkkitehtuuria käsitelleissä työpajoissa useat organisaatiot esittivät kansallisen arkkitehtuurin laajentamista koskemaan myös tavaraliikennettä. Tavaraliikenteen telematiikka-arkkitehtuurin kehittämisen esiselvitys käynnistettiin keväällä 2002 selvittämään, onko kansalliselle arkkitehtuurille tarvetta, millä tasolla arkkitehtuurin tulisi olla ja mitkä olisivat arkkitehtuurin painopistealueet. Esiselvityksessä katsottiin tärkeäksi kuvata tavaraliikenteen perusprosessit, käsitteistö ja toimijoiden väliset keskeiset rajapinnat. Esiselvityksen perusteella päätettiin käynnistää varsinainen arkkitehtuurityö. Tutkimus käynnistyi syyskuussa 2002 ja raportti valmistui helmikuussa 2003. Arkkitehtuurin suunnitteluun haasteita tuo ennen kaikkea logistisen toimintaverkoston monimuotoisuus. Kun arkkitehtuurilla pyritään kuvaamaan niin maa-, raide-, meri-, kuin ilmakuljetustenkin toimintaprosesseja ja telematiikkatarpeita, oikean tasapainon löytäminen abstraktiotason ja kuvauksen konkreettisuuden välillä sanelee pitkälti lopputuloksen hyvyyden. Toimialan globaalisuus, kansainvälisen standardointi- ja harmonisointikehityksen nopea eteneminen ja toimijoiden runsaus lisäävät tehtävän haasteellisuutta. Arkkitehtuurin laatiminen saattaa helpottaa erityisesti pk-yritysten liittymistä osaksi tavaraliikenteen laajenevia tietoverkostoja. Arkkitehtuurin toteutukseen vaikuttaa kuitenkin merkittävästi myös se, kuinka valmiita alan osapuolet ovat sitoutumaan arkkitehtuurin kehittämiseen ja käyttämiseen. 1 LVM. 2002. Tavaraliikenteen telematiikka-arkkitehtuuri. Esiselvitys. FITS-julkaisuja 10/2002. 13

1.2 Arkkitehtuurityön eteneminen Arkkitehtuurityö tehtiin kolmessa vaiheessa: Projektin valmistelu -vaiheessa täydennettiin ja hyväksyttiin projektin työsuunnitelma ja valmisteltiin prosessien työstämistä sekä haastatteluja. Prosessien työstön valmisteluun liittyi tiedon siirto esiselvityksen tekijöiltä. Prosessien työstäminen -vaiheessa projektiryhmä muodosti nykytilaa kuvaavien kertomusten pohjalta tavoitetilan prosessien kuvaukset. Nämä prosessikuvaukset tarkastettiin kahdessa työpajassa joulu-tammikuussa. Arkkitehtuurin yhteenveto -vaiheessa työ jakaantui kahteen osaan: toisaalta kuvattiin tavoitetilan ja nykytilan välistä kuilua kehityskohteiden löytämiseksi, toisaalta viimeisteltiin tavoitetilan prosessien kuvauksia ja tehtiin varsinaista arkkitehtuurikuvausta. Kehityskohteista muodostettiin kehitysohjelmat. Projektin valmistelu Prosessien työstäminen Haastattelut Arkkitehtuurin yhteenveto Työsuunnitelman täydentäminen ja hyväksyminen Tavoiteprosessien valmistelu Arkkitehtuurimalli Arkkitehtuurin lukeminen ja käyttö Arkkitehtuurin päivittäminen Prosessien työstön ja haastattelujen valmistelu Tavoiteprosessien jalostus Validointityöpajat Tavoiteprosessien viimeistely Nykytilan puutteet ja tarpeet Puutteiden ja tarpeiden priorisointi - työpaja Puutteiden ja tarpeiden yhteenveto Kuva 1.1. Arkkitehtuurityön eteneminen. Haastatteluissa kerättiin keskeisten toimijoiden näkemyksiä nykytilasta, tulevaisuuden tavoitetilasta ja tarkastettiin tavoitetilan kuvauksia. 1.3 Liitynnät muihin liikennetelematiikan arkkitehtuurihankkeisiin 1.3.1 Liikennetelematiikan kansallinen järjestelmäarkkitehtuuri TelemArk Liikennetelematiikan kansallisessa järjestelmäarkkitehtuurissa, TelemArkissa 2 on kuvattu maantieliikenteen prosesseja ja telemaattisia palveluita. TelemArkissa kuvatuista prosesseista ainakin prosesseilla Häiriönhallinta, Riskikuljetusten hallinta, Tiedotus autoilijoille, Kysynnän ohjaus / Pääsyn säätely ja Liikenteen ohjaus on suoraan liit- 2 LVM B 1/2000. Liikennetelematiikan kansallinen järjestelmäarkkitehtuuri. Tiivistelmä LVM B 2/2000. Liikennetelematiikan kansallinen järjestelmäarkkitehtuuri. Kehittämissuunnitelma 14

tymä tässä työssä kuvattuihin prosesseihin maantieliikenteen osalta. Lisäksi näyttää siltä, että TelemArkin prosessikuvauksia voidaan varsin pienin muutoksin yleistää koskemaan myös muita liikennemuotoja, joten TelemArkin kuvauksia voidaan pitää myös yleisten liikennemuotoriippumattomien prosessikuvausten lähtökohtana. Tässä työssä ei kuitenkaan laajenneta TelemArkissa kuvattuja prosessikuvauksia liikennemuotoriippumattomiksi kuvauksiksi. 1.3.2 Eurooppalainen liikennetelematiikan puitearkkitehtuuri KAREN Alunperin liikennetelematiikan eurooppalainen puitearkkitehtuuri on toteutettu EUprojektissa Karen. Karen-projektin työtä jatkaa kaksi projektia FRAME-NET, jonka tavoitteena on tarjota kaikille Euroopassa käynnissä oleville arkkitehtuuriin liittyville hankkeille mahdollisuus kokemusten ja tiedon vaihtamiseen sekä FRAME-S, joka vastaa Euroopan arkkitehtuurin päivityksistä koulutustilaisuuksista ja arkkitehtuurin käytön ajantasaisesta opastamisesta. KAREN 3 kuvaa liikennetelematiikan kahdeksan toiminnallista aluetta, joista yksi käsittelee tavaraliikennettä. KARENin lähtökohtana on maantieliikenne. KARENin alue 8 käsittelee kuljetusten ja kaluston hallintaa keskitetyn logistiikkapalvelukeskuksen lähtökohdista käsin. Arkkitehtuurissa on mallinnettu toiminnot hierarkkisina kaavioina, niiden väliset tietovirrat ja tarvittavat tietovarastot. Alue jakaantuu kolmeen osaan: Osat 8.1 Logistisen ketjun ja kuljetusten hallinta sekä 8.2 Kaluston hallinta käsittelevät logistiikkapalvelukeskuksen toimintoja. Toiminnoista on mallinnettu myös muiden kuljetusmuotojen kuin maantiekuljetuksen käyttö, kuitenkin vain rajapintatasolla. Osa 8.3 Ajoneuvotoimintojen hallinta kuvaa kuljetuksenaikaiset tietovirrat ja informaatiotarpeet. Toiminnot on kuvattu suhteellisen yksityiskohtaisesti neljällä tasolla. Myös tietovirrat on kuvattu hierarkkisina. KAREN-arkkitehtuurin alueen 8 kuvaukset käsittelevät maantieliikenteen osalta täsmälleen samaa ongelma-aluetta kuin mitä tässä työssä käsitellään. KAREN-arkkitehtuurikuvauksia on käytetty tarkistuslistana sekä toimintojen että tietovirtojen osalta. 1.3.3 Muut hankkeet ja tutkimukset Sähköisen tiedonsiirron kehittämistä vaarallisten aineiden kuljetuksissa viranomaisnäkökulmasta käsitellään liikenne- ja viestintäministeriön rahoittamassa tutkimuksessa, jonka loppuraportti on ilmestynyt kesällä 2001 4. Työssä tarkastellaan varsinaisesti yksityisen sektorin saavutettavissa olevia hyötyjä vaarallisten aineiden kuljetuksen val- 3 European Communities. 2000. KAREN European ITS framework architecture. CD-ROM. 4 LVM A 34/2001. Sähköisen tiedonsiirron kehittäminen vaarallisten aineiden kuljetuksissa. 15

vontajärjestelmästä. Raportissa otetaan jossain määrin kantaa VAK-kuljetusten valvontajärjestelmän rakenteeseen ja toimijoiden työnjakoon. Logistiikkaputken EDI -tutkimuksessa 5 selvitettiin tavarakauppaan ja tavarankuljetukseen liittyvien asiakirjojen päällekkäisyyttä ja mahdollisuuksia vähentää käytössä olevien asiakirjojen määrää. Tutkimusta on käytetty hyödyksi lähinnä prosessin tietovirtojen sisällön hahmottamisessa. Tässä raportissa on lähtökohdaksi otettu Logistiikkaputken EDI -raportissa esitetyn tavoitetilan mukainen asiakirjojen tietosisältö. 5 LVM A 37/1998. Logistiikkaputken EDI. 16

2 ARKKITEHTUURIN TAUSTA JA TAVOITTEET Tässä luvussa kuvataan tavaraliikenteen telematiikka-arkkitehtuurin visio, tavoitteet ja soveltamisalue sekä prosessikartta. Visio kuvaa lyhyesti tavaraliikenteen tavoitetilaa sen jälkeen, kun arkkitehtuurissa määritellyt asiat on toteutettu. Tavoitteet ohjaavat työprosessin etenemistä lopputuloksen käytettävyyden, laadun, sisällön tai rajausten kannalta. Tavaraliikenteen prosessit on kuvattu arkkitehtuurin soveltamisalue -kaaviossa ja prosessikartassa. Arkkitehtuurin soveltamisalue esittää tavaraliikenteen prosessialueen toimintaympäristön ja projektin rajaukset. Prosessikartta on luettelo ylätason prosesseista, niiden tarkoituksesta, rajauksista, edellytyksistä ja mahdollisista toiminnan seurannan mittareista. 2.1 Tavaraliikenteen telematiikka-arkkitehtuurin visio Tavaraliikenteen telematiikka-arkkitehtuurin visio kuvaa tavaraliikenteen tavoitetilaa sen jälkeen, kun arkkitehtuurissa määritellyt asiat on toteutettu. Visio on esitetty oheisessa kuvassa (Kuva 2.1) Tavaraliikenteen telematiikka-arkkitehtuurin Visio Yksilöityjen ja tunnistettujen lähetysten, tuotteiden, kuljetuspakkausten ja kuljetusvälineiden sijainnista, sisällöstä sekä olosuhteista voidaan kerätä tietoja reaaliaikaisesti ja hallitusti. Kerätty tieto kyetään yhdistämään suunnitelmatietoon ja jalostamaan tarkoituksenmukaiseen muotoon hyödynnettäväksi prosessin eri osissa sekä jakelemaan tehokkaasti ja ajantasaisesti prosessin toimijoille. Keräämällä, jalostamalla ja jakelemalla tietoa tehokkaasti organisaatiot kykenevät tehostamaan tavarankuljetuksen prosessia, alentamaan operatiivisia kustannuksiaan ja parantamaan logistiikkapalvelujen tarjontaa. Kuva 2.1. Tavaraliikenteen arkkitehtuurin visio. 17

Vision perusta on yksittäisten tavaroiden ja tuotteiden, lähetysten, kuljetuspakkausten sekä kuljetusvälineiden tunnistaminen ja tietojen keruu niiden sijainnista, sisällöstä sekä olosuhteista. Tämän tiedon jalostamisella päästään tehostamaan prosesseja, alentamaan operatiivisia kustannuksia ja parantamaan logistiikkapalvelujen tarjontaa. Visio ei ota kantaa siihen, millä mittareilla prosessien tehostumista ja palvelutarjonnan paranemista mitataan. Mittarit voivatkin eri toimijoiden kannalta olla erilaisia. Teollisuudella, kaupalla ja muilla kuljetuspalveluja käyttävillä yrityksillä mittareina voivat olla puhtaasti taloudellisten mittareiden lisäksi läpimenoajat tai turhien kuljetusten väheneminen. Julkisen vallan kannalta mittareina esimerkiksi infrastruktuurin pidentynyt käyttöikä, liikenteen ympäristövaikutusten pieneneminen, yleisen elämän laadun paraneminen tavaraliikenteen tehostumisen seurauksena. 2.2 Arkkitehtuurin tavoitteet ja rajaus Arkkitehtuurin tavoitteita on esitetty oheisessa kuvassa (Kuva 2.2). Tavoitteet ohjaavat työn tekemistä antamalla suuntaviivoja, rajauksia, huomioon otettavia asioita ja kertomalla tavoiteltuja vaikutuksia. Tavoiteltuja seurauksia Arkkitehtuurin tulee antaa sitä hyödyntäville organisaatioille mahdollisuus parantaa kilpailukykyään markkinoilla tehokkaamman toiminnan, monipuolisemman palvelutarjonnan tai paremman yhteensopivuuden muodossa. Arkkitehtuurin tulee ohjata alan toimijat arkkitehtuurissa hahmoteltujen suuntaviivojen mukaiseen kehittämiseen. Arkkitehtuurin tulee antaa lähtökohdat liikennemuotokohtaisten ja toimialakohtaisten arkkitehtuurien kehittämiseen. Kansainvälisen kehityksen huomioivia Arkkitehtuurin tulee olla yhdenmukainen eurooppalaisten referenssiarkkitehtuurien kanssa. Arkkitehtuurin tulee mahdollisuuksien mukaan ottaa huomioon tiedossa ja ennakoitavissa olevat eurooppalaiset ja kansainväliset standardit ja säännökset. Arkkitehtuurin tulee ottaa huomioon tiedossa ja ennakoitavissa oleva eri tavaraliikenteen muodoissa tapahtuva kehitys. Sisältöön vaikuttavia Arkkitehtuurin tulee olla multi-modaalinen l. l. kaikki tavaraliikenne-muodot huomioonottava ja riippumaton eri toimialojen käytäntöjen eroista. Arkkitehtuurin tulee kuvata toimijoiden välisten järjestelmien avoimia rajapintoja sitoutumatta tiettyihin teknologioihin. Arkkitehtuurin tulee mahdollistaa reaaliaikainen yksittäisen lähetyksen seuranta- ja jäljitystiedon saanti läpi toimitusketjun. Arkkitehtuurin tulee ottaa kantaa tietojen luottamuksellisuuteen ja tietoturvallisuuteen prosesseissa. Arkkitehtuurissa ei kuvata asioita, jotka on jo kuvattu Liikennetelematiikan kansallisessa järjestelmäarkkitehtuurissa (TelemArk). Rajaukseen vaikuttavia Arkkitehtuurin tulee kuvata vain tavaroiden kuljettamiseen suoranaisesti liittyvät prosessit ja niiden tietovirrat. Arkkitehtuurin tulee perustua tavarankuljetuksen yleisten prosessien mallintamiseen. Arkkitehtuurin aikatähtäimen tulee olla vähintään 10 vuotta, keskeisiltä osiltaan arkkitehtuurin tulee olla ikuinen. Kuva 2.2. Tavaraliikenteen telematiikka-arkkitehtuurin tavoitteet. Arkkitehtuurin tulee ennen kaikkea olla ohjaava ja mahdollistava; sen on annettava lähtökohdat toimialakohtaisten ja liikennemuotokohtaisten (osa-)arkkitehtuurien kehittämiselle ja sen tulee ohjata alan toimijoita arkkitehtuurin mukaiseen kehittämiseen. Sisällöllisesti arkkitehtuurin tulee keskittyä vain tavaroiden kuljettamiseen suoranaisesti liittyviin prosesseihin ja näiden prosessien tietovirtoihin. 18

Keskeisenä arkkitehtuurin sisältöön ja muotoon vaikuttavana seikkana on aikatähtäin, jonka tulee olla vähintään 10 vuotta; keskeisiltä osiltaan arkkitehtuurin tulee olla ikuinen. Tämä tarkoittaa sitä, että arkkitehtuurin tulee kuvata toimintaa ja toiminnan tarpeita ideaalitilanteessa. 2.3 Logistiikan trendejä 6 Seuraavassa on käsitelty logistiikan kehitystrendejä siltä osin kun ne vaikuttavat telematiikka-arkkitehtuurin rakentamiseen ja hyödyntämiseen. Kolme vaikuttavaa asiaa ovat yhteistyö, läpinäkyvyys ja ulkoistaminen. Nämä vaikuttavat yritysten toimintatapoihin ja lisäksi ulkoistaminen muuttaa työnjakoon yritysten välillä. Yhteistyö (Collaboration, Partnership) Toimitusketjujen hallinnan (SCM) alueella merkittävimpiä uusia sovelluksia ovat erilaiset kollaboraation, yhteistyön kehittämiseen tähtäävät toimet. Yhteistyön arvioidaan tulevina vuosina lisääntyvän merkittävästi. Esimerkkejä logistiikkayhteistyötä parantavista menetelmistä ovat CPFR (Collaborative Planning, Forecasting and Replenishment) sekä VMI (Vendor Managed Inventory). Lähtökohtana on tiedon, prosessien ja resurssien jakaminen toimijaverkostossa, esimerkkeinä ennusteiden, kuljetus- ja varastokapasiteetin jakaminen ketjussa. Yhteistyö vaatii onnistuakseen standardeja ja malleja joita telematiikka-arkkitehtuuri osaltaan tuottaa. Yhteistyö parantaa verkostossa toimivien yritysten kilpailukykyä mm. alentamalla kustannuksia, lyhentämällä läpimenoaikoja ja tuottamalla parempaa palvelua. Yhteistyötä voidaan teknisesti toteuttaa mm. Internet portaalin kautta. Läpinäkyvyys (Supply Chain Visibility, Transparency) Läpinäkyvyys merkitsee sitä, että toimituksien ja tuotteiden sijainti toimitusketjussa voidaan nähdä, samoin tieto (data) on eri osapuolten nähtävissä. Läpinäkyvyys parantaa toimitusketjun hallintaa; tuotteiden toimituksia voidaan ohjata, suunnitella, seuranta kaikissa toimitusketjun osissa. Toimitusten nopeus ja ketteryys paranee ja samalla piiskavaikutus tasaantuu. Poikkeamatilanteiden hallinta on helpompaa kun ketjun eri vaiheet ovat näkyvissä. Hyötyjä ovat mm verkoston toiminnan tehokkuuden paraneminen, esimerkkeinä kustannukset, läpimenoajat ja varastotasot. Strategiat Ulkoistaminen Joka yritys on rakenteeltaan ja toiminnoiltaan erilainen. Ulkoistamiskehitys jatkuu edelleen. Yritykset keskittyvät ydinosaamiseensa ja ulkoistavat toimintoja myös logistiikan alueella. Arkkitehtuurin täytyy perustua toimijoiden ja prosessien tavoitetilaan, ei 6 CLM Annual Conference 2002. www.clm1.org 19

yritysten toimintoihin koska yritysten rajapinnat verkostoissa ovat erilaisia ja muuttuvat jatkuvasti. 2.4 Ulkomaisia esimerkkitapauksia 7 Keskitetty tiedon hallinta on näkyvissä monissa eurooppalaisissa hankkeissa joissa on kehitetty tiedon infrastruktuuria ja tiedon hallinnan menetelmiä. Yhteinen piirre näissä on telematiikka-arkkitehtuuri ja keskitetty tiedon hallinta. Seuraavassa on esitetty kolme esimerkkiä jotka kattavat satamat (merikuljetukset), sisävesikuljetukset ja intermodaalit tie/rautatiekuljetukset. IP (Intermodal Portal) -hankkeella on pyritty parantamaan satamien integroitumista kuljetusketjuihin. IP:ssä on harmonisoitu hallinnollisia menettelyjä. Samalla on rakennettu tietoteknisiä työkaluja ja palveluja joilla parannetaan välttämättömien tietojen saamista samoin kuin tiedon jakamista ketjuissa eteenpäin. IP:ssä ideana on, että tieto löytyy yhdestä pisteestä (Single Desk). Tietosisältö kattaa mm. vaaralliset aineet, laivaagentin tiedot, satamapalvelujen tilauksen, ETA-tiedot, kuorma-autokuljetusten tilauksen ja XML viestien määrittelyt. IP on EU:n tutkimushanke. Also Danube -hankkeessa on parannettu sisävesikuljetusten hallintaa. Hallinta perustuu uuteen tietojärjestelmään (Common Source Logistics Database). Järjestelmässä yhdistyvät logistiikan hallinta ja liikenteen hallinta. Järjestelmä sisältää mm tilausten hallinnan, ketjun suunnittelun, seurannan ja poikkeamahallinnan. Järjestelmässä ovat 31.5.2003 jälkeen käytössä sopimusten hallinta, konttien hallinta, vaarallisten aineiden hallinta ja kuljetusketjun optimointi. Cesar on webbipohjainen teknologia-alusta yhdistettyjen kuljetusten hallintaa varten. Järjestelmä on rakennettu mukana olevien yritysten tietojärjestelmien päälle. Cesar on asiakkaiden suuntaa yhteinen Internet-pohjainen käyttöliittymä. Mukana ovat kuljetusten tilaus (buukkaus), seuranta, poikkeamat ja aikataulut. Taustalla ovat osapuolten väliset sopimukset. Järjestelmää pyörittämään on perustettu yritys. 7 EUTP Clustering 12.12.2002 Rotterdam, www.eutp.org 20

3 ARKKITEHTUURIN RAKENNE JA KÄYTTÖ Tässä luvussa kuvataan arkkitehtuurin rakenne, mitä arkkitehtuurissa on kuvattu, minkälaisia kuvauksia, mitä ne esittävät, miten niitä voidaan tulkita. Lisäksi kerrotaan minkälaisia asioita kuvauksista ei voida päätellä. Luvussa esitetään myös kuvauksiin ja kuvaustapaan liittyvien termien määritelmät. Luvussa esitetään myös millä tavalla kuvauksia mahdollisesti voitaisiin yrityksissä ja yhteisöissä hyödyntää. Arkkitehtuuri kuvaa yleisen kuljetusmuotoriippumattoman tavaraliikenteen prosessin. Näkökulma prosessiin on lähinnä kuljetettavan tavaran ja asiakkaan näkökulma. Arkkitehtuuriin kuuluvat kuvaukset ovat prosessien kuvaus, tietojen kuvaus (tietoarkkitehtuuri, tietomalli), tietojärjestelmäpalvelujen kuvaus ja tietovarastojen kuvaus. Näiden sisältöä on selvitetty tarkemmin seuraavissa kappaleissa. 3.1 Prosessien kuvaus Arkkitehtuurin soveltamisalue (luku 4.1 ) kuvaa ne arkkitehtuuriin kuuluvat prosessit ja arkkitehtuurin ulkopuolella olevat prosessit. Prosessikuvaus on hierarkkinen: ylätason prosessien osaprosessit on kuvattu yksityiskohtaisemmissa prosessikuvauksissa. Prosessihierarkiasta on kuvattu prosessit ja osaprosessitasolta toisen tason osaprosessit. Joistakin kohdin on hahmoteltu kolmannen tason osaprosesseja, mutta nämä ovat lähinnä todella vain hahmotelmia. Prosessikomponentit on numeroitu tasonsa mukaisesti (Kuva 3.1). Tässä dokumentissa käytetään termejä prosessikomponentti ja osaprosessi vaihtelevasti tarkoittamaan samaa asiaa. Prosessialue 1 Prosessi Ydinprosessitaso Prosessitaso 1.1 Osaprosessi 1.1.1 Osaprosessi Osaprosessitaso 1.1.1.1 Osaprosessi 1.1.1.1.1 Toiminto Toimintotaso Kuva 3.1. Prosessien hierarkia ja arkkitehtuurissa kuvatut prosessitasot. 21

Arkkitehtuurissa ja kuvauksissa käytettyjen termien määritelmät on esitetty oheisessa taulukossa (Taulukko 3.1). Taulukossa on esitetty myös termeille yleisesti käytettyjä synonyymejä. Tässä dokumentissa on pyritty käyttämään esitettyä termiä tai ajoittain on kuitenkin saatettu käyttää jotain synonyymiä, jos sekaantumisen vaaraa ei ole. Taulukko 3.1. Kuvauksissa käytettävien termien määritelmiä. Termi Kuvaus Synonyymejä Käsite Fyysistä tai abstraktia oliota kuvaava kokoelma tietoja. Kohde, (tieto-)objekti, tietojoukko Ilmentymä Käsitemalli Osaprosessi Prosessi Prosessikartta Prosessikomponentti Rooli Tietovirta Toimija Toiminto Käsitteen ilmentymä, jolla on elinkaari. Esimerkiksi käsitteen kuljetusväline ilmentymä on kuorma-auto, jonka rekisterinumero on ABC-123. Käsitemalli kuvaa käsitteiden välisiä suhteita. Se on luonteeltaan staattinen, pysyvä malli. Kuvaa siis olioiden välisiä pysyviä suhteita. Esimerkiksi laskulla voi olla yksi tai useampia laskurivejä. Osaprosesseja voi olla monella tasolla. Alimman tason osaprosessi koostuu joukosta aikajärjestyksessä suoritettavia toimintoja ja niiden välisiä tietovirtoja. Ylempien tasojen osaprosessit koostuvat joukosta alemman tason osaprosesseja. Osaprosesseista koostuva joukko toimintoja, joka muodostaa loogisen kokonaisuuden. Prosessi kuvaa toimintaa, tekemistä. Sillä on [yleensä] selkeästi määritellyt alku- ja loppupisteet ja tietovirrat prosessista sisään ja ulos. Taulukko, jossa on esitetty prosessikomponentin kuvaus, alku- ja loppupisteet sekä mahdollisesti muita tietoja. Toiminto tai osaprosessi. Yleinen nimitys eri tasoisille prosessin osille. Henkilö, ryhmä tai organisaatio, jonka vastuulla on jossakin prosessissa joku toiminto tai prosessi. Rooli on abstrakti käsite: sama fyysinen toimija saattaa olla prosessissa useissa rooleissa. Roolia käytetään selkeyttämään prosessikuvauksia, jotta saadaan näkyviin prosessin sisäistä rakennetta ja voidaan tarkastella sitä millä tavalla prosessia voidaan kehittää. Rooli voi olla myös laite tai järjestelmä. Tässä tapauksessa käsitteitä Rooli ja Toimija voisi käyttää synonyymeinä. Kahden toiminnon, osaprosessin tai prosessin välillä siirrettävä joukko tietoa. Fyysinen organisaatio tai henkilö, joka toimii prosessissa jossakin roolissa. Käytämme tässä dokumentissa käsitettä Toimija reaalimaailman toimijoista ja käsitettä Rooli abstraktissa merkityksessä. Yhdellä kertaa suoritettava joukko toimenpiteitä, joka muodostaa jollakin tavalla loogisesti yhteenkuuluvan kokonaisuuden. Toiminnon suorittaa yhdessä roolissa oleva toimija. Kohdemalli, tietomalli, relaatiokaavio Tehtävä 22

Kunkin prosessin kuvaus koostuu prosessikartasta ja prosessin kuvauksesta. Prosessikartta on taulukko, jossa on esitetty prosessikomponentin kuvaus, alku- ja loppupisteet sekä mahdollisesti muita prosessikomponenttiin liittyviä tietoja. Alku- ja loppupisteitä ei välttämättä ole esitetty, jos ne ovat itsestäänselvyyksiä. Esimerkki prosessikartasta on oheisessa kuvassa (Kuva 3.2). Nro Nimi Kuvaus Alku/Input Loppu/Output 1 Toimitus Tavaroiden kuljettaminen kuljetustilauksen mukaisesti Kuljetettava tavara on olemassa. lähtöpaikasta lähettäjältä määräpaikkaan Kuljetussuunnitelma vastaanottajalle. on olemassa. Tavara tietoineen on valmis käytettäväksi vastaanottajan tuotantoprosessin seuraavassa osassa. Rajaukset ja huomautukset Toimitusprosessin kaikki osat voivat tuottaa seurantatietoja lähetyksestä (sisältötiedot, sijaintitiedot, olosuhdetiedot). 1.1 Lähetys Tavaroiden valmistelu kuljettamista varten ja luovuttaminen kuljetusoperaattorille. Toimituserä (tavarat) ja vastuu niistä on luovutettu kuljetusoperaattorille. Prosessiin voi sisältyä lastaustoimenpiteitä lastauspaikalla ja kuljetusvälineessä. Kuva 3.2. Esimerkki prosessikartasta. Prosessin kuvaus on kaavio, jossa on esitetty ne prosessiin kuuluvat prosessikomponentit, niiden väliset tietovirrat ja ne roolit, jotka ovat vastuussa kustakin prosessikomponentista. Prosessin kuvausta täydentää taulukko, jossa kuvataan sanallisesti jossa kuvataan sanallisesti tietovirrat. Esimerkki prosessin kuvauksesta on oheisessa kuvassa (Kuva 3.3). 1 Prosessi 1.1 Osaprosessi Rooli A 1.1.1 Prosessi A 1.1.04 1.1.03 1.2.3 Prosessi D 1.1.01 Rooli B 1.1.2 Prosessi B 1.1.02 1.1.3 Prosessi C 1 2 3 4 5 Kuva 3.3. Prosessin kuvauksen esimerkki. Seuraavassa taulukossa on esitetty prosessin kuvauksen osat. 23

Taulukko 3.2. Prosessikuvauskaavion selitykset. Nro Kuvaus Mitä kaaviosta ei näe 1 Roolit on kuvattu kaavion vasemmassa reunassa. Roolin vastuulla olevat prosessikomponentit sijaitsevat roolin suorakaiteessa. Rooli kuvaa siis ennen kaikkea vastuuta prosessikomponenttien toteuttamisesta ja niistä tietovirroista, joita prosessikomponentti tuottaa. 2 Prosessikomponentit on numeroitu ja nimetty. Lisäksi prosessikomponenttien värillä saatetaan ilmaista jotain kuvauksen kannalta merkityksellistä seikkaa. Tämä on aina erikseen selitetty kuvauksen yhteydessä. Prosessikomponenttien ajallinen järjestys, jos sellainen voidaan määrittää, on kuvattu vasemmalta oikealle eteneväksi. 3 Prosessikomponenttien väliset tietovirrat on kuvattu nuolilla, jotka on numeroitu. Numerointi on osaprosessin osalta juokseva numerointi. Osaprosessista toiseen menevät tietovirrat on numeroitu sen osaprosessin mukaan, joka toimii aloitteellisena tietovirran suhteen (siis pääsääntöisesti ensimmäinen lähettäjä). Nuoli kuvaa tietovirran suunnan. Tietovirrat on pyritty piirtämään niin, että prosessikomponentista lähtevät tietovirrat alas ja oikealle ja tulevat tietovirrat saapuvat ylhäältä ja vasemmalta. Jos on ollut mahdollista, tietovirtojen järjestys on pyritty pitämään sellaisena, että ajallisesti aikaisempi tietovirta lähtee vasemmalta tai ylempää Tietovirtojen väreillä on saatettu kuvata jotain tietovirtojen ominaisuuksia. 4 Kaksisuuntaisista tietovirroista on kuvattu taulukossa molemmat suunnat. Nuolet on piirretty niin, että se prosessikomponentti, joka käynnistää tietovirran on pääsääntöisesti vasemmalla tai ylempänä. Joka tapauksessa tietovirta lähtee tämän prosessikomponentin oikeasta reunasta tai alareunasta.. 5 Ylemmän tason prosessivaiheet on kuvattu nimettynä katkoviivana. Nämä prosessivaiheet, jos ne on kuvattu, esittävät aina ajallista järjestystä. Prosessikomponenttien ajallista kestoa ei voida suoraan päätellä kaaviosta. Suhteelliset alkamisajat on pyritty esittämään niiltä osin kuin se on ollut mahdollista, mutta päättymistä ei monessa kohdassa voida esittää. Prosessikomponentit on piirretty saman suuruisina. Esimerkiksi kuvassa prosessikomponentti 1.1.1 kestää tietovirtanuolien perusteella ainakin niin pitkään, että 1.1.3 on alkanut. Se saattaa päättyä vasta 1.1.3:n päättymisen jälkeen. Tarkkaa päättymistä ei kuviosta kuitenkaan voida päätellä. Kaikilta osin ei tietovirtojen järjestyksestä voida päätellä niiden ajallista järjestystä. Kaaviosta ei voida päätellä, kuinka moneen kertaan jokin tietovirta toteutuu kahden prosessikomponentin välillä. Esimerkiksi tietovirrat 1.1.01 ja 1.1.02 saattavat toteutua ensin ennakkotietona useammankin kerran ja toteumatietona viimeisen kerran. 24

3.2 Tietojen kuvaus Tietoarkkitehtuuri on kuvattu tietomallina ja tietojoukkojen luettelona. Tietomalli kuvaa tietojoukkoja ja niiden käsitteiden välisiä pysyviä suhteita. Se on siis luonteeltaan staattinen malli. Tietomallin kuvaustapa on esitetty tietomallin yhteydessä (luku 5.1.1 ). Tietomallin ja tietojoukkojen kuvauksen lisäksi tietoarkkitehtuurissa on esitetty tietojoukkojen ja reaalimaailman käsitteiden välisiä suhteita. 3.3 Tietojärjestelmäpalvelujen kuvaus Arkkitehtuurin tietojärjestelmäpalveluiden tiedot on kuvattu tietojärjestelmäpalveluiden kuvauksina, sekä tietojärjestelmäpalveluiden hajautusmallina. Hajautusmalli kuvaa tietojärjestelmäpalveluiden sijoittumista erilaisiin organisaatioihin tavoitetilassa. Se on siis luonteeltaan staattinen malli. Käsitemallin kuvaustapa on esitetty tarkemmin luvussa 5.2. 3.4 Tietovarastojen kuvaus Arkkitehtuurin tietopalveluiden tiedot on kuvattu tietovarastojen sanallisina kuvauksina, sekä tietopalveluiden ydinkohdemallina. Ydinkohdemalli kuvaa arkkitehtuurin keskeisten tietojoukkojen suhdetta loogisiin tietovarastoihin. Ydinkohdemallin kuvaustapa on esitetty tarkemmin luvussa 5.3. 3.5 Arkkitehtuurin tulkinta Yleistä Tavaraliikennesektorin toimijoilla on erilaisia tehtäviä ja tavoitteita tavaraliikenteen telematiikan kokonaisuuden toteuttamisessa. Logistiikkapalvelun tuottamiseen erikoistunut organisaation voi olla kiinnostunut mahdollisimman tehokkaan ohjaustietojärjestelmän toteuttamisesta kuljetuskalustonsa optimaalisen ohjaamisen vuoksi, kun taas seurantaoperaattorin mielenkiinnon kohteena taas voi tehokas tiedonkeruu, tiedonvälitys ja siihen liittyvien standardien kehittäminen. Arkkitehtuurissa ylimpänä käsitteellisenä kuvauksena toimii tavaraliikenteen telematiikkaan liittyvien prosessien ylätason prosessikaavio (Kuva 4.3). Kaaviosta selviävät yhtäläisesti sekä liikennetelematiikan arkkitehtuurin prosessit, niissä vaikuttavat toimijat/roolit, että prosessien keskinäinen liittyminen toisiinsa. Kaavion tehtävänä on auttaa 25