Palautekooste: JHS XXX eams-rakenne ja skeema - Perusraportti

Transkriptio

1 Palautekooste: JHS XXX eams-rakenne ja skeema - Perusraportti 1. Organisaatio Vastaajien määrä: 31 - Yksityishenkilö - Maanmittauslaitos - Kuopion kaupunki - Senaatti-kiinteistöt - Maa- ja metsätalousministeriön tietopalvelukeskus - Lempäälän kunta - Eduskunnan kanslia - Liikenne- ja viestintäministeriö - Puolustusvoimat - Puolustusministeriö - Maa- ja metsätalousministeriö - Yksityishenkilö - Arkistolaitos - Kontiolahden kunta - Ulkoasiainministeriö - Valtiovarainministeriö, Tietoyksikkö - Nurmijärven kunta - Yksityishenkilö - Innofactor Software Oy - Lappeenrannan kaupunki - Arkistolaitos, UUSI VERSIO Liikennevirasto - Oikeusministeriö - Fujitsu Finland - KEMINMAAN KUNTA - Verohallinto - Opetus- ja kulttuuriministeriö - Helsingin kaupunki, Talous- ja suunnittelukeskus, Tietotekniikkaosasto - Yksityishenkilö - TEM, PRH, Tekes - OM/psta JHS-sihteeri, erillinen muistio 2. Yhteyshenkilön tiedot Vastaajien määrä: Yleiskommentit Vastaajien määrä: 21 - Kielen selkeyteen pitää kiinnittää enemmän huomiota. Tekstin ymmärtää vasta useamman lukukerran jälkeen ja vain, koska se on tullut ennalta työn kautta tutuksi. Teksti on täynnä merkityksettömiä täytesanoja ja lauseita, jotka poistamalla suosituksesta tulisi tiiviimpi ja selkeämpi. Käsitesekamelska on aikamoinen ja se on vaivannut koko eams-työtä alusta asti. Esim. eams=tos, toimenpide=käsittelyvaihe, asiaryhmä=tehtävä, käsittelyprosessin kuvauksen oletusmetatiedot=asian oletusmetatiedot jne. Edellä mainittujen samansisältöisten käsitteiden erot ovat semantiikkaa. Käsitemaailmaa tulisi rohkeasti yksinkertaistaa. - Osa käsitteistä vaatisi vielä lisätäsmennyksiä, jotta niiden tarkoituksen ymmärtäisi paremmin käytännössä. Ehdotettuja metatietokenttiä on lukumääräisesti todella paljon ja niiden yhteys sähke 2 lomakkeeseen ei ole aina kovin selkeä. EROT SÄHKE 2 NORMIN / LUOKITUKSEN JA JHS-ESITYKSEN VÄLILLÄ OLISI HYVÄ KOOSTAA OMAKSI KAPPALEEKSEEN. Osa määrittelystä on hyvin selkeää. - Suositus on tarpeellinen ja suosituksen rakenne vaikuttaa käytettävältä. - Saadusta palautteesta tulisi saada kooste JHS:n internet-sivuille. Lausunnolla oleva kokonaisuus perustuu Sähke 2 -ajatteluun toimenpidetasoineen, mikä mutkistaa ja

2 vaikeuttaa asiakirjallisen tiedon käsittelyä. Toimenpidetaso on asianhallintajärjestelmän käyttäjälle (virkamiehelle) hankalaa ja lisää runsaasti työtä eams:n laadinnassa. Tuoko toimenpidetaso lisäarvoa? Muiden metatietojen avulla saadaan riittävä tieto asiakirjan syntykontekstista. eams edellyttää, että kaikki viraston arjessa esiintyvät tehtävät voidaan määritellä etukäteen. Tämä ei ole käytännössä aina mahdollista. - Luettavuuteen kannattaa kiinnittää vielä huomiota. - Suosituksen teksti on vaikealukuista ja vaikeaselkoista. Tekstin luettavuuteen on kiinnitettävä huomiota. Vaikuttaa siltä, että suosituksessa on pyritty yhdistämään käsittelyprosessin kuvaus ja periytymään tiedot prosessin asiakirjoille. Sen vuoksi vaikuttaa epäselvältä, miksi käsittelyprosessin kuvaukselle pitäisi määritellä säilytysaika, henkilötieto tai säilytysajan laskentaperuste, kun nämä tiedon selkeästi liittyvät asiakirjoihin. - Suosituksen kieli ja käsitteet ovat osittain vaikeita, vaikka ehkä olisi voinut löytää tavan ilmaista asioita käytännön läheisemmin. Moni asia hahmottuisi paremmin, jos sitä selvennettäisiin esimerkein. Esim. metatietomallissa Asiakirjatyypin tarkenne, tai Asiakirjatiedon tallennuspaikka; minkälaisia nämä voisivat olla? On vaikea hahmottaa eams:n ja eams-määrityksen ero. Miksi kutsutaan eams:n tietosisältöä? Lisäksi on eams-rakenne ja rakenteen rakenneosat. Kaipaisi selkeää kuvausta näiden suhteista esim. kaaviona/kuvana. On monta erilaista tietoa /metatietoa ja oletusmetatietoarvoa, joista osa kuuluu tiedonohjaukseen, osa ei. Vaikea erottaa mitkä ovat eams-määrityksen "ulkoisia" metatietoja ja missä on eams:iin (vai eams-määritykseen?) sisältyviä metatietoja, jotka kuuluvat asialle (käsittelyprosessin kuvaukselle), toimenpiteelle ja asiakirjatiedolle. Lisäksi: - käytetäänkö käsitettä asiakirjat vai asiakirjatiedot - pitää tarkistaa: onko kyse erikoislaista, erillislaista vai erityislaista - käsitteistöön tulisi lisätä mahdollisuuksien mukaan: *metatietojen arvojoukko *hybridiaineisto *käsittelysääntö *rakenteinen tieto *kooste *natiivimuoto Pakolliset valtiolle termin muotoiltuksi "valtionhallinnon viranomaisille" - Suositus vaikuttaa perusteellisesti laaditulta. - Suositus parantaa ja yhdenmukaistaa käytäntöjä. Kaikki tuki on tarpeen, sillä työkenttä on laaja ja vaatii organisaatioissa viranomaisyhteistyötä. Suositus on ilmeisesti tarkoitettu vain asianhallinnan ja arkistoinnin ammattilaisille, sillä sen ymmärtäminen vaatii asiantuntemusta. - Erittäin selkeä ohjeistus. - Suositus on tarpeellinen. Kuitenkin tämän ja SÄHKE2:n terminologia on erilainen, joka ei helpota asian käsittelyä. Sanaston pitää olla niin selvää, että tavallinenkin henkilö ymmärtää, mistä kulloinkin puhutaan. Kaksi erillistä "ohjetta" samasta asiasta ei missään nimessä tee asiasta helpompaa, päinvastoin. - Moni asia hahmottuisi paremmin, jos sitä selvennettäisiin esimerkein. Esim. metatietomallissa Asiakirjatyypin tarkenne, tai Asiakirjatiedon tallennuspaikka; minkälaisia nämä voisivat olla? On vaikea hahmottaa eams:n ja eams-määrityksen ero. Miksi kutsutaan eams:n tietosisältöä? Lisäksi on eams-rakenne ja rakenteen rakenneosat. Suosituksen käyttäjä kaipaa selkeää kuvausta näiden suhteista esim. kaaviona/kuvana. Lisäksi olisi hyvä määritellä tiedonohjauksen suhde em. käsitteisiin. Suosituksessa puhutaan erilaisista tiedoista/metatiedoista ja oletusmetatietoarvoista, joista osa kuuluu tiedonohjaukseen, osa ei. Lukijan on hankalaa erottaa, mitkä ovat eams-määrityksen "ulkoisia" metatietoja ja missä ovat eams:iin (vai eams-määritykseen?) sisältyvät metatiedot jotka kuuluvat asialle (käsittelyprosessin kuvaukselle), toimenpiteelle ja asiakirjatiedolle. Suosituksen viimeistelyssä tulisi kiinnittää huomiota myös käsitteisiin asiakirjat ja asiakirjatiedot, joita kumpaakin käytetään lausunnolla olevassa luonnoksessa. Johdonmukaisinta olisi, että puhutaan vain asiakirjatiedoista, Arkistolaitoksen näkemyksen mukaan käsitteisiin tulisi lisätä myös seuraavat käsitteet: *metatietojen arvojoukko *hybridiaineisto *käsittelysääntö

3 *rakenteinen tieto *kooste *natiivimuoto - Hyvä, että eams-rakenne ja xml-skeema suositus on tekeillä, tarvetta sille on. - eams-rakennetta ja skeemaa koskevaa JHS-suositusta on jo odotettu, joten erittäin hyvä, että se on nyt tulossa. Esimerkit ovat suositusluonnoksessa hyviä ja selkeitä ja ne helpottavat asioiden ymmärtämistä. - Toivomuksena on, että JHS-suosituksen hyväksyminen ei tuo mittavia muutostarpeita kehitteillä tai olemassa oleviin tietojärjestelmiin - Keminmaan kunta toteaa lausunnossaan seuraavaa; Soveltamisalan osalta; - hyvä, että rajaus on tehty siten, että paperiasiakirjojen hallintaan riittää perinteinen arkistonmuodostussuunnitelma Termit ja lyhenteet; - selkeästi avattu tärkeä osa eams-rakenteen rakenneosat; - eams rakenneosakuvaus selkeä eams-määrityksen tiedot; - tietojärjestelmiä ja metatietoja varten tulee tulee kunnissa var-maankin käyttää ATK-palvelujen asiantuntemusta suunnitelmaa laadittaessa. Olisiko mahdollista avata vielä enemmän erityisasi-antuntemuksen osuutta (mm. tietojärjestelmien ym.. osalta) - tärkeää käyttöön oton kannalta, että eams-määritys voidaan laatia ja ottaa käyttöön osissa Tehtävien määrittely; - selkeästi kuvattu, että organisaatiossa tulee olla hyväksytty ja ajan tasalla oleva tehtävänluokitus (luettelot). - hyvä tiedonhallintatapa edellyttää, että organisaatiolla on ajan-tasaiset kuvaukset omista tehtävistä ja tehtävän yhteydessä kertyneistä asiakirjatiedoista. Olisiko vastuukysymyksiä hyvä avata vaikka vielä tarkemmin, jotta tehtäviä koskevat päivitykset hoidetaan asianmukaisesti. e-ams-rakenneosa; - kaaviot ja esimerkkiluokitukset avaavat asiaa hyvin - taulukot havainnoivat hyvin asiaa - yleensäkin malliesimerkit havainnollistavat hyvin asiaa Metatiedot - Metatietojen osalta meidän tulee tutustua osioon vielä tarkemmin - eams-rakenteessa pitäisi olla vaatimuksena, että eams on "tunnoton" sähköisille järjestelmille ja viranomaisella saa olla käytössään vain yksi eams, missä on kuvattu kaikki viranomaisen lakisääteiset tehtävät. - Kiitokset hyvästä työstä ja työtä on jatkettava. eams toteuttamisen tueksi tarvitaan juuri yhdenmukaistamista metatietojen ja arvojoukkojen osalta. Jotta eams pääsee tavoitteeseensa tiedonohjauksen masterdataksi, on tehtävä juuri tämän suosituksen tyyppisiä kuvailuja sekä korostaa pakollisten tietojen vaatimuksia ja määrittää selkeitä arvojoukkoja sekä markkinoitava tiedonohjauksesta saatavia hyötyjä. Tietomalli ja skeema auttavat julkishallinnon tietohallinnon asiantuntijoita sekä tietojärjestelmien kehittäjiä ymmärtämään tiedonohjauksen logiikkaa, sillä asiakirjahallinnon terminologia on edellä mainituille asiantuntijatahoille hyvin haasteellinen. Koska järjestelmien ja niiden kehittäjien kieli on englanti, olisi tärkeää, että eams kuvauksissa pidetään aina rinnalla tekninen termi englanniksi. Liitteessä 1 Metatietomalli nämä kohdat olivat osittain vielä täydentämättä ja tämä on varmaan viimeisteltynä seuraavaan katselmointiin mennessä. - Kiitos eteenpäin vievästä työstä. Pyrkikää edelleen mahdollisimman yksiselitteiseen esitystapaan (idioottivarmuus) ja yksinkertaisiin lauserakenteisiin. - TEM on koonnut kommentteja myös hallinnonalansa toimijoilta. Kommentit on saatu TEM lisäksi Tekesiltä ja PRH:lta. TEM hallinnonalta on JHS-suositusryhmässä toiminut edustajana Armi Helenius. Suositus on rakenteeltaan selkeä ja jako "päädokumenttiin" ja tarkentaviin liitteisiin on toimiva. - Oikeusministeriö on toimittanut erillisen muistion.

4 4. Anna arviosi seuraavista suositusluonnokseen liittyvistä väitteistä asteikolla 1-5 (5 = samaa mieltä, 1 = eri mieltä) Vastaajien määrä: Yhteensä Keskiarvo Suositus on tarpeellinen ,50 Suositus on otettavissa käyttöön ilman tukea ja koulutusta Suosituksen luettavuus ja ymmärrettävyys ovat hyvällä tasolla , ,23 Yhteensä ,47 5. Suositusluonnoksen hyväksyminen Vastaajien määrä: Vastustusperusteet 7. Yleiset muutosehdotukset Vastaajien määrä: 6 - Katso kohta 3. - Ihan jonnekin koko suosituksen alkuun pitäisi saada seuraavanlainen lause: eams-rakenneosia ovat: eams-määrityksen tiedot (eams-määrityksen termi selvennettävä esimerkillä), tehtävä, käsittelyprosessin kuvaus, toimenpide ja asiakirjatieto. Suosituksen kaltaisessa tekstissä tulisi käyttää mahdollisimman hyvää suomea. Lyhenteitä taivuttaessa tulisi käyttää kaksoispistettä, kuten eams:aan. Ei eamsin, eamsiin. - Suosituksen alkuun pitäisi saada seuraavanlainen lause: eams-rakenneosia ovat eams-määrityksen tiedot (eams-määrityksen termi selvennettävä esimerkillä), tehtävä, käsittelyprosessin kuvaus, toimenpide ja asiakirjatieto. - -Tulisi huomioida JHS 176 uudistamisen ja alkamassa olevan JHS-työn rekisteritietojen metatiedoista vaikutukset. -eams-rakenteen suositusluonnoksessa esiintyy vielä asiakirja-termiä asiakirjatieto-termin ohella. Sähköisessä asiankäsittelyssä ei ole enää olemassa asiakirjakäsitettä, sillä haluttu tietokooste muodostetaan useista tietojen palasista ja ne sijaitsevat useissa eri järjestelmissä. Myös eri tietolähteistä saatua tietoa voidaan käyttää

5 päätösten tekemisessä. Jää epäselväksi, miten määritellään säilytysajat näin käytetyille tiedolle. - Suomen- ja englanninkielen terminologian säilyttäminen rinnakkain erityisesti teknisissä nimissä voisi olettaa auttavan asiakirja- ja tietohallinnonosaajien kommunikointia kehityshankkeissa. - Vaikka suositus on rakenteeltaan selkeä, olisi asian ymmärrettävyyden kannalta tarpeellista hyödyntää suosituksessa nykyistä laajemmin konkreettisa käytännön esimerkkejä. Tämä helpottaisi asian avautumista myös asiaan syvällisemmin vihkiytymättömille. Esimerkit helpottaisivat asian selittämistä ja ymmärrystä erityisesti prosessin omistajien osalta. Vaikka kyse on suosituksesta, joka on tarkoitettu eams-tietosisällön määrityksiin silloin kun eams integroidaan yhden tai useamman operatiivisen tietojärjestelmän taustalle on taustalla kuitenkin aina toimintatavan ja käsittelyprosessin/toimintaprosessin kuvaaminen, jossa omistajana on substanssi EI tietohallinto tai asiakirjahallinnan asiantuntija. Jo nyt mukana olevat esimerkit ovat valaisevia ja avaavat asiaa hyvin. 8. Muutosehdotukset kappaleeseen 1. Johdanto Vastaajien määrä: 4 - Lainsäädännön lisäksi eams:n ja tiedonohjauksen käyttöä kannattaa/pitää perustella myös käytettävyydellä. - informatiivisempi johdanto [ ] asiakirjatyypit sekä näiden oletusmetatietoarvot mm. julkisuuden, henkilötietoluonteen ja säilytysajan osalta. eams kytketään tietojärjestelmän taustalle siten, että eams tuottaa automaattisesti metatietoarvoja operatiiviseen tietojärjestelmään. Tämä lause toistoa saman kappaleen ensimmäisen lauseen kanssa. Sama ajatus toistuu myöhemminkin lähes samoin sanoin, esim. soveltamisalassa, termeissä. - informatiivisempi johdanto [ ] asiakirjatyypit sekä näiden oletusmetatietoarvot mm. julkisuuden, henkilötietoluonteen ja säilytysajan osalta. eams kytketään tietojärjestelmän taustalle siten, että eams tuottaa automaattisesti metatietoarvoja operatiiviseen tietojärjestelmään. Tämä lause toistoa saman kappaleen ensimmäisen lauseen kanssa. Sama ajatus toistuu myöhemminkin lähes samoin sanoin, esim. soveltamisalassa ja käsitteissä. - eamsiin määritellään varmasti aina useita tehtäviä ja niiden käsittelyprosessien kuvauksia, joten toisen kappaleen toinen virke tulisi muuttaa kokonaan monikkomuotoon: "eamsiin määritellään tehtäviin sidotut käsittelyprosessien kuvaukset, niihin liittyvät toimenpiteet ja niiden yhteyteen liittyvät asiakirjatyypit sekä näiden oletusmetatietoarvot mm. julkisuuden, henkilötietoluonteen ja säilytysajan osalta." 9. Muutosehdotukset kappaleeseen 2. Soveltamisala Vastaajien määrä: 7 - "Vain integroimalla eams-määritys tietojärjestelmään automaattiseksi oletusmetatietoarvojen lähteeksi, eamsilla voidaan saavuttaa hyötyjä metatietojen automaattisen tallentumisen ja käsittelyprosessin ohjautuvuuden myötä." Kannattaa ottaa pois - vaikeasti kirjoitettu tyhjä lause, jonka sisältö on itsestään selvä. - Luvussa 2 Soveltamisala todetaan, että Tietojärjestelmien taustalle määriteltävä eams pitää laatia noudattaen tässä suosituksessa kuvat-tua eams-rakennetta ja suosituksessa määriteltyjä pakollisia metatietoja jne. Intuitiivisesti ajatuksen sisältö on ristiriidassa, kun on kyse suosituksesta, joka kuitenkin määrää tekemään tiettyjä toimenpiteitä. Onko suositusta noudatettava? - Lause: "Paperiasiakirjojen hallintaan riittää perinteinen arkistonmuodostussuunnitelma" on epäselvä. Tarkoitetaanko tällä, että paperisille ja sähköisille asiakirjoille on laadittava erilliset ams:t. Organisaatioiden asianhallinnan ja arkistoinnin toimivuuden kannalta se ei ole järkevää eli yksi ja sama ams eli tiedonohjaussuunnitelma molemmille asiakirjamuodoille. - Toiseksi viimeisen kappaleen virkkeen voi nyt ymmärtää siten, että tietojärjestelmiä - ei niiden sisältämää asiakirjatietoa - tiedonohjataan eams-määrityksillä. Virkkeen voisi muuttaa seuraavaan muotoon: "Suositus on tarkoitettu julkishallinnon toimijoille, jotka laativat tietojärjestelmissä toteutuvassa tiedonohjauksessa käytettäviä eams-määrityksiä, ja tietojärjestelmätoimittajille, jotka kehittävät tietojärjestelmiään eamsin laadintaan ja ylläpitoon sekä eamsia hyödyntäviä sovelluksia." Harkittavaksi pitäisikö tietojärjestelmä korvata kokonaan sovellus-sanalla. - eams suositus keskittyy käsittelyprosessin kuvaamiseen. eams:aa tarvitaan kuitenkin myös tilanteissa, joissa operatiivinen tietojärjestelmä arkistoi asiakirjoja, mutta itse käsittelyprosessi hoidetaan operatiivisen tietojärjestelmän sisällä (esimerkiksi laskujen käsittely). Tähän prosessiin ei eams voi tuoda ohjaavuutta, mutta säilyttämiseen liittyvät tiedot tarvitaan, kun operatiivisen tietojärjestelmän tiedoista luodaan säilytettävä

6 asiakirja. Suositukseen kannattaa lisätä ohje siitä, miten eams rakenne tällaisessa tilanteessa kuvataan. Tällä hetkellä on sallittua, että säilyttämiseen liittyvät tiedot voidaan myös lisätä myös arkistoinnin yhteydessä. Toivomme, että tämä mahdollisuus säilyy ja näkyy suosituksessa. - Perinteinen arkistonmuodostussuunnitelma jää tässä hieman irralliseksi ja vaatii tarkemman kuvauksen. - Vaikka onkin tarkoituksenmukaista laatia eams (vain) niistä tehtävistä, joita käsitellään operatiivisessa tietojärjestelmässä ja joihin eams tuottaa oletusmetatietoarvoja, niin eams-järjestelmään voi olla hyvinkin tarkoituksenmukaista käytännön kannalta laatia kuvaukset myös niistä tehtävistä/tietojoukoista, joita käsitellään järjestelmissä, joihin tiedonohjauspalvelua ei uloteta (syystä jos toisesta). Organisaatiossamme on tarkoitus tuottaa eams-järjestelmään eams(tos)osioita, joihin kootaan hallintatietoja tietoaineistosta, jonka taustalla ei esim. ole asiankäsittelyprosessia. Näillä osioilla ei ole ohjaavaa roolia ja näiden tietorakenne voi poiketa hyvinkin paljon Sähke1/2-rakenteista, mutta emme halua näiden tietoaineistojen hallintatietojen laadinnassa käyttää exceleitä tai vast. välineitä. 10. Muutosehdotukset kappaleeseen 3. Viittaukset - Säädösnumerot on merkittävä yhtenäisellä tavalla esim. 434/2003. Ensin numero ja sitten vuosi. Nyt säädösnumerotiedot ovat hallintolain ja arkistolain kohdalla väärin päin. Onko tässä olevien viittausten tarkoitus koskea koko suositusta liitteineen vai vain suositusta? Liite 1 Metatietomallissa mainitaan myös SFS-EN standardi, julkisuuslaki (621/1999), tietoturva-asetus (681/2010), VAHTI-ohje 2/2010 ja YSA. Lisäksi xml-standardia koskevat viittaukset puuttuvat. 11. Muutosehdotukset kappaleeseen 4. Termit ja lyhenteet Vastaajien määrä: 9 - Periaatteessa hyvä, mutta selitettäviä termejä saisi olla enemmän erityisesti kuntatasolle. Hyvä esimerkki laaajemmasta sanastosta löytyy osoitteesta: - Termi AMS: esitetään lisättäväksi TOS-lyhenne ja tiedonhallintasuunnitelma; THS. Termi eams: esitetään lisättäväksi tiedonhallintasuunnitelma THS. Huomioiminen myös myöhemmissä kohdissa, esim. eams-järjestelmä --> tiedonhallintajärjestelmä Käsittelyvaihe ja toimenpide: esitetään termin toimenpide määritelmäksi seuraavaa: Toimenpide: "asian tietyssä käsittelyvaiheessa tapahtuva yksittäinen toimi tai tapahtuma." Operatiivinen tietojärjestelmä: Onko operatiivinen järjestelmä myös järjestelmä, johon sähköinen asiakirjatieto (pysyvästi) tallennetaan? Jos ei, tulisi pysyvän tallentamisen järjestelmälle olla oma määritelmänsä. - Tässä kohdassa saisi olla mahdollisimman kattavasti määritelty suositusluonnoksessa käytetyt termit. Puuttuvista mainittakoon esim. arvojoukko ja rakenneosa. Myös termien väliset suhteet helpottaisivat asian omaksumista, samoin esimerkkitapaukset, joilloin JHS-suositus saataisiin ymmärrettävämmäksi. - Luvussa 4 s. 3 kohdassa arkistonmuodostussuunnitelma pitäisi varmaankin olla samaa tarkoittavana tiedonhallintasuunnitelma eikä tiedonohjaussuunnitelma (seuraavalla sivulla eams = TOS). asiakirjatieto [ ]ja jota se säilyttää tietovarantona sekä todisteena (ISO-SFS /Asiakirja). tietovarantona ja todisteena/ sekä tietovarantona että todisteena eams-määritys pitäisikö selventää tässä, että on eri metatietojen tuottajia: itse eams-sisältö + tietojärjestelmä, käyttäjä, ja käsittääkö eams-määritys nämä kaikki tahot. käsittelyvaihe Käsittelyprosessin yksittäinen vaihe, joka kuvastaa käsittelyprosessin laajempaa osaa. Käsittelyvaihe tallentuu tietojärjestelmään toimenpiteenä

