Kommenttipyyntö: eams-rakenne ja XML-skeema - Perusraportti

Transkriptio

1 Kommenttipyyntö: eamsrakenne ja XMLskeema Perusraportti 1. Kommentoin eamsrakennetta (valitse sopivin): Vastaajien määrä: Tietojärjestelmätoimittajana Asiakirjahallinnon näkökulmasta Tietohallinnon näkökulmasta Muu, mikä: Avoimet vastaukset: Muu, mikä: asiakirjahallinnon ja tietohallinnon yhdistävästä näkökulmasta 2. Kommentit rakenteen kuvaukseen ja esitettyihin linjauksiin yleisesti Vastaajien määrä: 12 Lähestymiskulma arkistonmuodostussuunnitelman rakenteeseen suppeasti on oikea. Rakenteen kuvaaminen koko julkiselle hallinnolle ei voi ollakaan kuin suppea, koska arkistonmuodostussuunnitelma voi vaihdella eri toimialoilla yksityiskohtien osalta. Hyvältä vaikuttaa: selkiyttää kokonaiskuvaa merkittävästi Eikö tehtäväluokituksessa käytettävä vähimmäistehtävätasojen määrä tulisi määritellä, koska kunnilla on niin vaihtelevia käytäntöjä ja joskus kuvailutaso ei ole riittävä. Luonnoksessa kerrotaan, "ettei eamsrakenne ota kantaa tietojen mallintumiseen tietojärjestelmässä". Tämä on mielestäni tulevan suosituksen ehdoton puute, sillä järjestelmänkehittäjät kaipaisivat suositukselta juuri tätä tietoa. Tehtäväluokituksen käyttö kohdassa sanotaan että "käsittelyprosessi kiinnittyy aina tehtäväluokituksen alimmalle tasolle. Tämän tehtävän alla ei voi olla enää alatehtävää." Voisi kuvata hieman tarkemmin mitä tuolla haetaan. Tarkoittaako samalla sitä että tehtävätasolle ei liity käsittelyprosessia, ts. sulkeeko nykyinen muotoilu pois sen että käsittelyprosessi liittyy tehtävätasolle ja alatehtävälle on toinen käsittelyprosessi? Esimerkkinä meillä EUtason komitea, jolla on omat kokousprosessit ja asiakirjatyypit, ja sen alatyöryhmät joilla on vähän eri prosessit, mutta valmistelevat kuitenkin samoja asioita. eamsrakenteen kuvauksessa (archimate) sekoittuvat nyt sekä eamsrakenteen (eamsjärjestelmä) että operatiivisen järjestelmän (esim. asiankäsittelyjärjestelmän) käsitteet. Tämä tekee kaaviosta monitulkintaisen. Jos otsikkona on eamsrakenteen kuvaus, niin siihen ei välttämättä kannata liittää työnkulkuja, käsittelijärooleja, varsinaisia asiakirjoja tms. Toisaalta eamsrakenteen yhtymäkohdat asiakirjallisen tiedon käsittelyprosessiin on suositeltavaa kuvata, mutta mielellään erillisenä kuvana tai niin, että järjestelmien rajat on selkeästi merkitty ja käsitteet, kuten asiakirja/asiakirjatyyppi ja asia/käsittelyprosessi, ovat toisistaan erillään. Tekstiosion kuvassa 1 on merkitty, että käsittelyprosessi kiinnittyy vain alatehtävään. Archimatekuvauksesta ja tekstistä saa kuitenkin sen käsityksen, että käsittelyprosessi voi liittyvä suoraan myös tehtävätasolle.

