TU ERP- ja APS-järjestelmien erikoiskurssi

Transkriptio

1 TU ERP- ja APS-järjestelmien erikoiskurssi ERP-järjestelmien ylläpidon haasteet ja ratkaisut Kevät 2010

2 Luennon aiheet 1. Yleisiä asioita ERP-järjestelmien ylläpidosta ERP-järjestelmien vaikutukset yritysten IT-kustannuksiin 2. Tekniset ongelmat ja niiden ehkäisy Käytön estyminen Käytön viivästyminen Käyttöoikeusongelmat 3. Käyttäjäongelmat ja niiden ehkäisy Transaktiotaso Master datan taso Konfiguraatiotaso 4. IT-arkkitehtuurin ylläpito Esimerkki tosielämän yritysten IT-ympäristöistä Point-to-point-integraatiot, EAI ja SOA 5. Yhteenveto

3 Moodi Mediaani 1.1 ERP-järjestelmä ja IT:n ylläpidon kustannukset ERP-järjestelmien hyödyistä tiedetään, että: Niitä on vaikea mitata Ne eivät realisoidu heti käyttöönoton jälkeen Ne vaihtelevat tapauskohtaisesti Kyselytutkimusten vastaajat ovat kuitenkin yhdestä asiasta yksimielisiä ERP-järjestelmän käyttöönoton jälkeisiä näkymiä: Tulevaisuudessa ICT-henkilöstömme määrä vähenee 77% (Aara, 2006) Eri mieltä 8% Samaa mieltä 25% ERP-järjestelmän käyttöönotto on vähentänyt yrityksemme IT-kustannuksia [Ruotsissa] (Olhager & Selldin, 2003) [USA:ssa] (Mabert et al., 2001) Täysin eri mieltä: ka = 2,1 Täysin samaa mieltä: 5 ERP-järjestelmän käyttöönotosta on seurannut..enemmän kustannuksia kuin säästöjä..enemmän säästöjä kuin kustannuksia (Abdinnour-Helm & Lengnick-Hall, 2005) ja lista vain jatkuisi: Davenport et al., 2002; Mabert et al., 2003; Shepherd et al., 2005; jne. ERP-järjestelmä ei yleensä vähennä IT-kustannuksia

4 1.2 ERP-järjestelmä ja IT:n ylläpidon haasteet Miksi ERP-järjestelmä ei vähennä IT-kustannuksia (vaan usein jopa kasvattaa niitä)? Sen alkuinvestointi on suuri, joten ylläpidettävää on sen mukaisesti vaikka järjestelmien yhteismäärä vähenisikin Se tuo IT:n uusiin tehtäviin ja edellyttää, että sitä myös käytetään niissä Siitä näkee, kun se ei toimi tai sitä käytetään väärin Ylläpidon kanssa kitsastelu ei ole helppoa Joko koulutuksen tai korjailujen ja paikkailujen kulut kasvavat Ylläpitohaasteita aiheuttavat ainakin seuraavat seikat: Käyttäjäongelmat Tekniset ongelmat IT-arkkitehtuurin hallinta

6 Käytön estyminen 2.1 Tekniset ongelmat ERP-järjestelmien kanssa kohdataan ainakin kolmenlaisia teknisiä ongelmia: Käytön estyminen: Käytön viivästyminen: aina iso ongelma ei välttämättä yhtä iso ongelma, mutta aiheuttaa monesti käyttäjäongelmia Käyttöoikeusongelmat: voivat olla isoja tai pienempiä ongelmia Ongelma Ratkaisuvaihtoehtoja Ohjelmistovirheet eli bugit Jonkun pitää olla vastuussa siitä, että järjestelmätoimittajan patchit asennetaan proaktiivisesti ja systemaattisesti Käyttäjäportaaleja pitää seurata muutenkin aktiivisesti ei pelkästään patchien ja ennakkovaroitusten takia vaan myös siksi, että niissä julkaistaan workaroundeja Versiopäivitysyllätykset (etenkin omat koodit ja rajapinnat ovat alttiina vaaroille) Testataan versiovaihdot aivan kuten kaikki muutkin konfiguraatiomuutokset (tästäkin syystä yrityksillä pitäisi tietenkin olla dokumentoidut testiskenaariot ja -rutiinit ) Ei välttämättä kannata olla aina ensimmäisenä asentamassa uusia versioita