7 Mikä on käsittelyprosessin laajempi osa? Voisiko käsitettä avata jotenkin tai muotoilla muuten? operatiivinen tietojärjestelmä Operatiivinen järjestelmä on tyypillisesti esim. asiankäsittelyjärjestelmä voisiko myös substanssijärjestelmän mainita esimerkkinä? prosessi Joukko toisiinsa liittyviä toistuvia toimintoja, joiden avulla syötteet muutetaan tuotoksiksi. Jos mahdollista, voisi laittaa esimerkin julkishallinnon prosesseissa syntyvästä konkreettisesta syötteestä ja tuotoksesta tehtäväluokitus Organisaation lakisääteisten tehtävien ja tuki- ja ylläpitotehtävien luettelo. Tehtäväluokitus voi toki kattaa muitakin tehtäviä kuin lakisääteisiä ja tuki- ja ylläpitotehtäviä, joten ehdotetaan edellä mainittuun lisäys: lakisääteisten ja muiden tehtävien sekä tuki- ja ylläpitotehtävien luettelo toimenpide Asian käsittelyyn liittyvä yksittäinen toimi tai tapahtuma. voisiko olla: tekemisen vaihe - Luvussa 4 s. 3 kohdassa arkistonmuodostussuunnitelma pitäisi varmaankin olla samaa tarkoittavana tiedonhallintasuunnitelma eikä tiedonohjaussuunnitelma (seuraavalla sivulla eams = TOS). eams-määritys pitäisi selventää, että on eri metatietojen tuottajia: eams-sisältö + tietojärjestelmä, käyttäjä, ja käsittääkö eams-määritys nämä kaikki tahot. käsittelyvaihe Käsittelyprosessin yksittäinen vaihe, joka kuvastaa käsittelyprosessin laajempaa osaa. Käsittelyvaihe tallentuu tietojärjestelmään toimenpiteenä Mikä on käsittelyprosessin laajempi osa, joka on kuitenkin vain yksittäinen vaihe? Voisiko käsitettä avata jotenkin tai muotoilla muuten? Käsitettä ei ole aikaisemmin käytetty ja tällaisenaan se on omiaan synnyttämään hämmennystä. operatiivinen tietojärjestelmä Operatiivinen järjestelmä on tyypillisesti esim. asiankäsittelyjärjestelmä voisiko myös substanssijärjestelmän mainita esimerkkinä? prosessi Joukko toisiinsa liittyviä toistuvia toimintoja, joiden avulla syötteet muutetaan tuotoksiksi. Jos mahdollista, voisi laittaa esimerkin julkishallinnon prosesseissa syntyvästä konkreettisesta syötteestä ja tuotoksesta. Voisi olla parempi käyttää predikaatista aktiivimuotoa, koska passiivi-ilmaisu tuottaa tässä yhteydessä mielikuvan siitä, että syötteiden muuttaminen tuotoksiksi on manuaalista toimintaa. tehtäväluokitus Organisaation lakisääteisten tehtävien ja tuki- ja ylläpitotehtävien luettelo. Tehtäväluokitus voi toki kattaa muitakin tehtäviä kuin lakisääteisiä ja tuki- ja ylläpitotehtäviä, joten ehdotetaan edellä mainittuun lisäys: lakisääteisten ja muiden tehtävien sekä tuki- ja ylläpitotehtävien luettelo. Toisaalta ehdotetaan myös harkittavaksi luettelomaisen tehtäväluokituksen uudelleen arviointia sähköisessä toimintaympäristössä. Luettelomainen tehtäväluokitus on paperimaailman väline. toimenpide Asian käsittelyyn liittyvä yksittäinen toimi tai tapahtuma. voisiko olla: tekemisen vaihe

8 - Muutaman termin kohdalla on tarpeettomasti toistettu sama termi uudelleen, joten seuraavista on poistettava tuplat: arkistonmuodostussuunnitelma, asiakirjatieto, eams ja eams-järjestelmä. Termien keskinäiset viittaukset puuttuvat. Lisättävä seuraavat: asiakirjallinen tieto ks. asiakirjatieto, asiakirja ks. asiakirjatieto, tiedonhallintasuunnitelma, THS ks. arkistonmuodostussuunnitelma, tiedonohjausjärjestelmä, TOJ ks. eams-järjestelmä ja tiedonohjaussuunnitelma, TOS ks. eams Arkistonmuodostussuunnitelman määritelmässä lukee "tiedonohjaussuunnitelma", vaikka oikea termi on tässä tapauksessa tiedonhallintasuunnitelma, THS. Tiedonohjaussuunnitelma on eamsin - ei AMSin - toinen nimi. eams-termin määrittely on suositeltavampaa olla monikkomuodossa: "Sähköinen arkistonmuodostussuunnitelma eli määritys, johon kuvataan tehtäviin sidotut käsittelyprosessien kuvaukset, niihin liittyvät toimenpiteet ja niiden yhteyteen liittyvät asiakirjatyypit, sekä näiden oletusmetatietoarvot." eams-määrityksen, eams-rakenteen ja eams-rakenneosan määrittelyjä tulisi mahdollisuuksien mukaan selventää, sillä nyt ne eivät ole selkeitä kaikille suosituksen lukijoille. Entä mikä on eamsin ja eams-määrityksen ero vai onko kyse samasta asiasta? Onko eams-määritys vain tekninen termi eamsille? Käsittelysääntö-termin määrittely puuttuu. Käsittelyvaihe-termi on nyt hankalasti määritelty. Jos käsittelyvaihe on osa käsittelyprosessia, on ristiriitaista määritellä se vaiheena, joka kuvastaa käsittelyprosessin laajempaa osaa. Ehdotetaan laajempaa-sanan poistamista termin määrittelystä, sillä se sekoittaa nyt näiden kahden käsitteen suhteet. Käsittelyprosessihan on käsittelyvaihetta laajempi käsite. Tehtävä-termin määrittelyn lopussa oli aiemmin "tai velvollisuus.", joten onko se unohtunut tästä? Tiedonohjaus-termin määrittelyn voi nykymuodossa ymmärtää siten, että tietojärjestelmä tuottaa eamsiin määriteltyjä metatietoarvoja ja käsittelysääntöjä. Määritelmän voisi muuttaa muotoon "Toiminnallisuus, joka tuottaa eamsiin määritellyt metatietoarvot ja käsittelysäännöt ohjaamaan asiakirjatiedon käsittelyä operatiivisessa tietojärjestelmässä." Tietojärjestelmän tilalla voisi käyttää myös sovellus-sanaa. Toimenpide-termin määrittelyssä "toimi" voisi olla ennemmin "toiminta" tai "teko". Toimesta tulee nyt enemmän esim. jonkun toimen (viran) hoito mieleen. xml-skeema-termi, joka on suosituksessa olennainen asia, puuttuu. Pelkkä skeema ei riitä. - Käsittelyvaihe: Käsittelyvaihe tallentuu tietojärjestelmään toimenpiteenä. Suosituksessa on yhdistetty käsittelyvaihe ja toimenpide samaksi asiaksi ja välillä puhutaan myös toimenpiteen tyypistä tarkoittaen samaa asiaa. Käsitteet pitää selkeyttää. - Rakenneosan määritelmä olisi hyvä lisätä (on selitetty lyhyesti luvun 5 alussa). eams-määritys sana on varmasti vaikea. Itse käytimme siitä muotoa TOS-taso tai vast. Sen määrittelyä voisi vielä tarkentaa. Hybridiaineiston määrittely. - Erittäin hyvä että suosistuksessa on avattu keskeiset termit. Kuitenkin uudet termit kuten "käsittelyprosessin kuvaus" ja eams-määritys vaikeuttavat paikoitellen tekstin ymmärtämistä. Termien listaaminen aakkosjärjestykseen hankaloittaa osin käsitteiden ymmärtämistä ja niiden liittymistä/riippuvuutta toinen toisistaan. Ymmärrettävyyttä saataisi tuoda lisää, mikäli termit niputettaiisiin kokonaisuuksiksi aakkosjärjestyksen sijaa. Termien aakkosellinen luettelo voisi lisäksi olla liitteenä. Termilistalta puttuu "olestusmetatieto", "asianhallintajärjestelmä ", "asiankäsittelyjärjestelmä" Käsittelyprosessi, käsittelyprosessin kuvaus ja käsittelyvaihe - avauksissa käsiteet toimenpide/käsittelyvaihe kuvataan osin ristiriitaisesti. Käsittelyprosessin todetaan muodostuvan toimenpiteistä - mutta käsittelyprosessin yksittäinen vaihe on kuitenkin käsittelyvaihe. Muutenkin pitäsimme tärkeänä vielä pohtia sitä, että pitäisikö hallintolaissa mainitut yleiset KÄSITTELYVAIHEET olla tässäkin suosituksessa käsittelyvaiheita, joihin voidaan liittää asiakirjoja joko suoraan TAI KÄSITTELYVAIHEIDEN alle niputettaviin kuhunkin käsittelyvaiheeseen liittyviin TOIMENPITEISIIN.