2 Pidämme hyvänä ratkaisuna, että suosituksessa yritetään löytää pienin yhteinen taso, johon kaikki voisivat sitoutua. Yleisenä havaintona tiedustelemme, että tuleeko arkistolaitoksen yllläpitämän eamstaulukon tilalle helppokäytöistä työkalua? Eli jos organisaatio ei halua hankkia ensin kaupallista tuotetta olisi sillä hyvä olla käytössä muu eams työkalu. Pienin yhteinen nimittäjä on hyvä lähtökohta. Rakenne ei saisi muodostua liian raskaaksi. Ok Miten koko eams voisi paremmin vastata asiakirjallisen tiedon kuvaamiseen. Jos se paranee sähke3:sen myötä, muuttuuko tässä JHStyössä tehtävä rakenne ja skeema jotenkin? Luonnoksessa puhutaan asiakirjatiedosta ja ainakin yhdessä kohden asiakirjallisesta tiedosta. Linjauksissa on varmaan takana tarve löytää malli eams työn helpottamiseksi. Vastakkaisena puolena on, että linjaukset vähentävät eams:n merkitystä onko itsenäiselle tietojärjestelmälle vielä tarvetta? Toiminnallisuutta katsotaan usein vain eams:n tietojen ylläpidon näkökulmasta, onko hyötyjä käytännön toiminnalle mietitty? Linjausten laatiminen ja kirkastaminen erittäin kannatettavaa. Lähtökohta linjauksille on kannatettava pienin yhteinen nimittäjä. Toivottavaa on että eams rakenne on toimiva ja eri tyypppisille tehtäville on mahdollista rakentaa toimiva ja mahdollisesti riittävän yksinkertainen malli ilman että pakotetaan "standardinomaiseen" samakaltaiseen käsittelyvaihejaotteluun kaikentyyppisissä tehtävissä. Rakenteen lähtökohdissa todetaan, että eams ei oteta kantaa tietojen mallintamiseen esim. asiankäsittelyjärjestelmässä. Määritteleekö se kuitenkin TOJ:n minimirakenteen. Samoin todetaan, että eams rakenteessa kuvataan ns. pinenin yhteinen nimittäjä. tarkoittaako tämä vähimmäismäärää jolla SÄHKE2 mukainen eams on mahdollista toteuttaa? 3. Kommentit käsittelyprosessin kuvaamiseen eamsissa (käsittelyvaiheet ja toimenpiteet) Vastaajien määrä: 10 Työryhmän näkökulma, joka perustuu SÄHKE2määräyksessä omaksuttuun ajatusmalliin asiakirjallisen tiedon muodostumisesta ja hallinnasta ei ole toimiva. Merkittävä määrä julkisen hallinnon asiakirjallisesta ja säilytettävästä tiedosta (ja asiakirjoista) syntyy tosiasiallisen hallintotoiminnan tuloksena mm. palveluja tuotettaessa tai toteutettaessa julkisuuslain tiedottamisvelvollisuutta tai hallintolaissa säädettyä neuvontavelvollisuutta eri muodoissaan. Tästä syystä asiakirjojen ja arkistonmuodostuksen sitominen pelkästään asiankäsittelyyn rajaa jo liian paljon suosituksen sisältöä eikä siten ole työryhmän tavoitteiden mukainenkaan. Tämä on erittäin merkityksellinen kuntahallinnon palvelutuotannossa sekä eri rekisterinpidon tehtävissä. Työryhmän tulisikin ottaa laajempi julkisen hallinnon toiminta tarkasteltavaksi asiakirjahallinnon näkökulmasta. Pelkästään hallintoasian käsittelyprosessiin kiinnittyminen on liian rajaava, jos AMSrakenteesta halutaan tehdä yleiseen käyttöön soveltuva. AMS rakenne tulisikin toimiakseen pohjautua seuraavaan tasoajatteluun: toimiala tehtävä palvelu toiminto vaihe Mihin perustuu käsittelyvaiheiden pakollisuus? On kokonaisuuksia (käsittelyprosesseja) jotka eivät etene ennalta mallinnetun kaavan mukaisesti. Liian tiukka ohjaavuus tekee arjesta hankalan ja johtaa helposti tietojärjestelmäkikkailuihin. Toisaalta riittänee että tietyissä asioissa (käsittelyprosesseissa) on vain peruskäsittelyvaiheet, virelletulo ja päättäminen. Hyvä ettei toimenpide ole pakollinen : varsinkin silloin kun toimenpide sisältäisi yhden asiakirjan on turhaa hienojakoisuuutta

