Kunnallisten service deskien aallonharjalla

KuntaPron service desk on tehnyt lähivuosina rohkeasti uudistuksia ja haluaa näyttää esimerkkiä muille kunnallisille palvelukeskuksille. Kehittymisessä koulutustyö on ollut suureksi avuksi.

Yli neljä vuotta KuntaProssa työskennellyt, tänä päivänä järjestelmäpäällikön titteliä kantava, Marko Vuorinen, vaikuttaa ilmeisen tyytyväiseltä lähivuosina työpaikallaan tehtyihin muutoksiin. KuntaPron service desk, eTiski, palvelee kaupungin ja kuntien henkilökuntaa kahdeksatta vuotta. Vuorisen mukaan eTiski on nyt Suomen ensimmäinen kunnallisen palvelukeskuksen keskitetty asiakaspalvelupiste.

”Ihan samantyyppistä ei ainakaan itselle ole tullut vielä vastaan”, Vuorinen sanoo. ”Trendi on kuitenkin selvästi nouseva, sillä monessa kaupungissa ollaan parhaillaan perustamassa vastaavanlaisia. Puolin ja toisin on vierailtu ja jaettu kokemuksia.”

KuntaPron eTiski tuottaa tukipalveluita pääosin henkilöstöhallinnan ja taloushallinnon järjestelmiin sekä ICT-puolelle. Suurimmat asiakassektorit kuuluvat Satakuntaan, Kanta-Hämeeseen ja Keski-Uusimaahan. Arkea eTiskissä pyörittää kymmenhenkinen tiimi, joka vastaanottaa asiakaskontakteja yhä enenevissä määrin sähköisiä kanavia pitkin puheluihin vastaamisen sijaan.

HDI Nordicin koulutuksista tuulta purjeisiin

”Koko KuntaPron tasolla on rakennettu mallia, jonka mukaan palvelupyynnöt ohjataan eri tahoille, ratkaistaan ja seurataan ratkaisuun menevää aikaa”, Vuorinen kertoo. ”Meidän toiminta perustuu käytössä hyväksi havaittuihin malleihin ja kyllähän siellä ITIL-viitekehys taustalla kummittelee”, Vuorinen nauraa.

Vuorisen mukaan KuntaProssa vaihtuvuus on ollut vuosien varrella vähäistä, mutta viimeisen vuoden sisällä joukkoon on palkattu uusia vahvistuksia. Haasteena on ollut erilaisten yrityskulttuuritaustojen yhteensovittaminen ja yhteisten toimintatapojen löytäminen.

”Palvelupyyntöjen käsittelyssä ja asiakaspalvelussa HDI Nordic (nyk. Wave) on ollut aivan keskeinen yhteistyökumppani meille. Yhdessä on luotu sellainen perustaso, joka vähintään meidän henkilöstön tulee tuntea.”

Kahden päivän peruskoulutus on Vuorisen mukaan tärkeä edellytys yhdessä työskentelylle. Kymmenkunta on halunnut kurssin lisäksi vielä suorittaa HDI-sertifikaatin todisteeksi osaamisestaan. Kun kaikki käyvät saman peruskurssin, jossa termit ja käytännöt tehdään tutuiksi, opitaan samalla myös yhteinen kieli, joka helpottaa työskentelyä tiiminä.

”Moni tulee peruskurssin jälkeen kysymään, että koska saa suorittaa ITIL Foundationin, joka on tästä sitten se seuraava askel”, Vuorinen sanoo.

Osana suurempaa kokonaisuutta

Vuorinen on KuntaPron uudistumiseen varsin tyytyväinen: palvelunhallintamalli on auttanut kanavoimaan, mittamaan ja seuraamaan työtä kokonaisuutena. Tiedolla johtamisesta on muodostunut tukeva kivijalka koko organisaation toiminnalle.

Keväällä 2015 KuntaPron eTiski osallistui Vuorisen johdolla Vuoden Service Desk -kilpailuun, joka osaltaan auttoi oikean suunnan hakemisessa. Vaikka voitto meni tänä vuonna toiseen osoitteeseen, tarjosi kilpailu ennen kaikkea mahdollisuuden saada perusteellinen arvio oman service desk -pisteen toiminnasta.