9 Onko tehtäväluokitus nimenomaan lakisääteisten tehtävien luettelo - vai organisaation kaikkien tehtävien luettelo. 12. Muutosehdotukset kappaleeseen 5. eams-rakenteen rakenneosat 1 - Yksinkertainen asia kuvattu hämmentävän monimutkaisesti (yksikössä??). eams-rakenneosa= eams:n osa, eams-rakenteen rakenneosat=eams:n osat? - Mielestämme eams-rakenne käsitteenä ei ole kovin selkeä kuntatasolla, kun olemme käyttäneet kuntien yhteistä tehtäväluokitusta oman TOS:n määrittelyssä. Asiasta toivoisi ainakin lisää kuvausta / määrityksiä termien selostusosaan / sanastoon. - Kaikki nykyiset järjestelmät eivät tue eamssin versiointia, lisäksi eamssia voidaan muuttaa monella tavalla, määrittelemättä jää, mistä kaikesta versio pitäisi muodostua (esim. kirjoitusvirheiden korjaus)? - Sama teksti toistuu kahteen kertaan: Käsittelyprosessin kuvaus liitetään aina tehtäväluokituksen alimmalle käytetylle tasolle, ja tämän tehtävän alla ei saa olla enää tehtävää. Tekstiä on hankala loogisesti seurata, koska tekstihierarkiassa termin vaatimukset alla käytetään rinnakkain termejä pitää, on suositelta-vaa, saa. - Kuva 1. eamsin päärakenne ja rakenneosat Voisiko jo kuvatekstin yhteyteen selventää nuo numeraaliset 1, 0 *, 1 * -kuvaukset (ei vasta tekstissä myöhemmin). - Kuva 1. eamsin päärakenne ja rakenneosat Voisiko jo kuvatekstin yhteyteen selventää nuo numeraaliset 1, 0 *, 1 * -kuvaukset (ei vasta tekstissä myöhemmin). - käsittelyprosessin kuvaus, joka sisältää toimenpiteet ja asiakirjatiedot, onko kyse toimenpiteistä vai käsittelyvaiheista? Pitäisi käyttää johdonmukaisesti termejä toimenpide ja käsitelyvaihe. Ymmärtäisin, että ne eivät ole synonyymejä, käsittelyvaihe voi sisältää useita yksittäisiä toimenpiteitä? - Kuva 1.:n merkinnät 1 ja 0...* pitäisi selittää ennen kuvaa tai kuvasta kertovassa tekstissä. Merkintöjä ei myöhemminkään avata, joten selitys olisi hyvä antaa jo tässä vaiheessa. - Pitäisikö hallintolain mukaiset käsittelyvaiheet kuvata myös tässä termillä käsittelyvaihe? Käsittelyvaiheella voitaisiin kuvata toimenpiteiden kokonaisuus, joka liittyy kyseisen käsittelyprosessin vaiheeseen. Ehdotetaan käsittelyvaiheet lisättäväksi kuvaan 1. Tällöin voidaan kuvata myös usean organisaation osallistuminen käsittelyprosessin vaiheiden suorittamiseen. - Tehtävän ja käsittelyprosessin kuvauksen suhde jää epäselväksi. Onko käsittelyprosessin kuvaus ("asiataso") alin tehtäväluokituksen taso ("alin tehtäväluokka") vai jotakin lisää? Tämä epäselvyys jatkuu liitteessä 1 Metatietomalli, ks. myöhemmät kommentit. eams-järjestelmässä toki loogisesti erotetaan nämä kaksi toisistaan. S. 7 on kuitenkin lause: Käsittelyprosessin kuvaus liitetään aina tehtäväluokituksen alimmalle käytetylle tasolle, ja tämän tehtävän alla ei saa olla enää tehtävää. >> Eli mitä tarkoitetaan sanalla "liitetään"? - eamsin päärakenne ja rakenneosat kuva (s. 6) Kuvaan on merkitty Tehtävä-kohtaan 0...* mutta eikö tehtävien määrä pitäisi olla vähintään 1 *? 13. Muutosehdotukset kappaleeseen 5.1 eams-määrityksen tiedot Vastaajien määrä: 3 - Jos pysyvä säilytysarkisto katsotaan operatiiviseksi järjestelmäksi, myös eams:n metatiedot tarvitaan. - eams-määrityksen tiedot; - tietojärjestelmiä ja metatietoja varten tulee kunnissa varmaankin käyttää ATK-palvelujen asiantuntemusta suunnitelmaa laadittaessa. Olisiko mahdollista avata vielä enemmän erityisasiantuntemuksen osuutta (mm. tietojärjestelmien ym.. osalta) - tärkeää käyttöön oton kannalta, että eams-määritys voidaan laatia ja ottaa käyttöön osissa - eams-määritys voi olla myös yhden viranomaisen sisällä osissa. Esim. omassa organisaatiossa jouduttaneen laatimaan tietyn ison tietojärjestelmän TOS eri rakenteeseen kuin esim. hallinnollisen asiankäsittelyjärjestelmän hyödyntämä TOS. 14. Muutosehdotukset kappaleeseen 5.2 Tehtävä 0

10 - Kuva 3. kuvateksteineen pois. Taulukko 1. havainnollistaa asian. - Tämän kappaleen sijoitus olisi parempi olla heti kappaleen 5 alussa, jolloin lukijan olisi helpompi lähestyä rakennekuvausta. Kappaleessa esiintyvien tehtäväluokitusrakennekuvien ymmärtäminen olisi selkeämpää, jos näkyvillä olisi myös johonkin asiaan liittyvä käytännön esimerkki heti kuvan vieressä. On hyvä, että rakenneosasssa esitellään kaksi erilaista tapaa / mallia, mutta olisi hyvä antaa suositus kumpaa mallia on hyvä käyttää. - Lause, joka alkaa "eams mahdollistaa tehtäväluokituksen kuvaamisen..." on epäselvä ja vaatii tarkentamista. Tehtäväluokituksen kuvaaminen "litteänä" on hyvä vaihtoehto hierarkiselle rakenteelle. - TEHTÄVÄN eams-rakenneosa Tarkennus tekstin väliotsikkoon: Nimenomaan tehtävää koskeva eams-rakenneosa. Tarkennettujen väliotsikoiden avulla tekstiä selattaessa löytää nopeammin oikean kohdan. - TEHTÄVÄN eams-rakenneosa Tarkennus tekstin väliotsikkoon: Nimenomaan tehtävää koskeva eams-rakenneosa. Tarkennettujen väliotsikoiden avulla tekstiä selattaessa löytää nopeammin oikean kohdan. - Kappaleessa eams-rakenneosa kaipaisin tarkennusta määrittelyyn "tehtävään saa kiinnittyä haluttu määrä käsittelyprosessin kuvauksia (0...*) Onko ajateltu niin, että alimmalle tehtävätasolle voisi kuvata n kappaletta erilaisia käsittelypeosessin kuvauksia, eli esim. kolmen eri asiatyyppin käsittelyvaiheet vireilletulosta päätökseen ja seurantaan? - Taulukko 1.:n tekstiin voisi lisätä tarkennuksen "Esimerkki hierarkkisen ja luettelomaisen tehtäväluokituksen alimpien tasojen käytöstä." - Tehtävien määrittely; - selkeästi kuvattu, että organisaatiossa tulee olla hyväksytty ja ajan tasalla oleva tehtävänluokitus (luettelot). - hyvä tiedonhallintatapa edellyttää, että organisaatiolla on ajan-tasaiset kuvaukset omista tehtävistä ja tehtävän yhteydessä ker-tyneistä asiakirjatiedoista. Olisiko vastuukysymyksiä hyvä avata vaikka vielä tarkemmin, jotta tehtäviä koskevat päivitykset hoide-taan asianmukaisesti. - Käsittelyprosessin kuvaamisen periaatteet tulisi kuvata yhdenmukaisesti sekä organisaation sisäisten että organisaatiorajat ylittävien prosessien osalta. Ohjeet eivät voi olla ristiriidassa keskenään (vrt. kohta 5.3: "Poikkihallinnollisten prosessien kuvaamisessa tulee huomioida, että käsittelyprosessin kuvauksen metatiedot voivat vaihtua riippuen siitä, mikä toimija vastaa käsittelystä." ja kuva 3.) Ehdotetaan, että selvennetään eri tehtäväluokituksia käyttävien käsittelyprosessien kuvausta. - Luvun vaatimuksissa todetaan, että tehtäväluokituksena on suositeltavaa käyttää julkisen hallinnon yhteisiä luokituksi. Nämä luokitukset tulisi listata tässä suosituksessa, jolloin selkeästi määriteltäisiin mitkä ovat yhteisiä, jossain yhteisiksi hyväksyttyjä, tehtäväluokituksia. Ymmärtääksemme yhteisen tehtäväluokituksen laatimisen käynnistämistä ollaan suunniteltu, mutta onko sellainen toteutettu? 15. Muutosehdotukset kappaleeseen 5.3 Käsittelyprosessin kuvaus Vastaajien määrä: 9 - Esitystapa kuvattaessa luokittelunumerointia pitäisi olla jollakin tavalla looginen. Alemman tason numeroesimerkit pitäisi olla ylemmän tason esimerkkinumeroon perustuvia. (Tämä kommentti koskee esityksen muitakin kohtia!) - Käsittelyprosessiksi tulisi sallia ns. geneerinen prosessi, joka on otettavissa eri tehtäviin tarvittaessa. Geneerinen prosessi on yleinen ja yksinkertainen malli niihin tehtäviin, joissa ei ole ennalta määriteltyä tai tarkkaa käsittelyprosessia. - eams-määrityksessä käsittelyprosessin kuvaukselle määriteltävät säilytysaikatiedot (säilytysajan pituus, peruste ja laskentaperuste) voidaan periyttää kaikille käsittelyprosessin kuvaukseen liittyville asiakirjatiedoille, mikäli lainsäädäntö ei erikseen aseta vaatimuksia asiakirjatietojen poistamiselle. On selkeämmin ilmaistu metatietomallin kohdassa 5.8. Säilytysajan pituus. Tästä saa käsityksen, että periyttämistä ei voi tehdä, jos lainsäädännössä on erillisiä vaatimuksia tietojen poistamisesta. Poikkeavat säilytysajathan voidaan muuttaa asiakirjatietokohtaisesti, mutta se ei estä tietojen periyttämistä muiden asiakirjatietojen osalta. - Käsittelyprosessin kuvauksen määrittely vaatii sen tärkeyden perusteella tarkennusta. Tällaisenaan se on varsin epäselvä. Tehtävän metatiedot ovat suosituksessa erikseen, mutta tässä kohdin selvitetään kuhunkin tehtävään liittyvistä

11 oletusmetatiedoista. Itse ymmärrän kohdan niin, että jos tehtävään liittyy yksikin sellainen asiakirja, joka on säilytettävä pysyvästi, kaikki tehtävään liittyvät asiakirjat säilytetään pysyvästi. Tämä automaattinen sp tuntuu oudolta. Monista tehtävistä syntyy valtava määrä asiakirjoja, joista suurin osa on määräaikaisesti säilytettäviä. Kun asiakirjoja kertyy tietojärjestelmiin runsaasti, niiden toiminta hidastuu ja juuri tällöin olisi tarpeellista hävittää ne kaikki asiakirjat, jotka säilytetään määräaikaisesti. Automaatio sp:llä tätä mahdollisuutta ei ole. - Kohdassa "Poikkihallinnollisten prosessien kuvaamisessa tulee huomioida, että käsittelyprosessin kuvauksen metatiedot voivat vaihtua riippuen siitä, mikä toimija vastaa käsittelystä." olisi hyvä kertoa esimerkinomaisesti, miten metatietojen vaihtuminen toimijan mukaan on ajateltu kuvattavan. - eams-määrityksessä käsittelyprosessin kuvaukselle määriteltävät säilytysaikatiedot (säilytysajan pituus, peruste ja laskentaperuste) voidaan periyttää kaikille käsittelyprosessin kuvaukseen liittyville asiakirjatiedoille, mikäli lainsäädäntö ei erikseen aseta vaatimuksia asiakirjatietojen poistamiselle. On selkeämmin ilmaistu metatietomallin kohdassa 5.8. Säilytysajan pituus. Tästä saa käsityksen, että periyttämistä ei voi tehdä, jos lainsäädännössä on erillisiä vaatimuksia tietojen poistamisesta. Poikkeavat säilytysajathan voidaan muuttaa asiakirjatietokohtaisesti, mutta se ei estä tietojen periyttämistä muiden asiakirjatietojen osalta. - Toisen kappaleen ensimmäisen virkkeen lopussa on luettava "...poistamiselle tai säilyttämiselle.", sillä lainsäädäntö voi antaa erikseen vaatimuksia myös asiakirjatietojen säilyttämiseksi. - Ehdotetaan kuvauksen tarkentamista ja selventämistä, myös esimerkein. Lukija on kokenut kuvauksen hiukan ristiriitaiseksi. - Käsittelyprosessin kuvaus teema tuntui tekstin perusteella ensin kokonaan uudelta TOS-tasolta, vaikka kyse on lopulta vain TOS:sta tulevista asian oletusmetatietoarvoista. Käsittelyprosessin kuvaus teema jääkin helposti epäselväksi tai aiheuttaa väärinkäsityksiä, sillä uuden käsitteen käyttäminen tuntuu aluksi harhaanjohtavalta. Käsittelyprosessin kuvaus tuntuu osin haasteelliseslta ja sen selkiyttäminen olisi paikallaan. Toivoisimme, että suosituksen liitteeksi lisättäisiin havainnollistava(t) kuva(t) TOS:sta, jossa pakollisten metatietoarvojen lisäksi osoitettaisiin erikseen vielä TOS:n osat tekstein. TOS-kuva olisi raportti asiankäsittelyjärjestelmästä, johon on ympyröity (tai osoitettu katkoviivoitetulla ympyröillä) TOS:n rakenteen osat. Ympyröiden yhteydessä olisi selittävä teksti, johon riittäisi vaikkapa vain JHS-suosituksessa asiasta käytetty termi. Kuvan olisi hyvä olla jo suoraan suosituksen yhteydessä tai suosituksen liitteenä eikä vasta Arkistolaitoksen sivuilla. Poikkihallinnollisten prosessien kuvaamiseen tulisi kiinnittää nykyistä enemmän huomiota. Olemme siirtymässä kaikkinensa prosessien sähköistämisen myötä siihen, että poikkihallinnollisten prosessien yhdenmukaisen kuvaamisen merkitys korostuu. Yhteentoimivuus on tärkeää niin hallinnon kuin myös asiakkaan näkökumasta. Erityisen keskeinen jouhevasti yli organisaatiorajojen kulkeva "sähköinen" prosessi on tehokkuuden ja tuottavuuden kannalta. 16. Muutosehdotukset kappaleeseen 5.4 Toimenpiteet 3 - Hienoa! Tämän kappaleen mukainen selvitystapa olisi hyvä löytyä muistakin osioista. Määrintelmät on kuvattu selkeästi tässä kohdassa. - Suosituksessa todetaan, että on suositeltavaa käyttää hallintolain mukaisia yleisiä käsittelyvaiheita, ja toisaalla taas, että Hallintolain mukaisten yleisten käsittelyvaiheiden käyttäminen on kaikille yhteinen vähimmäistaso toimenpiteiden määrittelyssä eamsiin. Kuitenkaan hallintolain mukaisia yleisiä käsittelyvaiheita ei suoranaisesti käytetä viranomaisen sisäisissä prosesseissa, kuten erilaisessa suunnittelussa, kehittämisessä, koulutuksessa. - Tulevatko hallintolain toimenpiteiden lisäksi määritellyt toimenpiteet samalle tasolle kuin luonnoksessa mainitut toimenpiteet? "Yhtenäinen toimenpiteiden määrittely mahdollistaa sen, että laadittavat eams-kuvaukset ovat tältä osin yhdenmukaiset koko julkisen hallinnon osalta." Kommentti: poikkihallinnollisissa prosesseissa asiakirjat eivät liity samaan toimenpiteeseen eri organisaatioissa. Sama asiakirja on organisaatiossa x valmistelua, organisaatiossa y päätöksentekoa. - Toimenpiteinä on suositeltavaa käyttää hallintolain (434/2003) mukaisia yleisiä käsittelyvaiheita. Näistä toimenpiteistä saa poiketa aina silloin, kun erillislaki tai käsittelyprosessin kuvauksen luonne edellyttää poikkeavien arvojoukkojen käyttöä. myöhemmin samassa kappaleessa puhutaan toimenpiteen tyypeistä, yhdenmukaisuus? Tarkempien toimenpiteiden käyttö on suositeltavaa, kun eams ohjaa asiakirjatietojen käsittelyä asianhallintajärjestelmissä, kun lainsäädäntö edellyttää yksityiskohtaisempien toimenpiteiden käyttöä ja kun kyse on poikkihallinnollisista prosesseista.

12 asiankäsittelyjärjestelmissä? Käsittelyssä ollut asia ratkeaa (taulukko 2). pitäisikö tässä olla yhdenmukaisuuden vuoksi valmistelussa olleen asian ratkaisu: tämä siksi, että edellä on käsittelyvaiheena valmistelu ja ollut esillä valmisteluna myös tämän sivun Hallintolain mukaisia yleisiä käsittelyvaiheita ovat [ ] -kohdassa Viranomaisen antamaa päätöstä toteutetaan (taulukko 2). Toimeenpano eli täytäntöönpano on viranomaisen määräys täytäntöönpanosta: tällainen määritelmä löytyy hallintolain 49, se on eri asia kuin päätöksen perusteella toimiminen eli toteutus sinällään. Tässä on siis virheellinen ilmaisu? Seuranta (taulukko 2). Puuttuuko tästä määritelmä tai esimerkki? Taulukko 2 / Kuva 4 aseteltuna samalle sivulle antaa sekavan vaikutelman. Lisäksi käsittelyvaiheet eivät kuvallisessa esimerkissä täysin vastaa aiemmin tekstissä esitettyjä. Kuvien ja taulukoiden sijoittamista informatiivisuuden kannalta järkeviin kohtiin kannattaa pohtia. On suositeltavaa käyttää hallintolain (434/2003) mukaisia yleisiä käsittelyvaiheita toimenpiteen tyyppeinä. Muilla toimenpidetyypeillä voidaan täydentää mainittua luetteloa. aiemmin samassa luvussa puhutaan toimenpiteistä, tässä toimenpiteen tyypeistä Toimenpiteet, Vaatimukset kohta (sivu 9/12): Hallintolain mukaisten yleisten käsittelyvaiheiden käyttäminen on kaikille yhteinen vähimmäistaso toimenpiteiden määrittelyssä eamsiin. esitetään muutettavaksi muotoon Hallintolain mukaisten yleisten käsittelyvaiheiden käyttäminen on suositeltavaa toimenpiteiden määrittelyssä eamsiin, muttei pakollista silloin kun käsittelyprosessin kuvaus ei sitä mahdollista Perustelu: Ulkoasiainministeriön hallinnonalan tehtäviin kuuluu keskeisenä, valmistelu- ja toimeenpanotehtävien lisäksi, runsaasti raportointitehtäviä, joiden käsittelyprosessi ei vastaa hallintolain mukaisia käsittelyvaiheita, mutta joista kuitenkin syntyy runsaasti asiakirja-aineistoa. - Vrt. edelliseen täällä todetaan, että asiakirjatiedon julkisuuden ja säilytysarvovaihtelut on huomioitava käsittelyprosessin eri vaiheissa. Kumpaa siis uskoa? Edellistä kohtaa vai tätä? Taulukko 2. kaikki muut on määritelty paitsi seuranta. Miksi sen määritelmä puuttuu? Miksi esittely on laitettu osaksi päätöksentekoa? Se eroaa esimerkisi kunta-alan säilytysaikaoppaiden päätöksentekoprosesseista, joissa esityslistat ovat osa valmistelua. Kunnallishallinnossa on tulkittu päätöksenteoksi se viimeinen toimielin, jossa päätös tehdään. Sitä on edeltänyt lautakuntien ja kunnanhallituksen esitykset. Ne eivät ole asiaa päättäneet, vaan esittäneet, mitä viimeinen toimielin = valtuusto tai joissakin tapauksissa kunnanhallitus päättää. - Toimenpiteinä on suositeltavaa käyttää hallintolain (434/2003) mukaisia yleisiä käsittelyvaiheita. Näistä toimenpiteistä saa poiketa aina silloin, kun erillislaki tai käsittelyprosessin kuvauksen luonne edellyttää poikkeavien arvojoukkojen käyttöä. myöhemmin samassa kappaleessa puhutaan toimenpiteen tyypeistä, yhdenmukaisuus? Tätä suositusta kannattaisi harkita vielä uudelleen. Erillislaki on erityislaki. Tarkempien toimenpiteiden käyttö on suositeltavaa, kun eams ohjaa asiakirjatietojen käsittelyä asianhallintajärjestelmissä, kun lainsäädäntö edellyttää yksityiskohtaisempien toimenpiteiden käyttöä ja kun kyse on poikkihallinnollisista prosesseista. asiankäsittelyjärjestelmissä? Taulukko 2. Hallintolain (434/2003) mukaiset yleiset käsittelyvaiheet ja niiden tarkemmat kuvaukset.