3 Pitäisikö toimenpiteen oikeantyyliseen kuvaamiseen antaa jotain esimerkkejä ja ohjeita, miten toimenpiteet tulisi kirjata, jotta ne kuvaisivat hyvin käsittelyprosessin vaihetta. Onko järkevää laittaa toimenpiteet vapaaehtoisiksi, tuleeko käsittelyprosessin kuvaamisesta liian yleinen/epäselvä jos toimenpiteitä ei kuvaa ollenkaan. hyvä lähtökohta, että käsittelyvaihe on pakollinen, ja toimenpidetaso taas ei. suosituksessa käsittelyvaiheina suositellaan käytettäväksi hallintolain (434/2003) mukaisia yleisiä käsittelyvaiheita (neuvonta, ohjaus vireillepano valmistelu, käsittely päätöksenteko toimeenpano tiedoksianto muutoksenhaku seuranta, valvonta), mutta esimerkissä kuitenkin käytetään termiä vireilletulo. Kun saadaan pohja yhtenäistettyä ja yleinen ymmärtämys kuinka asioida pitää tehdä, on otettu iso askel eteenpäin. Luku "Tehtäväluokituksen käyttö" Kohta 1: "eamsrakenne ei ota kantaa tehtäväluokituksen tasojen määrään." Rakennekuvassa (eamsrakenne_archimate2.pdf) on kuitenkin kardinaliteetit 1...n. Kohta 2 ja kuva 1: Tehtäväluokituksen tasojen nimeäminen (päätehtävä, tehtävä, alatehtävä) monimutkaistaa aihetta turhaan. Ne on todettu käytännössä turhiksi. Ehdotus: Tehtäväluokitus voi sisältää 1n tasoa ja tasojen nimi on "Luokitus" tai "Tehtävä" tai mikä yhteinen nimi sovitaankaan. Kohta 3: "eamsrakenteessa käsittelyprosessi ei voi kiinnittyä päätehtävälle." Onko tähän jokin erityinen syy? Käytännössä kai tilanne on harvinainen, mutta miksi se pitäisi kieltää? Kuva 1: Tekstin alussa mainitaan rakenteen lähtökohtana mm. että eamsrakenteen linjaukset noudattavat SÄHKE2normia. SÄHKE2arkistorakenne on muotoa..asia/toimenpide/asiakirja. Käsittelyvaiheen nostaminen omaksi tasokseen on hämäävää ja monimutkaistaa käsitteistöä. Luku "Käsittelyvaiheiden kuvaaminen" Kohta 1, 5 ja 8: eams:ssa käsittelyprosessin kuvaaminen on kaksiportaista, käsittelyvaihe ja toimenpide eivät ole rinnakkaisia. Miksi rakenne on eams:ssa tarve olla monitasoinen, kun se kohdan 8 mukaan kuitenkin mäpätään yksitasoisena rakenteena operatiivisessa järjestelmässä (käsittelyvaihe ja toimenpide = toimenpiteen tyyppi)? Mikä on käsittelyvaihetason kuvaamisen tavoite? Jos tavoitteena on ryhmitellä käsittelyprosessin vaiheita (näkymä): Käsittelyvaihe voi olla eamsjärjestelmässä muodostettava näkymä eli toimenpiteet ryhmiteltynä toimenpiteen tyyppien mukaisesti. Jos tavoitteena on yksinkertaistaa prosessin kuvaamista: Minimivaatimustaso toteutuu myös sillä, että rakenteeseen määritellään vastaavat käsittelyvaiheet toimenpidetietotyypillä (tyyppi="vireillepano/valmistelu/jne.") Kohta 7: JOS käsittelyvaihe on kuvattu, EIKÄ toimenpiteitä ole kuvattu, niin JOS toimenpiteet on kuvattu, niin => Hyvä todennäköisyys sille, että rakenteita kuvataan kirjavasti. Kuva 2: Jos rakenne on tarkoitus säilyttää kaksitasoisena, niin tähän kuvaan voisi lisätä myös esimerkin miten rakenne toteutuu operatiivisessa järjestelmässä (onko käsittelyvaihe = pelkkä toimenpiteen tyyppi? eli tyhjä toimenpide?) Käsittelyvaiheen viitataan liittyvän sekä toimenpiteen tyyppi metatietoon että käsittelyprosessin tilaan (ks. Keskeiset käsitteet) => Ei selkeää. Miten käsittelyvaiheen mukaantulo ja toimenpiteen valinnaiseksi muuttuminen vaikuttaa eamssertifiointikriteereihin?