”Näen tärkeänä, että osallistuimme, sillä saimme hyviä askelmerkkejä: vahvistusta sille, mitä on tehty oikein, mutta myös suuntaa sille, mitä kannattaa seuraavan kahden vuoden aikana tehdä. Seuraavan vuoden sisällä pyrimme vahvistamaan sitä ensimmäisen kontaktin kokemusta eli miten asiat saataisiin nopeammin käsittelyyn ja nopeammin ratkaistua”, Vuorinen maalailee tulevaa.

”Olemme onnellisessa asemassa, sillä meillä on niin johdon kuin asiakkaiden tuki tässä kehitystyössä. Nyt kun julkisuudessakin on puitu näitä kunta-alan muutoksia ja rohkeita ratkaisuja tarvitaan, pääsemme vaikuttamaan myös siihen keskusteluun työpanoksellamme.”

Tämä kirjoitus on julkaistu alunperin helmikuussa 2016. HDI Nordic on tammikuussa 2017 fuusioitu Wakaru Osakeyhtiöön ja jatkaa toimintaansa nimellä Wakaru Asiakaspalveluverkosto Wave. Tutustu tästä!

markovuorinen

Marko Vuorinen työskentelee KuntaPron Service Deskille järjestelmäpäällikkönä. Kuva: Janne Lehtinen

Miksi avoimen lähdekoodin käyttö kannattaa

Avoimen lähdekoodin hyödyntäminen ohjelmistokehityksessä on nykyisin hyvin yleistä, eikä syyttä. Avoimen lähdekoodin turvin on saatavilla runsaasti laadukkaita ohjelmistokomponentteja hyvin monipuolisesti. Tarjolla on kaikkea kirjastoista ohjelmistokokonaisuuksiin. Tällaisten ilmaisten ja helposti saatavilla olevien komponenttien käyttäminen voi nopeuttaa ohjelmistokehitysprojekteja huomattavasti. Yrityksen ei yksinkertaisesti ole järkevää koodata itse sellaista minkä joku muu on jo koodannut, varsinkin jos se on saatavilla ilmaiseksi ilman yrityksen toimintaa haittaavia rajoituksia.

Kaikki eivät kuitenkaan hyödynnä avoimen lähdekoodin tarjoamia mahdollisuuksia. PRH arvioi, että noin 30% Suomessa tapahtuvasta tuotekehityksestä on päällekkäistä, eli kehitetään sellaista minkä joku muu on jo kehittänyt. Tällainen päällekkäiskehitys ei yleensä ole järkevää resurssien käyttöä, ei yksittäisen yrityksen kannalta, eikä yhteiskunnallisesti. Joskus päällekkäistä tuotekehitystä ei kuitenkaan voi välttää. Näin käy esimerkiksi silloin kun aikaisempi tuote ei ole saatavilla tai sen lisensoinnista ei päästä tyydyttävään sopimukseen.

Avoin lähdekoodi kuitenkin tuo sen turvin julkaistun tuotteen kaikkien saataville ilmaiseksi. Koska erillisiä sopimusneuvotteluja ei tarvita, eikä tuotteesta tarvitse maksaa, on käyttöönottokynnys matala. Vaikka avoin lähdekoodi onkin ilmaista, voi monia avoimen lähdekoodin komponentteja käyttää maksullisissa tuotteissa. Varsinkin avoimen lähdekoodin ohjelmistokirjastot soveltuvat lähes aina myös suljetun kaupallisen ohjelmiston yhteydessä käytettäväksi. Muiden avoimen lähdekoodin komponenttien kohdalla on enemmän vaihtelevuutta.

Osa avoimen lähdekoodin lisensseistä vaatii, että avoin lisenssi periytyy kaikille ohjelmistoille, jossa kyseisen lisenssin alaisia komponentteja on käytetty (ns. copyleft lisenssit). Tämäkään ei kuitenkaan tarkoita, etteikö tuote voisi tuottaa liikevaihtoa. Tällaisten tuotteiden kaupallistaminen vaatii vain hieman epäkonventionaalisen ansaintalogiikan soveltamista.

Esimerkiksi Linux-kernel ja kaikki siihen perustuvat ohjelmistot ovat avoimen lähdekoodin (GNU GPLv2) alaisia tuotteita. Silti on olemassa maksullisia, varsinkin yrityskäyttöön suunnattuja Linux jakeluita. Näissä tuotteissa kaupallinen arvo muodostuu siitä, että järjestelmä on valmiiksi konfiguroitu ja siihen on asennettu tarpeelliset paketit. Lisäksi tuotekokonaisuus on huolellisesti testattu ja hinta sisältää teknisen tuen.

Myös Googlen Android®-käyttöjärjestelmä on Linux-pohjainen ja kuuluu avoimen lähdekoodin piiriin. Silti se on merkittävä tulonlähde Googlelle. Vaikka Google ei voikaan estää kolmansia osapuolia käyttämästä ja jakamasta järjestelmää, voi se kontrolloida tavaramerkkejään ja omia palveluitaan (esim. Play Store). Sanamerkki Android® sekä vihreä robottilogo ovat Googlen omistamia ja tarkkaan kontrolloimia tavaramerkkejä, joiden käyttö edellyttää tiukkojen ehtojen täyttymistä. Tällä Google käytännössä hallitsee koko Android® alustan käyttöä, sillä laitevalmistajien ja muiden kumppaneiden olisi vaikea myydä kuluttajille Android tuotteita ilman Googlen tavaramerkkejä tai palveluita.

Myös muita mahdollisuuksia ilmaisen tuotteen kaupallistamiseen on, vain mielikuvitus on rajana. Avoin lähdekoodi toki soveltuu myös perinteiseen suljetun lähdekoodin ohjelmistojen kehittämiseen, mutta silloin täytyy välttää copyleft-lisenssien käyttöä. Joskus voi myös olla mahdollista eristää tietyt ohjelmiston osat toisistaan siten, että copyleft-lisenssin käyttö yhdessä ohjelmiston osassa ei tuo koko ohjelmistoa avoimen lähdekoodin piiriin.

Perehtymällä avoimen lähdekoodin lisenssityyppeihin ja niiden ominaisuuksiin voitte määritellä oman yrityksenne liiketoimintamalliin sopivat ja epäsopivat avoimen lähdekoodin lisenssityypit sekä hyödyntää avoimen lähdekoodin komponentteja turvallisin mielin.

Tervetuloa keskustelemaan aiheesta tuleville kursseille:
Introduction to IPR – Immateriaalioikeuden perusteet
Software IPR Fundamentals – immateriaalioikeudet ohjelmistokehityksessä

Tulossa myös maksuton webinaari avoimen lähdekoodin hyödyntämisestä, seuraa webinaarikalenteria!

rasmus_kouluttajakuva

Rasmus Saviranta

Kirjoittaja on kansainvälisen taustan omaava IPR juristi. Vuodesta 2015 asti hän on toiminut Claystrand Consultingissa IPR-asiantuntijana ja -konsulttina sekä IPR-kouluttajana.

Ota yhteyttä:
rasmus.saviranta@claystrand.com

LinkedIn

Claystrand Consulting on yksi Oppia.fi – Oppimisen verkkokaupan 50:stä kouluttajakumppanista! Tutustu tapahtumiin, koulutuksiin ja digitaalisen sisällön tarjontaan www.oppia.fi

Standardien merkitys kokonaisarkkitehtuurityössä

Kokonaisarkkitehtuuriin liittyvistä standardeista tunnetuin lienee TOGAF®. Kuvauskieltä standardoiva ArchiMate® taas on hieman vähemmän tunnettu. Jotkut lukevat JHS179-suosituksen standardeihin, vaikka se on lähinnä suositus. JHS179:n perusteella ollaan tuottamassa JHS198:a, joka on ns. ”tekninen eritelmä” eli standardi. Standardien joukko on siis jossain määrin kirjava, joissain puhutaan enemmän työtavoista ja muista parhaista käytännöistä, joissain taas on standardoitu tuotosten formaatti. Teknisistä standardeista olemme jo oppineet, että standardien ansiosta asiat toimivat paremmin yhteen, kun kaikki osapuolet noudattavat samaa standardia.

