Sisällysluettelo
6 Liite : Välittäjäarkkitehtuurin osa-alueiden määrittelijöitä
Tässä esityksessä käytämme sanaa palvelu tarkoittamaan sähköisen kaupankäynnin kohteita, jollaisia ovat esimerkiksi tavara, tieto, elektroninen lehti, vakuutus, lomamatka tai jokin ostettu palvelu sanan normaalissa merkityksessä.
Kaupallinen transaktio tarkoittaa
palvelun valintaa, sen ostamisen ja ostetun palvelun sekä siitä
maksettavien vastikkeiden vaihdon tapahtuman eri osapuolten kesken. Kaupallisen
transaktion vaiheet voidaan jakaa eri tavoilla, mutta yksinkertaistettuna
kaupallinen transaktio muodostuu seuraavan kuvan esittämistä
kaupallisen transaktion vaiheista.
Kuva 1. Kaupallinen transaktio [Mer 99].
Informaatiovaiheessa (Information) ostajat etsivät tarvitsemiaan palveluja markkinoilla olemassa olevien palvelujen joukosta sekä vertailevat niiden ominaisuuksia ja hintoja. Myyjät puolestaan tarjoavat palvelujaan mainosten tai muiden markkinointikanavien kautta. Tämän vaiheen toimintoja tukee verkossa esimerkiksi katalogit, hakukoneet ja mainospainikkeet eli bannerit.
Neuvotteluvaihe (Negotiation) seuraa informaatiovaihetta, jos ostaja kiinnostuu tarjolla olevasta palvelusta. Tällöin ostaja- ja myyjäosapuolet pyrkivät sopimaan kaupan ehdoista. Tätä vaihetta tukee verkossa yhteistyöohjelmistot ja neuvotteluprotokollat.
Kaupan toteuttamisvaihe (Service Execution) seuraa neuvotteluvaihetta, jos se päättyy sopimuksen solmimiseen eli sopimuksen allekirjoittamiseen. Kaupan toteuttamisvaihe saattaa ajallisesti kestää muutamasta sekunnista useaan vuoteen. Toteuttamisvaiheen aikana verkossa tulee käyttöön asiankäsittelyohjelmistot, osallistujien yritysprosessien yhteistoiminta, verkkomaksaminen ja OVT- järjestelmät.
Kaupalliseen transaktion toteuttamisen yksinkertaistamiseksi siihen voi liittyä myös kolmansien osapuolten tarjoamaa lisäpalvelua, joista eräs on käsittelemämme välittäjä-palvelu eli brokerage-toiminta. Informaatiovaiheessa välittäjä auttaa löytämään oston kohteena olevat palvelut edullisesti ja toisaalta palvelujen tarjoajat löytävät välittäjäjien avulla luotettavia kauppakumppaneita. Sopimuksen allekirjoituksen yhteydessä voidaan tarvita luotettua kolmatta osapuolta varmistamaan allekirjoittajien henkilöllisyys ja se, että kaikki tarpeelliset osapuolet allekirjoittavat sopimuksen. Välittäjäjän tehtävä voi olla myös säilyttää allekirjoitettu sopimus ja taata sen muuttamattomuus ja häviämättömyys. Välittäjänä voi toimia myös sähköistä maksupalvelua tarjoava yhtiö ja maksu voi tapahtua joko elektronisen rahan muodossa tai maksu voi tapahtua sähköisesti pankkien kautta.
Tämä esitys on tehty verkosta
löytyvien lähteiden pohjalta ja lisäksi on käytetty
Mäkelinin kirjaa [Mäk98] suomenkielisen termistön ja eräiden
määrittelyjen lähteenä.
yhteenliittymistä
Välittäjä-arkkitehtuurin kehittämisessä on mukana useita eri tahoja ja organisaatioita, joista vain osa on esiintyy tässä seminaarityössä. Liitteessä 1 on tehty yhteenveto eräistä yhteenliittymistä, jotka kehittävät ja kokeilevat arkkitehtuurimalleja sekä tekevät standardien määrittelytyötä.
Nykyisin ostetaan verkossa palveluja
käyttäen katalogi- eli kauppapaikkaohjelmistoja. Niissä
on perustoimintoina nykyisin katalogin tekeminen ja hallinta, tietokanta,
ostoskärrytoiminnot, tilausten käsittely ja raportointitoiminnot.
Kehittyneempiin muotoihin kuuluu yksilölliset, asiakaskohtaiset näytöt
ja hinnoittelu, sekä tuki erilaisille markkinointi- ja palvelukonsepteille
[Mäk98].
Nykyisin välittäjän palvelujen avulla voidaan
löytää eräissä tapauksissa maailmanlaajuisesti "paras mahdollinen"
palvelu. Tieteellisen materiaalin hallintaan on olemassa Open digital library projekti,
jonka puitteissa voidaan etsiä ja hankkia tieteellistä kirjallisuutta ja erilaisia
artikkeleita. Esimerkkinä tarkastelemme MeDoC-projektia [MEDa99], jossa nimenomaan
välittäjä-palvelun avulla etsitään sopivinta materiaalin tarjoajaa. Medoc-projekti
lopetettiin heinäkuun lopussa 1999, mutta sen luoman arkkitehtuuria ryhdytään
kokeilemaan projektissa nimeltä InterDoc [IND99]. Uudessa projektissa laajennetaan
kokeilua käsittämään usean eri tieteenalan kirjallisuuden hakupalvelua. MeDoC käyttäjä lähettää välittäjälle materiaalin
hakupyynnön ja välittäjä päättelee tapauskohtaisesti parhaat tulokset antavat
materiaalin tarjoajat. Arvioinnissa käytetään perusteina palvelujen tarjoajien
materiaalin hintaa ja laatua. On huomattava, että välittäjä tuottaa tässä
tapauksessa lisäarvoa ostajalle, koska materiaalin tarjoaja voi ilmoittaa ostajalle,
kuinka monta osumaa materiaaleihin tuli (hit rate) ja mutta välittäjän tehtävä on
arvioida löytyneen materiaalin todellista hyötyä ostajalle ( request count).
Kuva 2. MeDoc välittäjä-palvelu [MEDb99].
Tiedon tarvitsijat ottavat yhteyden jonkin käyvän selaimen avulla käyttäjän agenttiohjelmaan (Nutzeragent), joka on yhteydessä välittäjiin. Yhteydenotto voidaan tehdä haluttaessa myös sähköpostin välityksellä. Selain ja käyttäjän agentti ovat asennetut käyttäjän organisaatiossa (installiert bei Nutzerinstitutionen). Kuvassa yhtenäinen viiva kuvaa yleisiä tietoliikenneyhteyksiä ja harva katkoviiva materiaalin etsintää ja dokumenttien hakua (Recherche & Dokumentenabruf). Välittäjän tehtävä on löytää etsintätehtävään soveltuvat aineiston tarjoajien hakuagentit (Anbieteragent) ja toimia niiden kanssa yhteistyössä, jota kaaviossa kuvaa tiheä katkoviiva. Tarjoajaorganisaatiossa (MeDoc-Anbietern), joita ovat esimerkiksi kustantamot ja yliopistot, on oltava tarpeelliset ohjelmistot, jotka tarjoavat liittymät käyttäjän agenttien ja välittäjän käytettäviksi.
Kuvan yhteenvetona voidaan esittää
seuraavaa: Käyttäjä tekee selaimellaan kyselyn, joka ohjautuu
välittäjille. Tämä suosittelee käyttäjälle joukkoa
tarjoajia, ja käyttäjä voi sen jälkeen samanaikaisesti
etsiä ja noutaa tarvitsemiansa tekstidokumentteja useasta eri paikasta.
Neuvotteluvaihetta kuvataan COMOS-projektissa [COS99] seuraavasti. Neuvotteluvaiheessa pyritään löytämään ehdot kaupan toteuttamiseksi. Mikäli kauppa neuvotellaan Internetin kautta, käytetään apuna siihen soveltuvia ohjelmistoja.
Yhteistyöohjelmat (collaboration tools) ovat yksinkertaisia neuvottelun apuvälineitä. Osapuolten edustajat voivat käydä neuvottelua kirjoittamalla samaa dokumenttia hallitusti ja muotovapaasti siten, että eri osapuolet näkevät välittömästi yhteiseen dokumenttiin tehdyt muutokset.
Neuvotteluosapuolet voivat hyödyntää neuvotteluprotokollia (negotiation protocols), jolloin joko ihmiset tai ohjelmistokomponentit osallistuvat neuvotteluun. Neuvottelun aihe näissä tapauksissa on strukturoimaton eli osallistujat tietävät itse, mitä kaikkia asioita neuvotteluissa tulee käsitellä ja mistä asioista on sovittava. Neuvotteludokumenttien käsittely ja rakenne on etukäteen määrätty ja protokolla määrää, kuka osapuolista kulloinkin toimittaa ennalta määritellyn tiedon ja kenelle tieto toimitetaan. Neuvottelu voidaan nähdä ennalta määriteltynä asiankäsittelyprosessina.
Käytettäessä formaalista
keskusteluja (formalized conversations) on neuvottelun muoto tiukemmin
määritelty kuin neuvotteluprotokollan tapauksessa. Esimerkki
formaaleista keskusteluista on Knowledge Query and Manipulation Language
(KQML), agenttien yhteistyön mahdollistava tiedon ja tietämyksen
siirtoon tarkoitettu yhteyskieli. Tämä mahdollistaa kielellisen
mahdollisuuden määritellä formaalisti neuvotteluja ja neuvottelussa
voidaan käyttää määriteltyjä termejä
kuten "tarjous", "hylätä", "ehdottaa", "hyväksyä" jne.
Kielen avulla voidaan räätälöidä järjestelmiä
eri kaupankäyntialojen neuvottelujen tukemiseen. Neuvottelun osapuolten
järjestelmät ymmärtävät myös tarjouksen ja
ehdotuksen välisen eron, tarjous sitoo sen esittäjää
ja hyväksyessään vastapuoli saa aikaiseksi pätevän
sopimuksen, ehdotus sen sijaan ei ole sitova. Neuvotteluprosessi voidaan
kokonaisuudessaan automatisoida, jolloin sen hoitaa itsenäiset agentit.
Tämä edellyttää sen, että tapa esittää
tietoa neuvottelun kohteesta (ontologia) on myös standardoitu. Tällaisessa
tapauksessa "puhuminen" ja "hinta" ovat tekijöitä, joista agentti
voi tehdä johtopäätöksiä. Nykypäivän
todellisuudessa ei käytetä automaattista neuvottelua, koska mitä
monimutkaisemmista asioista neuvotellaan ja pyritään sopimaan,
sitä monimutkaisemmaksi puhe muuttuu. Jos kaupan kohteena on yksinkertaiset
tuotteet kuten monet kulutustavaroista, nousee niiden tarjoajien lukumäärä
suureksi ja tällaisten hyödykkeiden hankinnassa neuvottelukustannukset
kasvaisivat liian suuriksi.
Avoimessa heterogeenisessa ympäristössä palvelujen tarjoaminen voi olla menestyksellistä vain, jos tarjous voidaan esittää sellaisessa muodossa, jota voi hyödyntää laaja joukko erilaisia käyttäjiä ja käytössä olevat eri tekniikat. Tällöin välittäjä voi palvella osapuolia tarjoamalla tekniikkaa, joka voi muuntaa esitetyt tarjouksen dynaamisesti ostajan haluamaan esitysmuotoon. Palvelun määrittelyvaiheen aikana järjestelmien tulee tarjota useita erilaisia vaihtoehtoja tietojen vaihtoon ja kussakin neuvotteluyhteydessä valitaan paras yhteinen käytettävä menettelytapa. Uusia menettelytapoja pitää voida lisätä automaattisesti ajoaikana muutamalla vain parametrejä. Ohjelmisto tulee voidaan konfiguroida helposti ja liittää osaksi muuta järjestelmää. Jos joustava järjestelmä saadaan aikaiseksi, on helppo käydä sähköistä kauppaa. Toistaiseksi on vielä ratkaistavana monia ongelmia ennen kuvatunlaisen järjestelmän syntymistä [COS99].
Suullinen sopimus
on pätevä sopimusmuoto ja sähköisen kaupankäynnin
yhteydessä sitä vastaa "OSTA" painikkeen klikkaaminen ruudulla. Usein suullinen
sopimus ei ole osapuolten kannalta riittävä, koska tällöin
riitatilanteessa on "sana vastaan sana", vaan on olemassa tarve tehdä sopimus vahvemmaksi ja pitävämmäksi.
Kirjallista sopimusta
ei voida jälkeenpäin muuttaa ja tällöin riitatilanteessa
ratkaisee sopimuksen tulkinta. Sähköisen kaupankäynnin yhteydessä
kirjalliseen sopimukseen tarvitaan allekirjoittaneiden osapuolten lisäksi
luotettu kolmas osapuoli, jonka hallussa on alkuperäiset sopimustiedot.
Näiden pohjalta viime kädessä ratkaistaan, mitä on
sovittu, ja erimielisyydet osapuolten välillä ratkaistaan tulkitsemalla
aitoa sopimusta. Lainkäyttäjien kannalta sähköiset
allekirjoitukset on osapuolten mahdollista hyväksyä eräissä
maissa, mutta sopimuksien säilytys kolmansien osapuolten hallussa
ei ole lainsäädännöllisesti vahvalla pohjalla. Jos
erimielisyydet ratkaistaan oikeudessa, joutuu oikeusistuin viimekädessä
päättämään dokumenttien ja allekirjoitusten oikeellisuuden [COS99].
Sopimus tulee toteuttaa sovitussa muodossa ja sen laillinen toteutuminen voidaan seurata ihmisen toimesta. Jos sopimukset talletetaan sähköisessä muodossa, ne voidaan myös toteuttaa ja seurata automaattisesti. Sähköisesti talletetun strukturoidun sopimuksen pohjalta voi asianhallintaohjelma lähettää huomautuksia ja ilmoituksia sovituista tapahtumista osapuolille. Ilmoitukset viittaavat sovittuihin asioihin, kuten maksuihin ja toimituksiin ja niiden toteuttamisaikoihin.
Kehittyneemmällä tasolla voi asianhallintaohjelma olla suoraan yhteydessä osapuolten tietojärjestelmiin. Yhteysjärjestelmiä voidaan luoda käyttäen hyväksi hajautettuja, olioperustaisia ohjelmistokomponentteja. Sopimuksen osapuolien etujen turvaamiseksi tulee käytettyjen komponenttien olla testattuja, yleisesti hyväksyttyjä vakiokomponentteja, jotka voidaan riskittä liittää osaksi olemassa olevia järjestelmiä. Jos tehdyt hankintasopimukset ovat toiminnaltaan monimutkaisia ja osapuolet ovat tehneet sopimukseen erityisehtoja, tulee yhteyden rakentavien komponenttien pystyä niistä selviytymään [COS99].
2.6 Välittäjä-toiminta hajautetussa ympäristössä
Kun Internet- ympäristössä käydään neuvotteluja ja tehdään sopimuksia, osapuolten ohjelmistojen yhteensovittamisesta tulee erittäin tärkeä kysymys. Koska toistaiseksi tällaiset yhteystapahtumat eivät ole tavanomaisia, tulee ainakin palvelujen tarjonnan alkuvaiheessa tehdä tapahtumista avoimia ja ihmiselle helposti seurattavia ja tarkkailtavia. Tutkielmassa tarkastellaan välittäjä-toimintaa hajautetussa ympäristössä Common Brokerage Architecture eli COBRA-projektissa esitettyjen näkemysten mukaisesti [MDS98].
Sähköiseen välittäjä-toimintaan
esitetyt mallit käsittelevät monen osapuolen välisiä
tapahtumia, joiden kestoaika voi olla pitkä. Kunkin osapuolen osallistumiseen
tapahtuman eri vaiheeseen sisältää joukon ennakko- ja jälkiehtoja,
joiden on täytyttävä ennen kuin osapuoli katsoo tapahtuman
siltä osin käsitellyksi. Kullekin transaktioon liittyvään
tapahtumille voidaan esittää seuraavia ominaisuuksia:
Transaktion tapahtumat
voidaan suorittaa kahdella eri periaatteella. Jos käytetään
keskitettyä
tapahtuman valvontaa, tulee jokaisen osallistujan asioida transaktion
valvojan kanssa. Transaktion valvojan ollessa luotettu, ovat loogiset asioinnit
tämän kanssa samalla myös osallistujan kannalta tapahtuman
kontrollin pisteitä. Mikäli tapahtumalla ei ole keskitettyä
hoitajaa eli kyseessä on hajautettu tapahtuma, on kaikilla
osapuolilla velvollisuus hoitaa transaktion tapahtumaa ja täten
myös tapahtumien looginen koordinointi ja niiden kontrollointipisteet
on monistettu ja hajautettu.
Keskitetyssä tapahtuman valvonnassa toiminta perustuu osallistujien toimintaan. Tällöin kaikilla osapuolilla tulee olla ennen transaktiota luotu yhteys sen valvojaan. Jälkimmäisessä hajautetun transaktion tapauksessa jokainen osapuoli on toisistaan riippuvainen ja kaikkien tulee voida seurata ja tulkita toisten suorittamia tekoja.
Keskitetyn tapahtumavalvonnan
tapauksessa osallistujien huolenaiheena on epävarma viestien välitys.
Tapahtumien atomisuus, informaation pysyvyys ja sanomien autentisuus on
käytetyn palvelun ominaisuuksia, välittäjän vastuulla. Hajautetun transaktion tapauksessa
on jokainen osallistuja velvollinen kantamaan vastuuta transaktion tapahtumista
ja lisäksi kukin osallistuja tarvitsee kyvyn seurata muiden osapuolten tekoja.
Järjestelmän tulee tietää varmuudella, milloin jokin
osapuoli on suorittanut sopimuksessa osoitetun velvollisuuden. Kaikkien
osapuolten tulee voida luottaa niin omassa järjestelmässään
käytettävien sovelluskomponenttien laatuun ja myös toisten
osapuolten järjestelmien laatuun. Hajautetun tapahtumavalvonnan kohdalla
ennalta luotu yhteys tapahtuu järjestelmien infrastruktuurin toimittajien
toimesta ja niihin luottaminen mahdollistaa osallistujille kyvyn luoda
kontakteja joustavasti. Kun tapahtumavalvonta on hajautettu useaan eri
yritykseen, jokaisen tulee voida replikoida järjestelmäänsä
kaikki sitä kiinnostavat transaktion seuraamiseen tarvittavat piirteet.
Heidän tulee myös voida luottaa infrastruktuurin luomaan ympäristöön
ja varmistua siitä, että heidän tietonsa transaktion tilasta
on oikea, joten ympäristön toimittajien vastuulle jää tällöin
taata tapahtumien atomisuus, pysyvyys ja turvallisuus osapuolten käydessä kauppaa.
Tarkastelemme sopimusmallliarkitehtuuria,
joka on julkaistu COSMOS-projektin toimesta, Mertzin teoksen mukaisesti [Mer99 s. 201 - 211].
Sopimusvaiheen malli on tärkeä, koska se muodostaa perustan kaupankäynnin
seuraaville vaiheille. COSMOS sopimusta tarkastellaan strukturoituna dokumenttina,
joka muodostuu tekstilohkoista. Pk-yritysten kohdalla on taloudellista
ajatella, että sopimus tehdään manuaalisesti tekstejä
editoimalla eikä sopimusta tehdä ohjelma-agenttien avulla. Riippumatta
tavasta, jolla sopimus on tehty, COSMOS- mallissa pyritään tekstistä
erottamaan sisällöllisesti tärkeät osat ja muuttamaan
sopimus elektronisesti suoritettavaan muotoon. Sopimuksen eri osat voidaan
erottaa esimerkiksi otsikoiden perusteella:
COSMOS- mallissa luodaan ensin sopimusrunko,
jossa ennalta määritellään kuinka - osa. Lisäksi
määritellään sopimuksessa tarvittavat roolit ja kustakin
velvollisuudesta tarpeelliset QoS- attribuuttiarvot. Sopimusrunko ei nimeä
sopijaosapuolia eikä tarkkoja attribuuttiarvoja kuten "Hinta kilolta
= 17,70" tai "Kosteusarvo = 8%", vaan attribuutit ilmaistaan raja-arvoina
esimerkiksi "Hinta kilolta < 18,00" tai "Kosteusarvo < 10%"
Välittäjä valmistaa sopimusehdotuksen ja täydentää sopimusrunkoa, mikäli katalogista löytyy palvelulle sopiva toimittaja. Välittäjän tehtävä on muuttaa QoS- attribuuttiarvot tarjouksen arvoiksi. Tätä varten välittäjällä tulee olla tiedot tarjolla olevien palvelujen laadusta ja usein tarvitaan mahdollisuus ajantasaiset tiedot tarjoajilta. Löydettyään sopivan palvelun, välittäjä liittää sopimusehdotukseen osapuolten tiedot. Jos välittäjän toiminnan jälkeen saadaan aikaiseksi periaatteellisella tasolla valmis sopimus, antaa ostaja vastatarjouksen.
Neuvotteluvaiheessa sopimusehdotuksia vaihdetaan osapuolten kesken. Riippuen käytetystä menetelmästä, sopimustarjous voidaan käsittää joko ehdotukseksi, joka ei ole laillisesti sitova, tai tarjoukseksi, joka sitoo tarjoavaa osapuolta. Kun kaikki osapuolet hyväksyvät sopimusehdotuksen, on sopimus valmis allekirjoitettavaksi.
Kun kaikki osapuolet tai heidän
edustajansa ovat allekirjoittaneet sopimuksen, vahvistaa sähköinen
sopimuspalvelu sen. Tämän jälkeen sopimus toteutetaan ja
voidaan siirtää asiankäsittelyohjelmistolle.
Kuva 3. COSMOS- mallin rakenneosat [Mer99
s. 209].
Kuvasta 3 ilmenee COSMOS- arkkitehtuurin viisi rakenneosaa.
Sopimuksen toiminnot liittyvät kiinteästi toisiinsa, koska ne
kommunikoivat keskenään käyttäen sopimusta tiedonsiirron
välineenä. Kaikki COSMOS- mallin mukaiset prototyypit voivat
käyttää haluamiansa osia. Mallia hyväksikäyttävä
yhteenliittymä saattaa olla muodostettu jo aiemmin ja katalogivaihe
sekä siihen liittyvää välittäjä-toimintaa ei tarvita. Toisissa
tapauksissa ei neuvotteluvaihetta käytetä, koska se olisi liian
kallista verrattuna tapahtumien lukumäärään. Myös
asianhallintaosuus ja sopimusten täytäntöönpano voi
puuttua. COSMOS- mallin komponenttien dynaamisuus mahdollistaa erilaisten
ratkaisujen muodostamisen ja toteutuksessa määritellään
siitä käytettävät osat. Mallin abstraktio ei koske
ainoastaan ohjelmistokomponentteja vaan myös käytettävää
sopimusmallia. Erilaisia toteutustekniikoita on mahdollista hyödyntää
eri COSMOS- malliin perustuvissa toteutuksissa. Seuraavassa luetellaan
eräitä mahdollisia komponentteja.
Pilotissa on kyseessä Milanon
kauppakamarin projekti, jossa välittäjä-toimintona välitetään
pk-yrityksille niille suunnattua yritystoiminnan kehittämiseksi ja
edistämiseksi tuotettua informaatiota.
Kuva 4. Välittäjä-toiminnon malli Milano-pilotti projektissa raportin [MDS98] mukaan.
Kaupalliset ja julkiset tiedon
tuottajat tarjoavat erilaista tietoa monissa eri muodoissa ja eri välineillä.
Tarjottujen tietojen vertailu on kokemattomalle vaikeaa ja asiakkaat eivät
aina itsekään tiedä, mitä tietoa he tarvitsevat ja
mistä tieto on saatavissa. Näistä syistä on tarve kokeneelle
välittäjälle, joka osaa opastaa asiakasta. Välittäjän velvollisuus on kerätä
ja valita asiakkaan tarvitsema tieto ja hänellä on osavastuu
myös siitä tiedosta, jonka asiakas lopulta ostaa. Ostajilla tulee
olla vankka luottamus välittäjään ja näin ollen siinä roolissa
toimii kauppakamari.
Kuva 5. Toiminnot ja vastuut Milano-pilotti projektissa raportin [MDS98] mukaan.
Kuvan 5. mukaan välittäjä on vastuussa
tiedon julkistamisesta ja levittämisestä ja tarvittavan tiedon
välittämisestä asiakkaalle. Asiakas ja välittäjä yhdessä
vastaavat valitun tiedon kelpoisuuden arvioinnista ja sen hankkimisesta.
Durham-pilotti muistuttaa Milano-pilottia siinä, että välittäjä-toiminto kohdistuu tiedon ja palvelujen
välittämiseen pk-yrityksille. Durhamin yrittäjäyhdistys
TEC (The County Durham Training and Enterprise Council), toimii ohjelman
sponsoreiden eli toimittajien agenttina ja pk-yritysten neuvojana. TEC:n
yritysneuvojat ja eri alojen asiantuntijat toimivat varsinaisina välittäjinä.
Nämä yhdessä tarjoavat palveluna eri tukiohjelmien ja yrittäjien
välillä. Tämä on tärkeää, koska erilaisia
ohjelmia käynnistyy ja loppuu ajan kuluessa. Tärkein aspekti
tässä kokeilussa on yritysten neuvontatoiminta.
Kuva 6. Välittäjä-toiminnon malli Durham-pilotti projektissa raportin [MDS98] mukaan.
Asiakkaat eivät välttämättä
tiedä tarpeitaan eikä tarjolla olevia tukiohjelmia, jolloin välittäjän
tehtävä on toimia ohjelmien tietopankkina ja heidän tulee osata
valita asiakkaille sopivat ohjelmat. Ohjelmien tiedottamisvastuu ei ole
ainoastaan välittäjillä vaan myös ohjelmien sponsoreilla, joiden
tulee ylläpitää tietoa ja olla valmiit toteuttamaan ohjelmiaan
yksittäisen asiakkaan kanssa. TEC:n tulee seurata ohjelmien
toteutumista ja raportoida siitä sponsoreille.
Kuva 7. Toiminnot ja vastuut Durham-pilotti projektissa raportin [MDS98] mukaan.
Helsinki-pilotti käyttää välittäjä-palveluja multimediapalvelujen markkinointiin. Muista piloteista poiketen välittäjätoiminnon
kohteena on monimutkainen tuotteiden ja palveluiden tarjontakokonaisuus. Välittäjä-palvelua
voidaan käyttää hyväksi kahdella tapaa, ensinnäkin
se mahdollistaa asiakkaille yhden paikan, josta voi ostaa kaikki multimediapalvelut
ja toiseksi se tarjoaa näyttelyjen ja tapahtumien järjestelijöille
, etenkin Helsinki 2000 juhlien järjestelijöille, tilaisuuden tutkia erilaisten esitysten teknisiä ja taloudellisia
tekijöitä.
Tapahtumiin voi välittäjän avulla hankkia palveluja useilta
eri toimittajilta. Välittäjä huolehtii kokonaistarjouksen teosta ja antaa
palvelujen tuottajille mahdollisuuden markkinoida palvelujaan.
Kuva 8. Välittäjä-toiminnon malli Helsinki-pilotti projektissa raportin [MDS98] mukaan.
Koska välittäjä-palvelu antaa mahdollisuuden
ostajille yhdistää osia eri tarjoajien palveluista ja näin
tukee asiakkaan tiedonkeruu ja valintaprosessia, on kuitenkin vastuu tiedon
keruusta, valinnasta ja palvelujen hankinnasta asiakkaalla. Välittäjän vastuulla
on tietojen julkistaminen ja hankintatoiminnan tuki ja seuranta.
Kuva 9. Toiminnot ja vastuut Helsinki-pilotti projektissa raportin [MDS98] mukaan.
Ero verrattuna aikaisempiin
esimerkkeihin on myös siinä, että pilotissa ei seurata pelkästään
yksittäistä tapahtumaa vaan pidetään kirjaa asiakkaan
kaikista tapahtumista. Välittäjällä on velvollisuus rekisteröidä
asiakkaat, tarjota hakupalveluja ja taata asiakkaan pääsy
niihin, hoitaa kirjanpito ja laskutus sekä asiakkaiden jälkihoito.
Brokerage toiminto on voimakkaasti
kehittymässä eikä vielä ole olemassa laajasti siitä
esimerkkejä. Kehittyäkseen käyttökelpoiseksi menetelmäksi
se vaatii mielestäni seuraavien yleisten teknologioiden kehittymisen.
Ensinnäkin maksamistavan on kehityttävä turvalliseksi ja
yleisesti hyväksyttäväksi kaupankäynnin muodoksi. Toiseksi
laajasti käytettynä toiminta tarvitsee älykkäiden agenttien
olemassaolon käytettäväksi sekä palvelujen hakuvaiheessa
että sopimusten neuvotteluvaiheessa. Kolmas tarpeellinen komponentti
on tapa liittää yritysten omat tietojärjestelmät yhteen
siinä määrin, että sopimukset voidaan toteuttaa mahdollisimman
automaattisesti.
Teknisten edellytysten lisäksi
on eri maiden lainsäädäntöjen kehityttävä
siten, että sähköinen kaupankäynti ja sopiminen on
luotettavaa ja lisäksi käytäessä globaalia kauppaa,
on eri maiden harmonisoitava lainsäädäntöään
näiltä osin.
Mäk98 |
Mäkelin, M., Sähköinen kauppa ja liiketoiminta Kilpailu ja yhteistyö digitaalitaloudessa. HM&V Research Oy 1998, ISBN 951-98059-0-7, Helsinki |
Mer99 |
Merz, M., Electronic Commerce, Aktualisierung: 12.04.99. Viitattu 30.9.1999. http://vsys-www.informatik.uni-hamburg.de/papers/buch.ps.gz |
COS99 |
Common Open Service Market for Small and Medium-sized Enterprises. Viitattu 30.9.1999. http://vsys-www.informatik.uni-hamburg.de/projects/cosmos/ |
IND99 |
Interdisziplinäre Dokumentenverarbeitung auf Basis des MeDoc-Dienstes. Viitattu 30.9.1999. http://interdoc.offis.uni-oldenburg.de/ |
MDS98 |
Martin, M., Dobson, M., Strens, R., COBRA Deliverable 10: The Final Enterprise Models , 14/1/98. Viitattu 30.9.1999. http://www.onyx.net/proj/cobra/papers/d10v1.zip |
Dif99 |
Computational View of Electronic Brokering Service Components. Viitattu 30.9.1999. http://www.det.ua.pt/Projects/difference/work/D5/d5chapA.html |
MEDa99 |
Multimedia electronic Documents. Viitattu 30.9.1999. http://medoc.informatik.tu-muenchen.de/ |
MEDb99 |
Architektur des MeDoc-Dienstes: Geschäftsmodell und System. Viitattu 30.9.1999. http://medoc.informatik.tu-muenchen.de/deutsch/projdescr/medocarch.html |
Välittäjä-toimintaa on kehittämässä suurehko joukko erilaisia toimijoita. Euroopassa monet ohjelmat ja ryhmät on perustettu Euroopan komission ACTS ohjelman puitteissa.
ACTS ohjelman puitteissa toimivat tai ovat toimineet mm. seuraavat ohjelmat, joista on mainittu lyhenne ja ohjelman kotisivun osoite:
Lyhenne | Ryhmän nimi | verkko-osoite |
ACTS | Advanced Communications and TechnologieS | http://www.uk.infowin.org/ACTS/ |
ABS | Architecture for Information Brokerage Service | http://b5www.deteberkom.de/ABS/ |
COBRA | Common Brokerage Architecture | http://www.octacon.co.uk/proj/cobra/ |
DIFFERENCE | Dissemination and Facilitation for European Research in Selected Chains | http://www.uk.infowin.org/ACTS/RUS/PROJECTS/ac207.htm |
GAIA | Generic Architecture
for Information Availability
|
http:// www.syspace.co.uk/GAIA/ |
OSM | Open Service
Model for Global Information Brokerage and Distribution
|
http://www.osm.net/ |
Taulukko 1. ACTS-ohjelmia.
Lisäksi on olemassa muita foorumeita, joista mainitaan seuraavat: