Eurykleia

Opasnet Suomista
Versio hetkellä 9. marraskuuta 2018 kello 14.55 – tehnyt Jouni (keskustelu | muokkaukset) (→‎Laske rahatilanne)
(ero) ← Vanhempi versio | Nykyinen versio (ero) | Uudempi versio → (ero)
Siirry navigaatioon Siirry hakuun




Eurykleia on suunnitelma THL:n talous- ja henkilöstönhallintaohjelmaksi.

Kysymys

Millainen talous- ja henkilöstönsuunniteelu- ja -hallintaohjelma THL:een tarvittaisiin? Sen tuli erityisesti auttaa eroon irrallisista Exceleistä, joita jokainen joutuu ylläpitämään oman projektinhallintansa tueksi.

Vastaus

Yksi mahdollisuus on hyödyntää THL:n omia valmiita järjestelmiä kuten Terhoa (Confluence-wiki) ja R-tilasto-ohjelma, jota kymmenet ihmiset talossa osaavat käyttää tehokkaasti. Tarkempi ehdotus löytyy Yhteistyötiloista sivulta Ehdotus Eurykleian toteuttamiseksi Terhossa ja sen toteutusesimerkki sivulta Esimerkki Terho-toteutuksesta.

Perustelut

Laskenta

Alla on peruskoodi tietojen hakemiseen Yhteistyötiloista ja joidenkin perusraporttien tuottaminen. Idea sinänsä on erittäin joustava, ja R:llä on helppo toteuttaa millaista raportointia tai seurantaa tahansa. Tiedot voidaan myös kytkeä Shinyyn, joka tehokkaana R-rajapintana auttaa tekemään monenlaisia kuvaajia talous- ja henkilöstötilanteesta.

Laske rahatilanne

+ Näytä koodi

Initiate functions

+ Näytä koodi

Kommentteja vaatimusmäärittelyyn