13 Käsittelyssä ollut asia ratkeaa. pitäisikö tässä olla yhdenmukaisuuden vuoksi valmistelussa olleen asian ratkaisu: tämä siksi, että edellä on käsittelyvaiheena valmistelu ja ollut esillä valmisteluna myös tämän sivun Hallintolain mukaisia yleisiä käsittelyvaiheita ovat [ ] -kohdassa Viranomaisen antamaa päätöstä toteutetaan. Toimeenpano eli täytäntöönpano on viranomaisen määräys täytäntöönpanosta: tällainen määritelmä löytyy hallintolain 49, se on eri asia kuin päätöksen perusteella toimiminen eli toteutus sinällään. Tässä on siis virheellinen ilmaisu? Seuranta: Puuttuuko tästä määritelmä tai esimerkki? Taulukko 2 / Kuva 4 aseteltuna samalle sivulle antaa sekavan vaikutelman. Lisäksi käsittelyvaiheet eivät kuvallisessa esimerkissä täysin vastaa aiemmin tekstissä esitettyjä. Kuvien ja taulukoiden sijoittamista informatiivisuuden kannalta järkeviin kohtiin kannattaa pohtia. On suositeltavaa käyttää hallintolain (434/2003) mukaisia yleisiä käsittelyvaiheita toimenpiteen tyyppeinä. Muilla toimenpidetyypeillä voidaan täydentää mainittua luetteloa. aiemmin samassa luvussa puhutaan toimenpiteistä, tässä toimenpiteen tyypeistä - kuten aikaisempi kommentti kohtaan 5 eams rakenneosat käsittelyvaihe vs. toimenpide. "Toimenpiteinä on suositeltavaa käyttää hallintolain mukaisia yleisiä käsittelyvaiheita" Miksi puhutaan toimenpiteistä, kun tarkoitetaan käsittelyvaiheita? Kuten kuva sivulla 10 osoittaa esim käsittelyvaihe vireilletulo sisältää kolme eri toimenpidettä. Tämä käsittelyvaihe ja toimenpide -termein käyttö ristiriitaisesti on myös SÄHKE normissa ja aiheuttaa hämmennystä. - Pitäisikö yleiset käsittelyvaiheet muuttaa kauttaaltaan yleisiksi toimenpiteiksi? Käytettäisiin vain yhtä termiä tästä samasta asiasta. Tiedoksianto tulee siirtää ennen toimeenpanoa tapahtuvaksi. Mitään ei voida panna toimeen, ellei sitä ole ensin annettu tiedoksi. Vireilletulon määritelmässä kerrotaan nyt vain vireillepanosta, joten määritelmä voisi olla muodossa: "Asia tulee vireille esim. siten, että viranomainen vastaanottaa vireillepanoasiakirjat." Entä sisältääkö toimeenpano esim. hallintolain hallinnollisten seuraamusten täytäntöönpanon? Käsittelyvaiheen kuvauksen määritelmää olisi tarkennettava, jos täytäntöönpanon ja sen keinojen katsotaan kuuluvan toimeenpanoon. Ellei tarkoitus ole, että organisaatiot voivat tarvittaessa tehdä täytäntöönpanosta oman yleisen käsittelyvaiheen? On hyvä, että yleiset käsittelyvaiheet pohjautuvat hallintolakiin. Tosin hallintolaissa ei mm. mainita toimeenpanoa sekä ohjaus on neuvontaa, valmistelu käsittelyä ja seuranta valvontaa. Näin ollen voidaanko tekstissä todeta suoraan, että nämä vaiheet ovat hallintolain mukaisia yleisiä käsittelyvaiheita? Kysehän on pikemminkin hallintolain pohjalta käsittelyprosessin kuvausta varten muokatuista yleisistä käsittelyvaiheista. - Tietojärjestelmän käyttäjän näkökulmasta Hallintolain (434/2003) mukaiset yleiset käsittelyvaiheet eivät ole toimintaa ohjaavia tai käsittelyn tapahtumia dokumentoivia toimenpiteitä, vaan ne kuvaavat enemmänkin sitä, missä vaiheessa käsittelyä asiakirja on syntynyt. käsitteiden pitää olla selkeitä ja yksikäsitteisiä. Jos eams kuvataan todelliselle toimenpide tasolle, toimenpide on pystyttävä suosituksen mukaan yhdistämään siihen käsittelyvaiheeseen, jonka yhteydessä se syntyy (esimerkiksi kuvassa sivulla 10 haastattelu toimenpide liittyy valmistelu käsittelyvaiheeseen). Jos eams on kuvattu käsittelyvaihe tasolla, syntyykö asianhallintajärjestelmään silloin käyttäjän nimeämä toimenpide kuten SÄHKE1-maailmassa vai käsittelyvaiheen esimerkiksi Valmistelu mukaan nimetty toimenpide? Pitäisikö eams luoda silloinkin kaksiportaisena (vireilletulo vireilletulo, valmistelu valmistelu jne.) joista ensimmäinen taso kuvaa käsittelyvaihetta ja toinen asianhallintaan syntyvää toimenpidettä, että tietorakenteet ja käsitteet eivät mene ristiin? - -Vaatimus 'Toimenpiteinä on suositeltavaa käyttää hallintolain (434/2003) mukaisia yleisiä käsittelyvaiheita ' on hiukan epäselvä, kun suositellaan käytettäväksi hallintolain käsittelyvaiheita, mutta kuitenkin jatkolauseissa kielletään näiden korvaaminen. Ehdotetaan ohjeistuksen tarkentamista. -Arkistolaitoksen eams-pohjassa käytetään termejä Toimenpidetyyppi ja Toimenpidetyypin tarkenne. Ehdotetaan käytettäväksi samoja termejä. Mahdolliset korjaukset myös sanastoon. - Toimenpide vs. käsittelyvaihe -keskustelu ei edelleenkään kirkkaan selvää. Mitä tarkoitetaan täsmällisesti sillä että "saa täydentää muilla toimenpiteillä"? Eli vastaako käytännössä hallintolain mukaiset yleiset käsittelyvaiheet eams-pohjan sarakkeen "5.6 Toimenpiteen tyyppi (=Yleinen käsittelyvaihe)" tietoja ja tuo täydentäminen sarakkeen "5.6 Toimenpidetyypin tarkenne (=Käsittelyvaihe)" tietoja? Tehkää tästä nyt idioottivarma malli, että sen voi todentaa onnistuvaksi myös eams-järjestelmässä, jossa lisätään yksi tietue ("kortti", jota kutsumme edelleenkin käsittelyvaiheeksi), jossa on tyyppitieto ja tarkenne. - Ppitäsimme tärkeänä vielä pohtia sitä, että pitäisikö hallintolaissa mainitut yleiset KÄSITTELYVAIHEET olla tässäkin suosituksessa käsittelyvaiheita, joihin voidaan liittää asiakirjoja joko suoraan TAI

14 KÄSITTELYVAIHEIDEN alle niputettaviin kuhunkin käsittelyvaiheeseen liittyviin TOIMENPITEISIIN. Hieman epäillen suhtaudumme kohtaan/sanamuotoon hallintolain mukaisten yleisten käsittelyvaiheiden käyttäminen on kaikille yhteinen vähimmäistaso toimenpiteen määrittelyssä eamsiin s.9. Tämä toimii silloin kun kyseessä prosessi, joka etenee vaihe vaiheelta, mutta on paljon sisäisiä prosesseja, joissa vain selkeä alku ja loppu. Tosin toisessa kohtaa yleisten käsittelyvaiheiden käyttäminen on vain suositeltavaa (s. 10). 17. Muutosehdotukset kappaleeseen 5.5 Asiakirjatiedot Vastaajien määrä: 4 - Liite-tyyppisen asiakirjan käyttöä ei pitäisi rajoittaa tapauksiin, joissa metatiedot eroavat toisistaan. Asiakirjatyyppi on loppukäyttäjille tärkeä tekijä myös asiakirjan luonteen hahmottamisessa esim. erilaisissa pitkissä listauksissa. - "Liiteasiakirjat kuvataan omaksi asiakirjatyypikseen erityisesti silloin, kun liitteiden metatiedot poikkeavat varsinaisen asiakirjatiedon tai sen muiden liitteiden metatiedoista. Jos asiakirjaan kuuluu liitteitä, mutta niiden metatietoarvot ovat täysin samat kuin varsinaisella asiakirjalla, ei liiteasiakirjoja tarvitse välttämättä määritellä erikseen eamsiin." Kommentti: On mahdotonta tietää eams:n laatimisvaiheessa, onko asiakirjalla liitettä. Entä jos on mahdollista, että liite voi olla julkinen tai salassa pidettävä ja suojaustaso voi vaihdella ST II-IV? Luonnoksen mukaan nämä kaikki tulisi määritellä etukäteen. - Tässä kappaleessa esitetty taulukko on hyvä ja ytimekäs: se pitäisi mielellään saada suositustekstin alkuun Liittyen taulukkoon: mikä on toimenpidetyyppi? onko toimenpiteistä ja toimenpiteen tyypeistä puhuminen johdonmukaista? kaipaisiko tarkentamista? - Liiteasiakirjan kuvaamista käsittelevä kpl hyvä. 18. Muutosehdotukset kappaleeseen 6. Metatiedot Vastaajien määrä: 3 - Metatietojen kirjaamisen vaiheet / kirjaamisjärjestyksen esittämistapa ei ole selkeä. A ja B mallien mukaan voi tehdä 2 hyvin erilaista tehtäväluokitusta. Lisäksi osa tässä esityksessä määritellyistä valinnaisista metatiedoista on eams -pohjassa (Sähke 2) tällä hetkellä pakollisia. - Metatietomallin laajentaminen asiakaskohtaisilla metatiedoilla tulee olla sallittua. TOJ:n tuottaman XML:n validoinnissa tulisi hyväksyä suosituksen mukaisten pakollisten ja valinnaisten metatietojen lisäksi muitakin metatietoja sisältävä metatietomalli. - Oheinen taulukko on hyvä ja ytimekäs: se pitäisi mielellään saada suositustekstin alkuun Muodostavat asian toimenpidetyypit ja niiden oletusmetatietoarvot. mikä on toimenpidetyyppi? onko toimenpiteistä ja toimenpiteen tyypeistä puhuminen johdonmukaista? kaipaisiko tarkentamista? 19. Muutosehdotukset kappaleeseen 7. Rakenteen xml-skeema - Voidaanko ensimmäisen kappaleen lopussa sanoa "usein" vai pitäisikö virkkeen olla muodossa "Nämä pohjautuvat esim. xml:ään."? 20. Muutosehdotukset kappaleeseen 8. Opastavat tiedot 21. Muutosehdotukset liitteen 1. Metatietomalli kappaleeseen 1. Metatiedot Vastaajien määrä: 4 - Tietojen toistettavuus eli mahdollisesti moniarvoiset metatietokentät olisi hyvä esittää metatietomallissa.

15 - Metatietokorttien Tunnus-kohdassa on nyt muutamissa valmiita termejä, osassa on <Tekniset termit skeemassa>-merkintä, yhdessä <>-merkintä ja lopuissa kohta on tyhjä. Puuttuvat tiedot lisättäneen viimeistään lopullisessa versiossa ja ne, joihin tietoa ei tule - pitäisikö niitä jäädä? -, merkitään yhtenäisellä tavalla. Pitäisikö myös metatietokortin kohdan "Tunnus" muuttaa silloin "Tekninen termi skeemassa"-nimiseksi? Sama koskee SÄHKE2-kohdan merkintöjä: yhtenäinen tapa (tarkemmat tiedot ao. kohdissa). - Liite1 yleisesti: -Ehdotetaan, että dokumentin rakenne ja otsikointi muutetaan Sähke2:n metatietomallia vastaavaksi ainakin luvusta 4 eteenpäin vertailun ja ymmärtämisen helpottamiseksi. -Valinnaisten metatietojen määrä on varsin suuri. Ehdotetaan tarkennettavaksi valinnaisten metatietojen osalta niiden valinnaisuutta. Valinnaisten metatietojen kuvaaminen eams:ssa/tos:ssa kannattaa arvioida aina organsiaation hyötynäkökulmasta ja varmistaa, ettei näiden osalta tehdä organisaatiossa päällekkäistä kehittämistyötä. - Sisällysluettleo selkeämmäksi. Nyt ei näe rakennetta, kun kaikki ovat hierarkisesti yhdessä pötkössä. Olisiko mitään ideaa ottaa metatietokorttiin mukaan tieto siitä, onko toistettava tai ei toistettava? Eri metatietojen kohdalla on nyt vaihtelua siitä, että jos kohta SÄHKE2 jää tyhjäksi, niin onko siinä viiva (-) vai ei. Metatietomallin rakenne ok. Teksti joka alkaa: "Mikäli useilla eams-määrityksen rakenneosilla on samat metatietoarvot..." >> Käytännön toteutus jää tästä tekstistä epäselväksi? Tarkoittaako käytännössä sitä, että valinnaiset metatiedot (jotka ovat yhteisiä) ovat eams-järjestelmässä kenttinä kuitenkin myös alemmilla tasoilla ja arvot periytetään ylemmältä tasolta. Vai että eivät ole edes kenttinä? Jotain jäi minulta nyt ymmärtämättä, koska ei auennut selkeästi. Mitä valinnaisuus aina tarkoittaa? Useimmissa eams-järjestelmissä esim. muokkausajankohtatieto tms. on joka tapauksessa olemassa ja oletuksena useimmiten myös käyttäjälle näkyvissä, ja joka tapauksessa ainakin konepellin alla vaikkei käyttäjälle näkyvissä. Lukija miettii näin ollen, että tarkoittaa valinnaisuus sitä, että tämän metatiedon ei ole tarvis olla näkyvillä käyttäjälle, mutta samalla, että tietojärjestelmän yleisten periaatteiden kannalta on järkevää, että esim. muokkausajankohta/laatija/laadinta-ajankohta kuitenkin tulevat. Lokittaahan järjestelmä kuitenkin, mutta. 22. Muutosehdotukset liitteen 1. Metatietomalli kappaleeseen 2. eams-rakenneosien yhteiset metatiedot Vastaajien määrä: 2 - Miksi päivämäärätietojen tallentamiseen suositellaan SFS-en standardin mukaista muotoa? Se ei vastaa suomalaista käytäntöä. 8tämä toistuu muutamassa muussakin kohdassa). - Rakenneosa, joka voi versioitua on oltava tietojärjestelmän näkökulmasta ehjä ja hallittava kokonaisuus. Kun asia avataan tehtäväluokkaan, koko käsittelyprosessin ajan on pystyttävä noudattamaan sitä tehtäväluokan rakennetta metatietoineen, toimenpiteineen ja asiakirjatyyppeineen, joka oli voimassa silloin, kun asia avattiin. Toivomuksena on, että edelleen tehtäväluokalla on metatiedot, jotka periytetään asialle ja jokaisella asiakirjatyypillä on kaikki metatiedot, jotka periytetään asiakirjoille jolloin kyselyt voidaan tehdä suoraan näihin rakenneosiin. Jäi hieman epäselväksi se, tarkoittaako suositus sitä, että jos metatieto on sama asialla ja asiakirjalla, se määritettäisi vain tehtäväluokka tasolla? 23. Muutosehdotukset liitteen 1. Metatietomalli kappaleeseen 2.1 ID 24. Muutosehdotukset liitteen 1. Metatietomalli kappaleeseen 2.2 Tila Vastaajien määrä: 2 - JHS-suosituksen luettavuuden kannalta olisi parempi, jos osa metatiedoista olisi kuvattu uudelleen eri rakenneosien kohdalla. Esim. AMS-rakenteen tilan metatietojen arvot poikkeavat asiakirjan tilan arvoista. - Lukijalle on jäänyt epäselväksi, miten ilmaistaan, että rakenneosa on ylläpidettävänä ja vanha vielä käytössä. Nyt Tila kertoo käytössä olosta tai uuden tekemisestä. Ehdotetaan, että metatietokuvauksia 2.2 Tila ja mahdollisesti 2.3 Rakenneosan versionumero tarkennetaan tältä osin. 25. Muutosehdotukset liitteen 1. Metatietomalli kappaleeseen 2.3 Rakenneosan versionumero

