KLUBITYÖ 2015 BM klubi Pohjanmaa 1 1 ISO 9001:2015 VAATIMUSTEN HUOMIOINTI MUUTOSTEN HALLINNASSA

Koko: px
Aloita esitys sivulta:

Download "KLUBITYÖ 2015 BM klubi Pohjanmaa 1 1 ISO 9001:2015 VAATIMUSTEN HUOMIOINTI MUUTOSTEN HALLINNASSA"

Transkriptio

1 1 ISO 9001:2015 VAATIMUSTEN HUOMIOINTI MUUTOSTEN HALLINNASSA

2 2 ISO 9001:2015 VAATIMUSTEN HUOMIOINTI MUUTOSTEN HALLINNASSA KLUBITYÖN SISÄLTÖ 1. Johdanto 2. Aiheen rajaus ja työkalun valinta 3. Työn tavoitteet ja toteutus 4. Kokemuksia muutoksen hallinnan onnistumisista ja epäonnistumisista 5. Case esimerkki / Anvia: Visio muutostenhallinnan tavoitetilasta 6. Case esimerkki / Asiakastietojärjestelmän kehitysprojekti 7. Case esimerkki / Uuden toimitilan asiakaspalvelupisteen rakentaminen 8. Muutoksenhallinnan kypsyystasotesti 9. Klubityön hyödynnettävyys 10. Johtopäätökset Lähteet 1. Johdanto Klubi kokoontui käynnistämään uutta kautta Klubin jäseninä ovat olleet Pia Haglund (Vaasan keskussairaala), Marko Laatu (ABB Oy), Minna Laatu (VAMK), Katja Luomaranta (Vaasan Sähkö), Reino Lähdemäki (Anvia Oyj), Tuomas Salli (Anvia Oyj) ja Kalle Ylinampa (Vaasan keskussairaala). Valitsimme aiheeksi ISO 9001:2015 vaatimusten huomioinnin muutosten hallinnassa. Aiheena muutostenhallinta on laaja ja riippuen näkökulmasta voidaan ko. aihe aluetta tarkastella mm. IT järjestelmien, henkilöstön, tietoturvan, ISO 9001 standardin, yrityksen menettelyohjeistuksen tai vaikkapa henkilöturvallisuuden kannalta. Muutoskohteiden ja muutostyyppien tunnistaminen / luokittelu Muutoksen kesto / tulevaisuuden ennakointi Isot muutokset / päivittäiset pienet muutokset Muutoksen tausta: ulkoa annettu / omista lähtökohdista Mistä muutos voi johtua ja mihin muutos voi kohdistua / vaikuttaa: Turvallisuus, työhyvinvointi Organisaatiorakenteet IT järjestelmät

3 3 Toimintatavat, prosessit Sopimukset kolmansien osapuolten kanssa Regulaattorit (viranomaisvaatimukset, lakisääteiset vaatimukset) Sidosryhmien hallinta / maine, brändi Tuote / palvelutarjonta Muihin muutoksiin ( muutoskalenteri ) Yksilölliset erot muutosten kokemisessa Kompetenssi / pätevyysvaatimukset Olemme koonneet klubityöhömme Vaasan alueelta eri organisaatioilta sekä hyviä onnistumisia että hyviä epäonnistumisia. Nämä toimivat toivottavasti lukijalle hyvinä esimerkkeinä, kun organisaatiossa määrittellään tarkempia toimintaohjeita eri tyyppisten (sekä ennakoimattomien että ennakoitujen) muutosten ohjeistuksen luomiseksi ja muutosten hallitsemiseksi. Yleisiä muutoksenhallintaprosessin tehtäviä Muutoshallintaprosessilla on seuraavat tehtävät: Hallita muutosten elinkaari Hallita muutoksiin liittyviä riskejä (mm. päällekkäiset muutokset) Minimoida realisoituvien riskien vaikutuksia Varmistaa oikeanlainen, ajantasainen sekä sopimusten mukainen tiedotus muutoksista kaikille sidosryhmille Huolehtia konfiguraatio ja relaatiotiedon ajantasaisuudesta Mittarointi sekä raportointi johdolle Varmistaa osaltaan palvelutasojen pysyvyyden Viestiä muutoksen vaikuttavuus rinnakkaisiin järjestelmiin ja prosesseihin

4 4 Muutoksia tulee johtaa neljällä tasolla. Jokaisesta osa alueesta on syytä kartoittaa muutoksesta aiheutuvat riskit ja tehdä suunnitelma, jossa huomioidaan myös henkilöstön suhtauminen muutostenhallitaan (ettei ohjeistus estä normaalia työntekoa ja täten muutu liian byrokraattiseksi): 1. asioiden johtaminen 2. ihmisten johtaminen 3. sidosryhmien osallistaminen 4. osaamisen varmistaminen 2. Aiheen rajaus ja työkalun valinta Aihetta pohtiessamme keskustelimme ennakoimattoman muutoksen hallinnasta ja muutoksen riskien arvioinnista. Työn edetessä havaitsimme, että erilaisten organisaatioiden muutoksen hallinnan lainalaisuudet ovat samansuuntaisia. Päätimme valita viitekehykseksi tulevan ISO 9001:2015 standardin.

5 5 ISO 9001 laatujärjestelmästandardissa laatu määritellään kokonaisuudeksi, joka muodostuu sellaisista ominaisuuksista, jotka mahdollistavat organisaation, toiminnon, prosessin tai tuotteen kyvyn täyttää siltä vaadittavat ja odotetut ominaisuudet (SFS EN ISO 9001, 22 32). ISO 9000 standardi sisältää perusteet laadunhallintajärjestelmälle ja selittää sen termistön. ISO 9001 standardi määrittää laadunhallintajärjestelmälle ne toiminnat, joilla organisaatio voi näyttää täyttävänsä asiakasvaatimukset ja sitä koskevat lakivaatimukset sekä osoittaa kykynsä toimittajana, kun tarkoitus on lisätä asiakkaiden tyytyväisyyttä. ISO 9004 standardi esittää suuntaviivat laadunhallintajärjestelmän vaikuttavuuteen ja tehokkuuteen. Se auttaa parantamaan organisaation suorituskykyä ja lisäämään asiakkaiden lisäksi kaikkien sidosryhmien tyytyväisyyttä. ISO standardi opastaa auditoinneissa. (SFS EN ISO 9000, 8.) Kuva: Model of a process based quality management system (ISO/DIS 9001:2015)

6 6 Kuluvan vuoden aikana julkaistavassa uudessa ISO 9001:2015 standardissa tulee uusia vaatimuksia liittyen muutosten hallintaan ja riskien arviointiin muutostilanteista. Muutosten ja riskien hallintaan liittyvät vaatimukset on kirjattu standardin kohtiin 6.3 ja ja Ohessa poimittuna kyseiset kohdat tulevasta ISO 9001:2015 standardin DIS versiosta. 6.3 Planning of changes Where the organization determines the need for change to the quality management system the change shall be carried out in a planned and systematic manner. The organization shall consider: a) the purpose of the change and any of its potential consequences; b) the integrity of the quality management system; c) the availability of resources; d) the allocation or reallocation of responsibilities and authorities Design and development changes The organization shall review, control and identify changes made to design inputs and design outputs during the design and development of products and services or subsequently, to the extent that there is no adverse impact on conformity to requirements. Documented information on design and development changes shall be retained Control of changes The organization shall review and control unplanned changes essential for production or service provision to the extent necessary to ensure continuing conformity with specified requirements. The organization shall retain documented information describing the results of the review of changes, the personnel authorizing the change, and any necessary actions. Nykyisessä ISO 9001:2008 standardissa vaatimuksia muutosten hallintaan ja riskien arviointiin muutostilanteissa on esitetty lähinnä kohdassa

7 Suunnittelun ja kehittämisen muutosten ohjaus Suunnittelun ja kehittämisen muutokset tulee tunnistaa ja niistä tulee ylläpitää tallenteita. Muutokset tulee katselmoida, todentaa ja kelpuuttaa soveltuvin osin sekä hyväksyä ennen niiden toteuttamista. Suunnittelun ja kehittämisen muutosten katselmuksissa tulee arvioida muutosten vaikutus tuotteen osiin ja jo toimitettuun tuotteeseen. Muutosten katselmusten tuloksista ja tarvittavista toimenpiteistä tulee ylläpitää tallenteita Control of design and development changes Design and development changes shall be identified and records maintained. The changes shall be reviewed, verified and validated, as appropriate, and approved before implementation. The review of design and development changes shall include evaluation of the effect of the changes on constituent parts and product already delivered. Records of the results of the review of changes and any necessary actions shall be maintained. Oheisessa taulukossa on esitetty merkittäviä uudistuksia uudessa ISO 9001:2015 standardiversiossa (Kaj von Weissenberg, Road Show laatubrunssit esitysmateriaali)

8 8 ISO 9001 standardin lisäksi myös iso standardista on tulossa uusi versio. Oheiseen kuvaan on tiivistettynä molemmille standardeille yhteisiä muutoksia (Kaj von Weissenberg, Road Show laatubrunssit esitysmateriaali).

9 9 3. Työn tavoitteet ja toteutus Klubityömme tavoitteena on ollut löytää erilaisia ratkaisuja täyttää ISO 9001:2015 standardin edellyttämät uudet vaatimukset muutosten sekä riskien hallintaan liittyen. Olemme myös koonneet klubityöhön Vaasan alueelta eri yrityksiltä onnistumisia ja hyviä epäonnistumisia. Osassa esimerkkejä on käytetty pohjana myös ITIL:n parhaita käytäntöjä. 4. Kokemuksia muutoksen hallinnan onnistumisista ja epäonnistumisista Tapaamisissa päätimme, että kukin kirjaa yhden parhaan onnistumisen ja yhden parhaan epäonnistumisen, joko omasta organisaatiosta tai yleisellä tasolla liittyen muutostenhallintaan. Onnistumiset Henkilön 1 paras onnistuminen muutostenhallinnan parhaista käytännöistä: Eräässä yrityksessä oli melkoisia haasteita ymmärtää eri tiimien tekemien muutostöiden vaikutussuhteita. Tämä aiheutti tilanteita, joissa jokainen tiimi mielestään hoiti työtehtävänsä esimiesten ja asiakkaiden edellyttämällä tavalla, mutta laadun ja toiminnan kokonaisvaltaisen hallinnan näkökulmasta yrityksessä syntyi poikkeamia ja palveluiden käyttökatkoksia, koska tiimit eivät keskustelleet töiden riippuvuuksien vaikutuksesta kokonaisuutena. Ongelma ratkaistiin luomalla pelisäännöt eri organisaatioiden tekemille muutostöille kunhan ensin oltiin saatu välttämättömyyden tunne ja ymmärrys muutostenhallinnan välttämättömyydestä aikaiseksi työntekijöiden keskuudessa. Jaottelu perustui A) muutostöihin, jotka vaativat yhteisen muutosraadin päätöksen ennen suorittamista, B) muutostöihin, jotka piti vähintään ilmoittaa muutosraadille ja C) muutostöihin, jotka kirjattiin ylös, mutta jotka

10 10 saatiin suorittaa ilman ilmoittamista muutosraadille, koska nämä muutostyöt olivat luonteeltaan vähäriskisiksi määriteltyjä. Tämä lisäsi mm. yhteisymmärrystä yrityksen palveluiden ja järjestelmien, asiakkaille luvattujen palvelutasojen sekä tuotantotilojen sähkötöiden riippuvuuksista toisiinsa ja vähensi osaltaan huomattavasti yrityksen muutostöiden riskitasoa. Henkilön 2 paras onnistuminen muutostenhallinnan parhaista käytännöistä: Keskussairaalan logistiikassa oli jo vuosia ollut haasteita sovittaa yhteen tilaavien yksiköiden, toimittavan yksikön ja materiaalihallinnon näkemykset parhaasta mahdollisesta tavasta toimittaa hoitoon tarvittavaa materiaalia. Kaikilla kolmella ryhmällä oli oma käsityksensä, miten materiaalilogistiikka tulisi talon sisällä hoitaa, jotta logistiikka olisi mahdollisimman optimoitua työn sujuvuuden kannalta. Tilaavien yksiköiden kesken oli myös eroja logistisista näkemyksistä ja tämän lisäksi tilaavien yksiköiden sisällä oli yksilökohtaisia eroja. Yksikään toimija talon sisällä ei ollut ottanut lähtökohdaksi keskussairaalan olemassaolon perustaa eli potilaita, vaan halut ja tarpeet kumpuavat henkilöstön omista mieltymyksistä. Standardisoinnin puute oli näkyvissä kaikkialla. Tarve muutokselle oli ollut olemassa jo pitkän aikaa. Viimein logistisiin ongelmiin reagoitiin, kun organisaation sisäisestä haittatapahtuman ilmoitusjärjestelmästä nousi tarve muutokselle yhden materiaalitoimituksen osalta koko organisaation tasolla. Muutokseen päätettiin ryhtyä lean filosofian keinoin eli potilaslähtöisyys ajavana voimana ja henkilöstö muutoksen aikaansaajana. Vanha tapa suorittaa organisaatiotason muutokset nähtiin jäykkänä, hitaana ja alttiina vaihtelulle. Vanha tapa käytännössä tarkoitti muutoksen suunnittelua, esittämistä kaikille sidosryhmille ja toteuttamista yksikkökohtaisesti, yksikön omin voimin. Vanha tapa sisälsi suurta vaihtelua yksiköiden välillä ja usein muutokset jäivät suutareiksi, koska ne tulivat ylhäältä välitettynä käskynä tehdä asioita. Päätettiin kokeilla keskitettyä muutosta, jossa ensin pilotoidaan muutos yhdessä yksikössä, informoidaan kaikki sidosryhmät tulevasta muutoksesta ja toteutetaan muutos yhden keskitetyn toimijan avustuksella ja valmennuksella, pitämällä henkilöstö mukana toteutuksessa. Tällä tavoin varmistettiin jokaisen sidosryhmän mukanaolo, pidettiin potilaslähtöisyys ajavana voimana, eliminoitiin vaihtelevuus ja saatiin muutos eteenpäin nopeasti, kun sitä oli aluksi pilotoitu ja todistettu sen toimivuus. Muutos saatiin toteutettua näinkin isossa organisaatiossa nopealla aikataululla. Muutoksen onnistumisesta kertovat reagoinnit prosessipoikkeamiin haittatapahtuma ilmoitusjärjestelmän kautta. Muun muassa uuden standardin noudattamatta jättäminen on raportoitu haittatapahtuma järjestelmään, mikä kertoo, että muutoksesta pidetään kiinni. Muutos palvelee paitsi potilaslähtöisyyttä myös työn sujuvuutta, mikä on havaittavissa myös

11 11 reagoinnissa poikkeaviin tilanteisiin muutoksen jälkeen. Toinen esimerkki muutoksen toimivuudesta ovat henkilöstön kyselyt ja toiveet hioa standardia paremmaksi ja levittää standardia myös muihin materiaalikuljetuksiin. Henkilön 3 paras onnistuminen muutostenhallinnan parhaista käytännöistä: Keskussairaalassa tehtiin aikaisemmin vuosittain laatu, turvallisuus ja potilasturvallisuustyöhön liittyen kolmea erilaista kyselyä, joka vaati yksiköiden aktivoitumista. Yksiköiden piti ensin keväällä täyttää SHQS kriteeristön vaatima itsearviointi, sen jälkeen syksyllä turvallisuustyön vaatima riskienarviointi ja vielä loppuvuodesta potilasturvallisuuden koko vuoden kattava tilanneraportointi, kaikkiin näihin oli vielä oma järjestelmänsä. Tilanne ei ollut millään tavalla toimiva, koska työllisti yksiköitä liikaa ja todellisuudessa nämä kolme toimintoa sisälsivät todella paljon tuplatyötä, koska samanlaisiin tai samankaltaisiin kysymyksiin vastattiin monta kertaa. Tapa työllisti sekä yksiköitä että suunnittelijoita liikaa, eikä ollut toimiva ja muutosta kaivatttiin. Muutos aloitettiin pitämällä kaikkien toimijoiden kesken kehityspäivä, jossa käytiin Lean menetelmien avulla läpi mitä tällä hetkellä tehdään, mikä toimii ja mikä ei. Lopuksi suunniteltiin miten jatkossa toimitaan. Jatkossa kaikki nämä kolme kyselyä tehdään yhtenä ajankohtana loppuvuodesta, yhdessä järjestelmässä ja yhdessä tapahtumassa. Itsearviointi pidetään omana lomakkeenaan, koska se on kriteeristön mukainen eikä sitä voi muuttaa mutta riskienarvioinnista poistettiin tuplakysymykset ja lisättiin aiemmin tilanneraportoinnissa läpi käydyt potilasturvallisuuteen liittyvät kysymykset. Muutokseen ovat tyytyväisiä sekä yksiköt, että asiantuntijat. Muutoksesta on tiedotettu monissa eri foorumeissa. Parhaat epäonnistumiset Henkilön 1 paras epäonnistuminen : Eräässä yrityksessä otettiin käyttöön muutostenhallintaprosessi ja tämän myötä myös muutosraati. Muutosraati koottiin siten että jokaisesta liiketoiminnasta oli edustaja paikalla. Ryhmän kokoonpano epäonnistui siltä osin, että muutostyöt joiden toteutuksesta ryhmä päätti oli puutteellinen: asiakasnäkökulma, asiakasvastuullisten näkökulma ja palveluiden omistajien näkökulma ei tullut muutosraadeissa esiin. Näkökulma oli liian tekninen. Tämä aiheutti turhaa kitkaa yrityksessä tulosvastuullisten palveluiden omistajien ja palvelua tuottavien sisäisten tiimien välillä. Mitä opittiin? Muutosraadin kokoonpano ei ole stabiili, muutosraateja voi olla useita, palvelun ja palvelua käyttävän asiakkaan edustus pitää olla aina mukana päätettäessä riskitasoltaan suurista muutoksista (mm. tiedotuksen takia). Myös turhien muutosten määrä vähenee kun palvelun omistaja(t) ovat tietoisia, kuka ehdotetusta

12 12 muutoksesta hyötyy. Muutosten tarpeellisuuden punnitsemisen näkökulmasta asiaa voi myös miettiä niin päin että,jos muutos ei vaikuta mihinkään asiaan tai palveluun kehittävästi, niin miksi muutos silloin pitäisi toteuttaa? Henkilön 2 paras epäonnistuminen : Keskussairaalassa siirrettiin koko sairaalan osastonsihteerit yhteen ja samaan yksikköön, ennen jokainen sihteeri kuului hallinnollisesti siihen hoitoyksikköön missä istui. Muutoksella haluttiin tavoitella tehokkuutta (sanelujen purku hallintaan), yhteistyön helpottumista ja säästöjä. Tarkoituksena on myös perustaa kirjoituskeskus mihin keskitetään kaikkien yksiköiden saneluiden purku. Muutosta edelsi konsulttien vetämä projekti, jossa mm. kellotettiin yhden klinikkaryhmien sihteerin työtehtävät ja suunniteltiin monia muita kehitystoimenpiteitä. Suunnitelmia tehtiin kauan ja niitä tekemässä oli moniammatillinen ryhmä, jossa paljon edustusta myös sihteereistä. Uusi yksikkö on ollut toiminnassa vuoden alusta asti ja toimii kohtuullisesti mutta epäonnistuminen tässä projektissa on ollut se, että koko hallinnollinen vastuu 160 sihteeristä (sijaiset mukaanlukien) oli yhden palvelupäällikön harteilla. Hänellä oli apunaan palveluesimies, mutta hänellä ei ole vastuuta henkilöstöhallinnosta. Jos yhden ihmisen pitää yksin huolehtia 160 ihmisen lomien, sairaslomien yms hyväksymisestä, rekrytoinneista, lomien ja työlistojen suunnittelusta yms. aikaa ei riitä mihinkään muuhun, eikä normaalin työajan puitteissa edes siihen. Kaikki kehittäminen mikä oli uuden yksikön kohdalla tärkeää, jäi tekemättä. 5. Case esimerkki / Anvia: Visio muutostenhallinnan tavoitetilasta Kun lähdetään tarkastelemaan ja kehittämään yrityksen muutostenhallintaa kokonaisvaltaisesti, on ensimmäisenä tavoitteena luoda henkilöstölle selkeä viesti muutostenhallinnan välttämättömyydestä. Tässä vaiheessa voidaan käyttää apuna ja esimerkkeinä aikaisempia läheltä piti tilanteita. Myös nykyisten tiimien useiden erilaisten toimintatapojen, järjestelmien, muutosten määrän ja kokonaisuuden kompleksisuuden ja relaatioiden esittäminen tuottaa usein henkilöstölle oivalluksen, kuinka monimutkaisesta kokonaisuudesta yrityksessä on muutostenhallinnassa on kyse. Anvian tapauksessa yritys on luonut vision muutostenhallinnan tavoitetilasta, jonka pohjalta Anvia on lähtenyt kehittämään asia, kokonaisuus ja toimintatapamuutos kerrallaan kouluttamaan ja viestimään käytännön muutostenhallinnan parhaita menettelytapoja. Samalla monen henkilön, tiimin ja roolin osalta on jouduttu käymään läpi kyseisten tahojen valtuudet ja velvollisuudet muutosten hallitsemiseksi.

13 13 Muutostenhallinnan määrittelyn, käyttöönoton ja jatkokehityksen aikana monet roolit ja toimintamallit sekä myös puutteet nykyisessä ohjeistuksessa ovat tarkentuneet. Jotta muutostenhallinnan käytännöt saatiin riittävän hyvin tukemaan laadukkaampaa toimintaa, otettiin Anvialla muutostenhallinnan piiriin aluksi vain kriittisimmät tekniset muutospyynnöt, jotka kohdistuivat verkkoihin, palvelimiin ja IT järjestelmiin. Muutostenhallinnan ohjeet ja toimivuus korostuvat varsinkin poikkeavissa oloissa, henkilöstön vaihtumisen tai avainhenkilöiden poissaolojen seurauksena, jolloin muutosten päävastuulliset henkilöt eivät ole käytettävissä ja pakollisista muutoksista vastaa varahenkilö tai kokemattomampi työntekijä. Näiden asioiden hallitsemiseksi Anvia on ottanut/ottamassa käyttöön ITSM/CMDB järjestelmää alkukesästä ITSM lyhenne on sanoista Information Technology Service Management ja CMDB tulee sanoista Configuration Management Database. Järjestelmän avulla voidaan kuvata kokonaisvaltaisesti yrityksen loppukäyttäjäpalveluiden, sisäisten palveluiden, sisäisten järjestelmien, tuotannon komponenttien (CI eli Configuration Item ), asiakkaiden ja asiakassopimusten väliset yhteydet eli relaatiot suhteessa toisiinsa. Järjestelmä mahdollistaa kokonaisvaltaisen muutostenhallinnan, visuaaliset muutoskalenterit, ja muutosten vaikutusten vaikuttavuuden suunnittelun ja tunnistamisen. Muutoskalenteiden avulla kuka tahansa työntekijä voi nähdä päiväkohtaisesti kuinka paljon muutoksia, kenen toimesta ja missä järjestyksessä tuotannossa tehdään. Jotta muutostenhallinta on ylipäänsä mahdollista, on yrityksellä oltava dokumentoituna ja määriteltynä eli palveluiden, tuotteiden ja tuotannon komponenttien (esim. serverit, laitteet, kaapelit, konesalit, sisäiset järjestelmät jne jne) omistajat. Palveluiden ja järjestelmien omistajat hyväksyvät, hylkäävät tai aikatauluttavat eteenpäin muutostenhallintajärjestelmään kirjatut muutosehdotukset. Osalla yrityksiä muutostenhallintaa ohjaa myös viranomaisvaatimukset (mm. teleoperaattoreilta edellytetään muutosten vaikuttavuuden ja toimenpiteiden ennakoitua suunnittelua, mikäli muutos ei onnistu suunnitellusti) ja Suomen lainsäädännön vaatimukset. Myös uudistuva ISO9001:2015 sertifikaatti tulee näillä näkymin lisäämään auditoinnin kohteeksi ja vaatimukseksi että yrityksessä on kuvattuna muutostenhallinta. Muutostenhallintaraati Apuna muutosten hallinnassa käytetään myös CAB:ia (Change Advisory Board) eli neuvoja antavaa (ja joskus myös päätöksiä tekevää) muutosraatia, joka kokoontuu kun tietyntyyppisiä muutospyyntöjä on kertynyt yhteiselle muutosraadille riittävä määrä.

14 14 Muutostyyppien hallinta Muutostenhallinnan käyttöönotto ja toimintatapojen määrittelyä tehtäessä on tärkeätä kategorisoida eri tyyppiset muutokset. Muuten muutostenhallinta kohtaa yrityksessä vastustusta. Tarkoitus ei tietenkään ole estää vähän riskiä sisältävien rutiininomaisten ja usein toistuvien muutosten suorittamista vaan turvata kokonaisuus, jotta asiakkaille usein pakollisista muutoksista ei aiheutuisi sellaista haittaa, joka estää tai vaikeuttaa heille tietyllä tasolla luvatun palvelun toimittamisen. Yrityksen tuleekin täten tunnistaa eri muutostyypit. Jaottelu voi perustua esim. tehtävän muutoksen vaikutukseen liikevaihdossa, siihen koskeeko muutos useita muitakin tuotannon järjestelmiä tai palveluita, muutoksen ajankohtaan (riskitaso on esim. suurempi kun muutos tehdään juuri ennen joululomia tai kiireisintä myyntikautta) tai vaikkapa siihen miten moneen työntekijään muutos tulee vaikuttamaan. Muutospyynnöt Muutospyyntöjen (Request for Change, RFC) tulee olla selkeästi määriteltyjä, rajattuja, testattuja, aikataulutettuja ja toteutettavissa olevia. Muutokset käsitellään määrämuotoisesti ja hyödyntäen prosessia ohjaavaa järjestelmää. Yleinen muutostenhallintaprosessi sisältää seuraavat vaiheet: 1. Muutospyynnön (RFC) luonti, johon kirjataan muutostoimenpiteet, siihen liittyvät kohteet (Configuration Item, CI), arvioitu vaikutus, muutoksen testauksen tulokset sekä palautussuunnitelma 2. Muutosraadin (Change Advisory Board, CAB) arviointi, jonka tehtävä on arvioida muutoksen => Riskit => Tarpeellisuus => Kustannusvaikutukset => Ristikkäisvaikutukset => Aikataulutus Muutosraati koostuu muutospäälliköistä, jotka ovat yleensä palveluiden omistajia tai liiketoimintayksiköiden edustajia. 3. Muutospäätös. Muutosraati (CAB) tekee päätöksen muutospyynnön (RFC) toteuttamisesta tai hylkäämisestä, jonka jälkeen muutokseen liittyvien palveluiden muutospäälliköt vastaavat

15 15 asiakkaiden ja sidosryhmien tiedottamisesta. Tarvittaessa muutospyyntöön pyydetään täydentäviä tietoja palauttamalla muutospyyntö takaisin sen tekijälle. 4. Muutoksen toteutus tai palautus, tehdään muutoksen tekijöiden toimesta. Esim. teknisissä muutoksissa asiantuntijaorganisaatio. Tärkeä osa muutoksen toteutusta on konfiguraatiotietojen (Configuration Management Database, CMDB) kohteiden (CI) sekä muun dokumentaation päivittäminen muutoksen jälkeen. 5. Muutoksen katselmointi, jonka tarkoituksena on käydä läpi tehty muutos ja arvioida käytäntöjen toimivuutta sekä täydentää ohjeistusta virheiden tai korjaamiseksi. Muutospyynnön sulkeminen. Kun kaikki muutokseen liittyvät asiat on käsitelty, muutospyyntö suljetaan muutospäällikön toimesta. 6. Case esimerkki / Asiakastietojärjestelmän kehitysprojekti Yrityksen käytössä oleva asiakastietojärjestelmä oli kehitetty 2000 luvun alkupuolella yhdessä muutaman alan toimijan kanssa. Aikoinaan kehitystarve lähti toimialalla tapahtuneista merkittävistä lainsäädännöllisistä ja rakenteellisista muutoksista. Asiakastietojärjestelmään piti saada merkittävästi enemmän tietoja, sopimustyyppien määrä kasvoi, laskutustapa muuttui, tietoja piti pystyä siirtämään eri järjestelmien välillä ja tarve erityyppisille raporteille kasvoi. Silloin käytössä ollut järjestelmä ei taipunut kyseisiin muutosvaatimuksiin, mistä syystä oli kehitettävä täysin uusi järjestelmä tai ostettava valmis järjestelmä. Koska markkinoilla ei katsottu olevan uusia tarpeita vastaavaa järjestelmää, yhtiössä katsottiin tarpeelliseksi lähteä rakentamaan uutta järjestelmään yhdessä toimialalla toimivien yritysten kanssa. Järjestelmän toimittajaksi valittiin ohjelmistotalo, jolla oli vahva tietotekninen tausta. Toimittaja oli toimittanut lukuisia erilaisia järjestelmiä, mutta ei kyseiselle toimialalle. Tilaajat katsoivat voivansa tarjota itse asiantuntemusta projektiin, joten ohjelmistotalon alan osaamattomuutta ei katsottu niin suureksi riskitekijäksi, että se olisi ollut esteenä ohjelmiston kehittämiselle.

16 16 Projekti toteutettiin ns. vesiputousmallina, jossa kulloinenkin kehityshanke eteni seuraavassa järjestyksessä yhdestä vaiheesta toiseen 1. Järjestelmävaatimukset (System Requirements) 2. Analyysi (Analysis) 3. Suunnittelu (Program Design) 4. Ohjelmointi (Coding) 5. Testaus (Testing) 6. Käyttöönotto (Operations) Kun vaatimusten määrittely oli valmistunut, siirryttiin suunnitteluvaiheeseen, eikä vaatimuksia enää muokattu. Suunnitteluvaiheessa valmistettiin selkeä kartoitus, jota ohjelmoijat sitten noudattivat. Haasteellista oli malli toimii täydellisesti vain silloin kun jokainen vaihe on suunniteltu 100% oikein ja täydellisen kattavasti ennen seuraavaan vaiheeseen siirtymistä. Koska toimiala oli ohjelmistotalolle täysin vieras, oli pienikin väärinkäsitys vaatimusmääritelyssä saattoi olla lopputuloksen kannalta kohtalokas. Vesiputousmallia pidetään huonona lähinnä siksi, että uskotaan olevan mahdotonta suunnitella täydellisesti etukäteen mitään suurempaa ohjelmistoa siten, ettei aiempiin vaiheisiin tarvitsisi palata. Usein ohjelmistotuotannossa asiakas ei osaa tarkasti määritellä omia vaatimuksiaan ennen kuin on päässyt kokeilemaan jollain tasolla toimivaa prototyyppiä. Siten ohjelmistotalon toimialaosaaminen on todella tärkeää. Vaatimusten muuttaminen kesken projektin tarkoittaa suuria kustannusmenetyksiä, koska suunnitteluun ja toteutukseen käytetty aika on mennyt osin hukkaan. Lisäksi projektin edetessä mahdolliset virheet aiemmissa vaiheissa saattavat kertautua valtaviksi ongelmiksi myöhemmissä vaiheissa Vaikka tilaajayhtiöt toimivatkin samalla toimialalla, ollemassa talokohtaisia eroja toimintatavoissa, joista ei haluttu luopua. Määrittelyistuntoihin osallistuminen oli edellytys yhtiökohtaisten tarpeiden mukaan saattamiseksi. Tuotteen testausvaihe oli varsin lyhyt ja se oli ns. käytöönottotestausta. Testausta varten ei oltu laadittu testaussuunnitelmia saatika käyttötapauksia.

17 17 Uusien ominaisuuksien koulutus toteutui uuden ominaisuuden esittelyn yhteydessä. Tuolloin ei ollut käytössä etäkoulutusmahdollisuutta, joten yhtiöt lähettivät rajoitetun määrän koulutettavia ohjelmistotalon omissa tiloissa järjestettäviin koulutuksiin. Projektin tuloksena syntynyt tuote toimi. Laskutus kuitenkin viivästyi usealla kuukaudella, mikä oli suuri haaste tilaajayhtiöille taloudellisesta näkökulmasta. Myös yritysten asiakaspalvelu kuormittui asiakaskontakteista. Konversiossa havaittiin paljon virheitä. Henkilökunnan sitoutumista muutokselle ei parantanut puuttellinen koulutus ja käyttöohjeistus. Lisäksi järjestelmän käytettävyys todettiin huonoksi, koska käyttäjien näkökulma oli jäänyt huomioimatta ohjelmoinnin yhteydessä. Myös muutosten tiedottaminen oli vähäistä. Käyttäjät eivät ymmärtäneet järjestelmän ei tietojen syy yhteyksiä. Käytettävyytttä parannettiin usean vuoden ajan tulipalojen sammuttamisen ohelle. Resursseja kehitystyölle oli tilaajayhtiöissä niukasti. Kehitystyöhön osallistuneet osallistuivat projektipalavereihin oman toimen ohella. Tietojen omistajuus oli määritelty, mutta se ei toteutunut käytännössä. Raportointitarpeet rakennettiin ns.kertymien päälle ja avointa rajapintaa ei ollut. Rajapintoja muihin järjestelmiin rakennettiin järjestelmän käytettävyyden parantamisen jälkeen. Ohjelmiston käyttöiän tullessa umpeen, päätettiin aloittaa uusi kehitysprojekti. Mukana oli kaikki samat tilaajayhtiöt kuin edellisessä projektissa. Projekti päätettiin toteuttaa Scrum menetelmällä. Scrum on projektinhallinnan viitekehys, jota käytetään yleisesti ketterässä ohjelmistokehityksessä. Vaikka Scrum on kehitetty erityisesti ohjelmistoprojektien hallintaan, sitä voidaan soveltaa myös yleisesti projektinhallinnassa. Scrumin on kuvattu tuovan uudenlaisenlähestymistavan tuotekehitykseen, jossa yksi ainoa monitaitoinen ryhmä suorittaa kehitysprosessin alusta loppuun vaiheistuksella, joka on vahvasti lomittunut. Ryhmän toimintaa verrataan rugby joukkueeseen, jossa koko ryhmä pyrkii etenemään yksikkönä ja toimimaan tiiviissä yhteistyössä. Ryhmä on tilanteisiin sopeutuva, nope ja itseohjautuva. Mikäli yrityksen toimintaympäristö on hektinen ja muutosten määrä on suuri Scrum viitekehys tarjoaa ketterämmän muutoksenhallintatavan. Tämä edellyttää yritykseltä selkeää ymmärrystä

18 18 Scrum Master ja Product Owner rooleista sekä yrityksen johdolta vastuun antamista henkilöstölle muutoksenhallinnasta. Onnistuessaan toimintamalli vähentää hierarkiaa ja vähentää byrokratiaa. Asiakastietojärjestelmää päätettiin uusia kahdessa eri vaiheessa. Ensiksi päätettiin keskittyä suorituskyvyltään kriittiseksi todettuun laskutusmoottoriin ja sen rinnalla toimivaan saatavien hallintamoduuliin. Sopimus ja laitemoduuli suunniteltiin otettavan käyttöön II vaiheessa. Järjestelmän tulisi hallitan entistä enemmän dataa ja integraatioiden määrä eri järjestelmiin tulisi mahdollistua. Kehitystyötä jatketaan saman ohjelmistotalon kanssa. Ohjelmisto talolle on kertynyt huomattavasti enemmän alan osaamista. Tilaajayhtiöt tiedostivat resurssoinnin kriittisyyden projekteissa. Esim. projektille on asetettu projektin johto, projektipäällikkö, projektiryhmä. Lisäksi projektissa käytetään eri osa aluiden asiantuntijoita. Projektiin on siis varattu resursseja ja palkattu lisähenkilöstöä. Painopiste on jatkuvalla testauksella. Tuotannosta tuodaan jatkuvasti testiaineistoa. Testausten jälkeen eri osa alueet hyväksytään. Hyväksynnän pohjana toimii osa aluuen vaatimusmäärittely. Testaukset perustuvat ennalta määriteltyihin käyttötapauksiin. Järjestelmän käytettävyys on nostettu etusijalle. Projektilla on jatkuva laadunvalvonta, joka toteutetaan ulkopuolisen toimijan toimesta. 7. Case esimerkki / Uuden toimitilan asiakaspalvelupisteen rakentaminen Viranomaisten ja elinkeinoelämän yhteistyönä on valmistunut hanke Palvelutyöpisteiden turvallisuussuunnittelu ja turvasuojaus (PATUT hanke). Hankkeen tuloksena valmistuneessa oppaassa kuvataan, millä tavoin palveluhenkilöstöön kohdistuvan fyysisen väkivallan käyttöä on mahdollista ehkäistä niin asiakaspalvelutyössä kuin palvelutyöpisteiden asiantuntevan suunnittelun ja turvasuojausratkaisujenkin keinoin. Opas soveltuu yleistietolähteeksi julkisen sektorin ja kaupan työyhteisöille sekä kiinteistö, turvallisuus ja sähköalan asiantuntijoille. Hankkeen tuloksena valmistuivat lisäksi tekniset ohjeet turvasuojauksen suunnittelijoille ja toteuttajille. Turvallisuusalan neuvottelukunnan julkaisema Palvelutyöpisteiden turvallisuussuunnitteluopas löytyy osoitteesta

19 19 Kyseessä olevassa yrityksessä rakennettiin täysin uudet toimitilat. Uusien asiakaspalvelutyöpisteiden suunnittelussa tunnistettiin seuraavat haasteet: käytännöllisyys vastaan arkkitehtien näkemykset, visiot ohjenuorana viranomaisohjeistus, työturvallisuus, henkilöstön viihtyvyys käytettävissä oleva tilan muoto asetti omat mahdollisuutensa/haasteensa yksittäisten henkilöstön jäsenten toivomukset poikkeavat toisistaan (oma työpiste vai avokonttori), työrauha vai turvallisuuden tunne avokonttorissa muutos entiseen palvelupisteeseen merkittävä tarpeet oli tuotava esille jo suunnitteluvaiheessa, ja niistä oli kommunikoitava jatkuvasti eri osa alueiden suunnittelijoille tulee antaa tarvittavat lähtötiedot toiminnan luonteen ymmärtämiseksi sovittujen asioiden dokumentointi, seuranta koko rakennusprojektin ajan kulkureittien eriyttäminen tärkeää (asiakkaat, henkilöstö) tekniikan hyödyntäminen (infonäytöt, jonotusjärjestelmä, kameravalvonta, hälytyslaitteet) asiakasohjeistus selkeää ja yksinkertaisia iso aulatila, vähäinen jonottajien määrä, hiljaisuus, asiakkailla ei suoraa näkyvyyttä palvelupisteisiin, koska tilan muoto ei tätä mahdollista asiakas ei ymmärrä välttämättä, että palvelupisteissä tehdään muutakin kuin odotetaan käyviä asiakkaita. järjestelmät tukemaan sisään tulevan asiakkaan huomaamista (kameravalvonta) kaikissa työpisteissä ei oteta vastaan asiakkaita jonotusjärjestelmä välttämättömyys, saattaa lisätä hämmennystä asiakkaiden taholta uusi tilanne myös asiakkaille, jotka aikaisemmin joutuneet välttämättä jonottamaan tai ottamaan vuoronumeroa, entisessä palvelupisteessä ollut suora näkymä palvelupisteisiin kalusteet teetettävä mittatilaustyönä (esim. pöydän kanteen liitettävä klaffiosa) Haasteiden taklaus: henkilökunnan osallistaminen niin pian kuin mahdollista eri henkilötyyppien tarpeiden huomioiminen o etukäteistutustumiskertoja uusiin toimitiloihin

20 20 jatkuva tiedotus, jokainen tietää pienimmistäkin asioista (esim. kukkien tilaus) o jaettu työpöytä uuden tekniikan testaus, hyödyntäminen turvallisuudentunteen maksimointi asiakastiedottaminen kaikki muutoksia ei voi/syytä tehdä heti o kaikki ei ole myöskään heti valmista (esim. vierastuoleja voi joutua odottamaan) riskien tunnistaminen, asiakasviihtyvyys ensi sijalla o näyttöjen hyödyntäminen, musiikki odotustiloihin, kasvit jatkuva reagoiminen muutostarpeisiin; hötkyilyä vältellen o kyltin paikan siirtämisellä metrin toiseen suuntaan voi suuri vaikutus siihen, että asiakkaat tietävät miten toimia keskustelu/tiedottaminen talon sisällä yhteisistä toimintatavoista o asiakaspalvelu on yhä edelleen ulkoisten asiakkaiden asiakaspalvelu positiivisten asioiden jatkuva esilletuonti 8. Muutoksenhallinnan kypsyystasotesti Alla olevaa testiä (kestää noin 12 minuuttia) ja kysymyksiä voi käyttää hyväksi yrityksen muutostenhallinnan kypsyystason arvioimiseksi. Laske pisteet yhteen. 1. Muutoksenhallinnan vastuualueet on määritelty. (Esim. mitkä muutokset eivät kuulu muutoksenhallintaan) 2. Kaikki muutospyynnöt kirjataan (esim. järjestelmään tai hallintatapa on ainakin sovittu) 3. On olemassa selkeä tapa, jolla muutospyyntöjä tehdään kirjallisesti 4. Muutos avataan ja rekisteröidään aina ennen kuin sitä aletaan käsitellä 5. Jokaisesta muutoksesta ylläpidetään muutostietuetta, josta ilmenee historiatiedot 6. On olemassa menettely, jolla muutospyyntöjä luokitellaan, arvioidaan, hyväksytään ja aikataulutetaan 7. Aikataulutuksessa otetaan huomioon sekä liiketoiminnan että IT:n näkemykset 8. Muutosaikataulu on asianomaisten tahojen käytettävissä (esim. ServiceDesk) 9. Muutoksen vaikutus operatiivisiin järjestelmiin tulkitaan järjestelmällisesti 10. Muutoksenhallinta hyödyntää konfiguraatiotietokantaa muutosta arvioitaessa 11. Muutosten aikataulutus perustuu prioriteetteihin ja riskin huomiointiin 12. Muutoksen kustannukset, vastuut, tarvittavat voimavarat, hyödyt ja riskit arvioidaan. 13. Hätämuutoksille on olemassa oma menettelynsä

21 Jälkikäteen arvioidaan oliko hätämuutoksen syynä todellinen hätätilanne 15. Standardimuutokset (Standard change) on määritelty ja niiden hallinta on annettu asianomaiselle prosessille tai toiminnolle 16. Jokaiselle muutokselle on dokumentoitu muutoksen peruuttamismenettely 17. Sekä tekniset vaikutukset että Iiiketoimintavaikutukset arvioidaan osana prosessia 18. Prosessin osana valvotaan, miten muutos edistyy ja etenee ajassa 19. Jokaiselle muutokselle suoritetaan jälkiarviointi ja kirjataan onko muutos täyttänyt tavoitteensa, missä on onnistuttu ja missä on parannettavaa 20. Jälkiarviointi sisältää arvion liiketoimintatulosten toteutumisesta 21. Muutoksenhallintaprosessi raportoi johdolle muutoksista riittävällä tasolla 22. Prosessi tuottaa raportteja esimerkiksi muutosten lukumäärästä aihepiireittäin, onnistuneiden ja epäonnistuneiden muutosten määrästä ja syistä, myöhästyneiden muutosten määrästä sekä prosessin ohittamisesta 23. Kaikki muutokset suunnitellaan ja priorisoidaan 24. Jos muutos voi aiheuttaa tuotantokatkoksen, asiakkaan on hyväksyttävä muutos ennen sen toteuttamista 25. Muutoksen edistyminen kirjataan osaksi muutostietuetta 26. Jos muutos epäonnistuu, syyt kirjataan ja analysoidaan 27. Hylätytkin muutokset ja syyt hylkäykseen rekisteröidään 28. Muutoksen tilasta raportoidaan muutoksen tilaajalle 29. Muutoksenhallinnan tehtävät on selkeästi määritelty 30. Vastuulliset ovat saaneet riittävää koulutusta tehtäväänsä 31. Johto on asettanut muutoksenhallinnalle selkeitä mitattavissa olevia tavoitteita 32. Muutoksenhallinnalla on käytössään siihen sopivia työkaluja 33. Muutoksenhallinta saa Service Deskiltä tietoa tehtyihin muutoksiin liittyvistä häiriöistä 34. Muutoksenhallinta kommunikoi jatkuvuudenhallintaprosessin kanssa muutosten vaikutuksesta jatkuvuussuunnitelmiin 35. Prosessi pyytää asiakkaalta palautetta ja pitää kirjaa asiakastyytyväisyydestä 36. Muutoksesta toimitetaan tiedot konfiguraatiohallintaan, konfiguraationhallintajärjestelmään (Configuration Management System) päivittämistä varten 37. Muutoksenhallinta koskee muutoksia sovelluksiin, järjestelmiin, prosesseihin, palveluparametreihin, palvelutasosopimuksiin ja näiden perustana oleviin alustoihin 38. Muutoskomitea (Change Advisory Board, CAB) kokoontuu tarvittaessa avustamaan muutosten arvioinnissa 39. Muutoskomitean kokoonpano vaihtelee käsiteltävien muutosten mukaan 40. Prosessin asiakastyytyväisyyttä mitataan järjestelmällisesti

22 22 Kypsyystasot: 0. Muutoksenhallintaprosessia ei ole. Muutoksia voi tehdä ilman valvontaa. Organisaatio ei tunnista muutoshallintaprosessin tarvetta. 1. Johto ymmärtää, että tarvitaan prosessi muutosten hallintaan. Käytännöt vaihtelevat ja on todennäköistä, että luvattomia muutoksia tapahtuu. Muutoksia ei dokumentoida hyvin ja konfiguraatiotiedot ovat epäluotettavia. Virheitä tapahtuu ja tuotantoympäristöön syntyy katkoja, jotka johtuvat huonosta muutostenhallinnasta. 2. Epämuodollinen muutoksenhallintaprosessi on olemassa ja monet muutokset noudattavat sitä. Prosessi on kuitenkin alkeellinen ja virheille altis. Konfiguraatiotiedot ovat joskus epäluotettava. Muutoksia arvioidaan ja suunnitellaan vain rajoitetusti ennen muutosten tekemistä. 3. On olemassa muodollinen muutoksenhallintaprosessi, joka sisältää luokituksen, priorisoinnin ja hätätoimenpiteet. Prosessia noudatetaan hyvin, mutta prosessia myös oikaistaan usein. Luvattomia muutoksia tehdään satunnaisesti. Muutosten vaikutusta Iiiketoimintaa analysoidaan järjestelmällisesti. 4. Muutoksenhallintaprosessi on hyvin kehittynyt ja useimmat muutokset noudattavat prosessia. Prosessi on toimiva ja tehokas, mutta on riippuvainen manuaalisesta laaduntarkkailusta. Kaikkia muutoksia suunnitellaan perusteellisesti. Muutosten hyväksymismenettely on olemassa. Muutosten dokumentointi on ajan tasalla, oikein ja muutoksia valvotaan järjestelmällisesti. Konfiguraatiotiedot ovat pääosin oikein. ITmuutoksenhallinta on osittain integroitu liiketoimintaprosessien muutosten kanssa siten, että koulutus, organisaatio ja jatkuvuusasiat tulevat huomioiduksi. Muutoksenhallintaprosessin suorituskykyä ja laatua mitataan. 5. Muutoksenhallintaprosessia arvioidaan ja päivitetään säännöllisesti parhaiden käytäntöjen mukaisesti. Konfiguraatiotietojen ylläpito on automatisoitu ja sisältää versionhallinnan. Muutosten jäljittäminen on kehittynyttä ja työkaluja käytetään luvattomien ja lisensoimattomien ohjelmistojen paikallistamiseksi. Myös IT muutoksenhallinta on integroitu liiketoimintamuutosten hallinnan kanssa siten, että IT voi aktiivisesti lisätä tuottavuutta ja luoda uusia liiketoimintamahdollisuuksia.

23 23 9. Klubityön hyödynnettävyys Yrityksen suunnitellessa oman organisaationsa muutoksenhallinnan toimintamalleja, työssämme esitellyt esimerkit antavat suuntaa toiminnan ohjeistukselle. Muutosten hallinnan kuvaaminen tulee ajankohtaiseksi kaikille ISO 9001 sertifioiduille yrityksille ja yhteisöille. Klubityö tarjoaa toimintamalleja muutoksenhallintaan. 10. Johtopäätökset Muutosten hallinta ja konfiguraationhallintatyökalu voivat olla käyttökelpoisia muutoksen hallinnassa, mutta ne eivät takaa muutoksen onnistumista, ellei koko organisaatiota saada mukaan muutoksen hallintaan. Hyvin onnistuessaan muutosten hallinta luo yrityksen johdolle hyvän näkyvyyden organisaation toimintaan ja siihen, mitkä muutokset tosiasiallisesti vievät yrityksen palveluita ja tuotteita sekä toimintavarmuutta eteenpäin ja mitkä muutokset voidaan todeta olevan turhia. Markkinoilta löytyy paljon työkaluja muutospyyntöjen ja konfiguraatioiden hallinnan käsittelyyn; ne eivät kuitenkaan takaa onnistumista, ellei yrityksen johto edellytä töiden ja muutosten kirjaamista ja vakiomuotoista toimintatapaa. Myös häiriö ja ongelmatilanteiden näkökulmasta hyvällä muutoksen hallinnalla voidaan nopeuttaa häiriöiden korjausta, koska usein osa yrityksen häiriöistä on itse aiheutettua. Hyvä muutoshistoria toimii tällöin hyvänä apuna häiriön rajaamisessa ja tukena tulevien uusien muutosten suunnittelussa. Tulevan ISO 9001:2015 standardin vaatimukset tulevat edellyttämään organisaatioita arvioimaan muutosten riskejä ja dokumentoimaan muutokset nykyistä järjestelmällisemmin. Klubityöhön kootuissa käytännön esimerkeissä on pyritty tuomaan erilaisia hyviksi koettuja toimintamalleja sekä esimerkkejä epäonnistumisista. Näitä voidaan hyödyntää erilaisissa organisaatioissa valmistauduttaessa uusiin standardien vaatimuksiin.

24 24 Lähteet SFS EN ISO Laadunhallintajärjestelmät. Perusteet ja sanasto. 2. p. Helsinki: Suomen Standardoimisliitto SFS. SFS EN ISO Laadunhallintajärjestelmät. Vaatimukset. 4. p. Helsinki: Suomen Standardoimisliitto SFS. SFS EN ISO Laadunhallintajärjestelmät. Suuntaviivat suorituskyvyn parantamiselle. 2. p. Helsinki: Suomen Standardoimisliitto SFS. SFS EN ISO Laadunhallinta ja/tai ympäristöjärjestelmien auditointiohjeet. 1. p. Helsinki: Suomen Standardoimisliitto SFS. SFS EN ISO Laadunhallintajärjestelmän dokumentointiohjeita. 1. p. Helsinki: Suomen Standardoimisliitto SFS. ISO/DIS 9001:2015 Muutostenhallinnan kypsyystasomittari: Ben Kalland ja Jari Kasslin, Tieturi Oy (lupa kysytty Beniltä ) Työterveyslaitos.fi (2014) Osallistava kehittäminen [online]. [Saatavissa ]: _kehittaminen/sivut/default.aspx Kaj von Weissenberg, Road Show laatubrunssit esitysmateriaali