4 Ok Kuvauksissa näkyy käsittelyprosessi taso, jota ei ole eams:issa vaan asianhallinnassa. Käsittelyprosessin (asian) metatiedot ovat eams:in näkökulmasta alatehtävän tietoja avauksen jälkeen tietysti myös asian tietoja asianhallintajärjestelmässä. Tätä kannattaisi selventää. Käsittelyvaiheiden kuvaaminen on pakollista, toimenpiteiden kuvaaminen on vapaaehtoista. Antaa mahdollisuuden luopua toimenpiteiden luonnista kokonaan. Jos toimenpiteet jäävät pois, asiankäsittelyprosessin etenemistä ei pystytä seuraamaan samalla tasolla kuin nykyisin. On vaikeaa todentaa, miten käsittely eteni tai mitä vaiheita käsittelyn aikana on jo tehty. Ei edistä prosessien tuntemista tai kehittämistä. Asiakirjan luonti yksinkertaistuu. Käsittelyvaiheet jäsentävät käsittelyprosessin kuvaamista hyvin. Asiakkaat ymmärtänevät tällä tavalla kuvatun prosessin toivottavasti paremmin. Onko tarkoitus, että käsittelyvaiheet edelleen ohjaavat asian tilamuutoksia? Käsittelyprosessitason rinnalle voisi s. 2 kuvassa nostaa "asiatason", kuten on eamsrakenteen kuvausksessa (Pekka Nieminen, Netum laatimassa). Tämä helpottaisi hahmottamista. Käsittelyvaiheiden kuvaaminen on todettu pakolliseksi. Toivottavastikuitenkinkäsittelyprosessista riippuen voivat käsittelyvaiheet olla valinnaisia ja tehtävästä riippuvia. Toimenpiteiden pakollisuus ei välttämättä olisikaan hyvä asia, mutta tulisiko esim. laajoissa ja monipolvisissa prosesseissa kuitenkin suositella toimenpiteiden käyttöä. Samoin poikkihallinnolliset prosessit olisi hyvä laatia hyödyntäen toimenpiteita, jolloin kyetään yhteinen poikkihallinnollinen prosessi kuvaamaan eri toimijoiden osalta yhteiseen eamsiin. 4. Kommentit määriteltyihin käsitteisiin Vastaajien määrä: 12 Arkistonmuodostussuunnitelmassa on ollut pitkään ongelmana, että se kategorisoi liian paljon asiakirjoja sen julkisuuden ja salassapidon osalta, joka on omiaan heikentämään viranomaisen asiakirjojen hallinnassa hyvän julkisuus ja salassapitorakenteen toteuttamista (JulkL k). Lisäksi julkisuuslain 10 :n mukaan kun vain osa asiakirjasta on salassa pidettävä, tieto on annettava asiakirjan julkisesta osasta, jos se on mahdollista niin, ettei salassa pidettävä osa tule tietoon. Tästä syystä liian yleisesti kategorisoiva luokittelu voi olla omiaan heikentämään julkisuusperiaatteen toteuttamista. Työryhmä voisi myös arvioida mahdollisuutensa edistää tämän ongelman ratkaisua AMS rakennetta kehitettäessä. Työryhmän esittämä käsitteistö on myös ongelmallinen. Esimerkiksi kunnille on säädetty laissa tehtävät, jotka jakautuvat palvelujen järjestämisvelvollisuuteen. Käsitteistö ei siten vastaa lainsäädännöstä lähtevää käsitteistö, joka voi olla ongelmallinen yhteentoimivuuden näkökulmasta. Työryhmän olisi syytä odottaa myös valtiovarainministeriön linjauksia ensimmäisessä vaiheessa kuntien tehtäväluokituksesta, jossa myös käsitteistö luokitusjärjestelmään kiinnitetään. Tulevat tarpeeseen. Erittäin hyvä! Voisiko määritellä myös päätehtävän ja alatehtävän. Käsittelysääntöesimerkin voisi kuvailla ymmärrettävämmin: kunnan arkistonhoitajan käytännön työn näkökulmasta. Missä on toimenpidetyypin tarkenne käsite? Jos on asian tila, niin eikö pitäisi olla myös asiakirjan tila? Luonnoksessa määritellyt käsitteet eivät ole vielä olleet ydinsanastotyöryhmän käsittelyssä, joten tästä olisi pitänyt olla vähintäänkin maininta luonnoksessa. Käsittelyprosessikäsite tuntuu hyvin epäkäytännölliseltä, sillä käsittelyprosessilla (sis. käsittelyvaiheet, toimenpiteet ja käsittelysäännöt) olisi tuolloin aivan eri merkitys kuin asiakirjallisen tiedon käsittelyprosessilla (sis. asia). Käsittelyprosessikäsite kuulostaa sanana vain asiakirjallisen tiedon käsittelyprosessi ilmaisun lyhenteeltä, joten ilmaisuja on syytä vielä pohtia uudelleen.