16 - 2.3 Rakenneosan versionumero vs. 3.3 Versio > Miten eroavat toisistaan? Eli 2.3 on valinnainen, mutta eams-tasolla on pakollinen. Edes yhtenevä nimeke eikä toisessa paikkaa Rakenneosan versionumero ja toisessa Versio. Vai juuriko siksi halutaan nimeketasollakin erottaa, kun on hieman poikkeava sisällöltään? 26. Muutosehdotukset liitteen 1. Metatietomalli kappaleeseen 2.4 Organisaatio 27. Muutosehdotukset liitteen 1. Metatietomalli kappaleeseen 2.5 Tietojärjestelmä tietojärjestelmä: metatieto on osiossa "kaikille yhteiset", mutta kuitenkin käyttö-laatikossa puhutaan nimenomaan tehtävästä: "tehtävällä ilmoitetaan missä tietojärjestelmässä ko. tehtävää käsitellään." Tämä voi olla olennainen tieto jo ylimmäisellä eams-tasolla, koska jos eams on eams-tietojärjestelmässä "palasina" eli eri rakenteina ja eri operatiiviset tietojärjestelmät hyödyntävät eri rakenteita. 28. Muutosehdotukset liitteen 1. Metatietomalli kappaleeseen 2.6 Muokkausajankohta Vastaajien määrä: 2 - Eikö eams:n muokkausajankohdan tulisi olla pakollinen tieto? - Muokkausajankohta/laatija/laadinta-ajankohta: Loogisempaa olisi järjestyksessä Laatija/laadinta-ajankohta/muokkausajankohta. Entä Muokkaaja? 29. Muutosehdotukset liitteen 1. Metatietomalli kappaleeseen 2.7 Laatija - Arvojoukko-kohtaan lisäys suosituksen laatijan nimitiedon muodosta esim. "Sukunimi Etunimi" 30. Muutosehdotukset liitteen 1. Metatietomalli kappaleeseen 2.8 Laadinta-ajankohta 31. Muutosehdotukset liitteen 1. Metatietomalli kappaleeseen 2.9 Hyväksyjä Vastaajien määrä: 6 - Tämän metatiedon arvojoukko ei liene päivämäärä vaan henkilö. - Henkilö, joka on hyväksynyt eams-määrityksen tai sen osan. voi olla muukin kuin yksi henkilö, riippuen organisaation ohjeistuksesta ja toimintatavoista - Hyväksyjä-tiedon arvojoukko ei voi olla päivämäärä. - Henkilö, joka on hyväksynyt eams-määrityksen tai sen osan. voi olla muukin kuin yksi henkilö, riippuen organisaation ohjeistuksesta ja toimintatavoista - Arvojoukko-kohdassa on nyt päivämäärän tallentamista koskevaa tietoa, joka ei kuulu tähän metatietoon. Kohdassa pitää olla ennemmin suositus hyväksyjän nimitiedon muodosta esim. "Sukunimi Etunimi" Hyväksyjä: Onko jäänyt kohtaan arvojoukko virhe, siinä puhutaan päivämäärän tallentamisesta, joka taas liittyy hyväksyntäajankohtaan? 32. Muutosehdotukset liitteen 1. Metatietomalli kappaleeseen 2.10 Hyväksyntäajankohta 33. Muutosehdotukset liitteen 1. Metatietomalli kappaleeseen 2.11 Voimassaolon

17 alkamisajankohta - Erilaisista ajankohdista: voimassaolon alku ja päättyminen - pitää olla pakollisia tietoja. 34. Muutosehdotukset liitteen 1. Metatietomalli kappaleeseen 2.12 Voimassaolon päättymisajankohta - Erilaisista ajankohdista: voimassaolon alku ja päättyminen - pitää olla pakollisia tietoja. 35. Muutosehdotukset liitteen 1. Metatietomalli kappaleeseen 3. eams-määrityksen metatiedot - KS. myös kommentit kohdasta 12. Miksi Käsittelyprosessin kuvauksella ("alin tehtäväluokka") ei ole nimekettä ja muita tehtävään liittyviä metatietoja? 36. Muutosehdotukset liitteen 1. Metatietomalli kappaleeseen 3.1 Nimeke 37. Muutosehdotukset liitteen 1. Metatietomalli kappaleeseen 3.2 Yhteyshenkilö Vastaajien määrä: 2 - Onko tämä oleellinen tieto, jos on, niin sen tulisi olla mieluummin roolipohjainen kuin luonnollinen henkilö. - Yhteyshenkilöt vaihtuvat ja tieto ei välttämättä säily ajantasalla. Organisaatiotieto voisi toimia paremmin ja olisi informatiivisempi. 38. Muutosehdotukset liitteen 1. Metatietomalli kappaleeseen 3.3 Versio - Versionumerointia oleellisempaa olisi muutostietojen lokittuminen 39. Muutosehdotukset liitteen 1. Metatietomalli kappaleeseen 3.4 Lisätietoja 40. Muutosehdotukset liitteen 1. Metatietomalli kappaleeseen 4.1 Tunnus Vastaajien määrä: 3 - Pitäisikö toimenpiteellä olla tietojärjestelmä -tieto? Tehtävä voi jakautua toimenpiteisiin, joita hoidetaan eri järjestelmissä. Esim. käyttöoikeuslupa, josta lähtee lasku asiakkaalle. Lupaprosessi käsitellään asianhallintajärjestelmässä, mutta laskutus-toimenpide tehdään toisessa järjestelmässä. Tehtävän, toimenpiteen ja asiakirjan tietojärjestelmä -tiedolla ohjataan niiden näkyvyyttä asianhallintajärjestelmässä (joka on meillä tällä hetkellä ainoa järjestelmä, jota ohjataan automaattisesti eams:lla). eams:iin on kuitenkin kuvattu kaikki tehtävät, toimenpiteet ja niissä syntyvät asiakirjat. Kahden AMS:n ylläpito ei ole mielekästä. - Tarkoittaako Tunnus-metatiedon valinnaisuus sitä, että organisaation tehtäväluokituksella ei tarvitse välttämättä olla numeerista tunnusta? Mistä tehtäväluokan tunnus-tieto silloin siirtyy asianhallintajärjestelmään, jos sitä ei ole pakko laittaa eamsiin? Vai tarkoittaako tämä sitä, että tehtävien yksittäisille asioille ei tarvitsisi jatkossa enää antaa diaari-/asianumeroita ollenkaan? SÄHKE2:n mukaan kohteen identifiointitunnus on pakollinen metatieto, mutta tarkoitetaanko tällä samaa metatietoa? - Arkistolaitoksen vaatiman siirtotiedostoskeeman tehtäväluokituksessa on eroja tähän kuvaukseen esim. pakollisuuksissa, mm. Tunnus. Ehdotetaan yhtenäistämistä. 41. Muutosehdotukset liitteen 1. Metatietomalli kappaleeseen 4.2 Nimeke

18 42. Muutosehdotukset liitteen 1. Metatietomalli kappaleeseen 4.3 Kuvaus Vastaajien määrä: 2-5 Käsittelyprosessin kuvauksen metatiedot: Mistä ilmenee, mikä käsittelyprosessi on kyseessä, eli mihin kuvaustiedot liittyvät? Id:llä voidaan kyllä linkittää teknisesti, mutta käyttäjä tarvitsee suorasanaisen tiedon. Tehtävään voi liittyä useita käsittelyprosesseja (kuvauksineen). - 5 Käsittelyprosessin kuvauksen metatiedot: Mistä ilmenee, mikä käsittelyprosessi on kyseessä, eli mihin kuvaustiedot liittyvät? Id:llä voidaan kyllä linkittää teknisesti, mutta käyttäjä tarvitsee suorasanaisen tiedon. Tehtävään voi liittyä useita käsittelyprosesseja (kuvauksineen). 43. Muutosehdotukset liitteen 1. Metatietomalli kappaleeseen 5.1 Julkisuusluokka Vastaajien määrä: 3 - Käsittelyprosessin kuvaus ei ole välttämättä salassa pidettävä, vaikka kaikki siihen liittyvät asiakirjatiedot ovat salassa pidettäviä. Käsittely-prosessin kuvaus voidaan merkitä salassa pidettäväksi silloin, kun tiedoissa (metatiedoissa) on salassa pidettävää tietoa. Aiemmissa määrityksissä AMS:n on todettu olevan kokonaan julkinen asiakirja, johon ei saa liittää salassa pidettävää tietoa. Tämä on ongelmallista erityisesti turvallisuusviranomaisille, joilla on salassa pidettäviä käsittelyprosesseja. Uusi tulkinta prosessin kuvauksen salassa pidosta helpottaa merkittävästi näiden viranomaisten asiakirjahallinnon suunnittelua. - Arvojoukko:julkinen, osittain salassa pidettävä ja salassa pidettävä. 1.10, 2010 voimaan tulleen tietoturvallisuusasetuksen mukaisesti pitäisi olla lisäksi arvot viranomaisharkinta ja käyttötarkoitussidonnaisuus. - Ehdotetaan selvennettäväksi, milloin käsittelyprosessin kuvaus ja metatiedot voidaan merkitä salassa pidettäviksi. 44. Muutosehdotukset liitteen 1. Metatietomalli kappaleeseen 5.2 Salassapitoaika Salassapitoaika Suositeltava arvojoukot ovat 25, 50, 100. JulkL 31 :n mukaan on mahdollista, että tietyissä tapauksissa salassapitoaikaa ei voida määritellä vuosina. 45. Muutosehdotukset liitteen 1. Metatietomalli kappaleeseen 5.3 Salassapitoperuste Vastaajien määrä: 3 - salassapitoperusteen tulisi olla vapaaehtoinen. Se ei aina ole yksiselitteinen ja peruste voi ajan kuluessa muuttua. Joka tapauksessa peruste on aina arvioitava uudestaan jos tietoa pyydetään nähtäväksi. Tämä myös on yksi yleisinten loppukäyttäjiltä täyttämättä jäävä kenttä, ja perusteiden täydentäminen jälkikäteen jonkun muun toimesta ei ole luotettavasti mahdollista. (julkisuuslain mukaan salassapitomerkinnät ovat asian valmistelijan vastuulla.) - Erikoislaki po. erityislainsäädäntö. Korjattava myös muualta luonnoksista. - Määritelmätarkennus: "Tieto siitä mihin käsittelyprosessin kuvauksen salassapito perustuu." 46. Muutosehdotukset liitteen 1. Metatietomalli kappaleeseen 5.4 Salassapidon laskentaperuste Vastaajien määrä: 6 - Kohta 5 Käsittelyprosessin kuvauksen metatiedot / 5.4. Salassapidon laskentaperuste: millä tavoin käsittelyprosessin kuvauksen salassapidon laskentaperuste voi riippua asian ratkaisusta, asiakirjan päivämäärästä, valmistumisesta tai saapumisajankohdasta? - Tämä lienee pakollinen jos salassa pidettävä - "Tapahtuma, joka käynnistää tietojärjestelmässä salassapitoajan laskennan alkamisen." "Suositeltavat: Asian ratkaisu Asiakirjan päivämäärä Asiakirjan valmistuminen Asiakirjan saapumisajankohta" Miten käsittelyprosessin kuvauksen salassapidon laskentaperuste voi riippua "asiakirjan päivämäärästä, valmistumisesta tai saapumisajankohdasta", kuten se nyt on kirjoitettu? - Miksi salassapidon laskentaperuste on valinnainen? Metatiedon pitäisi olla pakollinen, jos on salassa pidettävää. Miten muulla tavoin laskenta saadaan käynnistettyä, jos tämä metatieto ei ole pakollinen salassa pidettäville tiedoille?