Open Groupin linjaus on selvä. TOGAF on menetelmä ja ArchiMate on kuvauskieli. Tähän suuntaan ollaan menossa. Mitä ArchiMate kuvauskielenä tarkoittaa? Kukin elementti (kaikki ne laatikot ja soikiot, joita arkkitehtuurikuvissa käytetään) on standardoitu. ArchiMate:lla tehdyt arkkitehtuurikuvat näyttävät siis lukijan silmään samalta. Myös kuvissa käytetyillä nuolilla ja viivoilla on tarkkaan määritelty merkitys. Tämä helpottaa arkkitehtuurin viestintää. Riittää, että osaa lukea yhdenlaisia kuvia. Vähän samaan tapaan kuin rakennuspiirustuksissa. Ei kirvesmiehillekään tule milloin mitäkin kuvia tulkittavaksi.

Kokonaisarkkitehtuuria eli arkkitehtuurikuvia tehdään erilaisilla mallinnusvälineillä (Suomessa käytössä olevia mallinnusvälineitä ovat mm. QPR, Sparx, ARIS, BiZZdesign). Toki ennen ArchiMate-kuvauskieltä on ollut jonkinlaisia standardeja, mutta ei niin kattavia. Niinpä ennen kullakin mallinnusvälineellä oli perinteisesti oma tapansa kuvata arkkitehtuuria ja yksi osa mallinnusvälineen opettelua oli opetella siellä käytetty kuvaustapa. Koska mallinnusväline on organisaatiossa käytössä useita vuosia, ei tästä ollut merkittävää haittaa. Riittää toki, että organisaatiossa osataan sinne valitut mallinnusvälineet, ei ole tarpeen hallita kaikkia mahdollisia. Nykyisin tilanne on kuitenkin toinen, käytetään yhä enemmän konsultteja ja vaihtavat ne omatkin työntekijät silloin tällöin työpaikkaa.

Osaamista on huomattavasti helpompi hankkia ja ylläpitää, jos mallinnustapa pohjautuu avoimeen standardiin. Standardi itsessään löytyy netistä ja myös sen hyödyntämistä tukevaa dokumentaatiota on tarjolla runsaasti. Jos ei halua opetella asioita itsekseen, on tarjolla kursseja. Osaamisen voi mittauttaa suorittamalla sertifikaatin. Tämä tekee myös konsultoinnin ostajan elämän helpoksi. On olemassa selkeät kriteerit, joita voi toimittajilta edellyttää. On tämä konsultointitaloillekin hyvä juttu. Osaaminen on nimittäin melko helposti hankittavissa, jos vain tahtoa löytyy.

Mallinnusvälinettä valittaessa tyypillinen asiakasorganisaation toive on, että ei ajauduttaisi toimittajaloukkuun, vaan voitaisiin tarvittaessa vaihtaa väline toiseen ilman isompaa tuskaa. Toimittajaloukku voi syntyä monella tavalla, eikä ArchiMate luonnollisestikaan tuo ratkaisua kaikkeen, mutta tietojen siirtoon on olemassa ArchiMate Model Exchange File Format. Siirtotiedosto toimii siten, että mallinnusvälineessä oleva sisältö kirjoitetaan tiedostoon (export), avataan toinen mallinnusväline ja imaistaan sisältö sinne (import). Ja se toimii! Siirsimme nimittäin Coalassa kokeeksi yhden asiakkaan arkkitehtuurikuvaukset välineestä toiseen. Tähän meni semmoiset viisi minuuttia. Toimiiko tämä kaikkien välineiden välillä? Ei välttämättä. Vaikka monellakin välineellä voi piirtää ArchiMate:n näköisiä kuvauksia, eivät kaikki välineet välttämättä toteuta kaikkia standardin vaatimuksia, eli tuota mainittua siirtotiedostoa.

Julkishallinnossa on käytössä JHS179 ja JHS198 on tulossa. Tarvitaanko siellä näitä standardeja? JHS179 ei määrittele kuvauskieltä, vaan (yllätys, yllätys) pohjautuu ArchiMate:en. Niinpä ei riitä, että perehtyy JHS-suosituksiin, vaan on hallittava myös sen pohjalla olevat standardit.