5 julkisuusluokan muutos metatiedon merkitys jää epäselväksi: mihin metatietoa tarvitaan, kun kerran salassapitoaika ja salassapidon laskentaperuste kertovat jo asian. Käsitetaulukon (liite 1) mukaan Asia on Tehtävän yksittäinen ilmentymä, mutta eamsrakenteen kuvauksen mukaan Asia on Käsittelyprosessin ilmentymä, joka vain liittyy Tehtävään. Toinen käsitteellinen ristiriita esiintyy, kun asiakirjallisen tiedon käsittelyprosessista suositellaan käsitetaulukon huomautuksissa käytettävän termiä Asia. Tällöin eri abstraktiotason käsitteet "prosessi" ja "prosessin ilmentymä" menevät sekaisin. Voivatko "Asiakirjallisen tiedon käsittelyprosessi" ja "Asia" olla todella synonyymejä. Voi olla kuvattuna prosesseja, joihin ei ole tullut yhtään asiaa, mutta prosessit ovat kuitenkin oltava varmuuden vuoksi valmiina. Käsitteistössä on suosituksessa hienoista horjuvuutta. Miksi erilliset "Asia" ja "Asian nimeke" tai "Toimenpide" ja "Toimenpiteen nimeke"? Yleiskommenttina, että toivottavasti käsitteissä käytetään jo kertaalleen tehtyjä määrittelyitä tai mieluummin viitataan olemassa olevaan sanastoon/metatietomalliin/yms. Esim. "Käsittelyvaihe" on määritelty SÄHKE2 normissa ja tässä se on määritelty uudelleen. Käsittelyvaihe, Toimenpiteen tyyppi, Käsittelyprosessin tila, Asian tila => Käsitteiden väliset suhteet ja määritelmät vaativat tarkennusta Ok Operatiivisessa tietojärjestelmässä (esim. asiankäsittelyjärjestelmässä) käsittelyvaihe ja toimenpide voivat kummatkin vastata SÄHKE2metatietoa toimenpiteen tyyppi (5.6) Käsitteellisesti toimenpiteen tyypillä ei ole enää mitään merkitystä. Samaa tietoa toistetaan turhaan. Aikaisemmin toimenpiteen tyyppi on tarkoittanut käsittelyvaihetta. Tätä on pystynyt käyttämään hyödyksi käyttöliittymässä niputtamaan toimenpiteitä pienempiin tarkasteltaviin kokonaisuuksiin tai muodostettaessa graafisia kuvia käsittelystä Miten muutos vaikuttaa nykyisiin järjestelmiin? Pitääkö terminologia muuttaa vastaamaan tätä (= Käsittelyvaihe/toimenpide) jos sovelluksen nykyinen toiminnallisuus kuitenkin vastaa sitä mutta termit ovat eri (= toimenpide/välitoimenpide)? Käsitteistä puuttuu tehtäväluokitus. Toimenpiteen määrittelyssä voisi todeta sen olevan käsittelyvaiheella alisteinen ei "itsenäinen" Käsittelyprosessin tilan voisi kuvata kuten käsittelyvaihe on kuvattu ja todeta huomautuskohdassa, että ao. on SÄHKE2normissa käytetty termi. 5. Kommentit eamsrakenteen metatietoihin, niiden pakollisuuteen sekä mahdollisiin valmiisiin arvojoukkoihin, jotka tulevat sisältymään rakenteeseen. (HUOM! Arvojoukot määritellään myöhemmin). Vastaajien määrä: 8 Miksi asiakirjan liitteet eivät ole pakollisia? Oheismateriaalihan ei ole pakollinen mutta eikö liitteet voi olla asiankäsittelyn näkökulmasta tärkeitä asiakirjoja? Pitäisikö voa laittaa yhdeksi suositelluksi arvoksi, jos ei vaihtoehdot: sp + vuosiluvut käy kuvaamaan asiakirjan säilytysaikaa. Entä tuleeko asiakirjan säilytysajan perusteen merkitsemisvaihtoehtoja jotenkin tarkentaa, eli voisiko siihen laittaa oma tarve, jos ei löydy lakiperustetta säilytykselle. Nämä vaikuttivat hyviltä, mutta toivoisin vielä toimenpiteistä esimerkkilistausta. Onko esimerkiksi asiakirjan skannaaminen järjestelmään toimenpiteen nimeke? tyyppi? vai mitä nämä ovat (ja eikö skannauksesta tarvitakin aikaleima yms. tietoja?) Taukukon kuvaustapa on hieman epäselvä. Miksi asialla on säilytysaikatiedot tyhjiä tai miksei käsittelyprosesilla on pakollista suojaustasoa? Miksei asiakirjalla ole tehtäväluokitusta? Onko tarkoitus, että kaikilla asiakirjoilla on säilytysajasta pituus, peruste ja laskentaperuste? Vai tarkoitetaanko laskentaperusteella saapumispäivämäärää tai muuta aikaa, josta säilytysajan laskeminen aloitetaan? Ajattelen lähinnä säilytysaikamäärittelyjä "Harkinnan mukaan" vs "Pysyvästi säilytettävät"