Tunnisteet viittaavat Eurykleian vaatimusmäärittelyn versioon 8.12.2017 toiminnallisten vaatimusten osalta [1].

  • Vaatimukset YL01-YL27, VU01-VU16, TA01-TA09 yleensä ottaen muutkin ovat sellaisia, jotka on mahdollista rakentaa ja muokata halutulla tavalla, koska Terho-järjestelmä on tietorakenteeltaan niin joustava. Tätä ratkaisua on kuvattu Yhteistyötiloissa sivuilla Ehdotus Eurykleian toteuttamiseksi Terhossa sekä Esimerkki Terho-toteutuksesta.
  • YL12: suoritemäärää voi seurata, jos tieto syötetään määrinä ja yksikkökustannuksina eikä suoraan euroina. Toteutus vaatii oman taulukon muttei ole vaikea.
  • VU03, VU05: Budjettijako voidaan toteuttaa tapahtumina, joiden kustannuslaji on esim. "Budjettimyöntö". Nämä tapahtumat voidaan hallinnoida keskitetysti yhdestä tai hajautetusti useammasta taulusta, koska laskennallisesti kaikki taulut ovat yhtä ja samaa ja tiedot siitä periytyvät kaikkiin organisaation osiin kokonaislaskennan kautta. Osastolle jaettu budjettimyöntö on osastolle negatiivista, kun se jaetaan edelleen yksiköihin.
  • VV01-VV03: Jos tarvitaan useampia vaihtoehtoisia budjetteja, Tätä varten tarvitaan oma sarake johon määritellään skenaarion (version) nimi. Jos nimeä ei mainita tai sarake puuttuu, kyseinen tapahtuma toteutuu kaikissa skenaarioissa.
  • PR02: Budjettien täsmäämiseen on käytössä tasaustyökalu, joka kertoo paljonko kutakin yhtä kustannuslajia pitäisi tarkasteltavalla tasolla ja aikaikkunassa lisätä, jotta budjetti menisi nollille. Näin pystytään yhdellä silmäyksellä näkemään, paljonko on yli- tai alijäämää odotettavissa ja millä tavalla se saataisiin tasattua eri kustannuslajien menoja muuttamalla. Järjestelmä on joustava, koska se voidaan laskea mille tahansa tarkasteluun otetulle tilanteelle.
  • PR09: Perustuu Terhon omaan versiohistorian toiminnallisuuteen.
  • TA10-TA13, HE21: Rivitason tapahtumat ovat suojatulla serverillä, ja sen tekninen toteutus on tällä hetkellä epäselvä. Ne joilla on pääsy suoraan tälle serverille on myös mahdollisuus tarkastella rivitason tapahtumia. Tänne voidaan rakentaan halutut toiminnallisuudet. Yleisessä käyttöliittymässä voitaisiin tuottaa linkki, jolla haetaan halutut rivitason tiedot (ja joka toimii vain jos henkilöllä on oikeudet). Voi olla, että tämä olisi helpompaa toteuttaa suoraan Kiekussa.
  • HE01-HE04: Tarkoitus on Eurykleiassa käyttää vain henkilön nimeä tunnisteena, ja palkka- ym. tiedot nousevat laskentaan suojatusta tiedostosta ja summataan, jolloin henkilöiden palkat eivät järjestelmässä sellaisenaan näy. Sen sijaan HE15:n mukaiset tiedot eli esim. työsuhteiden kestot ja sijoitukset eri projekteille näkyvät kaikille (ellei yksikkö suojaa omaa budjetointisivuaan).
  • HE13: Vaatimusmäärittelyssä jää epäselväksi, millaista luokittelua tässä ajatellaan ja pitääkö olla viisi erillistä kenttää jossa on etukäteen määrätyt vaihtoehdot. Ehdotan sen sijaan, että on yksi sarake Luokittelut, johon voi kirjoittaa useita vapaamuotoisia luokitteluja esim. pilkulla erotettuna.
  • KA01-KA06: Järjestelmä rakennetaan kaksitasoiseksi: suunnittelutiedot, menot, tulot ja henkilöiden nimet ovat lähtökohtaisesti kaikkien nähtävissä. Palkkatiedot, hetut, vaativuusluokat ja suoriutumispisteet sen sijaan eivät. Tällä hetkellä on epäselvää, onko noihin salaisiin tietoihin lainkaan tarpeellista päästä tämän järjestelmän kautta, vai katsellaanko ja hallinnoidaanko niitä suoraan siellä missä ne ovat (eli HOT:ssa?).
  • HA01-HA13 sekä TI01-TI10: hankintatiedot ja tilatiedot tarvitsevat kokonaan omat taulunsa ja laskentakoodinsa. Tämä ei ole sinänsä ongelmallista, mutta ei liene myöskään välttämätöntä toteuttaa niitä ensi vaiheessa (ja kakkoskategoriaan ne on merkittykin).
  • LI01-LI27: Rajapintaliittymät ovat lähinnä kiinni niistä järjestelmistä, joista tietoa ollaan tuomassa. Tässä suunnitelmassa oletetaan, että tietoja tuodaan eräajoina eikä reaaliaikaiseen rajapintaan pyritä. Monien tietojen osalta riittää, että tiedot tuodaan tähän järjestelmään kerran viikossa. Yksinkertaisin versio on sellainen, että joku riittävillä oikeuksilla varustettu henkilö tekee haun esim. Kiekuun ja tallentaa rivitason tiedot suojatulle serverille CSV-tiedostona, jota Eurykleia puolestaan ne lukee. Hienompiakin tapoja voi kehitellä, mutta rutiinitoimenpiteenä tässä ei pitäisi mennä paria minuuttia kauempaa ja siksi kovin massiivisia järjestelmiä tuon pienen työn säästämiseksi ei kannata rakentaa.
  • LI07: Tarvittava kääntötaulukko voidaan ylläpitää Terhossa.

Katso myös