Quality Consulting M.Mikkola OY Mari.mikkola@qcmm.fi 050-3205088

Quality Consulting M.Mikkola OY Mari.mikkola@qcmm.fi 050-3205088 Quality Consulting M.Mikkola OY Mari.mikkola@qcmm.fi 050-3205088 Laadunhallintajärjestelmän tulisi olla organisaation strateginen päätös ISO9001 tarkoituksena ei ole edellyttää, että kaikilla laadunhallintajärjestelmillä

Lisätiedot

Soft QA. Vaatimusten muutostenhallinta. Ongelma

Soft QA. Vaatimusten muutostenhallinta. Ongelma Vaatimusten muutostenhallinta Ongelma Muutostenhallinta on usein vaatimustenhallinnan Akilleen kantapää. Projektien alkaessa ensimmäiset vaatimukset kootaan ja dokumentoidaan, mutta usein vaatimuksia ei

Lisätiedot

IT Service Desk palvelun käyttöönotto palvelukeskuksissa

IT Service Desk palvelun käyttöönotto palvelukeskuksissa IT Service Desk palvelun käyttöönotto palvelukeskuksissa ValtioExpo 7.5.2009 Antti Karjalainen, Johtaja Hankkeen taustaa Tavoitteena yhden talous- ja henkilöstöhallinnon palvelukeskuksen perustaminen vuonna

Lisätiedot

SFS, 27.11 2014 STANDARDIEHDOTUKSEN ISO/DIS 14001 ESITTELY

SFS, 27.11 2014 STANDARDIEHDOTUKSEN ISO/DIS 14001 ESITTELY SFS, 27.11 2014 STANDARDIEHDOTUKSEN ISO/DIS 14001 ESITTELY Anna-Liisa Koskinen SISÄLTÖ Uusi rakenne Uusia määritelmiä Keskeisistä muutoksista 2 ISO 14001 ympäristöjohtamisjärjestelmä ISO 14001 on tunnettu

Lisätiedot

Yrityskohtaiset LEAN-valmennukset

Yrityskohtaiset LEAN-valmennukset Yrityskohtaiset LEAN-valmennukset Lean ajattelu: Kaikki valmennuksemme perustuvat ajatukseen: yhdessä tekeminen ja tekemällä oppiminen. Yhdessä tekeminen vahvistaa keskinäistä luottamusta luo positiivisen

Lisätiedot

ABB Drives and Controls, 26.05.2015 Koneenrakentajan ja laitetoimittajan yhteistoiminta toiminnallisen turvallisuuden varmistamisessa

ABB Drives and Controls, 26.05.2015 Koneenrakentajan ja laitetoimittajan yhteistoiminta toiminnallisen turvallisuuden varmistamisessa ABB Drives and Controls, 26.05.2015 Koneenrakentajan ja laitetoimittajan yhteistoiminta toiminnallisen turvallisuuden varmistamisessa Sisältö 1. Koneenrakentajan haasteita koneiden turvallistamisessa 2.

Lisätiedot

EN 16555 -sarja Innovaatiojohtaminen yksi uusi työkalu

EN 16555 -sarja Innovaatiojohtaminen yksi uusi työkalu klo 15.45-16.15 EN 16555 -sarja Innovaatiojohtaminen yksi uusi työkalu Tekn.lis. Jarmo Hallikas, Falcon Leader Oy 2 Innovaatiojohtamisen standardi CEN/TS 16555 Osa 1: Innovaatioiden hallintajärjestelmä

Lisätiedot

Tietoturvapolitiikka

Tietoturvapolitiikka Valtiokonttori Ohje 1 (6) Tietoturvapolitiikka Valtion IT -palvelukeskus Valtiokonttori Ohje 2 (6) Sisällysluettelo 1 Johdanto... 3 2 Tietoturvallisuuden kattavuus ja rajaus Valtion IT-palvelukeskuksessa...

Lisätiedot

Fujitsu SPICE Lite. Kimmo Vaikkola Fujitsu Finland Oy Laatu ja liiketoimintatavat. Copyright 2010 FUJITSU

Fujitsu SPICE Lite. Kimmo Vaikkola Fujitsu Finland Oy Laatu ja liiketoimintatavat. Copyright 2010 FUJITSU Fujitsu SPICE Lite Kimmo Vaikkola Fujitsu Finland Oy Laatu ja liiketoimintatavat Copyright 2010 FUJITSU Laatu ja prosessit Fujitsussa Laatujärjestelmän rakentaminen ja systemaattinen prosessijohtaminen

Lisätiedot

Tapahtuipa Testaajalle...

Tapahtuipa Testaajalle... Tapahtuipa Testaajalle... - eli testaus tosielämässä 09.10.2007 Juhani Snellman Qentinel Oy 2007 Agenda Minä ja mistä tulen Testauksen konteksti Tapauksia tosielämästä ja työkaluja 2 Minä Juhani Snellman

Lisätiedot

Miten kerätä tietoa toiminnan jatkuvaan kehittämiseen

Miten kerätä tietoa toiminnan jatkuvaan kehittämiseen Miten kerätä tietoa toiminnan jatkuvaan kehittämiseen Tuija Sinervo FINAS - akkreditointipalvelu Mitä kehitetään? Asiakaspalvelua Osaamista Toiminnan sujuvuutta, tehokkuutta Tekniikkaa, toimintaympäristöä

Lisätiedot

Project-TOP QUALITY GATE

Project-TOP QUALITY GATE Project-TOP QUALITY GATE FOR SUCCESSFUL COMPANIES TYÖKALU ERP- JÄRJESTELMIEN TESTAUKSEEN PROJECT-TOP QUALITY GATE Quality Gate on työkalu ERP-järjestelmien testaukseen Huonosti testattu ERP- järjestelmä

Lisätiedot

IT-ERP Tietohallinnon toiminnanohjausratkaisuna. ja ITIL palveluiden kehittämisessä

IT-ERP Tietohallinnon toiminnanohjausratkaisuna. ja ITIL palveluiden kehittämisessä IT-ERP Tietohallinnon toiminnanohjausratkaisuna ja ITIL palveluiden kehittämisessä Case PRH Timo Junnonen Esityksen sisältö: 1. Patentti- ja rekisterihallitus (PRH) 2. PRH tietohallinto (PIT projekti)

Lisätiedot

LIITE 5. Vaaratapahtumajoukon tarkastelua ohjaavat kysymykset

LIITE 5. Vaaratapahtumajoukon tarkastelua ohjaavat kysymykset 67 (75). Vaaratapahtumajoukon tarkastelua ohjaavat kysymykset A. Kysymykset ilmoittavan yksikön (osaston) tasolla tapahtuvaan tarkasteluun YKSIKÖN VAARATAPAHTUMAT Mitä ilmoitetut vaaratapahtumat meille

Lisätiedot

Orientaatio ICT-alaan. Projekti

Orientaatio ICT-alaan. Projekti Orientaatio ICT-alaan Projekti Projekti Ajallisesti rajoitettu, kertaluonteinen tehtävä määrätyt resurssit sekä oma (linjaorganisaatiosta poikkeava) organisaatio Toteutus tapahtuu suunnitelmallisesti ennalta

Lisätiedot

Turvallisuuden ja toimintavarmuuden hallinta tieliikenteen kuljetusyrityksissä. Anne Silla ja Juha Luoma VTT

Turvallisuuden ja toimintavarmuuden hallinta tieliikenteen kuljetusyrityksissä. Anne Silla ja Juha Luoma VTT Turvallisuuden ja toimintavarmuuden hallinta tieliikenteen kuljetusyrityksissä Anne Silla ja Juha Luoma VTT Click to edit Master Tutkimuksen title style tavoitteet Click Selvittää to edit toimintatapoja

Lisätiedot

Tietoturva- ja tietosuojariskien hallinta tietojärjestelmäkilpailutuksessa

Tietoturva- ja tietosuojariskien hallinta tietojärjestelmäkilpailutuksessa Tietoturva- ja tietosuojariskien hallinta tietojärjestelmäkilpailutuksessa 13.05.2015 Terveydenhuollon ATK-päivät Tampere-talo Yleistä Riskienhallintaan löytyy viitekehyksiä/standardeja kuten ISO 31000

Lisätiedot

TARKASTUSMENETTELYT JA NIIDEN APUVÄLINETUKI

TARKASTUSMENETTELYT JA NIIDEN APUVÄLINETUKI TARKASTUSMENETTELYT JA NIIDEN APUVÄLINETUKI Vesa Tenhunen Tarkastusmenettelyt Keino etsiä puutteita ohjelmakoodeista, dokumenteista ym. ohjelmistoprosessissa syntyvästä materiaalista Voidaan käyttää kaikissa

Lisätiedot

Merlin Systems Oy. Kommunikaatiokartoitus päätöksenteon pohjaksi. Riku Pyrrö, Merlin Systems Oy 8.11.2007

Merlin Systems Oy. Kommunikaatiokartoitus päätöksenteon pohjaksi. Riku Pyrrö, Merlin Systems Oy 8.11.2007 Merlin Systems Oy Kommunikaatiokartoitus päätöksenteon pohjaksi Riku Pyrrö, Merlin Systems Oy 8.11.2007 Merlinin palvelujen toimittaminen ja Asiakasratkaisuyksikön tehtäväkenttä Merlin Asiakasratkaisut

Lisätiedot

HP OpenView ratkaisut toiminnan jatkuvuuden turvaajina

HP OpenView ratkaisut toiminnan jatkuvuuden turvaajina HP OpenView ratkaisut toiminnan jatkuvuuden turvaajina - Käytännön esimerkkejä ITIL ja ITSM mukaisista IT palveluhallinnan toteutuksista ja mahdollisuuksista Ville Koskinen Sales Specialist, HP Software

Lisätiedot

Ohjelmiston testaus ja laatu. Ohjelmistotekniikka elinkaarimallit

Ohjelmiston testaus ja laatu. Ohjelmistotekniikka elinkaarimallit Ohjelmiston testaus ja laatu Ohjelmistotekniikka elinkaarimallit Vesiputousmalli - 1 Esitutkimus Määrittely mikä on ongelma, onko valmista ratkaisua, kustannukset, reunaehdot millainen järjestelmä täyttää

Lisätiedot

Palvelunhallinta monitoimittajaympäristössä Sami Merovuo, Service Manager, HiQ Finland Oy sami.merovuo@hiq.fi, +358 45 133 5883

Palvelunhallinta monitoimittajaympäristössä Sami Merovuo, Service Manager, HiQ Finland Oy sami.merovuo@hiq.fi, +358 45 133 5883 itsmf Finland Conference 2013 TOP10 The Sounds of IT Service Management Palvelunhallinta monitoimittajaympäristössä Sami Merovuo, Service Manager, HiQ Finland Oy sami.merovuo@hiq.fi, +358 45 133 5883 #monitoimittajaympäristö

Lisätiedot

Henkilöstösuunnittelu: mitä, miksi, miten

Henkilöstösuunnittelu: mitä, miksi, miten Henkilöstösuunnittelu: mitä, miksi, miten Henkilöstösuunnittelu tulevaisuuden toiminnan suuntaajana - teema-aamupäivä Juha Eskelinen, KTT Melkior Oy 23.9.2015 Viestit 2 Haasteina kiristynyt talous, teknologiamurros,

Lisätiedot

Avoimen ja yhteisen rajapinnan hallintasuunnitelma v.1.4