19 Määritelmätarkennus: "Tapahtuma, joka käynnistää tietojärjestelmässä käsittelyprosessin kuvauksen salassapitoajan laskennan alkamisen." - Ehdotetaan muutettavaksi laskentaperuste pakolliseksi, jotta järjestelmä voi laskea sähkeen vaatimaa salassapidon päättymisajankohtaa : on kyse käsittelyprosessin kuvauksesta ja arvolistalla on asiakirjaa koskevia arvoja. Sama koskee 5.10:ä. Missä on käsittelyprosessin Julkisuusluokan muutos? Julkisuusluokan muutos on kuitenkin asiakirjatiedolla. Asiakirjatiedon tasolla käsittelysäännöt ovat erillään. Yhdenmukaisesti. 47. Muutosehdotukset liitteen 1. Metatietomalli kappaleeseen 5.5 Suojaustaso Vastaajien määrä: 5 - Voisi olla maininta, että käsittelyprosessin kuvaus ei välttämättä sisällä salassa pidettävää tietoa, vaikka siihen liittyvät asiakirjat olisivatkin salassa pidettäviä. - onko joskus tapauksia, joissa suojaustaso olisi kunnille pakollinen (valtion ja kunnan yhteenliittymät?) Käyttö:Salassa pidettävät asiakirjat tai niihin sisältyvät tiedot voidaan luokitella sen mukaan, minkälaisia tietoturvallisuutta koskevia vaatimuksia niiden käsittelyssä on tarpeen noudattaa. Kohdassa 5.1. erotetaan oikein asian ja asiakirjojen julkisuus, mutta tässä yhteydessä viitataan taas asiakirjoihin. - onko joskus tapauksia, joissa suojaustaso olisi kunnille pakollinen (valtion ja kunnan yhteenliittymät?) Käyttö:Salassa pidettävät asiakirjat tai niihin sisältyvät tiedot voidaan luokitella sen mukaan, minkälaisia tietoturvallisuutta koskevia vaatimuksia niiden käsittelyssä on tarpeen noudattaa. Kohdassa 5.1. erotetaan oikein asian ja asiakirjojen julkisuus, mutta tässä yhteydessä viitataan taas asiakirjoihin. - Käyttö-kohdan tarkennus samankaltaisella tekstillä kuin Henkilötietoja-metatiedon kohdalla on: "Käsittelyprosessin kuvaus ei välttämättä sisällä suojaustasoa vaativaa tietoa, vaikka kaikki siihen liittyvät asiakirjatiedot vaatisivat suojaustason. Käsittelyprosessin kuvaus voidaan merkitä suojaustasolla silloin, kun käsittelyprosessin kuvauksen tiedoissa (metatiedoissa) on suojaustasomerkinnän vaativaa tietoa." Käyttö-kohdan viimeiseen virkkeeseen myös pieni tarkennus, säädösnumero sulkuihin ja kursiivia voisi myös käyttää asetuksen nimen kohdalla kuten metatiedossa 5.3 on julkisuuslain kohdalla: "Suojaustason käyttö on määritelty tarkemmin valtioneuvoston asetuksessa tietoturvallisuudesta valtionhallinnossa (681/2010) ja sen soveltamisesta annetussa VAHTI-ohjeessa 2/2010." - Onko nyt niin, että on varmasti eksakti arvolista (ks. myös kohta 48). Eli että arvolistassa on kaikkien käytettävä muotoja ST I, ST II, ST III ja ST IV. Esim. leimoissa kun käytetään tekstejä: Suojaustaso IV jne. 48. Muutosehdotukset liitteen 1. Metatietomalli kappaleeseen 5.6 Turvallisuusluokka Vastaajien määrä: 3 - Voisi olla maininta, että käsittelyprosessin kuvaus ei välttämättä sisällä turvaluokiteltua tietoa, vaikka siihen liittyvät asiakirjat olisivatkin turvaluokiteltavia - Käyttö-kohdan tarkennus samankaltaisella tekstillä kuin Henkilötietoja-metatiedon kohdalla on: "Käsittelyprosessin kuvaus ei välttämättä sisällä turvallisuusluokiteltavaa tietoa, vaikka kaikki siihen liittyvät asiakirjatiedot olisivat turvallisuusluokiteltavia. Käsittelyprosessin kuvaus voidaan merkitä turvallisuusluokalla silloin, kun käsittelyprosessin kuvauksen tiedoissa (metatiedoissa) on turvallisuusluokiteltavaa tietoa." Käyttö-kohdan viimeiseen virkkeeseen myös pieni tarkennus, säädösnumero sulkuihin ja kursiivia voisi myös käyttää asetuksen nimen kohdalla kuten metatiedossa 5.3 on julkisuuslain kohdalla: "Turvallisuusluokan käyttö on määritelty tarkemmin valtioneuvoston asetuksessa tietoturvallisuudesta valtionhallinnossa (681/2010) ja sen soveltamisesta annetussa VAHTI-ohjeessa 2/2010." Miksi turvallisuusluokkamerkinnät on kirjoitettu isoilla kirjaimilla? Laittakaa eksakti arvolista ja selitykset merkittynä erillään. Eli arvolistajoukon, jonka VAPA hyväksyy. Nyt on hajontaa siinä, miten näitä organisaatiot merkitsevät. Tähän yhteyteen on hyvä mainita, että jos VAPA asettaa arvoille jotain rajoitteita, niin ne olisi hyvä mainita. 49. Muutosehdotukset liitteen 1. Metatietomalli kappaleeseen 5.7 Henkilötietoja

20 Vastaajien määrä: 4 - Kohta 5 Käsittelyprosessin kuvauksen metatiedot / 5.7 Henkilötietoja: miten käsittelyprosessin kuvaukseen voi sisältyä henkilötietoja? - "Käsittelyprosessin kuvauksen sisältämien henkilötietojen luokitus." Miten käsittelyprosessin kuvaus voisi sisältää henkilötietoja? - Henkilötietoja-metatiedon käyttö on käytännössä ollut usein haastavaa. Opastusta on pyydetty mm. arkistolaitokselta ja tietosuojavaltuutetulta, mutta yksiselitteisiä ohjeita ei ole toistaiseksi laadittu. Sisältää arkaluonteisia henkilötietoja-arvon käyttäminen on selkeää henkilötietolain johdosta, mutta laki ei kerro riittävän yksiselitteisesti milloin Sisältää henkilötietoja-arvoa tulee aina käyttää. Sitä voisi mahdollisuuksien mukaan avata tässä ja siitä olisi myös konkreettista hyötyä monille eams-laatijoille kuin myös asiankäsittelyjärjestelmien käyttäjille. Ellei Henkilötietoja-metatiedon käytöstä ole tulossa erillistä ohjetta? - Ehdotetaan selvennettäväksi, milloin käsittelyprosessin kuvauksen voidaan merkitä sisältävän henkilötietoja ja milloin ei. 50. Muutosehdotukset liitteen 1. Metatietomalli kappaleeseen 5.8 Säilytysajan pituus Vastaajien määrä: 4 - Säilytysajan pituus on suositeltavaa määritellä eamsiin käsittelyprosessin kuvaukselle, jolloin kaikki siihen sisältyvät asiakirjat saavat saman säilytysajan, ellei erillislailla määrätä erikseen tehtävään liittyen yksittäisten asiakirjojen poistamisvelvollisuudesta. Käytännössä tämä muuttaa viranomaisten säilytysaikavelvollisuutta huomattavasti, mikä vaikuttaa myös arkistotilojen riittävyyteen. Mikäli suosituksessa näin todetaan, olisi tarkasteltava myös mahdollisuutta siirtää aineistoa arkistolaitoksen säilytysvastuulle 40 vuotta nuorempien asiakirjojen osalta. - Minkä säilytysaika voi olla nolla vuotta? Käytännössähän se tarkoittaa, että asiakirja hävitetään heti sen valmistuttua. - Todellisuudessa valikoima on laajempi. Puuttuu mm. terveydenhuollon potilasasiakirjojen yleinen säilytysaika: 12 vuotta potilaan kuolemasta. - Määritelmätarkennus: "Käsittelyprosessin kuvauksen säilytysajan pituus vuosina." Missä tilanteessa käytetään arvoa 0? Tätä avaisi jokin esimerkki. 51. Muutosehdotukset liitteen 1. Metatietomalli kappaleeseen 5.9 Säilytysajan peruste Vastaajien määrä: 3 - Säilytysaika voi perustua lakiin tai olla organisaation oma päätös [ ] On myös muita päätöksiä, määräyksiä, joissa määritellään säilytysaika, esim. Valtiokonttorin määräys kirjanpitoaineistojen säilytysajoista. - Säilytysaika voi perustua lakiin tai olla organisaation oma päätös [ ] On myös muita päätöksiä, määräyksiä, joissa määritellään säilytysaika, esim. Valtiokonttorin määräys kirjanpitoaineistojen säilytysajoista. - Määritelmätarkennus: "Käsittelyprosessin kuvauksen säilytysajan peruste." 52. Muutosehdotukset liitteen 1. Metatietomalli kappaleeseen 5.10 Säilytysajan laskentaperuste Vastaajien määrä: 6 - Pakollinen määräajan säilytettäville. - Suositeltavat: Asian lopullinen ratkaisu Asiakirjan päivämäärä joissakin tapauksissa on käytetty määritteenä "arkistointi": tulisiko huomioida? - Suositeltavat: Asian lopullinen ratkaisu Asiakirjan päivämäärä joissakin tapauksissa on käytetty määritteenä "arkistointi": tulisiko huomioida? - Määritelmätarkennus: "Tapahtuma, joka käynnistää tietojärjestelmässä käsittelyprosessin kuvauksen