7 Käyttöoikeusasiat Käytön viivästyminen 2.2 Tekniset ongelmat Ongelma Ratkaisuvaihtoehtoja Raskaat transaktiot Suositaan tausta-ajoja (backgroung processing) raskaiksi tiedettyjen transaktioiden suorittamisessa Käytetään erillistä raportointiohjelmistoa (data warehousing) tietokantakyselyjen tekemiseen Palomuuriviiveet Mietitään, mihin ja miten palomuuri kannattaa asentaa Ylikuormitusviiveet Ei häslätä (siis: klikkailla ympäriinsä tai availla uusia istuntoja) Katkokset päätelaiteyhteyksissä Päätelaitteet (esim. mobiililaitteet) pitäisi ehdottomasti toimia myös offline. Selainpohjaiset käyttöliittymät ovat usein ongelmallisia tämän asian suhteen. Ongelma Käyttäjillä on liikaa oikeuksia Käyttäjillä on liian vähän oikeuksia Ratkaisuvaihtoehtoja Käyttöoikeuksien hallinnasta vastaavan henkilön pitää ymmärtää, mitä loppukäyttäjät töissään tekevät Oikeuksien päivitystarpeet pitää huomioida järjestelmällisesti aina, kun konfiguraatiota muutetaan tai henkilöiden tehtävät muuttuvat Testaaminen sekä selkeästi dokumentoidut testiskenaariot auttavat varmistamaan, etteivät työt keskeydy oikeuksien puutteeseen Käyttöoikeuksien systemaattisen hallinnan edellytys on, että ne paketoidaan profiileiksi Ymmärretään, että oikeuksien rajoittaminen on usein järkevää, mutta se pitää perustella muutenkin kuin varmuuden vuoksi

9 3.1 Käyttäjäongelmat Käyttäjäongelmat ilmenevät pääsääntöisesti huonona datanlaatuna, ja niiden parhaita lääkkeitä ovat koulutus, valvonta ja esimiesten oma esimerkki Tässä esityksessä tarkastelu jaetaan: Transaktiodatan (/raportoinnin) tasolla ilmeneviin ongelmiin Master data -ongelmiin Konfiguraatio-ongelmiin Nämä taas aiheuttavat monenlaisia operatiivisia ongelmia: Mittareihin ei voi luottaa Materiaalit, tilaukset ja laskut ovat hukassa Suunnitelmat ovat toteuttamiskelvottomia Toki käyttäjäongelmilla on myös muita vakavia seurauksia: Työn tuottavuus laskee Yleinen epätyytyväisyys kasvaa ja työssä viihtyminen heikkenee

