Mielikuvaelämä

Verkkolaskustandardi - paisuva maailmanmalli vai hajautettu hallinta?

Verkkolaskustandardin kehittäjät pyrkivät yhteen yleistettyyn standardiin ja laskun tietosisältöön, jota kaikki käyttäisivät, ja jonka schemaa vastaan verkkolaskut tarkastettaisiin. Heidän mukaansa yritysten tulee kehittää prosessinsa niin että se on mahdollista. - Laskujen lähettäjät ja vastaanottajat haluavat välittää laskuilla myös toimialakohtaista dataa kahdestakin syystä: sekä saadakseen verkkolaskujen hyödyt jo nykyprosesesseja käytettäessä, että voidakseen ylipäätään integroida laskuttajan ja laskunsaajan tietojärjestelmiä. - Kaksi erilaista mielikuvaa siitä, mikä olisi järkevää, hyödyllistä ja edes mahdollista. Mielikuvat on kuitenkin yhdistettävissä tavalla, joka tyydyttää molempien tarpeet: standardiin voitaisiin lisätä kohta toimialakohtaisille inserteille, joista toimialat itse vastaavat.


Me suomalaiset olemme sentään vielä joissakin asioissa aika lailla kärjessä uuden tietotekniikan hyväksikäytössä. Yksi näistä kärkiasioista on verkkolasku, siis laskun lähettäminen asiakkaalle tietoverkon yli esim. XML-muodossa. Tarkoitan nyt aitoa verkkolaskua, jossa kaikki tieto on datana, jonka myös laskun saaja voi integroida omiin tietojärjestelmiinsä. Unohda siis kaikki skannatut laskun kuvat, eivät ne ole oikeita verkkolaskuja. Varo vääriä jäljitelmiä!

Verkkolaskujen yleisiä standardeja ovat kehittäneet ainakin Suomen Pankkiyhdistys ja Pohjoismainen konsortio. Lisäksi ainakin TietoEnatorilla ja Postilla on omat standardinsa. Em. yleisten standardien painolastina on niiden ilmeinen EDI-tausta; ne näkevät maailman tuonti- ja vientikaupan näkökulmasta. Siten niihin on standardoitu vain EDI:stä tuttuja tietokenttiä. Kaikki muu tieto esitetään kuolleena tekstinä. Niinkuin esimerkiksi puhelinlaskun erittely.

Tekstitieto on aivan paikallaan silloin kun laskulla halutaan antaa yksityishenkilölle tarkempaa tietoa laskun perusteista. Mutta kun lasku lähetetään tietotekniikkaa käyttävälle yritykselle, tekstitieto edellyttää manuaalikäsittelyä. Ja se taas merkitsee koko verkkolaskun integraatiohyödyn vesittymistä.

Reaalimaailmassa laskuilla kulkee paljon muutakin dataa kuin laskustandardien tuntemat kentät. Data kuljetetaan laskulla siksi, että laskun vastaanottaja voi käsitellä laskun oikein omissa järjestelmissään. Jotta integrointi voidaan automatisoida, tieto tarvitaan laskulle tietenkin datana; ei tekstinä.

Verkkolaskustandardien kehittäjien mukaan verkkolaskujen tehokas hyväksikäyttö edellyttää myös laskujen vastaanottajien liiketoimintaprosessien kehittämistä siten, että integraatio voidaan tehdä laskustandardin jo tuntemien kenttien avulla. Integroimisen kohdistamiseen käytettäisiin tällöin erilaisia viitetietoja, joilla laskun vastaanottaja voi hakea oikeat tiedot omista tietojärjestelmistään.

Standardien kehittäjien näkemys on puhdasoppinen, mutta valitettavan kaukana tämän hetken arkitodellisuudesta: Esim. suuret vakuutusyhtiöt eivät mitenkään voi uusia järjestelmiään edes muutamassa vuodessa. Prosessien kehittäminen on niin pitkäjänteistä, kallista ja hidasta työtä, ettei verkkolaskujen integraatiohyödyn saaminen voi eikä saa jäädä odottamaan sen valmistumista.

Nykyisissä prosesseissa laskuttaja usein esittää laskulla sellaista uutta dataa, joka on syntynyt vasta laskuttajan omassa liiketoimintaprosessissa. Laskun saaja ei siten millään avaimilla voi löytää dataa omista järjestelmistään. Suomen Pankkiyhdistys esitti keväällä 2005, että standardiin voidaan lisätä näitä prosessien toiminnan kannalta välttämättömiä kenttiä tarpeen mukaan. Ehdotus oli hyvin positiivinen ja rakentava, mutta käytännössä se merkitsisi suureellista maailmanmallia: siinä olisi lopulta oltava mukana kaikkien toimialaojen kaikkien sovellusalueiden laskujen käsittelyssä tarvitsemat erillistiedot. - Sittenkin mahdoton ajatus, vai kuinka?

Suomen Pankkiyhdistys on kuitenkin itse jo toteuttanut omien jäsenyritystensä omistamien rahoitusyhtiöiden tarpeisiin tietoteknisesti terveemmän ratkaisun: Rahoitusyhtiöiden käytössä on oma insertti, jonka XML-sisällön rahoitusyhtiöt ovat itse määrittäneet. Ajatus on helppo kehittää edelleen sekä tietoteknisesti että loogisesti ehjäksi ja toimivaksi ratkaisuksi: käytetään vaihtoehtoisia toimialakohtaisia inserttejä.

Inserttejä ei siis ympätä yhteen ja samaan standardiin ja sen schema-kuvaukseen, vaan sen sijaan yleiseen schema-kuvaukseen lisätään vain paikka insertille. Kukin toimiala määrittää sitten omat inserttinsä ja vastaa niiden schemoista. XML-tekniikka tätä varten on jo olemassa ja se sallii ratkaisun. Yhden valtavan suuren maailmanmallin sijasta luodaankin yhteinen standardoitu perusrunko ja siihen upotettavat insertit, joiden määrittely ja schemahallinta on hajautettu eri toimialojen omien yhteiselinten vastuulle.

Puhdasoppisuus ei saa olla kehityksen este. Eihän? Varsinkaan kun vaihtoehtoinen tapa sekin on informaatioteknisesti aivan puhdasoppinen. Yhdistetään mieluummin nämä eri mielikuvamaailmat ja synnytetään laajempaa käyttäjäkuntaa palveleva laajempi yhteinen mielikuvamaailma. Sen myötä saadaan toimialakohtainen sovellusdata mukaan mielekkään kokoiseen ja ylläpidettävissä olevaan verkkolaskustandardiin. Ja verkkolaskujen integraatiohyödyt saadaan nopeasti käyttöön.

posted by Unknown @ 10:00