Kuten mainitsin jo aikaisemmin, standardien soveltamiseen löytyy koulutusta. Coalan tarjonnassa on mm. Johdanto ArchiMate® 3 kuvauskieleen. Sertifiointiin johtavaa kurssia meillä ei vielä ole, koska uusimpaan standardin versioon ei ole vielä sertifiointia ja vanhoja standardeja ei oikein kannata opiskella. Jos taas kokonaisarkkitehtuuritoiminnon pystyttäminen tai välinevalinta askarruttaa, on meillä siihenkin useita kursseja.

Anna_Aaltonen

Anna Aaltonen

Kirjoittaja on kokonaisarkkitehti ja konsultti Coalasta. Hänellä on yli 15 vuoden kokemus arkkitehtuurityöstä sekä organisaation omana arkkitehtinä että konsulttina. Anna tuntee kokonaisarkkitehtuurin työtavat ja välineet ja on soveltanut niitä erilaisissa organisaatioissa ja käyttötilanteissa. Anna myös harrastaa arkkitehtuuria toimimalla Kokonaisarkkitehtuurin osaamisyhteisössä ja irrottautuu työasioista koirien MH-luonnekuvausten parissa.

 

 

 

Kehitä service deskiäsi kisaamalla

Miten on teidän service deskinne kilpailukyvyn laita? Onko jo tehty ylimääräisiä tunteja tai vuodatettu hikeä liikuntapäivänä? Olisiko kilpailukyky jopa siinä kunnossa, että uskaltaisitte lähteä kisaamaan Vuoden Service Desk 2017 -tittelistä?

Oli kyvykkyys huipussaan tai ei, kannattaa lähteä mukaan! Väitän, että voitto ei ole tässä kisassa tärkeintä, vaan kaikki se hyöty, jonka kisaaja saa oman toimintansa ulkopuolisesta arvioinnista. Kokemusteni perusteella finaaliin päässeille jo pelkästään kisaan kuuluva itsearviointi on ollut osallistujille hyvin valaisevaa.

Jokainen finaaliin päässyt saa auditoinnista myös loppuraportin.  Siitä voi noukkia ”rusinat pullasta”, eli hyödyntää niitä kehitysideoita tai korjauksen kohteita, jotka itsestä tuntuvat omalle toiminnalle sillä hetkellä sopivilta. Kisan auditoijilla Liisa Torkkelilla ja allekirjoittaneella on pitkä ’kisakokemus’ ja myös alan tuntemus: toimimme molemmat service desk -alueen kouluttajina. Liisalla on kokemusta myös käytännön service desk -työstä sekä vastuuhenkilönä että konsulttina. Tästä on suuri hyöty auditoinnissa ja raportin laadinnassa.

Tietysti jos vielä sattuu voittamaan kisan, se on totta kai kunnianosoitus tehdylle työlle ja piristysruiske motivaatiolle. Teinkin pikagallupin parin viime vuoden voittajien fiiliksistä ja kyselin kuulumisia:

Viime vuoden voittajan Fujitsun 24/7 service deskin vetäjä Pauli Ketolainen kertoi kisasta saadun hyödyn olevan moninainen: ”Parhaiten hyöty näkyy päivittäisessä tekemisessä. Voitto vahvisti ryhmän uskoa siihen, että olemme tehneet oikeita asioita ja suunta on ollut oikea. Myös ylpeys omaan tekemiseen kasvoi. Olemme parhaita!”, Pauli kuvaili voittajan tunnelmia ja jatkoi: ”Omaan johtamiseen ja kehittämiseen sain myös suuresti apua; annetut parannuskohteet olivat konkreettisia ja niiden hyöty helposti ymmärrettävissä. Nämä auttavat huomattavasti kehittämään palvelua tulevaisuudessa.”

Edellisvuonna voiton vei CGI, jonka Production Director Kimmo Metso valotti kisaan lähtemisen syitä: ”Meille lähtökohta oli meidän benchmarkkaus, ja tiedossa oli, että saamme kattavan raportin toiminnastamme service deskinä – oli meidän sijoittuminen sitten mikä tahansa. Toki, emmehän me olisi lähteneet kisaan, jos emme olisi olleet luottavaisia siitä, että toimimme niin kuin service deskin tulee toimia.”