Avoimen ja yhteisen rajapinnan hallintasuunnitelma v.1.4 Avoimen ja yhteisen rajapinnan hallintasuunnitelma v.1.4 Tämän esityksen sisältö tausta avoimet toimittajakohtaiset rajapinnat (toimittajan hallitsemat rajapinnat) avoimet yhteiset rajapinnat (tilaajan

Lisätiedot

Ohjelmistotekniikka kevät 2003 Laatujärjestelmät

Ohjelmistotekniikka kevät 2003 Laatujärjestelmät Laatujärjestelmät Ohjelmistotekniikka kevät 2003 Prosessiajattelu Sisään Prosessi Ulos ohjaus mittaus Laatujärjestelmät Laatujärjestelmät määrittelevät sen, mitkä prosessit täytyy olla määritelty ei sitä,

Lisätiedot

Tutkittua tietoa. Tutkittua tietoa 1

Tutkittua tietoa. Tutkittua tietoa 1 Tutkittua tietoa T. Dybå, T. Dingsøyr: Empirical Studies of Agile Software Development : A Systematic Review. Information and Software Technology 50, 2008, 833-859. J.E. Hannay, T. Dybå, E. Arisholm, D.I.K.

Lisätiedot

Laboratorion näkökulma muuttuvaan standardiin 15189: 2012 mikä muuttuu?

Laboratorion näkökulma muuttuvaan standardiin 15189: 2012 mikä muuttuu? Laboratorion näkökulma muuttuvaan standardiin 15189: 2012 mikä muuttuu? Laatupäällikkö Anna-Maija Haapala osastonylilääkäri, dosentti Fimlab Laboratoriot Oy STANDARDI 15189 (2012) Suomennos standardista

Lisätiedot

Avoimen ja yhteisen rajapinnan hallintamalli

Avoimen ja yhteisen rajapinnan hallintamalli Avoimen ja yhteisen rajapinnan hallintamalli 1.10.2015 Sisältö tausta avoimet toimittajakohtaiset rajapinnat (toimittajan hallitsemat rajapinnat) avoimet yhteiset rajapinnat (tilaajan hallitsemat rajapinnat)

Lisätiedot

Mikä on avoimen tuotteen hallintamalli perustiedot ja taustoitus. Jukka Kääriäinen, Tapio Matinmikko, Raija Kuusela 22.4.2015 Jukka.kaariainen@vtt.

Mikä on avoimen tuotteen hallintamalli perustiedot ja taustoitus. Jukka Kääriäinen, Tapio Matinmikko, Raija Kuusela 22.4.2015 Jukka.kaariainen@vtt. Mikä on avoimen tuotteen hallintamalli perustiedot ja taustoitus Jukka Kääriäinen, Tapio Matinmikko, Raija Kuusela 22.4.2015 Jukka.kaariainen@vtt.fi Avoimen tuotteenhallinta Esityksen sisältö Mitä on tuotteenhallinta?

Lisätiedot

Miten varmistaa laboratoriotoiminnan hyvä laatu nyt ja tulevaisuudessa. Tuija Sinervo FINAS akkreditointipalvelu

Miten varmistaa laboratoriotoiminnan hyvä laatu nyt ja tulevaisuudessa. Tuija Sinervo FINAS akkreditointipalvelu Miten varmistaa laboratoriotoiminnan hyvä laatu nyt ja tulevaisuudessa Tuija Sinervo FINAS akkreditointipalvelu Hyvä laatu Laboratorion menestystekijät Laboratorion hyvä laatu perustuu asiakkaiden tarpeiden

Lisätiedot

Scrumjatkuvan palvelun DWprojektissa-case. Niina Mäkiranta & OP-scrum-tiimi Aureolis Oy

Scrumjatkuvan palvelun DWprojektissa-case. Niina Mäkiranta & OP-scrum-tiimi Aureolis Oy Scrumjatkuvan palvelun DWprojektissa-case OP-Pohjola Niina Mäkiranta & OP-scrum-tiimi Aureolis Oy Agenda Scrum lyhyesti Jatkuvan palvelun DW-projekti- Case OP-Pohjola Lähtötilanne ennen Scrumia Scrumin

Lisätiedot

Avoimen ohjelmistotuotteen hallinta julkisella sektorilla. Jukka Kääriäinen VTT Oy , Oskari-verkostopäivä

Avoimen ohjelmistotuotteen hallinta julkisella sektorilla. Jukka Kääriäinen VTT Oy , Oskari-verkostopäivä Avoimen ohjelmistotuotteen hallinta julkisella sektorilla Jukka Kääriäinen (jukka.kaariainen@vtt.fi) VTT Oy 19.5.2015, Oskari-verkostopäivä Esityksen sisältö Mitä on tuotteenhallinta? Mikä on avoimen tuotteenhallintamalli?

Lisätiedot

Integrated Management System. www.ims.fi, Ossi Ritola

Integrated Management System. www.ims.fi, Ossi Ritola Integrated Management System www.ims.fi, Ossi Ritola Mitä prosessien tunnistaminen on? Löydämme ja ryhmittelemme organisaation toistettavat työnkulut optimaalisimmalla tavalla organisaation tulevaisuuden

Lisätiedot

Testaaminen ohjelmiston kehitysprosessin aikana

Testaaminen ohjelmiston kehitysprosessin aikana Testaaminen ohjelmiston kehitysprosessin aikana 04.02.2004 http://cs.joensuu.fi/tsoft/ Sisällys 1. Johdanto 2. Yksikkö- ja integrointitestaus 3. Järjestelmätestaus 4. Hyväksymistestaus http://cs.joensuu.fi/tsoft/

Lisätiedot

LUC Service Desk. Käyttöönottoprojektin taustat ja kokemukset Sakari Tarvainen

LUC Service Desk. Käyttöönottoprojektin taustat ja kokemukset Sakari Tarvainen LUC Service Desk Käyttöönottoprojektin taustat ja kokemukset Sakari Tarvainen Taustaa IT-palvelut ovat osa konsernin tukipalvelukeskusta IT-henkilöstöä noin 70 IT-palveluja tarjotaan seuraaville asiakkaille

Lisätiedot

Miten löydän Sen Oikean? 22.11.2012 Senaattoritilaisuus Liisa Paasiala, Senior Consultant

Miten löydän Sen Oikean? 22.11.2012 Senaattoritilaisuus Liisa Paasiala, Senior Consultant Miten löydän Sen Oikean? 22.11.2012 Senaattoritilaisuus Liisa Paasiala, Senior Consultant On mahdollista löytää Se Oikea! Luotanko sattumaan? Onnistuminen on aloitettava heti Onnistumisen kaava on 4 x

Lisätiedot

Pyhä ITIL - mikä toimii ja mikä ei. Aale Roos www.pohjoisviitta.fi @aalem

Pyhä ITIL - mikä toimii ja mikä ei. Aale Roos www.pohjoisviitta.fi @aalem Pyhä ITIL - mikä toimii ja mikä ei Aale Roos www.pohjoisviitta.fi @aalem ITILIN lyhyt historia 1980 luku brittiläinen julkishallinto sisäinen => mainframe => luokkayhteiskunta => byrokratia => ei asiakkuuksia

Lisätiedot

Ajoneuvolainsäädäntö 2011 Tuotannon vaatimustenmukaisuuden valvonta (HAP) Jarmo Hirvonen Trafi. Vastuullinen liikenne. Yhteinen asia.

Ajoneuvolainsäädäntö 2011 Tuotannon vaatimustenmukaisuuden valvonta (HAP) Jarmo Hirvonen Trafi. Vastuullinen liikenne. Yhteinen asia. Ajoneuvolainsäädäntö 2011 Tuotannon vaatimustenmukaisuuden valvonta (HAP) Jarmo Hirvonen Trafi Vastuullinen liikenne. Yhteinen asia. Näkökulma Esityksen näkökulma lähes puhtaasti viranomaisnäkökulma, viranomaisvaatimukset

Lisätiedot

Manner-Suomen maaseudun kehittämisohjelma 2007-2013

Manner-Suomen maaseudun kehittämisohjelma 2007-2013 Manner-Suomen maaseudun kehittämisohjelma 2007-2013 Ohjelman hallinto, verkostoituminen ja viestintä Reijo Keränen 22.1.2013 Aluksi Esitys keskittyy ohjelman hallintoon ml. verkostot ja viestintä Taustalla

Lisätiedot

Arviointiraportti. Patenttitoimisto Jaakko Väisänen

Arviointiraportti. Patenttitoimisto Jaakko Väisänen 2016-06-16 1 (5) Arviointiraportti Patenttitoimisto Jaakko Väisänen 14. - 16.6.2016 Raportti nspecta Sertifiointi Oy Visiting address CN: 1065745-2 Group headquarters: nspecta Group Oy, Helsinki, 2016-06-16

Lisätiedot

Käytännön laatua matkailuyrityksiin. Petkeljärvi 1.10.2009

Käytännön laatua matkailuyrityksiin. Petkeljärvi 1.10.2009 Käytännön laatua matkailuyrityksiin Petkeljärvi 1.10.2009 Mitä laatu on? Kokonaisvaltainen johtamismalli, joka kattaa kaikki yrityksen toiminnot strategisesta suunnittelusta asiakaspalveluun. 80 % systematiikkaa

Lisätiedot

Testauksen tuki nopealle tuotekehitykselle. Antti Jääskeläinen Matti Vuori

Testauksen tuki nopealle tuotekehitykselle. Antti Jääskeläinen Matti Vuori Testauksen tuki nopealle tuotekehitykselle Antti Jääskeläinen Matti Vuori Mitä on nopeus? 11.11.2014 2 Jatkuva nopeus Läpäisyaste, throughput Saadaan valmiiksi tasaiseen, nopeaan tahtiin uusia tuotteita

Lisätiedot

Onnistunut SAP-projekti laadunvarmistuksen keinoin

Onnistunut SAP-projekti laadunvarmistuksen keinoin Onnistunut SAP-projekti laadunvarmistuksen keinoin 07.10.2010 Patrick Qvick Sisällys 1. Qentinel 2. Laadukas ohjelmisto täyttää sille asetetut tarpeet 3. SAP -projektin kriittisiä menestystekijöitä 4.

Lisätiedot

Scrum is Not Enough. Scrum ei riitä. Ari Tanninen & Marko Taipale. Nääsvillen oliopäivä 2009 Tampereen teknillinen yliopisto 9.12.

Scrum is Not Enough. Scrum ei riitä. Ari Tanninen & Marko Taipale. Nääsvillen oliopäivä 2009 Tampereen teknillinen yliopisto 9.12. Scrum is Not Enough Scrum ei riitä Ari Tanninen & Marko Taipale Nääsvillen oliopäivä 2009 Tampereen teknillinen yliopisto 9.12.2009 Ari Tanninen Vanhempi ohjelmistoinsinööri Marko Taipale Teknologiajohtaja,

Lisätiedot

TIETOTILINPÄÄTÖS. Ylitarkastaja Arto Ylipartanen/ Tietosuojavaltuutetun toimisto. Terveydenhuollon ATK-päivät 20.5.2014; Jyväskylä

TIETOTILINPÄÄTÖS. Ylitarkastaja Arto Ylipartanen/ Tietosuojavaltuutetun toimisto. Terveydenhuollon ATK-päivät 20.5.2014; Jyväskylä TIETOTILINPÄÄTÖS Ylitarkastaja Arto Ylipartanen/ Tietosuojavaltuutetun toimisto Terveydenhuollon ATK-päivät 20.5.2014; Jyväskylä 20.5.2014 TSV:n tsto/ylitarkastaja Arto Ylipartanen 2 LUENNON AIHEET 1.

Lisätiedot

Yhteenveto tuotteenhallinnan tiimoilta kertyneistä opeista. Jukka Kääriäinen Jukka.kaariainen@vtt.fi 22.4.2015

Yhteenveto tuotteenhallinnan tiimoilta kertyneistä opeista. Jukka Kääriäinen Jukka.kaariainen@vtt.fi 22.4.2015 Yhteenveto tuotteenhallinnan tiimoilta kertyneistä opeista Jukka Kääriäinen Jukka.kaariainen@vtt.fi 22.4.2015 Sisältö Mistä tietoja koottu? Opit Yhteenveto Mistä tietoja koottu? Nämä tiedot on kerätty

Lisätiedot

Sopimuksiin perustuva toiminnan jatkuvuuden hallinta

Sopimuksiin perustuva toiminnan jatkuvuuden hallinta Sopimuksiin perustuva toiminnan jatkuvuuden hallinta Haasteena verkoston toimintavarmuuden kehittäminen Ohjaus heikkenee Häiriö toimijan toiminnassa vaikuttaa verkoston toiminnan jatkuvuuteen 2 Vaatimuksia

Lisätiedot

Laadunvarmistuksen merkitys toimitusketjussa. Fingrid: Omaisuuden hallinnan teemapäivä. Kaj von Weissenberg

Laadunvarmistuksen merkitys toimitusketjussa. Fingrid: Omaisuuden hallinnan teemapäivä. Kaj von Weissenberg Laadunvarmistuksen merkitys toimitusketjussa Fingrid: Omaisuuden hallinnan teemapäivä Kaj von Weissenberg 19.5.2016 1 Lisää Inspectasta Luomme turvallisuutta, luotettavuutta ja kestävää kehitystä Pohjois-Euroopassa

Lisätiedot

Markkinatutkimus tilasuunnittelupalveluiden potentiaalisille asiakkaille

Markkinatutkimus tilasuunnittelupalveluiden potentiaalisille asiakkaille Markkinatutkimus tilasuunnittelupalveluiden potentiaalisille asiakkaille Tausta ja menetelmät Toteutimme markkinatutkimuksen tilasuunnittelupalveluiden potentiaalisille asiakkaille maaliskuussa 2013 Kyselyn

Lisätiedot

Mobiilit ratkaisut yrityksesi seurannan ja mittaamisen tarpeisiin. Jos et voi mitata, et voi johtaa!

Mobiilit ratkaisut yrityksesi seurannan ja mittaamisen tarpeisiin. Jos et voi mitata, et voi johtaa! Mobiilit ratkaisut yrityksesi seurannan ja mittaamisen tarpeisiin Jos et voi mitata, et voi johtaa! Ceriffi Oy:n seuranta- ja mittauspalveluiden missio Ceriffi Oy:n henkilöstö on ollut rakentamassa johtamis-,

Lisätiedot

Monikäyttöinen, notkea CAF - mihin kaikkeen se taipuukaan?

Monikäyttöinen, notkea CAF - mihin kaikkeen se taipuukaan? Monikäyttöinen, notkea CAF - mihin kaikkeen se taipuukaan? Raila Oksanen 1.9.2016 Page 1 Monikäyttöisyyden lähtökohta CAF on tarkoitettu helppokäyttöiseksi työkaluksi julkisen sektorin organisaatioiden

Lisätiedot

Sosiaalihuollon asiakastietomallin hallinta

Sosiaalihuollon asiakastietomallin hallinta Sosiaalihuollon asiakastietomallin hallinta Jarmo Kärki & Erja Ailio 24.6.2014 Asiakastietomallin hallinta / Kärki & Ailio 1 Esityksen sisältö Millainen ylläpidon ja kehittämisen rakenne on sosiaalihuollon

Lisätiedot

27.8.2015. Turvallisuuden kehittäminen ja vaaratapahtumien raportointiprosessi Marina Kinnunen KTT, Hallintoylihoitaja

27.8.2015. Turvallisuuden kehittäminen ja vaaratapahtumien raportointiprosessi Marina Kinnunen KTT, Hallintoylihoitaja 27.8.2015 Turvallisuuden kehittäminen ja vaaratapahtumien raportointiprosessi Marina Kinnunen KTT, Hallintoylihoitaja SISÄLTÖ Turvallisuuden kehittäminen Määritelmä, tarve ja periaatteet Suunnitelmallisuus

Lisätiedot

Kieku tuki ja ylläpito

Kieku tuki ja ylläpito Kieku tuki ja ylläpito Kiekun tuen ja ylläpidon toimintamalli Kieku-infotilaisuus Mitä tuki ja ylläpito on? Käyttäjätukea Sovellusylläpitoa Järjestelmän toimivuuden valvontaa ja reagointia ongelmatilanteisiin

Lisätiedot

Miten kuvaat ja kehität organisaation kokonaisarkkitehtuuria?

Miten kuvaat ja kehität organisaation kokonaisarkkitehtuuria? Miten kuvaat ja kehität organisaation kokonaisarkkitehtuuria? Kuntamarkkinat Tietoisku 10. ja 11.9.2014 1 Mitä on kokonaisarkkitehtuuri? Kokonaisarkkitehtuuri on organisaation johtamis- ja kehittämismenetelmä,

Lisätiedot

Susanna Syrjänen, Tiimiesimies Jaakko Marin, Service Consultant

Susanna Syrjänen, Tiimiesimies Jaakko Marin, Service Consultant Susanna Syrjänen, Tiimiesimies Jaakko Marin, Service Consultant Keravan kaupungin tietotekniikan palvelukeskus Henkilöstö: noin 30 hlö Asiakkaat: Järvenpään, Keravan ja Mäntsälän kunnat Työasemia: noin

Lisätiedot

Aikuisopiskelijan viikko - Viitekehys alueellisten verkostojen yhteistyöhön

Aikuisopiskelijan viikko - Viitekehys alueellisten verkostojen yhteistyöhön Aikuisopiskelijan viikko - Viitekehys alueellisten verkostojen yhteistyöhön Aikuisopiskelijan viikko tarjoaa mainion tilaisuuden toteuttaa tapahtumia yhteistyössä oman alueen eri organisaatioiden kanssa.

Lisätiedot

Reilun Pelin työkalupakki: Kiireen vähentäminen

Reilun Pelin työkalupakki: Kiireen vähentäminen Reilun Pelin työkalupakki: Kiireen vähentäminen Tavoitteet Tämän toimintamallin avulla opit määrittelemään kiireen. Työyhteisösi oppii tunnistamaan toistuvan, kuormittavan kiireen sekä etsimään sen syitä

Lisätiedot

Palvelukatalogi liiketoiminnan tukena

Palvelukatalogi liiketoiminnan tukena Palvelukatalogi liiketoiminnan tukena itsmf risteily 10.2.2011, Eija Hallikainen DataCenter Finland Oy:n palvelutarjooma Korkean käytettävyyden energiatehokkaat konesalipalvelut Laadukkaat etä- ja lähitukipalvelut,

Lisätiedot

Mikkelin sähköisen asioinnin alusta - päätöksenteko. Kalle Launiala / ProtonIT Oy kalle.launiala@protonit.net +358 44 5575665

Mikkelin sähköisen asioinnin alusta - päätöksenteko. Kalle Launiala / ProtonIT Oy kalle.launiala@protonit.net +358 44 5575665 Mikkelin sähköisen asioinnin alusta - päätöksenteko Kalle Launiala / ProtonIT Oy kalle.launiala@protonit.net +358 44 5575665 Esityksen osat Hankemallista jatkuvaan ylläpitoon Etenemisehdotus sidosryhmien

Lisätiedot

QL Excellence -käsikirja

QL Excellence -käsikirja QL Excellence -käsikirja QL Laatutoiminta Oy:n laadunhallinta 2010 Sisällysluettelo: QL Excellence -käsikirja...3 Yleiskuvaus... 3 Laatupolitiikka...3 Laatukäsikirja...3 Laadunhallintajärjestelmän kuvaus...

Lisätiedot

TYÖHYVINVOINNIN OHJAUSJÄRJESTELMÄN KEHITTÄMINEN

TYÖHYVINVOINNIN OHJAUSJÄRJESTELMÄN KEHITTÄMINEN PUUSTELLI GROUP OY LOPPURAPORTTI TYÖHYVINVOINNIN OHJAUSJÄRJESTELMÄN KEHITTÄMINEN Laatija: Timo Hemmilä, Hemcon Oy Päiväys: Luottamuksellisuus: julkinen Hyväksynyt: Tarmo Vesimäki, Puustelli Group Oy Projektin

Lisätiedot

LUC-palvelupiste. Käyttöönoton vaiheet ja tulevaisuuden tavoitteet Sakari Tarvainen

LUC-palvelupiste. Käyttöönoton vaiheet ja tulevaisuuden tavoitteet Sakari Tarvainen LUC-palvelupiste Käyttöönoton vaiheet ja tulevaisuuden tavoitteet Sakari Tarvainen Taustat - Konsernin strategiasta (2009) löytyy toiminta-ajatus Palvelut tuotettava pääosin yhdessä - Yhdeksi kehityskohteeksi

Lisätiedot

Koulutuksen nimi Koulutuksen kuvaus Tavoite Esitiedot Alkaa Päättyy Viim.ilm.päivä

Koulutuksen nimi Koulutuksen kuvaus Tavoite Esitiedot Alkaa Päättyy Viim.ilm.päivä Tulevat ITIL Service Design (jatkokoulutus) paikka Jyväskylän yliopisto, Agora (Mattilanniemi 2) agb301 tausta ja tavoitteet ITIL on globaalisti hyödynnetty, ITalan parhaista käytännöistä

Lisätiedot

Kokemuksia projektimallin misestä sprinttimallilla. Jani Lehtinen Tulosyksikön johtaja, Sovelluspalvelut Solteq Oyj 12.8.2009

Kokemuksia projektimallin misestä sprinttimallilla. Jani Lehtinen Tulosyksikön johtaja, Sovelluspalvelut Solteq Oyj 12.8.2009 Kokemuksia projektimallin kehittämisest misestä sprinttimallilla Jani Lehtinen Tulosyksikön johtaja, Sovelluspalvelut Solteq Oyj 12.8.2009 Solteq Oyj Solteq on ohjelmistopalveluyhtiö, joka tukee asiakkaidensa

Lisätiedot

Testausdokumentti. Kivireki. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Testausdokumentti. Kivireki. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Testausdokumentti Kivireki Helsinki 17.12.2007 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Anu Kontio Ilmari

Lisätiedot

Hyvän johtamisen kriteerit julkiselle sektorille: Hyvällä johtamisella hyvään työelämään

Hyvän johtamisen kriteerit julkiselle sektorille: Hyvällä johtamisella hyvään työelämään Hyvän johtamisen kriteerit julkiselle sektorille: Hyvällä johtamisella hyvään työelämään 8.5.2014 MARJUKKA LAINE, TYÖTERVEYSLAITOS 0 Verkoston lähtökohta ja tehtävät Hallitusohjelma 2011: Perustetaan Työterveyslaitoksen

Lisätiedot

Ohjelmistoprosessit ja ohjelmistojen laatu Kevät Ohjelmistoprosessit ja ohjelmistojen laatu. Projektinhallinnan laadunvarmistus

Ohjelmistoprosessit ja ohjelmistojen laatu Kevät Ohjelmistoprosessit ja ohjelmistojen laatu. Projektinhallinnan laadunvarmistus LAADUNVARMISTUS 135 Projektinhallinnan laadunvarmistus Projektinhallinnan laadunvarmistus tukee ohjelmistoprojektien ohjaus- ja ylläpitotehtäviä. Projektinhallinnan laadunvarmistustehtäviin kuuluvat seuraavat:

Lisätiedot

KOODAAKO PROJEKTIPÄÄLLIKKÖ?

KOODAAKO PROJEKTIPÄÄLLIKKÖ? KOODAAKO PROJEKTIPÄÄLLIKKÖ? - ROOLIODOTUKSET KETTERISSÄ OHJELMISTOPROJEKTEISSA Mikko Viskari Development Manager Ohjelmistoprojektikokemusta vuodesta 2005 Teknisen projektipäällikön roolissa vuodesta 2011

Lisätiedot

2. päivä. Etätehtävien purku Poikkeamat. Poikkeamat Auditoinnin raportointi Hyvän auditoijan ominaisuudet Harjoituksia

2. päivä. Etätehtävien purku Poikkeamat. Poikkeamat Auditoinnin raportointi Hyvän auditoijan ominaisuudet Harjoituksia OAMK / Luova 4.5. ja 11.5. Sisäinen auditointi osa Oamkin ympäristöohjelmatyötä Sisältö 1. päivä Johdanto Auditoinnin tavoitteet Ympäristöstandardin (ISO 14001) pääkohdat Alustava ympäristökatselmus Auditoinnin

Lisätiedot

Riskienhallinta- ja turvallisuuspolitiikka

Riskienhallinta- ja turvallisuuspolitiikka Riskienhallinta- ja turvallisuuspolitiikka Tavoite Riskienhallinta ja turvallisuustyö toiminnan jatkuvuuden, tehokkuuden ja häiriöttömyyden varmistajana. Riskienhallinta ja turvallisuustyö strategian mahdollistajana.

Lisätiedot

RAKSAKYMPPI käytännöksi

RAKSAKYMPPI käytännöksi RAKSAKYMPPI käytännöksi Perusteet Käyttö Hyödyt Kokemuksia Tarja Mäkelä VTT RATUKE-seminaari 20.9.2007 RAKSAKYMPPI -uutta ajattelua työturvallisuuteen Lisätietoja: Tarja Mäkelä VTT Puh. 020 722 3308, tarja.makela@vtt.fi

Lisätiedot

OMAVALVONTA ISO 9001 ISO / FSSC 22000 ISO 14001 OHSAS 18001 SATAFOOD KEHITTÄMISYHDISTYS RY 24.9.2015. Marika Kilpivuori

OMAVALVONTA ISO 9001 ISO / FSSC 22000 ISO 14001 OHSAS 18001 SATAFOOD KEHITTÄMISYHDISTYS RY 24.9.2015. Marika Kilpivuori SATAFOOD KEHITTÄMISYHDISTYS RY Laatu- ja ympäristöjärjestelmät 24.9.2015 Marika Kilpivuori OMAVALVONTA ISO 9001 ISO / FSSC 22000 BRC ISO 14001 OHSAS 18001 IFS 1 MIKÄ JÄRJESTELMÄ MEILLÄ TARVITAAN? Yrityksen

Lisätiedot

Henkilöstötuottavuuden johtaminen ja työelämän laadun merkitys organisaation tuottavuudessa Tauno Hepola 11.2.2010

Henkilöstötuottavuuden johtaminen ja työelämän laadun merkitys organisaation tuottavuudessa Tauno Hepola 11.2.2010 Henkilöstötuottavuuden johtaminen ja työelämän laadun merkitys organisaation tuottavuudessa Tauno Hepola 11.2.2010 Organisaatioiden haasteita Työelämän laadun rakentuminen Työhyvinvointi, tuottavuus ja

Lisätiedot

Hyvät käytännöt. LEAN Siuntiossa

Hyvät käytännöt. LEAN Siuntiossa Hyvät käytännöt LEAN Siuntiossa SIUNTION KUNTA SJUNDEÅ KOMMUN Lean-menetelmä Siuntion toteutus Lean-konferenssi 20.5.2015 Kehittämispäällikkö Antti-Pekka Röntynen Siuntion kunta Esityksen sisältö 1. Miksi

Lisätiedot

Bimodaalisuus IT Palvelunhallinnassa Case UPM

Bimodaalisuus IT Palvelunhallinnassa Case UPM Bimodaalisuus IT Palvelunhallinnassa Case UPM Kuka on Johanna Manager, IT Service Managmement UPM:lla ja osana IT Strategy and Governance tiimiä Vastuulla Palvelunhallinnan maturiteetti UPM IT:ssä BBA

Lisätiedot

Hyvät t käytännöt t julkisiksi miksi ja miten?

Hyvät t käytännöt t julkisiksi miksi ja miten? Hyvät t käytännöt t julkisiksi miksi ja miten? Olemme kaikki kuulleet sanottavan, että virheistä opitaan ja kantapää on hyvä opettaja. Tekevälle tapahtuu virheitä ja niiden salliminen on välttämätöntä,

Lisätiedot

SATAFOOD KEHITTÄMISYHDISTYS RY. Laatujärjestelmät yrityksen toiminnan tehostajana 4.3.2015. Marika Kilpivuori ISO 9001 ISO / FSSC 22000 ISO 14001

SATAFOOD KEHITTÄMISYHDISTYS RY. Laatujärjestelmät yrityksen toiminnan tehostajana 4.3.2015. Marika Kilpivuori ISO 9001 ISO / FSSC 22000 ISO 14001 SATAFOOD KEHITTÄMISYHDISTYS RY Laatujärjestelmät yrityksen toiminnan tehostajana 4.3.2015 Marika Kilpivuori OMAVALVONTA ISO 9001 ISO / FSSC 22000 BRC ISO 14001 OHSAS 18001 IFS 1 MIKSI OMAVALVONTA EI AINA

Lisätiedot

Testauksen suunnittelu ja dokumentointi ketterässä testauksessa Tutkimustuloksia

Testauksen suunnittelu ja dokumentointi ketterässä testauksessa Tutkimustuloksia Testauksen suunnittelu ja dokumentointi ketterässä testauksessa Tutkimustuloksia Nina Perta, Senior quality consultant Knowit Oy Elina Varteva, QA Specialist Knowit Oy Copyright Knowit Oy 2014 Nina Perta

Lisätiedot

PROJEKTIN SUUNNITTELU JOUNI HUOTARI, PAAVO MOILANEN, ESA SALMIKANGAS

PROJEKTIN SUUNNITTELU JOUNI HUOTARI, PAAVO MOILANEN, ESA SALMIKANGAS PROJEKTIN SUUNNITTELU JOUNI HUOTARI, PAAVO MOILANEN, ESA SALMIKANGAS 10 KEYS TO SUCCESSFUL SOFTWARE PROJECT 1. Clear Vision 2. Stable, Complete, Written Requirements 3. Detailed User Interface Prototypes

Lisätiedot

Laadunhallinnan viralliset tasot Katsaus laadun todentamiseen ja virallisiin vaatimuksiin. Technopolis Linnanmaa 19.2.2015 Kaj von Weissenberg

Laadunhallinnan viralliset tasot Katsaus laadun todentamiseen ja virallisiin vaatimuksiin. Technopolis Linnanmaa 19.2.2015 Kaj von Weissenberg Laadunhallinnan viralliset tasot Katsaus laadun todentamiseen ja virallisiin vaatimuksiin Technopolis Linnanmaa 19.2.2015 Kaj von Weissenberg Johtamisjärjestelmä Näkemyksiä laadun hallintaan, sisältä ja

Lisätiedot

ERP järjestelmät. Mitä, miksi ja kuinka? Parhaita käytäntöjä. Kevät 2017 Lauri Tapola

ERP järjestelmät. Mitä, miksi ja kuinka? Parhaita käytäntöjä. Kevät 2017 Lauri Tapola ERP järjestelmät. Mitä, miksi ja kuinka? Parhaita käytäntöjä. Kevät 2017 Lauri Tapola Vanha liiketoimintamalli organisaation toiminta osastoperustaista. Lopputuote Raaka-aine Kaikilla funktioilla omat

Lisätiedot

Master data tietojen ja kriteeristön sekä hallintamallin määrittely ja suunnittelu TRE:933/02.07.01/2011

Master data tietojen ja kriteeristön sekä hallintamallin määrittely ja suunnittelu TRE:933/02.07.01/2011 Lisätieto 15.2.2011 Master data tietojen ja kriteeristön sekä hallintamallin määrittely ja suunnittelu TRE:933/02.07.01/2011 Vastaukset täydentävät vaatimusmäärittelyämme lisätietona ja ne tulee ottaa

Lisätiedot

AVOIMEN TUOTTEEN HALLINTAMALLIT. Kunnassa toteutettujen tietojärjestelmien uudelleenkäyttö. Yhteentoimivuutta avoimesti 2.12.2011

AVOIMEN TUOTTEEN HALLINTAMALLIT. Kunnassa toteutettujen tietojärjestelmien uudelleenkäyttö. Yhteentoimivuutta avoimesti 2.12.2011 AVOIMEN TUOTTEEN HALLINTAMALLIT Kunnassa toteutettujen tietojärjestelmien uudelleenkäyttö Yhteentoimivuutta avoimesti 2.12.2011 Erikoistutkija, MSc. Tapio Matinmikko, Teknologian tutkimuskeskus VTT 2 Esittäjästä

Lisätiedot

ADE Oy Hämeen valtatie 144 20540 TURKU. Tuotekonfigurointi. ADE Oy Ly Tunnus: 1626957-3

ADE Oy Hämeen valtatie 144 20540 TURKU. Tuotekonfigurointi. ADE Oy Ly Tunnus: 1626957-3 Tuotekonfigurointi ADE Oy lyhyesti Asiakkaiden tarpeisiin suunnattua innovatiivista ja toimivaa ohjelmisto- ja 3d animaatiopalvelua. Ade Oy on toteuttanut vuodesta 2000 alkaen haastavaa interaktiivista

Lisätiedot

Specifying user requirements for corporate intranet with user centered design methods. Espoo Tekijä: Henri Ström Valvoja: TkT Kalevi Kilkki

Specifying user requirements for corporate intranet with user centered design methods. Espoo Tekijä: Henri Ström Valvoja: TkT Kalevi Kilkki Specifying user requirements for corporate intranet with user centered design methods Espoo 29.9.2016 Tekijä: Henri Ström Valvoja: TkT Kalevi Kilkki Sisältö Työn tausta Ongelman asettelu Metodiikka Kehitysprojekti

Lisätiedot

TOIMIJAREKISTERIN TOTEUTUKSEN JA YLLÄPIDON HANKINTA - HANKINNAN YKSI- LÖINTI HUOM!

TOIMIJAREKISTERIN TOTEUTUKSEN JA YLLÄPIDON HANKINTA - HANKINNAN YKSI- LÖINTI HUOM! TARJOUSPYYNTÖ / LIITE 1 1 (5) TOIMIJAREKISTERIN TOTEUTUKSEN JA YLLÄPIDON HANKINTA - HANKINNAN YKSI- LÖINTI HUOM! Tällä liitteellä yksilöidään hankinnan kohteen ominaisuuksia ja toiminnallisuuksia, jotka

Lisätiedot

Kehittämisen omistajuus

Kehittämisen omistajuus Kehittämisen omistajuus Kuntaliitto 18.4.2013 Tuottava ja hallittu kehittämistoiminta kunnissa hanke (KUNTAKEHTO) Pasi-Heikki Rannisto Kehityspäällikkö, HT Tampereen Palveluinnovaatiokeskus (TamSI) Kehittämistyön

Lisätiedot

LEAN & KORJAUSRAKENTAMINEN; KOKEMUKSIA LEAN -TYÖKALUJEN JA TOIMINTAMALLIEN SOVELTAMISESTA KORJAUSRAKENTAMISEEN

LEAN & KORJAUSRAKENTAMINEN; KOKEMUKSIA LEAN -TYÖKALUJEN JA TOIMINTAMALLIEN SOVELTAMISESTA KORJAUSRAKENTAMISEEN LEAN & KORJAUSRAKENTAMINEN; KOKEMUKSIA LEAN -TYÖKALUJEN JA TOIMINTAMALLIEN SOVELTAMISESTA KORJAUSRAKENTAMISEEN Korjausrakennushankkeen osapuolten aikainen osallistaminen; Case Joensuun Kirkkokatu Professori

Lisätiedot

KOKONAISSUUNNITELMA KEHITTÄMISTEHTÄVÄLLE lomake 1

KOKONAISSUUNNITELMA KEHITTÄMISTEHTÄVÄLLE lomake 1 KOKONAISSUUNNITELMA KEHITTÄMISTEHTÄVÄLLE lomake 1 TYÖRYHMÄN NIMI: pvm: jolloin täytetty työryhmän kanssa KEHITTÄMISTEHTÄVÄN NIMI TAVOITTEET Leppävaaran sosiaaliohjaajat (Espoo, lastensuojelun avopalvelut)

Lisätiedot

Testataanko huomenna?

Testataanko huomenna? Testataanko huomenna? Qentinel Group 2014 Esko Hannula 03.06.2014 Ohjelmistokriisistä testauskriisiin 1985: Ohjelmistot ovat huonolaatuisia ja aina myöhässä Jonkun pitäisi testata, ehkäpä noiden huonoimpien

Lisätiedot

LAATUKÄSIKIRJA SFS-EN ISO 9001:2000

LAATUKÄSIKIRJA SFS-EN ISO 9001:2000 LAATUKÄSIKIRJA SFS-EN ISO 9001:2000 LAATUPOLITIIKKA Puutyöliike Pekka Väre Ky:n liiketoiminnan kehittyminen ja jatkuvuus varmistetaan koko henkilökunnan yhdessä omaksumien toimintaperiaatteiden ja yrityksessä

Lisätiedot

ITSM. Olli Saranen Senior Consultant Avoset Oy Oliko ennen kaikki paremmin kuin nykyään? Kivikaudelta nykyaikaan

ITSM. Olli Saranen Senior Consultant Avoset Oy Oliko ennen kaikki paremmin kuin nykyään? Kivikaudelta nykyaikaan ITSM Oliko ennen kaikki paremmin kuin nykyään? Kivikaudelta nykyaikaan Olli Saranen Senior Consultant Avoset Oy 31.8.2016 Esittely Mukana suomalaisten pankkijärjestelmien kehittämisessä ja ylläpitotyössä

Lisätiedot

SMS ja vaatimustenmukaisuuden

SMS ja vaatimustenmukaisuuden SMS ja vaatimustenmukaisuuden valvonta Tiedotustilaisuus: Pienet hyväksytyt koulutusorganisaatiot non-complex ATO Vastuullinen liikenne. Yhteinen asia. Turvallisuuden hallintajärjestelmä, SMS ICAO Document

Lisätiedot

Johdantoluento. Ohjelmien ylläpito

Johdantoluento. Ohjelmien ylläpito Johdantoluento Ylläpito-termin termin määrittely Ylläpito ohjelmistotuotannon vaiheena Evoluutio-termin määrittely Muita kurssin aiheeseen liittyviä termejä TTY Ohjelmistotekniikka 1 Ohjelmien ylläpito

Lisätiedot

Jatkuva parantaminen Case: Alkon laboratorio Pekka Lehtonen /

Jatkuva parantaminen Case: Alkon laboratorio Pekka Lehtonen / Jatkuva parantaminen Case: Alkon laboratorio Pekka Lehtonen Akkreditointi vuodesta 1993 Väkiviinan ja alkoholia sisältävien juomien ja teknokemiallisten tuotteiden kemiallinen testaus 34 akkreditoitua

Lisätiedot

Tilannetietoisuus läpinäkyvyys antaa välineet parempaan palveluun

Tilannetietoisuus läpinäkyvyys antaa välineet parempaan palveluun Tilannetietoisuus läpinäkyvyys antaa välineet parempaan palveluun l Yrityksen kumppanien yhteydenpidon lisääminen Janne Ohtonen, Enterprise Architect, Affecto Finland Oy Yit Yrityksen kumppaniverkosto

Lisätiedot

KUOPION KAUPUNGIN PALVELUALUEUUDISTUS. Tsr/R.Tajakka

KUOPION KAUPUNGIN PALVELUALUEUUDISTUS. Tsr/R.Tajakka KUOPION KAUPUNGIN PALVELUALUEUUDISTUS Tsr/R.Tajakka 1 1) PALVELUALUEUUDISTUKSEN TAUSTAT JA TAVOITTEET 2 Mitkä ovat uudistuksen tavoitteet? Asiakkaan (ja yhteiskunnallisen vaikuttavuuden) näkökulman entistäkin

Lisätiedot

Omavalvonta ja laadunhallintajärjestelmä. Elintarvikkeiden tarjoaminen julkisille keittiöille 16.8.12

Omavalvonta ja laadunhallintajärjestelmä. Elintarvikkeiden tarjoaminen julkisille keittiöille 16.8.12 Omavalvonta ja laadunhallintajärjestelmä Elintarvikkeiden tarjoaminen julkisille keittiöille 16.8.12 Omavalvonnan säädökset Elintarvikelain 23/2006 mukaisesti kaikilla elintarvikealan toimijoilla on oltava

Lisätiedot

Yhteisöllisen toimintatavan jalkauttaminen!

Yhteisöllisen toimintatavan jalkauttaminen! Yhteisöllisen toimintatavan jalkauttaminen! Käyttöönoton vaiheet Yrityksen liiketoimintatavoitteet Yhteisöllisen toimintatavan käyttöalueet Työkalut Hyödyt yritykselle Hyödyt ryhmälle Hyödyt itselle Miten

Lisätiedot