10 Transaktio- ja mittaridatan taso 3.2 Käyttäjäongelmat Ongelma Järjestelmää ei käytetä (esim. varastokirjauksia/ suunnitteluvaiheita/ kuittauksia ei tehdä) Järjestelmän käyttöä korvataan esim. erilaisilla Excel-virityksillä Järjestelmää ei käytetä tarkoituksenmukaisesti (esim. pakollisiin kenttiin kirjataan puppua) Transaktioita ei tehdä reaaliaikaisesti Ratkaisuvaihtoehtoja Järjestelmään konfiguroitavat kontrollit: audit trail -tarkistukset sekä pakolliset kentät transaktioissa Palkkiojärjestelmien sitominen transaktioihin (esim. kuittaukset) Koulutus (etenkin kokonaisia prosesseja käsittelevät kurssit auttavat perustelemaan, miksi kaikki eri työvaiheet tarvitaan) Järjestelmän kehittäjien pitää olla alati valveilla se suhteen, että konfiguraatio vastaa reaaliprosessia Epämuodollisten järjestelmien syntymistä pitää valvoa, ja niihin pitää puuttua (ei pelkästään kieltämällä ja kitkemällä, vaan myös miettimällä, miksi niitä syntyy, ja miten IT:tä voisi kehittää vastaamaan paremmin käyttäjien tarpeita) Esimiesten oma esimerkki, valvonta ja motivointi ovat korvaamattomia kaikessa kurinpidossa Virheet datansyötössä (esim. syötetään tuotenumero kappalemääräkenttään) Järjestelmään kertyvää dataa ei käytetä Järjestelmään konfiguroitavat toleranssit (estetään tai ainakin varmennetaan esim. älyttömän isot taikka audit trailin perusteella odottamattomat kirjaukset) Toleranssien perustalle voidaan konfiguroida myös erilaisia hyväksymiskäytäntöjä (näiden tarve pitää aina harkita tarkkaan) Systematisoidaan korjauskirjausten teko (ja annetaan siihen asianmukaiset koulutukset) Koko organisaatio pitää kouluttaa hyödyntämään järjestelmään kertyvää tietoa ja tekemään omia tehtäviään tukevia raportteja

11 Master datan taso 3.3 Käyttäjäongelmat Ongelma Syntyy duplikaatteja Master datat eivät pidä paikkaansa (esim. väärät toimitusosoitteet, pankkitiedot jne.) Ratkaisuvaihtoehtoja Koulutuksessa pitää painottaa, kuinka moninaisia ja kauaskantoisia haittoja duplikaateista ja virheellisestä datasta voi seurata Loppukäyttäjien tarvetta luoda master dataa voidaan vähentää luomalla esim. asiakkaista ja toimittajista kerta-asiakas- /-toimittaja-datat Palkataan master data managereita vaalimaan datanlaatua Saman yrityksen eri implementaatioissa ylläpidetään erilaisia master datoja (esim. asiakkaiden luottotiedot) Suunnitteluparametrit eivät vastaa todellisuutta Pyritään hyödyntämään järjestelmien master datan siirtoominaisuuksia (transportation) Erillisestä CRM-ohjelmistosta (customer relationship management) voi olla hyötyä Erillisestä PDM-ohjelmistosta (product data management) voi olla hyötyä (ks. alla) Suunnittelijoiden ammattitaito on kriittistä sen suhteen, onko suunnittelusta mitään hyötyä. On välttämätöntä ymmärtää perin pohjin, mitkä parametrit vaikuttavat mihinkin ja miksi ne vaikuttavat niin kuin vaikuttavat. Pitää myös erottaa toteuman luonnolliset vaihtelut systemaattisista virheistä (tai muuten voi seurata ns. planning bullwhip) Etenkin kappaletavarateollisuudessa voi olla hyötyä keskitetystä PDM-ohjelmistosta sekä muodollisesta tuotekonfiguraatioiden (variant configuration) ja speksimuutosten hallinnasta (engineering change management)

12 Konfiguraatiodatan taso 3.4 Käyttäjäongelmat Ongelma Konfiguraatio ei vastaa reaaliprosessin tarpeita (Liittyy suoraan transaktiotason ongelmiin: on vaikea kirjata tapahtumia, joita ei oikeasti tapahdu ) Ratkaisuvaihtoehtoja ERP-järjestelmän huomioiminen pitää olla luonnollinen osa prosessikehitystä Myös kehityshankkeiden ulkopuolella tapahtuvia muutoksia pitää seurata valppaasti Käyttäjiltä kannattaa kerätä palautetta Järjestelmän ylläpitäjien ammattitaito on kriittisessä roolissa. Heidän pitäisi ymmärtää loppukäyttäjien työt, tarpeet ja motiivit. Järjestelmän ylläpitäjät tukehtuvat muutospyyntöihin/-vaatimuksiin Muutospyynnöt ovat keskenään ristiriitaisia Konfiguraation muutostarpeiden (kuten muidenkin IT-tarpeiden) keruu ja niiden toteutus on hyvä järjestää sykleinä Muutostarpeiden priorisointi, ristiriitaiset pyynnöt ja ongelmien ratkaisukeinot pitää selvittää hyvässä yhteisymmärryksessä eri intressiryhmien kesken ja tarvittaessa sopivaan auktoriteettiin tukeutuen. On tärkeää huomata, että eri ongelmat kytkeytyvät toisiinsa Tekniset ongelmat voivat pakottaa väärinkäyttöihin taikka johtaa niihin turhautumisen kautta Toisaalta väärin syötetty data aiheuttaa helposti pattitilanteita Järjestelmän oletusten ja käyttäjien tarpeiden välillä tasapainoilu onkin kaikkea muuta kuin pelkkää IT:n ylläpitoa