Kimmo uskoo, että kaikki service deskit hallitsevat perusprosessit ja mittaukset, mutta CGI satsasi asioihin, joilla on vaikutusta laatuun: ”Meillä oli pohjana tiettyjen asioiden ja toimintatapojen painotus sekä niiden viilaus, joita toimme kisassakin esille, ja jotka myös nousivat esille loppuraportoinnissa myönteisellä tavalla” hän kertoi.

Myös jälkeenpäin kisa antoi kättä pidempää: ”Kotiläksyjä kisasta jäi myös eli tuo auditointiraportti on ollut meillä käytössä, kun olemme katsoneet asioita eri kantilta: missä voisimme kehittää, mistä voisimme luopua, mitä tarvitsemme lisää.”

—–

Vuoden Service Desk -kisan arviointi pohjautuu alan parhaisiin käytäntöihin kuten HDI:n kansainväliseen tukipalvelustandardiin, ISO/IEC 20000 -standardiin ja ITIL-viitekehykseen. Lisätietoa kisasta ja käytännöistä täältä!

 

marko-uusitalo-new

Marko Uusitalo

Kirjoittaja on kouluttanut asiakas- ja tukipalveluja kohta jo parikymmentä vuotta. Service deskeille Marko on kouluttanut pääasiassa viestintää ja asiakaspalvelutaitoja. Markon valmennuksiin on kuulunut myös HDI:n kansainvälinen SCA-sertifikaatikoulutus, joka perustuu kisankin taustalla olevaan HDI:n tukipalvelustandardiin. Vuoden Service Desk -kisan auditoijana hän on toiminut 4 kertaa.

marko.uusitalo@konkreetti.fi

LinkedIn

Lisää asiakaspalveluaiheisia koulutuksia Oppia.fi – Oppimisen verkkokaupassa!

Arvostava esimies rakentaa yhdessä tekemisen kulttuuria joka päivä

Helsingin Sanomissa käytiin syyskuussa 2016 keskustelua työhyvinvoinnista – lähinnä siitä näkökulmasta, paljonko työpahoinvointi tulee yhteiskunnalle maksamaan. Summat ovat vaihdelleet, mutta on puhuttu kymmenistä miljardeista euroista vuositasolla.

Työpahoinvoinnin euromääräisten summien lisäksi kyse on erityisesti käänteisestä asiasta eli työhyvinvoinnista – siitä, miten ihmiset voivat, jaksavat, innostuvat ja tekevät työnsä ja siitä, miten paljon tuottavampaa hyvällä mielellä tehty työ on.

Työn tekemisen tarkoitus on tehdä työtä, työhön ei lähtökohtaisesti mennä viihtymään vaan tekemään työtä mutta työstä saa nauttia ja työssä saa tuntea olonsa turvalliseksi ja hyväksi. Useimmiten työtä tehdään yhdessä, vain jokunen prosentti työtätekevistä ihmisistä työskentelee yksin – voimme siis puhua kanssakäymisen työkulttuurista.

Millä tavalla rakennamme yhdessä tekemisen työkulttuuria ja mitä sitten, kun hankaluuksia, ristiriitoja tai väärin ymmärryksiä tulee ja tapahtuu? Haasteellisissakin tilanteissa on mukana aina myös mahdollisuus päästä eteenpäin kohti parempaa lopputulosta.

Ennakointi, yhteiset pelisäännöt, ripeä puuttuminen ja ratkaisukeskeinen rakentava palaute, ovat esimiehen avaintaitoja. Arvostava ote hankalissa tilanteissa avaa näkökulmia ja helpottaa ratkaisun löytämistä. Kiitos ja onnistumisten huomaaminen ja sen ääneen sanominen kantaa eteenpäin.

Arjen onnistumisia ja työn tekemisen kulttuuria rakennetaan joka päivä, pienin askelin. Korjataan mitä korjattavaa on, vahvistetaan niitä asioita ja tapoja, jotka ovat toimivia ja joiden koetaan olevan kunnossa.