6 Luku "eamskuvauksen metatiedot" 1. kohta: eamskuvauksen metatiedot tarvitaan (ei ole ehdollinen erityisesti sähköisessä eams:ssa). 2. kohta: eamskuvauksen metatiedot tarvitaan kaikille tasoille. Osa voi olla järjestelmän tuottamia teknisiä tietoja (esim. laadittu pvm). eamskuvauksen metatiedot: Tarvitaan myös voimassaoloajan päättymispvm Luku "Metatiedot ja arvojoukot" Käsittelyvaiheen ja toimenpiteen metatiedot? Ilmeisesti tarvitaan minimissään käsittelyvaiheelle "Tyyppi" "Asiakirjan liitteet" on ollut epäselvä tapaus eamstietomallissa. Jos se tulee säilymään, niin sen käyttötapaa tulisi tarkentaa. Mitä siihen kuvataan ja miten. eamsrakenteen kuvaus (erillinen liite, eamsrakenne_archimate2.pdf) Kuvauksen mukaan tehtäväluokituksen tasoja on oltava vähintään neljä (1 *) Ns. eams:n hallintatiedot (ID, Nimeke, Voimassaoloaika, jne.) tarvitaan myös muille rakenneosille (asia, asiakirja) Käsittelyvaiheen/Toimenpiteen tiedot? Vähintään perustietoja (ID, muita?) ja tyyppi? Tarkoittaako asian ja asiakirjan "Tila" SÄHKE2normissa olevaa Tilametatietoa vai eamsrakenteen tilaa kuvaavaa tietoa? Tarvitaan erityisesti jälkimmäinen. Käyttäjäryhmän rooli+kuvaus tiedot (salassa pidettäville)? Mitä käsittelyvaiheeseen ja toimenpiteeseen kytketyt "Rooli" ja "Henkilö, Toimija, Vastuutaho, Resurssi" tarkoittavat? Miten niitä on tarkoitus käyttää? Ok Kuinka hyvin arvojoukkoja voidaan määritellä valmiiksi arvojoukoiksi? eli kuinka hyvin se palvelee lopulta kutakin virastoa? Esim säilytysaikaa säätelee viranomaiskohtainen lainsäädäntö. Myös salassapitoa: Julkisuuslaki tietysti koskee kaikkia yleislakina mutta erityislainsäädäntö voi ohjata hyvinkin tarkkaan vo:n salassapitoperusteita. Eli arvojoukot jäävät pitkälti esimerkkitasolle... Erinomaista, että paperiasiakirjojen pakollisista metatiedoista luovutaan! Eikö Säilytysajan pituus ja Säilytysajan peruste ole Pakolloisia kun niiden arvojoukot kuitenkin sitä ovat?