14 4.1 IT-arkkitehtuurin ylläpito Olkoonkin, että ERP-järjestelmä integroi prosessit jne., niin se ei oikeastaan ikinä ole yrityksen ainoa IT-järjestelmä Esimerkki: RcCP SOP APS MPS CRM PDM CRP MRP SRM MES Finite loading SW LVL Det. Sch. Vehicle routing SW PO GR TO LIV KZ Re PrO TR TO GI Conf PrO GR OR Del TO GI Bill DZ Prnt Conf Prnt Conf Settle Conf Prnt ERP WMS Banking DW Message server eikä tässä ole vielä tukiprosesseja. ERP:ssä ei välttämättä ole esim.: lisäksi yrityksillä on liittymiä muiden yksiköiden ja kumppanien järjestelmiin HR Payroll QM Maintenance Asset mgmt Kaikki palvelutuotantoon liittyvä

15 4.2 IT-arkkitehtuurin ylläpito eli ERP-järjestelmät eivät ole poistaneet tarvetta järjestelmäintegraatiolle Toki ne ovat hieman vähentäneet rajapintoja täysin hajautettuun funktionaalisten järjestelmien arkkitehtuuriin verrattuna Monille yrityksille on ollut myös hyötyä suurimpien ERPjärjestelmätoimittajien viestistandardeista Lisäksi monet ohjelmistot ovat nykyään bolt-on eli lähtökohtaisesti toimivat ERP-järjestelmän liittymien kautta Yhtä kaikki: yritysten tietojärjestelmissä on edelleen valtavasti rajapintoja ylläpidettävinä IT-rajapintojen ja -arkkitehtuurin hallinnasta voi erottaa ainakin kolme evoluutiovaihetta: Kahdenväliset (point-to-point) integraatiot Integraatioalustat (enterprise application integration, EAI) Palveluperusteinen arkkit. (service-oriented architecture, SOA)

16 4.3 IT-arkkitehtuurin ylläpito Vanhin, hyvin yleinen ja kenties epätoivottavin ratkaisu on point-to-point: Nykyisin suosittu ratkaisu on EAI [so. middleware] (esim. SAP XI): Puheiden tasolla eniten on kuitenkin esillä SOA (esim. SAP ESA) ERP EAI ESB ERP ERP Lienee sanomattakin selvää, että kahdenvälisesti räätälöidyissä rajapinnoissa riittää ylläpidettävää Integraatioalustat yleistyivät 90-luvulla Tietty riski on siinä, että EAI:lla voi olla liian helppo säilyttää rinnakkaisia softia ESB (enterprise service bus) on riippumaton logiikasta, joilla ohjelmistoja käytetään Se helpottaa mm. liittymien avaamista yhteistyökumppaneihin ( )