Arvostava esimies – haastavat tilanteet koulutus Tampereella. Katso uusin toteutus täältä ja ilmoittaudu mukaan!

Tervetuloa Luotaimen innostaville aamiaisbrunsseille!
Mikä meitä motivoi? 14.3. Tampereella
Puhumassa Päivi Mayor, joka kertoo Steven Reissin motivaatioteoriasta.

na%cc%88ytto%cc%88kuva-2017-02-05-kello-12-09-41

Tuula Kiuru-Ahvonen

Kirjoittaja on ollut työelämässä yli 30 vuotta hyvin monenlaisissa rooleissa ja tehtävissä: työntekijänä, päällikkönä, esimiehenä, johtajana, yrittäjänä, hallituksissa ja johtoryhmissä. Kaikkia hänen töitään on yhdistänyt toisaalta kiinnostus ihmisiin, ihmisten motivaatiotekijöihin, esimiestyöhön sekä toisaalta vastuunotto ja kehittäminen sekä näiden edellytysten vahvistaminen työyhteisöissä.

 

 

Kirjoitus on julkaistu alunperin Luotaimen omilla kotisivuilla.

Luotain on yksi Oppia.fi – Oppimisen verkkokaupan 50:stä koulutuskumppanista. Tutustu Luotaimen koko koulutustarjontaan täältä!

Miksi tietoarkkitehtuuri on niin vaikeaa?

Tiedon merkitystä korostetaan usein, etenkin näin digitalisaation aikana. Tieto on voimavara. Tieto on kilpailuetu. Tieto on organisaation tärkeintä omaisuutta. Tiedon elinkaari on pitkä. Toisaalta tietoarkkitehtuuri on arkkitehtuurin osa-alueista vaikein. Näistä asioista on helppo olla samaa mieltä, mutta mitä tehdä?

Entisaikaan tietoa oli helpompi lähestyä. Rakennettiin yksi keskitetty tietokanta ja sitä käyttivät kaikki. Ylläpidettiin tietokannan suunnittelussa tehtyä dokumentaatiota, jota saatettiin kutsua jopa yritystietomalliksi. Tosin jo silloin sanalla ”yritystietomalli” oli myös paha kaiku, se nimittäin viittasi iäisyysprojekteihin, joita oli tehty väellä ja voimalla saamatta juurikaan hyötyjä. Lähestymistapa oli kuitenkin se, että on yksi yhteinen tietomalli.

Mikä on tietoarkkitehtuurin tilanne nykyisin? Kehittämiseen kuuluvissa praktiikoissa on kussakin erilainen lähestymistapa tietoon. Kokonaisarkkitehtuurissa puhutaan käsitemallista, julkisessa hallinnossa myös päätietoryhmistä ja loogisista tietovarannoista. Tietokantojen suunnittelussa on edelleen käytössä looginen tietomalli ja siitä generoitu fyysinen tietomalli. Tehdäänpä joissain organisaatioissa myöskin sanastotyötä, jota alan harrastajat kutsuvat terminologiseksi käsiteanalyysiksi. Hei, siellähän oli siis myös sana ”käsite”. Sama, jota kokonaisarkkitehtuurissa käytetään! Voimmeko siis korvata kokonaisarkkitehtuurin käsitemallin terminologien tuotoksilla? Valmisohjelmistojen mukana tulee myös tietokannan rakenne, kullakin valmisohjelmistolla parhaaksi katsomansa. Voimmeko pakottaa valmisohjelmistoja samaan muottiin organisaatiomme muiden tietomallien kanssa? Useimmiten emme. Entäpä integroinnit ja palvelurajapinnoissa kulkevat tiedot? Voisin jatkaa tätä listaa melkein loputtomiin, mutta tarkoitus taisi jo tulla selväksi. Entinen aika ei palaa. Joudumme siis elämään useiden erilaisten tietomallien ja muiden tietoarkkitehtuuriin liittyvien tuotosten kanssa.

Mikä olisi nykypäivään soveltuva ratkaisu? Erilaisuudesta emme pääse eroon, sen kanssa on opittava elämään. Ensimmäinen askel on ymmärtää, mitä tietoarkkitehtuurin eri tuotoksia tehdään ja mihin käyttötarkoituksiin. Seuraava askel on hahmottaa, miten ne liittyvät toisiinsa. Organisaatiossa ei saa olla montaa käsitystä siellä käsiteltävistä tiedoista, eli eri mallit eivät saa olla ristiriitaisia toistensa kanssa.