7 6. Muita huomioita Vastaajien määrä: 9 Työryhmän työ on tärkeää tietojärjestelmien yhteentoimivuuden edistämiseksi. Tästä syystä työryhmän tulisikin irtautua pelkästään perinteisen asiakirjahallinnon omaksumasta näkemyksestä viranomaisen tiedonhallinnasta, joka perustuu valtaosin muuhun kuin perinteiseen hallintomenettelyprosessiin. On otettava huomioon onko eamstehtäväluokittelun rakenteessa loogisia puutteita, eli toiset tasot on kuvattu tarkemmalle tasolle kuin toiset tai että jokin alatehtävä tulisi kuuluakin johonkin toiseen tehtäväluokkaan eamskuvauksen tiedot otsikon alle tarvitaan täsmennystä, mitä nämä tiedot ovat: eamsin laadinta/päivitystietoja? vai joitakin muita tietoja? Suosituksessa on vielä horjuvuutta ja käsitteistö tulisi yhtenäistää taulukoissa ja tekstissä. Esimerkkinä asiakirjan tehtävä on taulukossa merkitty harmaana, mutta kuviossa mahdollisena. Tarkoittaako * pakollisuutta, koska samassa kuviossa se ilmeisesti tarkoittaa kahta eri asiaa (eams rakenteen kuvaus). Mitä vaatimuksia eams:n raportointiin ja lokitukseen liittyy? Esim. voidaanko raportoida/säilyttää osissa? Tuleeko kaikki koodistot säilyttää? Yhteenveto kommenteista: eamsrakenteen kuvaamisen ja ylläpidon kannalta tulisi pyrkiä mahdollisimman selkeään ja yksinkertaiseen tietorakenteeseen. Tätä tavoitetta edistävät ainakin: Tehtäväluokituksen tasojen yksinkertaisempi nimeäminen (yksi rekursiivinen tietorakenne, ei akateemisia ja teoreettisia tasokohtaisia nimiä) Yksitasoinen käsittelyvaihe (tai toimenpide, kumpaa sitten käytetäänkään). Käsittelyvaiheen voi kuvata eri tavoin (kuten JHSluonnoksessakin on ehdotettu): Tyyppi = "Vireillepano" ei asiakirjoja Tyyppi = "Vireillepano" liittyy asiakirjoja Tyyppi = "Vireillepano" Nimeke = "Asiakkaan neuvonta" ei asiakirjoja Tyyppi = "Vireillepano" Nimeke = "Hakemuksen vastaanottaminen" liittyy asiakirjoja Pelkkien asiakirjallisten tietojen huomioiminen ei enää nykymaailmassa riitä, vaan pitää olla myös malli tiedon säilyttämisen ohjaamiselle. Tehtäväluokituksen tasoja ei tulisi syventää kovin pitkälle. Selkeys ja yksinkertaisuus on tässäkin valttia Kuvassa: asiakirjataso: pitäisi päästä kuvaamaan tietoa. Asiakirjataso on vanhentunutta ajatttelua osin. Kuvataanko asiakirja ja (asiakirjallinen) tieto samalla tavalla? Kuvassa eamsrakenteen kuvaus > Tehtäväluokitustaso: Alatehtäviä on merkitty olevan 1..* > ei välttämättä ole yhtään alatehtävää vaan voi jäädä tehtävätasolle. Tekstissä myös sanotaan, että tasoja voi olla tarvittava määrä, kuvan perusteella se ei ole mahdollista jos kuvaa luetaan tiukasti. Miten tämä tuleva JHSsuositus tulee vaikuttamaan SÄHKE2sertifioituihin järjestelmiin? Toivottavaa on että asia kuvataan mahdollisimman selkeästi, käytännön läheisesti ja ymmärrettävästi siten, että asia avautuu riittävällä tasolla myös niille, jotka eivät ole asiaan syvällisesti peryhtyneet/vihkiytyneet. Suosituksessa olisi hyvä käyttää esimerkkejä asian avaamiseksi. eams rakenne on organisaatiolähtöinen. Miten on tarkoituksena kuvata "asiakkaan käsittelyvaiheet" Aineistossa todetaan, että eams rakenteen perusteella määritellään vain XMLskeema eams tietojen välittämiseksi eri eamsjärjestelmien kesken. Miten esim. suhde ns. vapaaehtoisiin/organisaationkohtaisiin metatietoihin miten ne "hyväksytetään" esim. YSRkäsittelyssä vai ovatko orrganisaatikohtaiset eams

8 metatietodot täysin yksittäisten organisaatioiden määrittelyn varassa.