17 4.4 IT-arkkitehtuurin ylläpito SOA:n perusajatuksia: Ohjelmistot ovat service providereja ja service consumereja. Ne tarjoavat sisältöjään (ERP-järjestelmän tapauksessa transaktioita) standardimuotoisina palveluina eli webserviceinä ESB:llä yhdistetään yrityksen tarvitsemat service providerit ja consumerit. ESB ei välitä siitä, miten mitäkin palvelua käytetään. Businesslogiikka eli sen tietäminen, mitä ja miten webservicejä milloinkin käytetään, on service consumerin vastuulla. Niinpä integraatiokerros on ohut ja siihen liittyminen on helppoa SOA:n erot EAI:hin: EAI-sovelluksen ja taustaohjelmistojen rajapinnat integroidaan tapauskohtaisesti Logiikka siitä, mitä ohjelmaa käytetään mitenkin (work flow:t) konfiguroidaan/ohjelmoidaan EAI-sovellukseen EAI ei edellytä muutoksia taustaohjelmiin (Ei tietty SOA:kaan sen jälkeen, kun järjestelmätoimittajat ovat kerran koodanneet service providerien sisällöt webserviceiksi)

18 4.5 IT-arkkitehtuurin ylläpito Toki businesslogiikkakin pitää olla konfiguroitu jonnekin Siksipä ERP-järjestelmätoimittajat ovat aikansa asian kanssa jarruteltuaan alkaneet lämmetä SOA:lle Ne eivät kuitenkaan ole markkinoilla yksin. Ns. BPM-järjestelmistä (business process management) on kasvanut kokonaan uusi markkina. BPM-softa sisältää ainakin: Prosessien mallintamisen: Graafisen käyttöliittymän kautta valitaan, mitä ohjelmaa/webserviceä käytetään milloinkin Prosessien kontrolloinnin: Ei käytetä ohjelmien käyttöliittymiä, vaan ne/webservicet avataan BPM-ohjelmasta. Graafisten prosessikaavioiden perusteella käyttäjä tietää, milloin pitää tehdä mitäkin Prosessien mittaamisen: Eri ohjelmiin/service providereihin kertyviä tietoja haetaan tarpeen mukaan ilman erillistä tietokantaa BPM-toimittajia ovat esim. IBM, Tibco, webmethods, Action Technologies, Savvion, BEA Systems ja tietty SAP (NetWeaver ja ARIS-yhteistyö) sekä Oracle ja MS jne.

19 4.6 IT-arkkitehtuurin ylläpito SOA-BPM-lopputulos voisi olla jotakin tällaista: Käyttäjä avaa transaktiot BPM-softasta RcCP SOP MPS BPM-softa tietää, mitä webserviceä käytetään milloinkin BPM CRP LVL MRP Det. Sch. Re Conf PO GR TO LIV KZ TR TO GI GR OR Del TO GI Bill PrO PrO DZ Prnt Conf Prnt Conf Settle Conf Prnt ESB ERP DW MES Message server Finite Vehicle SRM WMS loading PDM APS Banking routing CRM HR Payroll QM Maintenance SW SW Asset mgmt Taustaohjelmien (service providerien) sisällöt webserviceinä Tosin mitään tällaista ei tiettävästi ole vielä implementoitu missään ja tarinassa on vielä kysymysmerkkejä Esim. eikö muka ERP-järjestelmän konfiguraatio riipu siitä, mitä, miten ja missä järjestyksessä erilaisia webservicejä käytetään? Innostus näyttää kuitenkin olevan kova

21 5.1 Yhteenveto Mitä tämän luennon jälkeen pitäisi tietää ERP-järjestelmien käyttämisestä ja ylläpitämisestä? Millaisia ongelmia yritykset kohtaavat ERP-järjestelmiensä kanssa ja miksi? Miten erilaisia teknisiä ongelmia voi välttää ja ratkoa? Miten erilaisia käyttäjistä riippuvia ongelmia voi välttää ja ratkoa? Miten tekniset haasteet ja käyttäjäongelmat liittyvät toisiinsa? Mitä pitäisi tietää IT-arkkitehtuurista? ERP-järjestelmät eivät korvaa kaikkia muita softia. Erilaisten rajapintojen ylläpitämisestä ei olla päästy eroon Millaisia ohjelmistoja yrityksien IT-infrastruktuuriin kuuluu? Mitä eroa on point-to-point-integraatiolla ja EAI:lla? Lisäksi on hyvä tietää karkealla tasolla, mitä SOA tarkoittaa?