Näihin kysymyksiin olemme törmänneet useissa toimeksiannoissamme. Niinpä päätimme asian selkiyttämiseksi koota aiheesta kurssin, sitä kun ei ollut kenelläkään muulla tarjolla.

 

Anna_Aaltonen

Anna Aaltonen

Kirjoittaja on kokonaisarkkitehti ja konsultti Coalasta. Hänellä on yli 15 vuoden kokemus arkkitehtuurityöstä sekä organisaation omana arkkitehtinä että konsulttina. Anna tuntee kokonaisarkkitehtuurin työtavat ja välineet ja on soveltanut niitä erilaisissa organisaatioissa ja käyttötilanteissa. Anna myös harrastaa arkkitehtuuria toimimalla Kokonaisarkkitehtuurin osaamisyhteisössä ja irrottautuu työasioista koirien MH-luonnekuvausten parissa.

Privilege escalation with bypassing UAC

Operating Systems are very complex piece of code but once you see their logic, everything is clear.

As one of the widely spread operating system, Microsoft Windows OS is on top on the list of hackers potential targets. Same as the water looks a way to get out trough very tiny hole, hackers are looking for a way to bypass any security measures they face.

In some cases, hackers can gain unauthorized access to Windows OS but with limited privileges. This is because of protection called User Access Control or UAC. With intent to protect as security measure, UAC is preventing execution of actions that need administrative privilege with compulsory direct user interaction which can give permission or deny execution of administrative privilege actions. In evolution of Windows OS, this feature was firstly introduced in Windows Vista OS.

kuva1

The case is that the hackers will always find a way to bypass security measure if there is enough time given to them. In UAC bypass technique that elevate standard user rights to administrator user rights we have two stages:

  • Writing to a secure location
  • Exploiting DLL hijacking vulnerability

In first stage we need to find and exploit a method of COM Object or find Windows Update Standalone Installer (wusa.exe) to use its manifest with auto-elevate. Each version of Windows OS (Win7, Win8, Win8.1 and Win10) has different processes that can be used for auto-elevate. For example, in Win7 we have the following processes that might be exploited with injecting malicious DLL:

  • C:\Windows\explorer.exe
  • C:\Windows\System32\wuauclt.exe
  • C:\Windows\System32\taskhost.exe

The same as in first stage, we need genius Windows OS processes with corresponding DLL’s located in a secure directory with autoElevate property in its manifest.  Each version of Windows OS (Win7, Win8, Win8.1 and Win10) has different processes that can be used for auto-elevate. For example, in Win7 we have the following process with DLL that might be exploited:

  • C:\windows\System32\cliconfg.exe
  • C:\Windows\System32\NTWDBLIB.DLL

Very easy one can find hacking tools that have automated this bypass UAC technique for multiple versions of Windows OS. Very often ethical hackers are using them as they are key component in System Hacking methodology. In Module 5 (System Hacking) from EC-Council’s Certified Ethical Hacker course, ethical hackers learn about various types of technique and tools for bypassing UAC as part of Privilege Escalation process.

If you’d like to discuss with the writer sign in to these!
 
Free webinar:
Certified Network Defender CND – Sneak peek to the course content 07.02.2017
For the first time in Finland:
EC-Council Certified Network Defender Program – CND -course

mane_200x200

Mane Piperevksi

Mane is an Information Technology Expert with extensive experience in Information Security. Over 10 years in IT industry and 5 years’ experience in field of Information Security. With a breadth of technology skills, including networks, operating systems, databases and application development, Mane has provided IT services in various industry sectors such as banking, electronic payment services, transportation, software development companies, utilities, pension and disability insurance, state courts and government institutions. As experienced trainer and instructor Mane has conducted official EC-Council and Microsoft training classes for over 300 students all over Europe. As Security Expert he understands and knows how to look for the weaknesses and vulnerabilities in systems, how they work, how to investigate them and exploit for Proof of Concept.