SAP konsultiksi – mitä ja miten?

Moni SAPia töikseen käyttävä taho miettii jossakin välissä SAP-konsultin ehkä rahakastakin uraa, mutta keinot murtautua konsulttimaailmaan ovat epäselvät. Tässä artikkelissa kerromme muutamia vinkkejä, kuinka on mahdollista edistää mahdollista tulevaa konsultin uraa ja että kuinka päästä sisälle SAP-maailmaan.

Ensinnäkin on pakko korjata muutamia harhaluuloja:

• Konsultin ura ei todellakaan ole niin rahasta kuin luullaan. Se on kokenut huomattavan inflaation ja nykypäivänä Suomessa konsultti tienaa n. 2500-4500 euroa/kk riippuen kokemuksesta. Poikkeuksia on, mutta näihin tähdenlentoihin itsensä rinnastaminen ei ole realistista.
• Konsultin työ varsinkin asiakasrajapinnassa on epäkiitollista työtä. Hyvästä työstä ei mainita ja huonosta tulee senkin edestä kuraa. Tästä huolimatta pitäisi jaksaa tehdä asiakaspalvelutyötä asiakkaille, jotka eivät joko halua ottaa sanomaa vastaan tai eivät vain ymmärrä sitä.
• Nykyään SAPista löytyy paljon osaamista Suomestakin, joten kilpailu on koventunut huomattavasti. Se, että osaa SAPia ei tee vielä mitään, vaan pitää olla SAP-projekteja takana – ne painavat vaakakupissa eniten.
• SAP-konsulttina oleminen on jatkuvaa opiskelua. Ei riitä että tekee projekteja vaan pitää myös olla selvillä pari vuotta tulevaisuuteen mitä SAPilta on tulossa. Pelkästään SAP ERP versioiden hallinnassa on haastetta varsinkin jos siirtyy 4.6C tai 4.7 versiosta versioon 6.0.
• Työ on projektiluontoista ja loppuvaihe on joka projektissa raskas. Kun projekti on takana, alkaa heti perään toinen ennenkuin entisestäkään on kunnolla toipunut. Tässä kärrynpyörässä moni ei jaksa olla mukana pitkään.

Jos kuitenkin haluat konsultiksi?

Konsultin uralle lähdetään usein joko jonkin SAP-kurssituksen kautta taikka jos yritykseen jossa työskentelee hankitaan SAP. Näistä jälkimmäinen on usein se yleisin tapa. Kuten muissa tämän sivuston artikkeleissa on sivuttu tätä asiaa, olennaisinta on hallita ensin käytännön liiketoiminnan kuviot alalta jolla työskentelee. Se tarkoittaa sitä että syvällisesti ymmärtää, mihin EAN-koodeja käytetään, mitä ongelmia voi olla tavaran vastaanotossa, mitä missäkin käytännön tehtävässä työskentely vaatii tietojärjestelmiltä, … Ilman tätä osaamista ei mielestäni kehity hyväksi konsultiksi. Miten auttaa asiakasta määrittelyvaiheessa, jos ei itsekään ymmärrä liiketoiminta-aluetta? Tekninen konsultointi ja varsinkin ratkaisukonsulttien työ on asia erikseen, mutta näissäkin olisi hyvä osata käytännön prosesseja. Tämän sanon siksi, että liian usein teknisillä kikkailuilla ja uusilla järjestelmähankinnoilla koetetaan ratkaista ongelma, jonka voisi aivan yhtä hyvin ratkaista muuttamalla tapoja toimia. Tästä ei konsulttitalo saa rahaa ehkä niin paljon, mutta takuuvarmasti talo saa asiakkaan luottamuksen ja arvostuksen joka kiirii ehkä eteenpäinkin.

Asiakasyrityksessä pitäisi jaksaa työskennellä SAPin parissa 2-5 vuotta. Tänä aikana saa samalla hyvän pohjan SAP-konsultiksi. Teknisenä henkilönä (jos asiakas itse ylläpitää SAPia) osaaminen on jo vahvaa parin vuoden päästä jos tekee tätä täysipäiväisesti ja pääsee tekemään laajemminkin esimerkiksi integraatioita.

Mille osa-alueelle?

Alla linkki, josta näkee mm. UK:n SAP-palkkauksia, suosittuutta per tehtävä jne. Tätä samaa voi karkeasti ajatella myös Suomeenkin, varsinkin jos muutos % on suuri esimerkiksi ylöspäin. http://www.itjobswatch.co.uk Laita hakusanaksi SAP.

Nyt suosituimpia osa-alueita ovat BI (Business Intelligence), portaali ja liiketoiminta-osaamiskonsultointi. Tekniikka tulee kaukana takana. Nykyään haetaan yhä enenevissä määrin osaajia, jotka hallitsevat SAPia ennemminkin prosessimielessä alusta loppuun kuin että osaavat yhden moduulin.

Murtautuminen konsultiksi

Parasta olisi, jos olet ollut jonkin osa-alueen vastuullisena asiakkaan puolella ns. pääkäyttäjänä. Tällöin todennäköisesti tunnet liiketoiminnan hyvin ja olet saanut samalla SAPista pääkäyttäjäkoulutuksen joka on huomattavasti laajempi kuin loppukäyttäjille annettava. Tähän tehtävään projektissa kannattaa pyrkiä jos mahdollista. Asiakkaan projektipäälliköille tilanne on vaikeampi koska he eivät opi SAPia vastaavalla tavalla kuin pääkäyttäjät, ”ainoastaan” SAPin projektimetodin ja osia sieltä täältä. Pidä mielessä että konsulttitalo katselee enemmän tai vähemmän asiakkaan projektiryhmäläisiä potentiaalisina konsultteina ja hyville henkilöille löytyy aina töitä. Usein suora rekrytointi on kiellettyä asiakas-toimittaja suhteessa, mutta jos työntekijä itse lähtee ja toimittaja hänet myöhemmin palkkaa, on ehkä tilanne toinen. Joka tapauksessa toimittajan konsultit tuntevat paljon muita SAP-konsultteja ja siksikin on tärkeää että teet asiat hyvin ja olet muutenkin motivoitunut koska sana kiertää ja kuitenkaan osaajia ei ole arviolta kuin 2000-3000 konsulttia Suomessa.

Hanki sertifikaatti vaikka itse. Sertifikaatti on pelkkä paperi, mutta sillä on usein iso painoarvo Asiakkaalle. Jos sinulla on tällainen, se on osoitus siitä että osaat jotakin vaikka projekteja ei olisikaan kuin yksi ja ainoa.

Asiakkaat katsovat usein konsulttien CV:t ennen projektiryhmän kiinnittämistä ja jos projekteja ei ole takana, on vaikea päästä tiimiin mukaan. Asiakasprojekti lasketaan tällöin usein yhdeksi projektiksi. Aloittelevat konsultit tekevät toki usein uusissa projekteissa käytännön konfiguroinnit, mutta asiakkaalle heitä ei vielä uskalleta päästää. Kun tässä tehtävässä on vuoden tai pari toiminut, uskalletaan juniori päästää ehkä kuunteluoppilaaksi asiakasprojekteihin. Parin, kolmen projektin jälkeen uskalletaan antaa vastuulle ehkä jokin moduuli kuten SD (myynti & jakelu).

Oma konsulttitalo?

Jos oman yrityksen perustamista mietit, tämä asia on sinulle jo täysin päivän selvää eikä meidän tarvitse kertoa tästä enempää.

Read Full Post »

SAP ERP Projekti – Osa 6: Käyttöönoton valmistelu

SAP Projekti on edennyt käyttöönoton valmisteluvaiheeseen, integraatiotestit on tehty ja olennaisimmat bugit korjattu. Nyt on aika hyväksyntätestata järjestelmä ja kouluttaa tämä loppukäyttäjille. Pääkäyttäjät ovat saaneet koulutusta pitkin projektia. Saunailta olisi kova sana tässä vaiheessa.

Hyväksyntätestauksen jälkeen testiraportin perusteella ohjausryhmä tekee päätöksen tuotantoon menosta. Ohjausryhmälle ei kannata lähettää testiraportteja, koska eivät he tästä mitään hyödy. Tärkeämpää on että otsikkotasolla luodaan esimerkiksi Excel jossa listattu testitapaukset PASS/FAIL periaatteella jossa lisäksi tieto, estääkö käyttöönoton ja arvio toimittajalta, milloin tämä saadaan arviolta korjattua. Muussa tapauksessa korjaukset venyvät koska yleensä käyttöönoton jälkeen vedetään tovi henkeä kunnes taas ponnistetaan uuteen syöksyyn.

Tässä vaiheessa ohjausryhmä käy myös läpi CUT-OVER käyttönottosuunnitelmaa joka yksinkertaisimmillaan on excel, jossa on kuvattu esim. liiketoiminta-alueittain seuraavat tiedot:

• Alkaa (päivä)
• Loppuu (päivä)
• Tehtävän kuvaus
• Toteutustapa
• Edeltävät tehtävät
• Status
• Vastuuhenkilö
• Huomioita
• Kriittisyys (estää tuotantoon menon Kyllä/Ei)

Tämän dokumentin pohjalta voidaan tehdä päätös tuotantoon menosta.

Kun vihreää valoa tuotantoon menolle on näytetty, alkaa asiakkaalle kasautumaan enemmän töitä mm. suoritettavan manuaalisen tiedon syötön että konversioiden muodossa.

Tietojen konversio voi olla helpompaakin

Konversio-ohjelmat (ja ehkä ajotkin) tekee usein toimittaja ja SAPissa tämä on LSMW (Legacy System Migration Workbench). Tätä työkalua voidaan ehkä käyttää myöhemmin päivittäisessä työssäkin, mutta alunperin LSMW on tarkoitettu konversiotyökaluksi. Ennenkuin kuitenkaan konversioita voidaan tehdä, on nykyisistä järjestelmistä otettava mm. avoin ostoreskontra ulos ja muokattava SAPille sopivaan muotoon, samoin kuin tuotteet, toimittajat, asiakkaat, valmistajat jne.

Tämä tehdään valitettavan usein käsin exceleillä mikä on käsittämätöntä, koska työmäärä pienenee huomattavasti, jos käytettäisiin esimerkiksi MySQL kantaa ja PHP-koodia. Esimerkiksi WAMP-paketti (sis. Windows Apache+MySQL+PHP) on nopea asentaa ja käyttöönottaa ja se pyörii hienosti vaikka normaalilla kannettavalla.

Avoin osto- ja myyntireskontra

Yksi olennaisimmista töistä asiakkaalla on joko käsin viedä avoin osto- ja myyntireskontra SAPiin taikka tähän on tehty myös konversiotyökalu. CATT -työkalu sopii tähän hyvin. Käytännön asiana olennaista on ilmoittaa valmistajalle tai tavarantoimittajalle ostotilausten tilausnumerot jos prosessi kulkee niin että vastaanotto tehdään ostotilausta vastaan. Ilman ostotilausnumeroa toimittajan lähetteessä muodostuu helposti tilanne, jossa saapuvia lähetyksiä on kymmeniä tai satoja, eikä nopeasti löydetä oikeaa ostotilausta lähetykselle. Silloin varasto puuroutuu ja pahimmassa tapauksessa tavaran saanti ajoissa oikeaan paikkaan estyy.

Ennen kuin tätä voidaan tehdä on tuotteet, asiakkaat, toimittajat, valmistajat oltava SAPissa – ja oikein. Jos perustiedossa on virheitä, tilanne voi luisua todella kaaokseen. Siksi on äärimmäisen tärkeää tarkistaa perustieto useaan kertaan ja varmistua sen oikeellisuudesta ennenkuin aletaan syöttämään reskontratietoa.

Historiadatan vieminen SAPiin?

Usein halutaan SAPiin historiadata mm. myynnin, ostojen jne. osalta. Näiden konversioiden toteutus onnistuu kyllä, mutta työmäärä voi olla todella suuri. Siksi kannattaa miettiä vakavasti, mitä historiadataa tulee oikeasti viedä SAPiin. Tilanne olisi aika hyvä jos käytössä olisi ulkoinen raportointiratkaisu, josta tiedot löytyvät ja jonka käyttöä jatkettaisiin myös SAPin käyttöönoton jälkeen. Tällöin tarvitsisi luoda rajapinnat SAPista raportointiratkaisuun, mutta aiempaa historiatietoa ei tarvitsisi luoda uudelleen SAPiin ellei käyttöön oteta myös SAPin MRP toiminnallisuutta (resource planning) jonka avulla voidaan asettaa SAP tekemään ehdotuksia hankinnoista, varastosiirroista jne. tai jos historia-dataa jollakin tavalla hyödynnetään järjestelmän toimesta automaattisesti (alennukset ostomäärien perusteella jne). Mitään yksiselitteistä parasta ratkaisua ei ole olemassa vaan tämä on käsiteltävä aina tapauskohtaisesti. Jos tätä asiaa herätään pohtimaan vasta tässä vaiheessa, ollaan jo pahasti myöhässä. Asia olisi pitänyt ratkaista määrittelyvaiheen aikana.

Read Full Post »

On se vaan ihme…

Projektityössä törmään toistuvasti tilanteisiin, joita voi vain hämmästellä. Voisi olettaa, että jokainen projektiin osallistuva hallitsisi edes jonkinlaiset atk-taidot ja kyvyn kommunikoida toistensa kanssa. Viime viikolla sain sähköpostin, jossa valiteltiin tiedoston olevan väärässä formaatissa ja jonka vuoksi työt ovat nyt pysähdyksissä. Kun aloin lukemaan viestiketjua läpi, selvisi että työt ovat olleet itse asiassa jumissa jo useita viikkoja tuohon väärään formaattiin vedoten. Viestin lähettäjä pyysi minua toimittamaan heille oikeanlaisen Excel-tiedoston pikimmiten. Kukaan ei tietenkään ollut vaivautunut mainitsemaan asiasta henkilölle joka oli tehnyt tämän tiedoston alun perin.

Viestin alkuperäinen lähettäjä oli toimittanut datan txt-muodossa, eikä kukaan tiimin jäsenistä ollut saanut tätä auki Excelissä. Koska kyseessä oli SAP:n raportti, niin mieleeni tuli ensin että tiedosto on tallennettu SAP:sta väärässä formaatissa (unconverted). Lähempi tutkiminen kuitenkin paljasti, että kyseessä oli aivan oikeanlainen txt-tiedosto, jossa data oli eroteltu sarkaimella. Ja kas kummaa, Excel avasi tämän tiedoston ongelmitta. Ymmärrän kyllä, että tiimissä voi olla henkilöitä joiden atk-taidot ovat heikot, mutta miten ihmeessä kaikki ovat sattuneet juuri samaan tiimiin?

Soitin viestin lähettäjälle ja kerroin tilanteesta. Kuitenkin hänen mielestään tuollaisen datan aukaiseminen on aivan liian vaikeaa ja että olisi suotavaa saada tiedosto Excel-formaatissa. Ja koska data oli jo minulla auki Excelissä, niin hän pyysi minua tallentamaan sen xls-formaattiin ja lähettämään sen hänelle. Tässä vaiheessa en enää tiennyt että itkeäkö vai nauraa…

Olen joutunut/saanut aikaisemmin tehdä hyvinkin paljon samankaltaisia tiedostoja. Vielä asiakkaana ollessani jouduin toimittamaan asiakas- ja materiaalidataa konsulttien määrittelemässä formaatissa, eikä mieleeni tullut heittää koskaan hanskoja naulaan jos kohtasimme ongelmia datan keräämisessä tai konversioissa. Datan kerääminen oli vuorovaikutteista työtä ja kirjeenvaihtoa konsulttien kanssa käytiin lähes päivittäin. Näin varmistimme, että data on meidän puolelta valmiina deadlineen mennessä juuri sellaisessa formaatissa kuin konsultit sen haluavat ja ettei ongelmia ilmaannu dataa ladattaessa SAP:iin. Eikä muuten ilmaantunutkaan.

Meidän onni tässä projektissa oli, että meidän ydinryhmällä oli loistavat tietotekniset taidot. Ilman tietokanta- tai ohjelmointitaitoja projekti olisi myöhästynyt pahastikin, koska käsityönä Exceliin naputeltuna tietojen keruu olisi kestänyt ikuisuuden. Valitettavasti tiedän, että useissa projekteissa tämä tehdään yhä käsityönä, koska käytössä olevia työkaluja ei osata hyödyntää. Yksi syy voi olla tietenkin ettei työkaluja haluta hyödyntää; liian usein kuulen myös sanottavan ”Ettei tämä ole minun tehtävä, kysy joltain toiselta”. Juuri tällainen ajattelutapa saattaa myöhästyttää projektia useita viikkoja vaikka tarvittava työ olisi ollut tehtävissä minuutissa!

Siinäpä sitten selittelet projektin johdolle, miksi ollaan myöhässä aikataulusta…

Read Full Post »

SAP ERP projekti – Osa 4: Toteutus

SAP Projektin toteutus ja testausvaiheessa keskitytään toteuttamaan määrittelyjen mukainen toiminnallisuus kuten arvata saattaa. Toteutusvaiheessa ei oteta enää uusia toiminnallisuuksia mukaan, ellei niitä määritelty aiemmin tai niiden toteutus ole muuten vähäpätöinen työ, joka ei suuremmin vaikuta prosesseihin ja erityisesti ei vaikuta aikatauluun. Olennaisinta toteutusvaiheessa on ylläpitää jatkuvaa dialogia toimittajien konsulttien ja asiakkaan projektiryhmän kesken ja seurata toteutusta tiiviisti. Tästä dokumentista oli tulla mammutti, joten tiivistimme paljon. Lisäämme myöhemmässä vaiheessa linkityksin tarkempaa tietoa eri vaiheista.

Jos tässä vaiheessa ei ole toiminnallisuuksia karsittu määrittelystä/sovellusanalyysistä, on se jo suoranainen ihme. Yleensä lähes poikkeuksetta, jotta pysytään aikataulussa – karsitaan toimintoja myöhempään vaiheeseen. Toteutusvaihe on valitettavan usein sellainen jossa toimittajan konsultit vetäytyvät komeroon konfiguroimaan määrittelyn mukaista ratkaisua (osin siksi että toteutuksen tekevät juniorikonsultit senioreiden ohjeistuksen mukaan – taikka sitten työ tehdään Intiassa). Konsultit tulevat konfiguroinnin jälkeen ulos kaapistaan ja esittelevät asiakkaalle Baseline -toteutuksen. Jos asiakas ei ole nähnyt tätä ennen SAPin käyttöliittymiä lainkaan, voi järkytys olla suuri. Ensimmäisenä saattaa tulla mieleen (minulle ainakin aikoinaan oli järkytys) että tällähän ei yksinkertaisesta voi tehdä liiketoimintaa, koska kukaan ei ikinä tule oppimaan käyttöliittymiä jotka ovat kuin lentokoneen ohjaamosta, ja toiseksi vaikka oppisivat, työhön menee aivan liikaa aikaa, varsinkin asiakaspalvelutilanteissa. Ei siis ihme että SAPin ympärille on syntynyt erinäisiä yrityksiä jotka tarjoavat helppokäyttöisempiä käyttöliittymiä / toimintoja integroituna SAPiin. Uudessa SAP 6.0 (SAP ERP 2005) versiossa on olemassa jo roolipohjainen näkymä jolla saa rajattua toiminnot roolipohjaisesti, mutta koska emme ole ehtineet tutkia asiaa tarkemmin, jätämme sen myöhempään vaiheeseen.

Tässä vaiheessa (toivottavasti) tiedetään jo tulevat pääkäyttäjät riippuen toki yrityksen koosta. Laajemmissa projekteissa ja yrityksissä prosessi- ja liiketoimintamäärittelyt hoidetaan oma tehtävänään ja pääkäyttäjät ovat enemmänkin tukitiimi käytön ja kehityksen osalta. Hankalin tilanne on jos talossa ei ole entuudestaan SAP-osaamista. Silloin pitää joko rekrytoida osaajat talon ulkopuolelta ja/tai kouluttaa joistakin henkilöistä SAP-pääkäyttäjiä. Vähintäänkin yksi SAP-osaaja tulisi olla, joka osaa organisoida tukitiimin toiminnan ja koulutukset. ”Statushuntereille” tiedoksi että yleensä tämä henkilö on jonkinlainen koordinaattori tai -päällikkö.

Alla toteutusvaiheen (osa 1) tehtävät projektisuunnitelmasta otettuna.

1. Käyttökoulutuksen suunnittelu SAPin ja muiden järjestelmien osalta
   1. Pääkäyttäjien koulutussuunnittelu
   2. Loppukäyttäjäkoulutussuunnittelu
   3. Loppukäyttäjäkoulutusmateriaalin tuotto
2. Konfigurointi SAP sekä muihin järjestelmiin
   1. Konfigurointi toteutus (tilikartta, yritykset, toimipisteet, organisaatiot, jakelutiet, ryhmät, …)
   2. Konfiguroinnin testaus
3. Järjestelmän tekninen hallinta
   1. Asennetaan verkot ja koneet
   2. Asennetaan ohjelmistot ja järjestelmät.
   3. Tuotantolaitteisto käytettävissä
4. Liittymät
   1. Liittymät pankkeihin yms.
   2. Muut liittymät
5. Konversiot
   1. Luodaan konversiomenetelmät
   2. Testataan konversiot

Koulutuksen suunnittelu

Jos toteutus ja testaus yhdistetään, tällöin ensimmäisenä on käyttökoulutuksen suunnittelu sekä loppukäyttäjille että pääkäyttäjille. Loppukäyttäjädokumentaation toteutus on usein asiakkaan vastuulla ja sen tekevät usein pääkäyttäjät. Tämä on usein hyvä myös siitä syystä että opettaminenhan on yksi tehokkaimmista tavoista oppia uutta. Loppukäyttäjädokumentaatioon kannattaa ehdottomasti lisätä myös videota ts. videoida kaikki prosessit ja transaktiot joiden perusteella oppiminen käy nopeammin. Tähän on olemassa myös SAPilla työkalu nimeltä SAP Tutor, jolla voi nauhoittaa transaktioita ja lisätä interaktiivisuutta niihin, ts. ohjelma odottaa käyttäjältä oikeanlaista tietoa oikeaan kenttään ennen jatkamista. Vaikka tämän toteutus koettaisiinkin ylimääräiseksi työksi opetusmateriaalin luontivaiheessa, se maksaa itsensä nopeasti takaisin. Helpoin tapa tietenkin on videoida oikeaoppinen prosessi jollakin ruudunkaappausohjelmalla.

Kannattaa viimeistään tässä vaiheessa myös käydä keskustelu (ellei jo aiemmin sovittu) jotta miten konfigurointi dokumentoidaan. SAPilla on ns. Solution Manager jota voidaan hyödyntää tässä tai se voi olla toimittajalla jonne asiakkaan tiedot ladataan, mutta joka tapauksessa asiakkaalla olisi hyvä olla TARKALLA tasolla dokumentaatio mitä konfigurointia on tehty ja miksi. Jos tätä ei tehdä selväksi ennen toteutusta – ei dokumentaatio tule koskaan olemaan halutulla tasolla. Käyttöönoton jälkeen tekeminen on paljon verkkaisempaa eikä kannata päästää toimittajaa pinteestä sopimalla dokumentaation päivittämisen käyttöönoton jälkeiseen aikaan. Tämä jo siksi että koulutusdokumentaation tekeminen on työläämpää ja jos asiakas tekee itse loppukäyttäjämateriaalin – no, tuskin tarvitsee kertoa enempää. Laadunvarmistus koskee erityisesti dokumentaatiota. Yksi hyvä tapa luoda koulutus-, käyttö-, yms. dokumentaatio on aloitaa liiketoimintaprosessitasolla ja edetä tästä alaspäin niin tarkalle tasolle kuin halutaan. Tämä kannattanee tehdä HTML-sivuiksi joka voidaan linkittää minne sitten intranetissä halutaan. Alla kuva havainnollistamassa asiaa. Entä jos käyttäisikin Blogia dokumentaatioon/ viestintään?

Myös SAPin HELP -dokumentaatio voidaan tuoda SAPiin joka voi auttaa käyttäjiä.

Konfigurointi

Konfigurointiin ei yleensä ota asiakas osaa, vaan konsultit (Intiassa tai muualla) toteuttavat tämän. Konfiguroinnissa olennaista on järjestys. Jos toimittajalla oli jokin esiparametroitu SAP-ratkaisu, he todennäköisesti lataavat paketin sisään ja sitten muokkaavat/päivittävät toiminnot määrittelyjen mukaiseksi. SAPilla on myös Best-Practice ratkaisuja, joita voidaan hyödyntää konfiguroinnissa. Niistä saa paljon oppia vaikka konfigurointia ei näiden perusteella tehtäisikään. Konfigurointiin pääsee kiinni SAPissa transaktiolla SPRO, jos käyttöoikeudet antavat myöten. Konfigurointi on listattu kategoriamaisesti jossa pääsee aina syvemmälle tasolle tarvittaessa. Ei itse asetusten muuttaminen ole vaikeaa – sen sijaan riippuvuuksien huomioiminen on. On olemassa jonkin verran legendoja ja esimerkkejä että on muutettu yksittäinen kenttä jotakin maata varten toiseksi ja kas kummaa, maapallon toisella puolen tulosteet eivät enää pelaakaan.

Muutokset ja konfigurointi tehdää aina kehitysympäristössä. Muutoksesta syntyy siirtopyyntö (ns. Request) joka siirretään testiin ja testauksen jälkeen tuotantoon. Tähän on olemassa oma työkalunsa jonka osaaminen pitää olla vähintäänkin henkilöllä, joka siirtää jonkun hyväksynnän perusteella muutokset tuotantoon. Tämä on lähes poikkeuksetta asiakkaan vastuulla.

Järjestelmän tekninen hallinta

Toteutusvaiheessa asennetaan verkot, ohjelmistot ja laitteet mitä vielä ei ole tehty. Kehitys- ja testiympäristöhän kasattiin jo määrittelyvaiheessa. Jos käyttäjät käyttävät SAP-GUI ohjelmistoa päästäkseen SAPiin, on suositeltavaa asentaa jonnekin palvelimelle SAPin SAPAdmin Front-End Setup Manager. Tällä voidaan keskitetysti hallinnoida työkoneille asennettuja SAP-GUI asennuksia ja niiden versioita. Kun ladataan SAPAdmin ohjelmaan uusi paketti, kaikki käyttäjät saavat seuraavan kerran kirjautuessaan tästä tiedon ja voivat päivittää ohjelmansa (olettaen että heillä on käyttöoikeudet joihinkin paikalliselle koneelle asennettaviin SAP-GUI tiedostoihin, kuten saplogon.ini,..). Työkalulla voidaan myös päättää, mitkä toiminnot toimivat SAP-GUI kautta (Excel-rajapinta taloushallinnossa,..). Tässä vaiheessa asennetaan viimeistään myös tulostimet, jotka usein on jo verkossa, mutta pitää konfiguroida SAPiin. SAP voi ohjata suoraan tulostukset tulostimille, tai sen voi manuaalisesti valita. Tämä on pikku juttu jos tiedetään tarvittava informaatio kuten tulostimien nimet, ip:t, mallit, jne.

SAPin virheitä yms. hallitaan CCMS toiminnoin, joilla voidaan seurata hälytyksiä, asettaa ne lähetettäväksi haluttuun sähköpostiin jne. Sitten tietenkin pitää konfiguroida siirtopyyntöjen ketju valmiiksi jos ei sitä vielä ole tehty. Yksi olennainen huomio SAPin asennuksissa on että kun vaihtaa raudan tai asentaa SAPin, pitää tämän raudan HW-ID päivittää SAPin sivuilla. Jos tätä ei tee, on yllätys XX päivän päästä kun SAPiin ei pääse kukaan kiinni. Teknisiksi ylläpitäjiksi tulevien kannattaa opetella SAPin asennus koska tästä oppii paljon. Sitä kannattaa tehdä vaikka jollekin ulkoiselle palvelimelle, jossa on potkua riittävästi. Palvelimen pitäisi olla sellainen, että sen saa surutta vetää tyhjäksi tarvittaessa ja aloittaa kaikki alusta.

Jos on useita SAP-asennuksia, voidaan kaikki SAPit kytkeä SAP Solution Manageri ohjelmaan ja valvoa keskitetysti virheitä ja hälytyksiä. Jos on tehty sopimus jossa valvontavastuu on toimittajalla, voi olla hyvä ottaa käyttöön Solution Manager toimittajan päässä ja sopia jaksottaisista automaattiraporteista joita toimittajan Solution Manager puskee ulos. Uuden SAPin (6.0) asennus vaatii Solution Manager -avaimen, mutta tämän voi kiertää ja monissa yrityksissä juuri näin on tehtykin. Itse en tunne tätä osa-aluetta tarpeeksi hyvin jotta siitä osaisin tarkemmin kertoa, mutta isot pojat ovat kertoneet, että tässäkin kannattaa lähteä pienestä liikkeelle ja laajentaa kun osaamista karttuu. Solution Managerillahan voi jollakin tasolla hallita myös prosesseja, ts. muuttaa konfiguraatiota.

Liittymät

SAPissa on vakiona paljon rajapintoja erilaisten liittymien toteuttamiseen, mutta usein (varsinkin NetWeaver maailmassa) otetaan käyttöön myös SAP XI, joka onkin de-facto ratkaisu SAPin ja ulkoisten järjestelmien liitoksille. En lähde tässä tarkemmin kuvaamaan lisensointimallia, mutta tästä kannattaa ottaa selvää ja sopia tarkasti asiat. XI:llä liittymien toteutus on helppoa. SAPista saa suoraan ladattua SAPin sanomakuvauksen (RFC,IDoc,…) ja jos tiedetään toisen pään tiedostokuvaus TARKASTI, ei mäppäyksessä kauaa mene (ehkä). Pahimpia ongelmia syntyy, kun yritys-erehdys periaatteella kokeillaan liittymät toimiviksi ja seuraavan vuoden ajan sitten tehdäänkin jatkuvasti pieniä lisäyksiä ja muutoksia mäppäykseen eikä kenelläkään ole enää kivaa. SAPiin voidaan myös tehdä liittymiä suoraan esimerkiksi WebServices rajapinnoin tai kutsua suoraan RFC-funktioita. Java-puolella tälle on olemassa ratkaisu nimeltä Jco – Java Connector ja PHP puolella PHP-RFC paketti. SoapUI -työkalulla voidaan testata myös liittymiä kun ladataan SAPin WebServiceBrowser toiminnallisuudesta (selain-pohjainen) WSDL paketit omalle koneelle. Teknisesti liittymät tekee nopeasti, mutta jos pitää luoda esimerkiksi jonkin tapahtuman pohjalta sanoma ulkoiseen järjestelmään, on yleisimpiä vaihtoehtoja muutamia:

• Workflow – työnohjaus
• Oma funktio/raportti liipaisulla tai tausta-ajona
• Sanomaohjaus erilaisin parametrein
• Tausta-ajot valmiiden SAP-raporttien/funktioiden osalta

Sanomaohjaus kannattaa opetella kunnolla, koska tämä on yksi yleisimpiä toiminnallisuuksia ja käytetään SAPissa laajasti (tulosteet, sisäinen laskutus, ostotilaukset EDInä,…)

Jos rajapintafunktiot tehdään aina itse, pitää SP-tason nostossa tai version vaihtuessa tarkistaa funktioissa käytettyjen alifunktiokutsujen ajantasaisuus ja muuttumattomuus (kuten aina). Lisäksi SAPissa on niin paljon valmiita funktioita (RFC) ja sanomarajapintoja (IDoc, XML) että harvoin täytyy luoda kaikkea täysin nollasta. Olennaista on kuitenkin että SAPin vakiotoimintoihin EI TEHDÄ muutoksia, koska uusi versio tai SP-tason nosto voi ylikirjoittaa muutokset ellei olla tarkkana. Tosin tämäkin sääntö on tehty rikottavaksi ja joskus on pakko vähän säätää… Maininnan arvioinen asia on myös kassaliittymä (Retail), jota hallitaan SAP konfiguraatiossa (POS Profile,..).

Konversiot

Konversioiden määrä riippuu pitkälti vietävän datan suuruudesta. Konsultit ehdottavat että jos dataa ei ole esimerkiksi yli 200 riviä per data-aineisto (kuten tuotteet, asiakkaat jne), kannattaa data viedä SAPiin käsin. Konversioiden osalta tulee olla erityisen tarkkana. Data, mitä viedään SAPiin tulee myös tarkistaa useaan kertaan. Jos kuraa menee sisään, ei se SAPissa muuksi muutu. Lisäksi poistaminen SAPista tapahtuu arkistoinnin kautta joka työllistää kohtuullisesti. Hyvä tapa on antaa toimittajan luoda excel-taulukot, joissa kuvattu tiedot mitä SAPiin viedään ja testata konversiot. Valmiista Excel-kuvauksesta sitten tehdään asiakkaalla esimerkiksi johonkin MySQL kantaan vastaava kuvaus ja ladataan täytetyt excelit kantaan. Jos tässä käytetään esimerkiksi PHP:tä apuna, voidaan nopeasti tehdä erilaisia parsereita ja tarkistuksia, sekä dataa voidaan massana muuttaa halutunlaiseksi joka mahdollistaa exceleissä sarakkeiden minimoinnin. Tällä välin toimittaja tekee esimerkiksi LSMW-työkaluun asetukset, jolla voidaan data ajaa sisään. Tämä työkalu on tarkoitettu nimenomaan migraatioihin ja alustuksiin. Jos työkalusta halutaan pysyvä, LSMW:hen ei kannata kovin tarkalla tasolla työstää tarkistuksia, ettei sitä jouduta jatkuvasti muuttamaan. XI mahdollistaa myös datan siirtämisen sisään suoraan MySQL-kannasta, jolloin samat rajapinnat palvelevat myös käyttöönoton jälkeenkin jos niin halutaan, olettaen että mitään erillistä tuotehallintaratkaisua ei ole. Tästä enemmän myöhemmässä artikkelissa. TxShuttle on myös hyvä työkalu, jolla voi Exceleistä dataa viedä sisään. Sitten on tietenkin CATT työkalut. Taulukuvauksia ja taulujen sisältöä näkee transaktiolla SE11 ja SE16 ja sisällön voi ladata tätä kautta esimerkiksi Exceliin suoraan. Muutenkin kannattaa opetella asiakkaalle tärkeimmät SAPin taulut koska täältä näkee nopeasti mitä tietoa on viety sisään, kuka muuttanut yms..

Kun konversiot on tehty, on aika ladata data sisään. Sisään lataus tapahtuu testiympäristöön aluksi, jossa asiakkaan organisaatio suorittaa hyväksyntätestit omalla sisään viedyllä datallaan. Tuotantoon tehtävä konversio käsitellään myöhemmässä artikkelissa. Seuraavassa dokumentissa pureudutaan raportteihin, käyttöoikeuksiin, tulostuksiin ja testaukseen.

Read Full Post »

SAP ERP Projekti – Osa 5: Toteutus

Tämä artikkeli on osa artikkelisarjaa SAP ERP projektin läpiviemisestä. Tässä osassa keskitytään käymään läpi SAPin raportointia, tulosteita, käyttöoikeuksien hallintaa ja testausta. Mikähän kumma siinä on, että puhuttaessa tulosteiden muokkaamisesta tai uusien sellaisten luomisesta ovat kaikki konsultit pöydän alla piilossa?

Jo projektista sovittaessa kannattaa huolehtia, että halutut tulosteet on määritelty jo ennakkoon. Yleensä projektiin ei sisälly tulosteiden tai raporttien muokkaamista ja silloin täysin poikkeuksetta joutuu maksamaan tästä lisähintaa ja koska aikautaulu on tiukka, ei halutunlaisia tulosteita välttämättä ehditä tehdä jne jne..

Tähän artikkeliin sisältyy projektisuunnitelman vaiheet jotka alla:

1. Raportointi
   1. R/3 Perusraportit
   2. Räätälöidyt raportit
   3. Mahdolliset SAP BW raportit
2. Tulosteet
   1. Tulosteiden läpikäynti
   2. Tulosteiden muutokset
3. Käyttöoikeusmäärittelyt
   1. Määritellään käyttöoikeustasot SAPiin ja ulkopuolisiin järjestelmiin
   2. Luodaan roolitukset
   3. Testataan käyttöoikeudet
4. Integraatiotestaukset
   1. Testiryhmän kokoaminen
   2. Testin laajuuden määritys
   3. Testiprosessien määrittely
   4. Testauksen toteutus
5. Tulosten läpikäynti ja analysointi

Raportit

SAPista löytyy raportteja vaikka mihin tarpeeseen. Niitä voi myös itse toteuttaa lisää SAP Queryn avulla ohjelmoimatta yhtään riviä. Taloushallinnolle on olemassa täysin oma raporttikehitystyökalu ReportPainter. Lisäksi voidaan koodata uusia ABAP-ohjelmointikielellä. Näistä kahdella ensimmäisellä saa tehtyä osaava henkilö muutamassa minuutissa halutunlaisia raportteja jos ei SAPin valmiit raportit miellytä syystä tai toisesta. Ennen toteutusta suosittelisin kuitenkin tutkimaan jo olemassa olevat raportit, koska on hyvin todennäköistä että haluamasi raportti on jo olemassa. Sovellusanalyysivaiheessa tulisi jo kertoa, millaista tietoa SAPista halutaan seurata jotta voidaan etsiä tähän sopivat raportit. Näiden oikeellisuuden tarkistus on yksi olennainen osa hyväksyntätestauksessa. Raportit voivat näyttää oikeellisilta, mutta raportti voi laskea väärin ja siksi on tärkeää tarkistaa ne myös laskemalla itse jos mahdollista. Raportointi SAPissa jakaantuu erilaisiin informaatiojärjestelmiin kuten LIS (logistic information system), joka sisältää

• SIS (Sales information system),
• PURCHIS (Purchase information system),
• INVCO (Inventory Controlling)
• QMIS (Quality Management Information System) ja
• RIS (Retail information system) jota tosin ei ylläpidetä enää versiosta 4.6c eteenpäin vaan SAP suosittelee ja on suositellut jo pitkään Retail-maailmaan SAP BW käyttöönottoa suurten tapahtumamäärien vuoksi.

joissa data on tallennettu ns. inforakenteisiin (infosets). Nämä rakenteet ovat kuin tietokantatauluja ja erinäisillä raporteilla että transaktioilla voidaan kutsua haluttua inforakennetta ja noutaa tästä haluttu data.

Tulosteet

Tulosteiden osalta on lähes poikkeuksetta totta, että kukaan konsultti ei halua näitä lähteä muokkaamaan saati tekemään uusia. Tälle itse olen päätellyt syyksi SAPin vanhan SAP Script menetelmän, jolla vielä nykyäänkin on toteutettu ja toteutetaan osa tulosteista. Työkalu ei ole niitä helppokäyttöisempiä ja pientenkin lomakemuokkausten teko voi olla suuritöistä ja asiaa ei auta kiittämätön asiakas, jolle jokin viiva voi olla kaksi pikseliä liikaa vasemmalla tai oikealla. Ei siis ihme että SAP on integroinut Adoben työkaluja itseensä jonka käyttöönotto taitaa olla ensimmäistä kertaa mahdollista versiossa 5.0 eli SAP ERP 2004. Toinen käytetty tulostuslomakkeiden työkalu on SAPin Smartforms joka on myös transaktion nimi. Tällä muokkaaminen on jo helpompaa ja tähän löytyy jo valmiinakin perusraportit kuten ostotilaus, tilausvahvistus, tarjous jne. Tämän blogin kirjallisuus osiosta löydät kirjan tähän.

Itse miettisin kahdesti mm. Adoben työkalujen hankkimista. Ensinnäkin järjestelmä on aika kallis ja vastaavan toteuttaa itse murto-osalla tästä rahasta open-source työkaluin. En tunne Adobea niin hyvin että osaisin sanoa, voiko Adoben työkalulla tehdä myös tulostuslomakkeiden muutokset, mutta jos voi, silloin tämän käyttö voisi olla perusteltua. Joku asiaan enemmän perehtunyt voisi kommentoida, millainen Adobe-lisäosan käyttöönotto oikeasti on.

Käyttöoikeudet

Käyttöoikeudet ovat yksi eniten tukiorganisaatiota työllistävä asia. Varmaa on että luodut käyttäjäroolit eivät ainaisesti sovi yritykselle, vaan jossakin välissä joudutaan näitä muuttamaan. Jotta käyttöoikeus-asiaa voisi analysoida ja määritellä, tulee tuntea myös SAPiin konfiguroidut organisaatiorakenteet. Tämän pohjalta on usein tehty käyttöoikeus-roolit ja omakohtainen näkemykseni on, että tätä ei kannata viedä äärettömyyksiin. Liian tarkalle tasolle vietynä tästä tulee jatkuvaa säätämistä tukitiimille ja liian vähäisenä taas käyttäjä näkee ehkä liikaa asioita mitkä hänen tehtäväänsä ei kuulu.

Käyttöoikeudet voidaan oikeasti määritellä vasta sitten, kun tiedetään millaisia reaalimaailman ryhmiä, organisaatioita ja henkilöitä tulee SAPia käyttämään, millainen on SAPin organisaatiorakenne ja että mihin organisaatiorakenteisiin, yrityksiin, toimipisteisiin jne. käyttäjän tulee päästä tehdäkseen myyntiä, tavaran vastaanottoja, ostoja jne. Nämähän on käyty läpi määrittelyvaiheessa. Jokaiselle transaktiolle voidaan määrittää oikeudet organisaatiorakenteen mukaisesti. Jos esimerkiksi myyntiorganisaatiotasolla on arvona *, tämä tarkoittaa että kaikki myyntiorganisaatiot on sallittuna. Yleensäkin * tarkoittaa kaikille avointa. Rooleista generoidaan sitten profiilit. Niitä ei tule muuttaa käsin. Käyttäjän profiilissa näkyy molemmat, sekä roolit että profiilit. Käyttäjälle voidaan antaa myös pääsy kaikkialle SAPissa johon on olemassa oma SAPin valmis profiili, mutta jota en tässä paljasta jotta me kaikki saisimme nukkua yömme rauhassa. Käyttäjän takana on myös lisenssitiedot, ts. välilehti ja siellä tieto, mihin käyttäjäryhmään käyttäjä kuuluu. Tämän perusteella SAP suorittaa lisenssimittauksen. Tästä syystä on tärkeää, että vastuu käyttöoikeuksista on jollakin nimetyllä taholla. Käyttäjän takana on paljon muutakin tietoa kuten sähköpostiosoite, parametrit joilla voidaan esiasettaa arvoja transaktioille jne. mutta ei niistä sen enempää.

SAPilla on olemassa myös keskitetty käyttäjien hallintatoiminnallisuus, jota itse en ole käyttänyt, mutta jonka käyttö voisi olla mielekästä jos ympäristöjä on useita. Tämä on oma client josta käyttäjien salasanoja yms. voidaan ylläpitää keskitetysti. Se mahdollistaa myös kehitys-testi-tuotanto ympäristöjen samanaikaisen tunnusten ja oikeuksien ylläpidon. Nykyään tämä taitaa olla integroituna SAP Solution Manageriin, mutta tästä en ole 100% varma. Kommentoikaa jos olen väärässä.

Kolmas vaihtoehto on integroida SAP yrityksen nykyiseen käyttäjähallintaratkaisuun ja SAP tukeekin LDAP mallia. Mielestäni tämä on tehtävä heti jos yrityksessä on paljon käyttäjiä ja käytössä useita käyttöoikeuksin rajoitettuja ratkaisuja. SAPista riippumaton keskitetty käyttäjähallinta mahdollistaa sen, että yksillä tunnuksilla voidaan kirjautua eri järjestelmiin ja poistuvien/saapuvien työntekijöiden osalta tunnusten luontia / poistoa tarvitsee tehdä vain yhteen paikkaan joka helpottaa merkittävästi ylläpitämistä. Myös kulunvalvonta yms. voitaneen integroida tällaiseen haluttaessa. On myös päätettävä ketkä perustavat käyttäjiä SAPiin, ketkä valvovat poistuvia käyttäjiä jne. Usein tähän joudutaan toteuttamaan jonkinlainen lomake jolla pyydetään tarvittavat tiedot oikeuksien ylläpitämiseksi. Lomakkeella tulisi olla myös esimiehen kuittaus jotta tiedetään hänen hyväksyneen myös mahdolliset syntyvät kustannukset.

Integraatiotestaus

Integraatiotestauksessa testataan konfiquroinnin ja liittymien toimintaa. Sen tekee yleensä osin asiakas, mutta myös konsultit ovat tässä vahvasti mukana. Testauksessa voi hyödyntää joitakin automatisoituja testityökaluja kuten Mercuryä joka tulee SAPin asennuslevyjen mukana, mutta usein työmäärä on paljon isompi tätä kautta kuin mitä itse testaukseen menee aikaa tietojen syöttämisineen. Testauksesta laaditaan pöytäkirjat, testitapaukset ja näiden perusteella korjataan havaitut virheet. Kaikki dokumentaatio kirjataan esimerkiksi redmine -pohjaiseen projektikirjastoon. Testitapaukset suunnittelee usein vielä tässä vaiheessa toimittaja. Näitä testitapauksia asiakas voi hyödyntää myös hyväksyntätestauksessa jossa asiakkaan tehtävänä on määritellä testit. Kun testit on tehty hyväksytysti, on aika siirtyä käyttöonoton valmisteluun. Asiakkaan kannattaa osallistua tähän mahdollisimman paljon, koska vielä tässä vaiheessa on testauksen varjolla mahdollista saada ”ilmaista koulutusta” konsulteilta. Samalla oppii prosessit päästä päähän. Organisoinnin osalta kannattaa miettiä, opettaako kaikille pääkäyttäjille (joita oletan testaajien olevan) päästä päähän prosessit vaiko opettelevatko jokainen vain oman alueensa. Itse suosin mallia että kaikki olisivat opettelemassa muidenkin osa-alueita koska tämä tulee väistämättä esiin viimeistään käyttöönotossa. Myös virheiden korjaus ja välttäminen helpottuu jos esimerkiksi logistikko tietää mitä myyntivaiheessa olisi pitänyt tehdä tai että tietää, miksi vastaanottoa ei voidakaan tehdä kun perustiedoissa on virhe, ostotilauksella virhe tms. Tässä pärjäävät paremmin organisaatiot jotka uskaltavat antaa enemmän tietoutta käyttäjälle kuin että lokeroisivat tiukasti käyttäjät johonkin moduuliin tai prosessin osaseen.

Tämän vaiheen lopulla pidetään jonkinlainen istunto, jossa päätetään tuotantoon menosta ja analysoidaan testitulokset. Jos mitään hälyttävää ei ole tullut ilmi, siirrytään vaiheeseen ”käyttöönoton valmistelu”. Kannattaa myös analysoida, paljonko sovellusanalyysin tai määrittelyn aikaisista toiminnoista on jätetty/siirretty myöhempään vaiheeseen ja että nämä ovat myös GAP-analyysissä eikä niitä unohdeta.

Read Full Post »

SAP ERP projekti – Osa 3: Määrittely

Osassa 2 käsiteltiin projektin aloittamista ja tätä ennen tehtäviä toimenpiteitä joita olivat: Sovellusanalyysin luonti, Projektimetodista sopiminen, Yhteydenpidosta ja dokumentaatiosta päättäminen, SAP tiimin (projektitiimin) valinta ja SAP kouluttautuminen SAPin lähteitä hyödyntäen. Tässä artikkelissa keskitytään käymään läpi SAP-projektin valmisteluvaiheen päättäminen ja määrittely. SAP projekteja (kuten mitä tahansa projekteja) määriteltäessä on olemassa kolme määräävää tekijää:

• Aika
• Resurssit
• Kustannus

, joka voidaan piirtää tasakylkisenä kolmiona jos projektia viedään eteenpäin perinteisellä ASAP metodilla. Olennaista kolmiossa on sivujen mittasuhteiden säilytys. Jos halutaan lisää toimintoja, tämä tarkoittaa lisää resursseja, lisää aikaa ja lisää kustannuksia. Riippuen sopimuksesta projekti voi olla kiinteähintainen ja se voi samalla olla tavoitehintainen, ts. jos hinta ylittyy, portaittain vähennetetään esimerkiksi tuntihinnasta jokin osuus pois kunnes lopussa päätetään, mitä projektin kanssa tehdään. Toinen ääripää on tuntihintainen toteutus. Olennaista on kuitenkin että on artikkelin osa 1 mukaisesti sovittu projektin toteutustavasta ja projektiseurannasta puolin ja toisin sekä samalla kerrottu mahdollinen ulkopuolinen SAP-auditoija jota asiakas haluaa käyttää. Esittämäni reaaliaikainen projektikirjaston ja ns. tiketöintijärjestelmän käyttö on äärimmäisen suositeltavaa. Tällä tavalla projekti laskutuksineen on läpinäkyvä ja molemmat osapuolet tietävät missä mennään.

SAP määrittelyt

Alla määrittelyosion karkea projektirunko

1. Perusinfran + verkkopalvelujen määrittely
2. Järjestelmäarkkitehtuurin läpikäynti
3. Toimintojen läpikäynti
   1. Yhteiset toiminnot
   2. Perustietojen määrittely
   3. FICO – Taloushallinnon toiminnot
   4. MM-LO – Logistiikan toiminnot
   5. MM-PUR – Oston toiminnot
   6. SD – Myynnin toiminnot
   7. Liittymien määrittelyt
4. Konversioiden määrittely
5. Toimintojen hyväksyntä

SAP-projektin läpivienti ilman määrittelyjä (kuten minkä tahansa isomman kokonaisuuden toteuttaminen) on käytännössä mahdotonta. Kaikki tapaamiset, määrittelydokumentit ja viestintä tulee kirjata projektikirjastoon. Itse asiassa on parasta että projektikirjastoa käytetään myös viestintävälineenä. Näin kaikki viestintä, dokumentaatiot ja palaverit tallentuvat yhteen paikkaan. Jos asiakkaalla ei aiemmin ole ollut käytössään ERP ratkaisua tai se ei ole toiminut liiketoimintaprosessivetoisesti, muutos on väistämättä iso. SAPissa on liiketoiminta jaoteltu lohkoihin: SD – myynti + lähtevä logistiikka, MM – saapuva logistiikka + osto, WM – Keskusvarasto, FICO – sisäinen ja ulkoinen taloushallinto joka on hyvä tunnistaa jo tässä vaiheessa ja tarpeen tullen aloittaa käytännön organisaatiouudistusten toteutus.

SAPin versio on yleensä sovittu jo sopimuksessa, mutta jos ei ole, kannattaa tätä miettiä tarkasti. Yleensä aivan uusinta versiota ei kannata ottaa käyttöön, koska siinä on yleensä vielä paljon virheitä ja ongelmatilanteissa avun saaminen mm. SAPin noottien kautta ei ole mahdollista vaan kaikki ongelmatilanteet on raportoitava suoraan SAPin tukeen. Tällä hetkellä SAP ERP 6.0 (SAP NW 2005) on yleisin käyttöönotettava versio.

Liiketoimintaprosessimäärittelyt

SAP-projektin alkuvaiheessa liiketoiminta-alueiden konsultit perinteisesti haastattelevat asiakkaan liiketoiminnan ammattilaisia ja yrittävät tätä kautta saada selvyyden, kuinka SAP pitäisi konfiguroida ja löytyykö SAPista kaikki halutut toiminnallisuudet konfiguroinnin kautta, vaiko vaaditaanko laajennuksia tai ohjelmistomuutoksia SAPin koodiin. Määrittelyä helpottaa huomattavasti, jos konsulteilla on olemassa valmiit peruskysymykset joihin asiakkaan määrittelyryhmien tulee vastata ennen varsinaisten määrittelyjen aloittamista. Parasta olisi jos asiakkaalla olisi myös omat liiketoimintaprosessit kuvattuna prosessimaisesti (”laatikkoleikki”) esimerkiksi powerpoint-esityksinä.

Määrittelyvaiheessa kannattaa olla ehdottoman tarkkana. Olipa projektista sovittu mitä hyvänsä sopimuksissa ja sovellusanalyysin kautta, määrittelyvaiheessa tehtävät määrittelyt käytännössä rajaavat sen mitä tullaan toteuttamaan. Jos määrittelyssä halutaan tuoda esiin uusia toimintatapoja ja liiketoimintamalleja, ne on syytä olla tarkkaan dokumentoituja ja pohdittuja jo ennen projektin aloittamista, ts. liiketoimintaprosessit on oltava kuvattuna. Määrittelyn aikana on vaikeaa (ellei mahdotonta) enää alkaa itse liiketoimintaa kirjoittamaan uusiksi, konsulteilla kun on usein tarpeeksi suuri työ yrittää ymmärtää asiakkaan nykyistäkään liiketoimintaa (ja termejä).

Jos joistakin asioista ei päästä yhteisymmärrykseen, näistä luodaan ns. GAP-analyysi joka on yksinkertaisimmillaan Excel jossa luetellaan ne tahtotilat ja toiminnallisuudet, joita ei saada aikataulussa toimimaan halutulla tavalla. Priorisointi on myös hyvä tehdä näille, ts. päätettävä mitkä yritetään saada käyttöönottoon mennessä valmiiksi ja mitkä myöhemmin jos mahdollista. Tämän kirjaaminen on siksi tärkeää, että myöhemmin näitä ei jouduta käsittelemään muutoskäsittelyn kautta, josta aiheutuu ehkä mahdollisia lisäkuluja.

Älä unohda teknistä suunnittelua

Määrittelyjen aikana on hyvä käydä keskustelu SAPin teknisestä maisemasuunnittelusta (SAP Landscape) ja määrittää palvelinrauta, muistin määrä, palvelinten sijoituspaikka jos ei vielä tässä vaiheessa tätä ole päätetty. SAP asennetaan aina yleensä vähintään kolmelle palvelimelle kehitykseen, testiin ja tuotantoon johon konfiguroidaan kytkentä järjestelmien välille konfigurointien siirtämiseksi kehityksestä testiin ja tästä edelleen tuotantoon. Tietokannan valintaakin kannattaa hetki pohtia. Nykypäivänä mm. Microsoft on voimakkaasti yleistynyt SAP-maailmassa ja sen hyöty on mm. siinä että uudelleenorganisointia ei tarvitse tehdä toisin kuin Oraclella. Tämän sanon vain Microsoft kokemuksesta kun en paremmastakaan tiedä (ellei parempi ole MaxDB, MySQL:stä SAPin muokkaama versio, joka itse asiassa on hyvä alusta mm. portaalille ja XI:lle).

Tässä vaiheessa on hyvä miettiä jo neljättäkin SAP-asennusta ns. hiekkalaatikkoa joka ei ole kytkettynä ns. Transfer Request ketjuun (siirtopyynnöt kehityksestä testiin ja edelleen tuotantoon). Tämä siksi koska aina jossakin vaiheessa testin sisältö vanhenee ja usein on tarpeen testata asioita tuotantodataa vasten. Neljättä SAPia voidaan käyttää tuotannon homogeenisessa systeemikopioinnissa jossa tuotanto-SAP kopioidaan sellaisenaan neljänteen SAP-asennukseen ja tästä tarvittaessa edelleen kehitykseen ja josta testiin. Tämä tehdään yleensä kerran vuodessa. Tämän tekemättä jättäminen aiheuttaa huomattavasti lisätyötä tulevien testien tekemisessä, koska tällöin kaikkien mahdollisten testien vaatima data tulisi toteuttaa testejä varten yksinomaan, eikä siltikään saataisi kaikkia testitapauksia testattua. Hiekkalaatikko-SAPista on myös se hyöty, että jos tämä asennetaan jo määrittelyvaiheessa, voidaan pääkäyttäjät päästää järjestelmään kiinni opettelemaan SAPin saloja ja toteuttaa mm. navigaatiokoulutus. Varsinkin teknisille ylläpitäjille ja integraatioita suunnitteleville tämä on tärkeää.

SAPilla on mitoitukseen olemassa oma mitoitussivusto joilla voidaan karkeasti laskea tarvittavien palvelimien prosessi- ja muistimäärät. Tätä kirjoitettaessa SAP ei enää suosittele 32-bittisen järjestelmän käyttöönottoja ja kannattaakin aloittaa suoraan aloittaa 64-bittisillä alustoilla. Lisäksi kannattaa miettiä High-availability malleja, joihin SAPilla on olemassa lukuisia esimerkkimalleja joilla voidaan estää mm. SPOF-elementtien (Single-Point-Of-Failure) syntyminen.
SAPin suurimpia pullonkauloja suorituskyvyn suhteen on aina ollut muistinkäyttö ja 32-bittisessä maailmassa tämä raja tulee vastaan takuuvarmasti. Tämä johtuu siitä, että SAPin ohjelmistoja ajetaan muistissa jonne valitettavan usein SAPin vakiotoiminnoissa ladataan koko ohjelma kerralla ns. sisäisiin tauluihin (internal tables) ja jos ajo on suuri, loppuu muisti ja ajo pysähtyy jolloin syntyy ns. ABAP Dump. Tämä on yksi SAPin olennaisimpia asioita tausta-ajoja ja päivittäisiä töitä suunniteltaessa, joten on tärkeää ohjeistaa käyttäjiä suorittamaan haluamansa ohjelmat mahdollisimman tarkoin rajauksin. Tämä myös siitä syystä että SAPissa on X kpl eli määritellyn verran prosesseja käytössä (jossa limiitti tulee vastaan) ja jos esimerkiksi näitä on 15 kpl ja 5 käyttäjää varaa näistä 5 prosessia täysin itselleen suorittamalla resurssisyöppöjä ajoja, tämä tarkoittaa että SAPin suorituskyky heikkenee karkeasti 30% joka taatusti näkyy muille käyttäjille ohjelmasuoritusten hidastumisena.

Jos ylläpito tai vasteajoista on sovittu toimittajan kanssa, yllä esitetyt asiat on syytä käydä läpi, koska muuten toimittajan on käytännössä mahdotonta ottaa vastuuta vasteajoista ohjelmasuoritusten tai palvelujen saatavuuden suhteen.

Konversioiden määrittely

Konversioiden määrittelyt vanhoista järjestelmistä aloitetaan jo tässä vaiheessa. Riippuen organisaation ja yrityksen koosta (globaali, kansallinen) konversiot ovat yksi olennaisimmista asioista jotta SAP jatkossa toimisi halutulla tavalla. Jos vanhassa järjestelmässä tiedot eivät ole ajantasalla, on turha luulla että ne sitä olisivat uudessakaan, ts. jos kuraa vie SAPin sisään, ei se siitä muuksi muutu SAPissakaan.

Konversioissa määritellään ns. SAPin masterdataksi kutsuttu tieto jota ovat mm. tuotetiedot sisältäen myös tavararyhmittelyt, toimittaja-, asiakastiedot. Avoimen osto- ja myyntireskontran siirrosta on myös sovittava miten tämä tehdään (tarvitaanko vanhempaakin tietoa?). Jos SAPiin viedään vain avoimet tilaukset ja laskut ja vanha historiadata jää vanhaan järjestelmään, laaditaan ns. Audit Trail dokumentti (joka pitää aina tehdä) jolla voidaan osoittaa mm. tilintarkastajille, kuinka tiedot on viety uuteen järjestelmään. Tietojen täytyy olla yhtenäinen molemmissa järjestelmissä. Tämä dokumentti on tärkeä mm. verottajaa ajatellen vaikka tätä yleensä eivät muut kuin tilintarkastajat kysele. Nyrkkisääntönä konversioissa voidaan pitää määrää, jossa jos yksittäisiä konvertoitavia rivejä on yli 200, ne voidaan konvertoida, muussa tapauksessa kannattaa syöttää tiedot SAPiin käsin.

Kun mietitään konversioita, yksi olennainen asia on jatkossa tavarantoimittajille tai valmistajille lähetettävien SAPin ostotilausten numerot. Eli jos on avoimia ostotilauksia toimittajille ja tavara ei tule ennenkuin SAP otetaan käyttöön, pitää nämä tilaukset perustaa esimerkiksi vaikka käsin SAPiin ja lähettää syntyneet ostotilausnumerot toimittajille. Tämä siksi, että SAPiin voidaan ottaa vastaan saapuvia toimituksia ostotilauksen, rahtikirjan tai muun ulkoisen numeroinnin avulla (tai ilman numeroa), jossa on eroja riippuen halutusta toimintatavasta. Yleensä tämä on kiinnitetty SAPin ostotilausnumeroon. Jos toimittajille ei lähetetä uusia tilausnumeroita jo sisällä olleille tilauksille ja tilauksia on paljon, alkaa todella hikinen urakka vastaanotossa selvittää, mikä vastaanotto kuuluu millekin toimitukselle. Ennenkuin ostotilauksia voi syöttää SAPiin, pitää tuotteet ja toimittajat olla syötettynä järjestelmään, ts. master data kunnossa. .

Konversiot voidaan suorittaa monella tapaa, mutta yleensä käytetään SAPin LSMW-(Legacy System Migration Workbench) työkalua. Työkalun avulla on mahdollista luoda erilaisia tarkistuksia ja mäppäykset tietojen viemiseksi SAPiin. Jos käytössä on SAP XI, tätä voidaan myös hyödyntää tai käyttää muita valmiita rajapintoja (RFC,Batch Input, IDoc jne..). Toteutustapoja on useita ja datan osalta on vain löydettävä se paras ratkaisu huomioiden myös tulevaisuuden tarpeet (massatuoteperustamiset, yms). Se joka väittää että SAPiin on vaikea viedä dataa sisään tai sitä tuoda ulos, ei oikeasti osaa SAPin rajapintoja tai näiden toiminnallisuutta. Nykypäivänä lähes kaikkiin tarpeisiin on useitakin valmiita rajapintoja.

GAP-analyysi

Projektin määrittelyjen aikana tulee kirjata ylös (esimerkiksi Exceliin) puutteita, joita ei kyetä määrittelemään syystä tai toisesta. Tästä puutelistasta käytetään nimitystä GAP-analyysi. Analyysi on yksinkertaisuudessaan koottu lista, joka sisältää kaikki puutteet mitä määrittelyn aikana ja erityisesti ENNEN blueprintin hyväksyntää on havaittu. Olennaista GAP-analyysissä on kirjata ylös kaikki ne asiat, joita ei syystä tai toisesta voida tehdä projektin aikana tai ei vielä tunneta kaikkia tekijöitä. GAP-analyysi voidaan jakaa alla olevan jaottelun mukaisesti jossa jokaisella moduulilla on olemassa kuusi pääkohtaa sekä teknisesti yhteisenä kolme kohtaa.

Moduulikohtaiset:

• Organisaatiorakenne
• Perustiedot
• Toiminnallisuus
• Raportointi
• Tulosteet
• Käyttöoikeudet

Tekniset:

• Liittymät
• Konversiot
• Basis

Moduulikohtaisesti ryhmät pitävät sisällään erilaista tietoa. Esimerkiksi tulosteet SD ja MM moduuleilla eroavat toiminnallisuudenkin mukaan. SD-moduuli käsittelee tilausvahvistuksia, tarjouksia, laskuja ja MM-moduuli käsittelee ostotilauksia. lähetyslistoja jne. Sama on jokaisella ryhmällä.

Toimittaja voi haluta viedä nämä muutosprosessilla läpi jolloin kannattaa selvittää, tuleeko tästä muutoskäsittelyn mukainen lisämaksu. Asiakas on vielä vahvoilla tässä vaiheessa, joten ei kannata hyväksyä Blueprintiä ennenkuin myös GAP-analyysi on ajantasalla.

Määrittelyn hyväksyntä

Määrittelyn loppuvaiheessa määrittelyt kootaan yhteen ns. Blueprint -dokumentaatioksi. Määrittelyvaihe päättyy tämän dokumentaation hyväksyntään jonka asiakas allekirjoituksellaan hyväksyy. Blueprintin hyväksynnässä kannattaa käyttää SAP-konsulttia asiakkaan puolella tarkastamassa että määrittely on laadultaan riittävä. Konsulttia voidaan käyttää jo aiemmin tarkistamaan projektikirjastoon tehtailtujen määrittelydokumenttien laatu. Kun määrittely hyväksytään, siirrytään samalla toteutus/testaus vaiheeseen josta enemmän artikkelisarjan osassa 3.

Dokumentit

• Liiketoiminnan osa-alueiden dokumentaatio (organisaatiorakenteet, perustiedot, toiminnallisuudet, tulosteet, raportit, käyttöoikeudet)
• Liittymät
• Konversiot
• Asennusdokumentaatiot + landscape
• GAP-analyysi

Read Full Post »

SAP ERP projekti – Osa 2: Valmistelu

Tämä artikkeli on SAP ERP projekti -artikkelisarjan toinen osa. Se sisältää tietoa projektimetodeista, hallinnoinnista ja yhteydenpidosta ja artikkelin lopussa on kuvattu ne dokumentit jotka tässä vaiheessa yleensä tehdään.

2. Valmisteluvaihe

Kun sopimuksesta on päästy yksimielisyyteen ja itse projekti alkaa, tehdään ensimmäisenä ns. valmisteluvaihe. Tässä vaiheessa haalitaan resurssit asiakkaan puolelta, sovitaan projektin toimintatavoista jne.

2.1. Projektimetodeista hieman

SAPin tarjoamaa valmista projektimetodia kutsutaan ASAP (Accelerated SAP) -metodiksi. Metodi on SAPin laatima menetelmä projektin läpiviemiseksi projektin käynnistämisestä käyttöönottoon. Se on hyvin tarkka malli jossa kärjistetysti ilmaisten on kerrottu millaisia tusseja mihinkin palaveriin tarvitaan. Maalaisjärkeä kannattaa käyttää, eikä turhaa vaikeuttaa projektia liiallisella byrokratialla. ASAP on se malli, jolla toimittaja lähes poikkeuksetta nykyään esittää projektia vietävän eteenpäin. Olennaisin asia metodissa on huomioida ns. muutoskäsittely, jossa oletetaan että projektin määrittelyvaiheessa tehdään tarkka määrittely halutusta kokoonpanosta ja toiminnoista joita ei projektin aikana enää muuteta ilman erilliskustannuksia. Muutoskäsittelyllä sovitaan miten muutokset hoidetaan projektin aikana ja paljonko tästä tulee mahdollisia lisäkustannuksia asiakkaalle. Mielestäni mikään muu projekteissa ei ole varmaa kuin se, että jokin asia takuuvarmasti muuttuu määritellystä. SAPin osalta projektit kestävät keskimäärin kuudesta kuukaudesta kahteen vuotta, jopa pitempäänkin. Tänä aikana tapahtuu yritysjärjestelyjä, liiketoiminnan painopiste saattaa muuttua, mitä vain voi tapahtua. Tämä malli ei mielestäni ole asiakkaan kannalta aina hyvä menetelmä, koska viimeistään muutoksista ilmoitettaessa alkavat projektin ongelmat, varsinkin kiinteähintaisissa projekteissa. Tämän ovat hiljalleen sisäistäneet myös toimittajat ja alkaneet tarjota vaihtoehtoista mallia projektien läpiviemiseksi, jota kutsutaan nimellä Scrum.

Scrum-metodi poikkeaa perinteisestä siinä, että asiakkaan ja toimittajan resursseista kootaan ryhmä joka priorisoi ja suorittaa maksimissaan kahden päivän mittaisia tehtäviä prioriteettien mukaisesti. Prioriteetit määrää joko asiakkaan srcum-master (joka vastaa projektipäällikköä tietyin poikkeavuuksin) ja itse scrum-tiimi. Ideana on että on olemassa kolme listaa (product backlog, release backlog, sprint backlog). Päälista on ns. Product backlog eli tuotelista josta siirretään julkaisulistaan tehtäviä versioittain tai vaiheittain. Tuotteen työlistan tehtävät kannattaa arvioittaa ulkopuolisella auditoijalla, joka tuntee SAPin toiminnallisuutta riittävän hyvin osatakseen sanoa, onko lista puutteellinen. Product backlog -lista peilaa sovellusanalyysia vasten. Release backlog, eli julkaisulistasta otetaan taas työn alle esimerkiksi viikon tai kahden välein tärkeimmiksi priorisoidut tehtävät relaatiosuhteet huomioiden, jotka viedään seuraavaksi läpi eli siirretään työlistaan. Tiimille pyritään antamaan täysi työrauha sprintin (työlistan) ajaksi ja työn alla oleviin tehtäviin ei saa tehdä muutoksia tiimin ulkopuolelta. Jos tehtävä osoittautuu laajemmaksi kuin kahden päivän työ, tulee tehtävä pilkkoa pienempiin osiin jonka tiimi tekee yhdessä scrum-masterin kanssa ja priorisoi uudelleen nämä tehtävät. Scrum metodissa olennaista on että joka aamu ryhmä kokoontuu yhteen jossa scrummaster kysyy jokaiselta kolme kysymystä:

• Mitä teit eilen?
• Mitä teet seuraavaksi?
• Onko ongelmia jotka haittaavat tehtävän valmistumista?

Palaveri ei saa kestää kuin korkeintaan 15 minuuttia, eikä palaverissa aleta ratkomaan ongelmia joita tiimiläiset tuovat esiin, vaan ne tehdään palaverin jälkeen yhdessä tiimin jäsenen tai jäsenten kesken.

2.2. Projektisuunnitelma

Alla yhdenlainen projektisuunnitelma-esimerkki, joka on osin ASAP -mallin mukainen, mutta josta on karsittu pois kaikki turha. Tällä projektirungolla SAPin olennaisimmat osa tulee otettua huomioon joskin jokainen tehtävä vaatii tarkemman kuvauksen alatehtävistä. Uudessa SAPissa ydintä kutsutaan nimellä ECC (Enterprise Core Component) joka sisältää erilaisia komponentteja, mutta käytännössä konsulttimaailmassa puhutaan yhä moduuleista. Sitten on tietenkin olemassa lisäosia kuten SCM (Supplier Chain Management), SRM (Supplier Relationship Management) jne. SAP onkin lyhennefriikin luvattu viidakko ja jotta lyhenteiden opettelu olisi tehty vieläkin vaikeammaksi, ne saatetaan uudelleen nimetä versiosta toiseen. Usein konsulteillakin on täysi työ pysyä nimeämisten perässä. Alla olevassa projektisuunnitelma -esimerkissä on käytetty mallia jossa ovat edustettuina modulit SD, MM, FI, CO ja metodina hybridimalli. Jos halutaan käyttää Scrumia projektimetodina, silloin pitäisi tehtävät kirjata huomattavasti tarkemmalla tasolla, varsinkin sprint-jaksoille jossa tehtävät saavat olla maksimissaan 2 htp. Huomioi, että ASAP -mallista poiketen toteutus ja testaus on tässä suunnitelmassa asetettu samaan kategoriaan jo siksi että samalla kun konfiguroidaan toimintoja, voidaan suorittaa integraatiotestit lähes samanaikaisesti ja nopeasti muuttaa konfigurointia jos toiminnallisuus ei tyydytä. SAPissa on tietty järjestys konfiguroinnille, jota on seurattava, jotta asioita yleensä voitaisiin tehdä. Näiden riippuvuuksien vuoksi on suositeltavaa, että moduuleista vastaavat konsultit kommunikoisivat mahdollisimman sujuvasti ja katkoitta keskenään (sama huone, reaaliaikainen keskustelukanava jne).

Jos käyttöönotettavia järjestelmiä on muitakin, vaikkapa SAPin portaali (EP- Enterprise Portal), SAP BW (Business Warehouse), SAP XI (Exchange Infrastructure), SAP MDM (Master Data Management), SAP CRM (Customer Relationship Management), POS (Point-Of-Sale), verkkokauppa, jne.. Näistä kannattaa jokaisesta luoda oma projektinsa ja vaiheistaa mielellään SAP ERP jälkeisiksi käyttöönotoiksi, koska pelkästään SAP ERP käyttöönotto on mittava projekti jonka haltuunotto käyttäjäorganisaatioissa ei tapahdu hetkessä. Usein vasta kuukausien päästä käyttöönotosta nähdään, mitä seuraavaksi pitäisi tehdä ja voi olla että vaiheistus joka tehtiin sopimusta tehdessä, joudutaan osin tai kokonaan repimään auki.

Jos asiakas toimii globaalisti ja toimipisteitä (plant tai site) on eri puolilla maailmaa, kannattaa SAP ottaa käyttöön yhdessä tai muutamassa maassa ja roll-outteina myöhemmin ottaa loput maat mukaan. Tästä tulee jonkin verran ylimääräistä työtä, mutta soppa on todella iso, jos kaikki maat yritetään saada kerralla mukaan. Tämä kaikki toki riippuu asiakkaan resursseista.

Huomioi, että alla esitetty projektirunko ei sisällä mahdollisia organisaatio- ja muita muutoksia vaan keskittyy pitkälti SAPin ja sen integraatioiden ympärille. Tässä artikkelissa projekti on tarkoitus viedä läpi ns. ”BigBang” -metodilla ja moduuleiksi on valittu myynti (SD), osto (MM-PUR), talous(FI/CO) ja logistiikka(MM-LO). Isoimmissa projekteissa projekteja viedään läpi enemmän prosessiohjauksella jossa jokaisella prosessilla on omistajansa. Tässä oletetaan projektin olevan PK-sektorille, joten moduulikohtainen organisointi on riittävä.

1. Projektin valmistelu
   1. Kick-Off tilaisuus
   2. Resurssit ja organisointi
   3. Pelisäännöt
2. Määrittelyt / Blueprint
   1. Perusinfran + verkkopalvelujen määrittely
   2. Järjestelmäarkkitehtuurin läpikäynti
   3. Toimintojen läpikäynti
      1. Yhteiset toiminnot
      2. Perustietojen määrittely
      3. FICO – Taloushallinnon toiminnot
      4. MM – Logistiikan toiminnot
      5. MM – Oston toiminnot
      6. SD – Myynnin toiminnot
      7. Liittymien määrittelyt
      8. Konversioiden määrittely
   4. Toimintojen hyväksyntä
3. Toteutus & Testaus
   1. Käyttökoulutuksen suunnittelu SAPin ja muiden järjestelmien osalta
      1. Pääkäyttäjien koulutussuunnittelu
      2. Loppukäyttäjäkoulutussuunnittelu
      3. Loppukäyttäjäkoulutusmateriaalin tuotto
   2. Konfigurointi SAP sekä muihin järjestelmiin
      1. Konfigurointi toteutus
      2. Konfiguroinnin testaus
   3. Järjestelmän tekninen hallinta
      1. Asennetaan verkot ja koneet
      2. Asennetaan ohjelmistot ja järjestelmät.
      3. Tuotantolaitteisto käytettävissä
   4. Liittymät
      1. Liittymät pankkeihin
      2. Muut liittymät
   5. Konversiot
      1. Luodaan konversiomenetelmät
      2. Testataan konversiot
   6. Raportointi
      1. R/3 Perusraportit
      2. Räätälöidyt raportit
      3. Mahdolliset SAP BW raportit
   7. Tulosteet
      1. Tulosteiden läpikäynti
      2. Tulosteiden muutokset
   8. Käyttöoikeusmäärittelyt
      1. Määritellään käyttöoikeustasot SAPiin ja ulkopuolisiin järjestelmiin
      2. Luodaan roolitukset
      3. Testataan käyttöoikeudet
   9. Integraatiotestaukset
      1. Testiryhmän kokoaminen
      2. Testin laajuuden määritys
      3. Testiprosessien määrittely
      4. Testauksen toteutus
      5. Tulosten läpikäynti ja analysointi
4. Käyttöönoton valmistelu
   1. Loppukäyttäjäkoulutus SAP, ulkopuolisten järjestelmien osalta
   2. Järjestelmän tekninen hallinta
      1. Tuotantoympäristön tulostimet ja spool-jonot
      2. SAP tausta-ajojen toteutus
      3. Variantti- ja muut toteutukset
   3. Luodaan käyttöönottosuunnitelma
      1. Suoritetaan vaadittavat konversiot
      2. Suoritetaan manuaalinen tietojen syöttö
   4. Suunnittelun viimeistely
   5. Tuotantoaloituksen hyväksyntä
      1. Varmistetaan käyttäjien valmius
5. Käyttöönotto ja tuki

2.3 Projektin sisäinen viestintä on avain onnistumiseen

Suurissa projekteissa ei kuitenkaan ole useinkaan mahdollista järjestää yhteisiä palavereja esimerkiksi maantieteellisistä eroista johtuen jolloin yleensä otetaan käyttöön jonkinlainen projektiseuranta- ja raportointiratkaisu, jollainen mm. redmine -ratkaisu on. Se on toteutettu Ruby-On-Rails toteutuksena. Joka tapauksessa ratkaisun tulee sisältää lähes reaaliaikainen viestintä, ts. jokaisesta tehtävästä ja asiasta mitä ratkaisuun kirjataan, tulisi lähteä sähköpostia määritellyille tahoille. Tällä tavalla tiedetään koko ajan projektin tilanne ja voidaan nopeasti reagoida ongelmiin. Näin toimittaessa 15 minuutin päivittäiset statuspalaverit käyvät turhiksi.

Redmine -työkalu mahdollistaa myös dokumentaation, kalenterimerkintöjen yms. tallennuksen keskitettyyn palveluun. SAP-projektissa syntyy paljon dokumentteja mm. sovellusanalyysi esimerkiksi liiketoiminta-alueittain, määrittelydokumentit, toteutusdokumentit, testausdokumentit, koulutusmateriaalit, palaverimuistiot ja myös yhteydenpidosta jää merkintä. Tämä mahdollistaa myöhemmin tarkemman seurannan sille, mitä päätettiin tehdä ja missä vaiheessa ja miten. Ratkaisu kannattaa ehdottomasti olla asiakkaan hallinnoimalla palvelimella ja tietokannalla jos osaamista tähän on riittäväsi koska näin projektin olennainen dokumentaatio jää asiakkaalle. Dokumentaatiota mm. koulutusdokumenttien yms. osalta on myöhemmin helppo päivittää ratkaisuun, varsinkin jos ratkaisu sisältää myös versiohallinnan tai tuen sille.

Projektisuunnitelmasta tai siitä powerpoint-muotoon muokatusta esityksestä tulee selkeästi käydä ilmi projektin kriittinen polku.

2.4 Asiakkaan resurssien kiinnittäminen

Pääkäyttäjä- ja projektitiimin voi koota monella tapaa. Joissakin organisaatioissa pääkäyttäjiä voi olla ainoastaan yksi henkilö, kun taas joissakin yrityksissä pääkäyttäjät on jaettu SAPin moduulien tai organisaatioiden perusteella. Tämän sanelee pitkälti se, aiotaanko itse ylläpitää SAPia ja millä tasolla. Oma ylläpito edellyttää että pääkäyttäjä(t) tuntee/tuntevat SAPin moduulin toiminnan hyvin ja osaavat mahdollisesti katsoa konfiguroinnista nykyiset asetukset. Erityisen tärkeää pääkäyttäjien osalta on että pääkäyttäjä ensisijaisesti tuntee omat liiketoimintaprosessinsa hyvin. SAPin tekninen tuki on asia erikseen, joka sekin yleensä vaatii jonkin verran liiketoiminnan ymmärtämistä.

SAP on erilainen IT-järjestelmä, koska liiketoiminta-osaamisella on erittäin suuri painoarvo ja tässä suhteessa ikärasismia ei ole vaan asia on juuri päinvastoin. Arvostetuimmat ja osaavimmat SAP-liiketoimintakonsultit ovat henkilöitä joilla on vahva osaaminen joltakin liiketoiminnan osa-alueelta ts. tuntevat alan erityispiirteet ja prosessit erittäin hyvin. SAP konsultit syntyvät usein SAP-käyttäjistä ja erityisesti SAP-pääkäyttäjistä siksi että he tuntevat valmiiksi jonkin liiketoiminnan osa-alueen erittäin hyvin ja asiakkaan kouluttamana ovat saaneet myös peruskoulutuksen SAPin osalta.

Toimittajat voivat tarkastella projektin kestäessä asiakkaan projektiryhmän jäseniä ja analysoida joukosta potentiaalisia SAP-konsultteja. Yleensä SAPin käyttöönoton jälkeen tapahtuu aina henkilöstön osalta vaihtuvuutta johon kannattaa varautua jo hyvissä ajoin – yleensä jo projektia suunniteltaessa. IT-2000 jo sinänsä kieltää suoran rekrytoinnin projektin aikana.

Projektiin on varattava ainakin seuraavat henkilöt:

1. Projektipäällikkö
2. Liiketoimintaryhmille jokaiselle vetäjä
3. Teknisen ryhmän vetäjä ja tiimi

Harvoin on tilanne se, että yksi henkilö asiakkaalta voi määritellä esimerkiksi myynnin toiminnan SAPiin, varsinkaan jos myyntiä tehdään monella rintamalla (verkkokauppamyynti, yritysmyynti jne). Nämä henkilöt, varsinkin ryhmien vetäjät kannattaa valita huolella koska heidän päätösten pohjalta SAP tulee myös pitkälti toimimaan, vaikka lupa etenemisille yms. tapahtuisikin myös johtoryhmässä. Henkilöt on hyvä sitouttaa yritykseen jollakin tavalla jo tässä vaiheessa, koska jotkut heistä todennäköisesti lähtevät ennemmin tai myöhemmin juniori SAP-konsulteiksi maailmalle.

2.5 Asiakasresurssien kouluttaminen

Koulutuksesta on sovittava koulutusaikataulu, karkea sellainen viimeistään valmisteluvaiheen lopulla ja tämä liitettävä projektisuunnitelmaan, jos tätä ei aiemmin ole tehty. SAP-työryhmille ja/tai pääkäyttäjille on kuitenkin huomioitava kouluttaa SAPia pitkin projektia, ei vain yhdellä kertaa projektin loppuvaiheessa.

2.6 Vaiheen dokumentit

Tässä vaiheessa tehtävät/aloitettavat dokumentit. Osa dokumenteista on vielä raakileita tässä vaiheessa, mutta kannattaa laittaa jo nyt asiakkaan projektipäällikölle tutustuttavaksi ja sisäistettäväksi. Tässä vaiheessa olisi hyvä antaa ASAP-metodista SAPin BestPractice ASAP paketti, koska tästä on paljon hyötyä vaikkakin sisältö on usein turhankin laaja. Sen läpi kahlaamalla saa kuitenkin hyvän kuvan, mitä pitäisi tehdä ja missäkin vaiheessa. Asiakkaan projektipäällikölle olisi hyvä antaa myös SAPin ASAP projektimetodipaketti, josta voi katsella, miten SAPin projekteja tulisi viedä läpi, vaikka projektimetodi ei tämä olisikaan. Se kuitenkin kertoo, mitä missäkin vaiheessa pitäisi tehdä.

• Projektisuunnitelma v1.0
• Alustava käyttöönottosuunnitelma v0.1
• Alustava koulutussuunnitelma v0.1
• Asennussuunnitelma v0.5
• Konversiosuunnitelma v0.5
• Liittymäsuunnitelma v0.5
• Testausmenettely v1.0
• Hyväksymismenettely v1.0
• Raportointimenettely v1.0
• Avointen asioiden hallinta v1.0
• Riskien hallinta v1.0 – TÄRKEÄ!
• Kommunikaation hallinta v1.0
• Laadun varmistus v1.0

Read Full Post »

Blogi käyttöönotto sisäisessä viestinnässä?

Blogit ovat olleet kuuma puheenaihe viimeiset pari vuotta Internetin alueella. Valitettavasti Suomessa blogit eivät ole lyöneet vielä läpi vastaavalla tavalla kuin esimerkiksi FaceBook, MySpace tai vastaavat palvelut, mutta kiinnostusta blogeihin on havaittavissa erityisesti yrityksen sisäistä viestintää koskien.

Ajatus ei ole uusi, tätä miettii varmasti moni organisaatio tahollaan. Tässä artikkelissä yritän avata blogin mahdollisuuksia ja tehokkuutta suhteessa Intranet järjestelmiin. Blogi on Wikipedian mukaan:

”…verkkosivu tai sivusto, jossa voidaan jakaa informaatiota avoimesti tai rajoitetusti esimerkiksi käyttöoikeuksien mukaan. Blogissa on mahdollista julkaista sisältöä tekstin lisäksi myös kuvien, videokuvan tai äänen muodossa. Tiedon esityksessä blogeille tunnusomaista – ”normaaleihin” www-sivuihin verrattuna – on ajan, linkityksen ja henkilökohtaisen näkökulman painotus. Muita tunnusomaisia piirteitä blogeille on kommentointimahdollisuus ja RSS- tai ATOM-syötteet, joiden avulla voidaan helposti ohjelmallisesti seurata ja levittää blogin sisältöä.

Blogit taipuvat myös yritysten työkaluiksi. Blogia voi kirjoittaa julkisesti asiakkaille ja sidosryhmille tai julkaista vain yrityksen työntekijöiden luettavaksi intranetissä. Molemmista löytyy jo Suomesta esimerkkejä: yrityksen sisäisessä intranetissä blogia kirjoittavat Finnairin toimitusjohtaja Jukka Hienonen ja Nokian toimitusjohtaja Olli-Pekka Kallasvuo….”

Myös tämä sivusto on blogialustalle toteutettu. Olen liittänyt tähän haluamani laajennukset, joita blogeihin löytyy netistä paljon. Laajin sivusto laajennusten lataukseen on WordPress.org Plugin osio. Blogialustoja on paljon ja suosituimman alustan osalta on käynnissä kilpajuoksu jossa on mukana myös Googlen Blogger. Blogger eroaa WordPress -blogista siinä että Blogger on heti valmis ja pyörii Googlen hallinnoimalla palvelimella ja asetuksilla. Itse kuitenkin halusin mahdollisuuden muokata blogiani milloin mihinkin suuntaan ja testailla erilaisia laajennuksia, tämä ei ollut oikea ratkaisu ja päädyin WordPressiin.

WordPressin asennus on helppoa. Aivan ensimmäiseksi tulee asentaa Web-palvelin jos tällaista ei vielä ole. Sisäiseen viestintään web-palvelimelle riittää jokin mikä tahansa tietokone, joka on yrityksen verkossa kaiken aikaa. Tähän asennetaan joko Windows web-palvelinpaketti tai Linuxille vastaava. Näitä kutsutaan usein WAMP ja LAMP paketeiksi. Paketin nimi muodostuu seuraavasti:

W = Windows, L = Linux

A = Apache

M = MySQL

P = PHP

Paketin asennus on suoraviivainen ja nopea. Jos vähänkään tuntee ATK:ta, tämä ei todellakaan ole iso ponnistus, älä jätä kokeilematta sen vuoksi että epäilet asennuksen olevan vaikean ja että et ehkä osaisi – kyllä sinä osaat. Aikaa asennus vie ehkä 5 minuuttia. Asennusohjeet löytyvät yleensä sivustolta jolta lataan paketin.

Kun tämä on tehty, ladataan WordPress paketti. Paketti puretaan asentamasi WAMP paketin www-hakemistoon. Loput asennusohjeista löydät WordPress sivustolta.

Kun olet tämän tehnyt, sinulla pitäisi olla Blogi-sivusto valmis. Jos haluat sivuston näkyvän sisäverkossa, voit asettaa WAMP palvelimen ”Online” tilaan jolloin muut pääsevät lukemaan blogia.

Jos yrityksellä on olemassa jokin Intranet järjestelmä, blogin ei ole pakko korvata koko järjestelmää vaan se voi toimia sen osana. Tämä tulee eteen varsinkin jos intranetissä on toiminnallisuuksia esimerkiksi henkilöstöhallinnon osalta, mutta aivan vastaavalla tavalla nämä voidaan toteuttaa lisälaajennuksina blogiinkin. Jos taas intranet on tiedoston jakamista, lomakkeita tms. varten, heittäisin Intranet-portaalin pois ja tekisin nämä blogiin koska kustannukset kehittää blogia ja lisälaajennuksia ovat usein aivan toista kuin massiivisten valmistuoteportaalien osalta. Alla muutamia huomioita ja ideoita blogeista yleensä:

• Blogi on toteutettu kokonaan artikkelien julkaisua silmällä pitäen jossa on huomioitu valmiina hakutoiminnot, arkisto ja kategoriat artikkeleille.
• Blogin pystytys on helppoa, sen saa asennettua muutamassa minuutissa
• Blogin työkalut ovat todella helppokäyttöisiä ja jotka varmasti ovat tiedotusvastaavien mieleen. Kirjoittamisen osalta käytössä on Wysiwyg-editori (kuten word) tai tekstit voidaan myös kopioida suoraan Wordin dokumenteista jolloin kappaleiden otsikointi, fonttikoot, värit jne voi tuoda kopioinnin yhteydessä Wordista.
• Blogi ja tietokantana MySQL ovat ilmainen vaihtoehto kalliille intranet-ratkaisuille jotka vaativat joskus IT-väen kouluttautumisen ylläpitoon ellei osaamista ole jo entuudestaan.
• Blogissa käyttäjille voidaan lähettää tiedotteet RSS-syötteinä suoraan sähköpostiin ja tiedotteet näkyvät myös selaimissa johon RSS-feed on ladattu. Lataaminen itsessään on todella helppo toiminto.
• Blogissa artikkelit voidaan suojata salasanoin (kuten portaaleissakin).
• Blogiin voidaan perustaa kategorioita joiden ylläpito voidaan antaa esimerkiksi osastonvastaavien tehtäväksi. Tällöin kirjoitettujen juttujen ei tarvitse olla niin virallisia joka mielestäni pehmentää yrityksen sisäistä imagoa.
• Toimitusjohtajan palsta voi olla myös blogissa jonne toimitusjohtaja voi säännöllisin väliajoin kertoa ajatuksistaan ja tulevaisuuden näkymistä yritystä koskien.
• Blogiin voidaan luoda myös koulutus yms. osioita ja kirjoittaa dokumentit suoraan Blogiin kuvineen kaikkineen tai ne voidaan kirjoittaa Word -dokumentteina ja kopioida Blogiin jolloin Wordin ulkoasut yms. säilyvät myös Blogissa. Erityisen hienoa tässä on se, että blogissa oppaiden sisältöä voidaan hakea nopeasti hakusanoin joka helpottaa dokumenttien käyttöä ja oikean tiedon löytämistä.
• Projekteissa tämän käyttö voisi myös olla hyvä idea varsinkin tiedottamismielessä. Projektiryhmälle itselleen suosittelen Redmine -työkalun käyttöä.
• Blogiin on olemassa satoja laajennuksia, joiden käyttöönottaminen on hyvin nopeaa (<5min). Tämä on täysin toista kuin valmisohjelmistona hankitun intranet-portaali ja siihen halutut lisäosat jotka hyvin usein joudutaan itse toteuttamaan ja joka vaatii osaamista aivan toisella tavalla kuin Blogi (lisälaajennuksia, joita itse olen testannut ovat Adman, AJAX Calendar, Google AdSense manager, Amazon Machine Tags, Coupon manager, Flickr manager, Google Map, IM Online, IPCCP, ExZo, FLV Embed, QuickShop, Post2PDF, podPress, Google XML Sitemaps, XML Google Map).

Itse olen vakuuttunut blogien esiin marssista yritysten sisäisessä viestinnässä ja tämän käyttöönotto vaatii ehkä jonkin verran avoimuutta ja uskallusta kokeilla jotakin uutta. Nyt kun olen blogia jonkin aikaa käyttänyt myös omassa työssäni, en vaihtaisi tätä mihinkään portaaliratkaisuun, varsinkin kun portaalit ovat usein kymmenien tai satojen tuhansien eurojen kustannuksia, jonka toteuttaminenkin on saattanut kestää vuosia. Ymmärrän hyvin että jos tuhansien eurojen sijoitukset intranetiin on tehty, kynnys lähteä vaihtamaan ratkaisua johonkin avoimeen lähdekoodiin perustuvaan, vapaasti ladattavaan ohjelmaan voi olla monessakin mielessä tuskallista…

Read Full Post »

Eräs web-projekti ja tarinan opetus

Tämä artikkeli on kuvaus eräästä web-sivustoprojektista, jossa tahtotila oli saada nopeasti postiennakkomyynnillä varustettu sivusto pystyyn. Kiire oli tietenkin kova ja eilen piti olla valmista.

Sisältöä ei ollut vielä ideointivaiheessa, joten pyysin sisältömateriaalin lähetettävän minulle heti kun se saapuu, jonka sainkin viikon päästä perjantaina. Referenssisivusto tosin oli joka auttoi paljon. Vaimo oli käymässä kotopuolessa joten minulla koko viikonloppu aikaa tehdä tätä (muuta elämäähän minulla ei olekaan kuin netissä roikkuminen ja kaikennäköisten web-härpäkkeiden kanssa puuhastelu).

Sivustoja mitä olen ollut tekemässä, kiire on kova, sivustot eivät saa maksaa mitään ja silti sivuston odotetaan räjäyttävän liiketoiminnan aivan toiselle tasolle. On se hyvä että asiakkailla on yhä mielikuvitusta.

Materiaalin saatuani aloin siis pohtimaan sivuston ulkoasua. Kello oli 1400 perjantai-iltapäivä. Ainoa ohjenuora suunnitteluun oli, että sivut vastaisivat värimaailmaltaan annetun referenssisaitin sivuja. Vääntelin sivuston ulkoasua muutaman tunnin enkä tuntunut pääsevän puusta pitkään. Sivuston leiskoja syntyi kaksi, mutta en ollut kumpaankaan tyytyväinen. Ulkoasut olivat enemmän tai vähemmän leikittelyä ja ideointia. Matkalla kotiin sain viimein idean jonka päätin toteuttaa. Idea jäi kaivelemaan niin paljon, että oli pakko alkaa heti kotiin päästyäni tätä työstämään. Klo 01.00 sivu oli HTML-muodossa ja mielestäni menetteli ottaen huomioon ajan rajallisuuden. Lauantaina esittelin sivuston eteenpäin. Näin lyötiin lukkoon ulkoasu. Sivuston perustoiminnallisuudet oli myös mietitty tähän esitykseen valmiiksi ja nämä hyväksyttiin samalla.

Lauantaina sivustoa esitellessäni asiasta innostui myös kaverini, joka toteutti tilaustoiminnallisuuden sivustolle. Yhdessä aisaparina sitten teimme sivustoa eteenpäin sitä mukaa kun saimme uusia ideoita. Tässä projektissa kuvat sain sekä painettuna, että PDF-muodossa sekä suurimman osan erikseen TIFF kuvina. Muu data oli Wordin dokumenteissa. Suurin työ sivustolle oli kuvien skaalaus oikeisiin kokoihin (thumbnail, listauskuva, medium- ja iso). Tiedot vein exceliin ja muokkasin kantarakennetta vastaavaan rakenteeseen, josta aisaparini latasi datan MySQL kantaan. Loppuvaiheessa aloin jo epäillä valmistumisaikataulua (taikka Battery alkoi jo loppua), joten päätimme jättää kaiken ylimääräisen tässä vaiheessa pois. Lopulta sivusto valmistui ja yhteensä laskin että käytimme työtunteja projektiin 70+25 eli 95 työtuntia. Sivusto on tietokantapohjainen, joten sisällön ylläpito on helppoa (jos osaa käyttää MySQL GUI työkaluja jota asiakas tietenkään ei osaa).

Käytetty työaika omalta osaltani:

Pe klo 1400-1700 ja 1800 – 0100. Sivuston suunnittelua ja toteutusta (10h)

La klo 1000-1800 ja 2000-0100: Sivuston toteutus jatkuu. (13h).

Su klo 1000-1700 ja 1900-0100: Tietojen ja kuvien konvertointi ja sovitus sivustolle. Toiminnallisuuden toteutusta (13h)

Ma klo 0900-1900 ja 2000-0100: Tietojen ja kuvien konvertointia. Toiminnallisuuden ja sivuston viilausta. Lisätoimintoja käyttöön (15h).

Ti klo 0900-1700 ja 1900-2200: Sivuston grafiikan ja kuvien viilausta. Toimintojen viimeistelyä (11h).

Ke klo 0900-1700: Kuvien viilausta, sisällön muokkausta, viimeiset toiminnallisuudet valmiit. Siirto tuotantopalvelimelle (8h).

Tämä projekti oli jonkin sortin haaste ja samalla testi, kuinka nopeasti postiennakkomyyntiä harrastavan verkkokaupan saisi pystyyn n. 300 tuotteen valikoimalla (lue: otti pannuun niin ankarasti että apinan raivolla painettiin homma nopeasti maaliin). Halusin alunperin osoittaa, että itse tekemällä pääsee paljon pienemmin kustannuksin, saa nopeammin valmista ja toteutus on käyttökelpoinen. Tässäkin projektissa päti samat lainalaisuudet kuin muissakin web-projekteissa pk-sektorilla. Tässä siis ilmaisia vinkkejä jos teet asiakkaalle pientä sivustoa ja haluat sivuston tulevan valmiiksi:

• Varmista että saat sisällön vaikka sitten ruutupaperilla tms.
• Ota vastuu myös sisällöstä ts. muokkaa sisältö itse/vie se tietokantaan
• Käsittele kuvat ja siirrä palvelimelle
• Suunnittele sivuston toiminnallisuus ja toteuta se – älä odota asiakkaan suunnittelevan mitään
• Pyydä asiakkaalta vaikka puhelimessa puuttuvat tiedot (yritys ja yhteystiedot)
• Luo itse markkinointitekstit ”täyttötekstinä” joista usein tulee pysyviä kun muutakaan ei keksitä.

Muussa, tapauksessa voit olla varma, että sivusto jää ottamatta käyttöön aikataulussaan, varsinkin jos odotat sisältöä jossakin tietyssä formaatissa. Voit myös olla varma että kun sivusto on valmis, jonkin ajan kuluttua alkaa ”sataa” pyyntöjä lisätoiminnallisuuksista mitä pitäisi tehdä (ja tottakai ne kuuluvat samaan hintaan, eikö?).

Mielestäni yritysten tulisi sivustoa suunnitellessa miettiä ensimmäisenä sen tarkoitus. Mitä sivustolla haetaan – nopeaa myyntiä, luotettavaa ja stabiilia toimintatapaa, molempia, jne? Mielestäni nykyään liian usein sivustosta yritetään tehdä liian automatisoitua (ja järeää), eikä oteta tarpeeksi huomioon projektin aikaisia kustannuksia ja takaisinmaksuaikaa tai ylläpitoon kuluvia kustannuksia projektin jälkeen. Usein voisi olla järkevämpää lähteä pienestä liikkeelle ja alkaa nopeasti tekemään tulosta, jonka jälkeen on helpompi laajentaa toimintaa. Pienellä liikkeelle lähdettäessä on myös helpompi opiskella sähköisen liiketoiminnan prosesseja ja riskit ovat pienemmät.

Mikä oli tarinan opetus?

Kun kuulet asiakkaan haluavan web-sivuston, jonka ansaintalogiikka / hyöty on epäselvä,, aikaa ei ole tunnu olevan nykyisenkään toiminnan pyörittämiseen, toteutus ei saa maksaa kuin muutaman ravintolaillallisen verran tai että asiakas ei osaa käyttää selainta – suosittelen perääntymistä.

Tiedän, että kauppaa ei useinkaan saa tehtyä jos ei sitoudu tiukkoihin aikatauluihin ja tee edullisesti. Tämä johtuu siitä, että markkinat on ylikyllästetty web-koodareilla ja aina löytyy tuttavapiiristä joku, joka tekee sivut halvemmalla tai ilmaiseksi. Anna siis tällaisissa tapauksissa heidän tehdä ne. Turhaa vaivaat itseäsi mitättömän korvauksen vuoksi kun kuitenkin saat hyvin todennäköisesti epäkiitollisen asiakkaan ja itselle näppylöitä. Kaikista parasta olisi jos vaihtaisit alaa tai vähintäänkin suuntaa – web-sivuja tekemällä ei rikastu – ei edes vaurastu, ei ainakaan pienille yrityksille tarjottavien sivustojen toteutuksilla.

Read Full Post »

Miksi “IT-nörtit” rakentavat liiketoimintaa nopeammin?

Hiljattain Yhdysvalloissa tehty tutkimus johtajien kiinnostuksesta teknologiaan paljastaa että omistajien teknologia-osaamisen taso on verrannollinen yrityksen tuottoon ja työntekijöiden lukumäärään. Tutkimus osoitti että informaatioteknologian hallinta olivat suurimpia haasteita kasvuun suuntautuneissa yrityksissä.

Tutkimukseen osallistui eri alojen yrityksiä jossa oli huomioituna auto- ja rakennusteollisuus, koulutuspalvelut, talouspalvelut, terveydenhoito, lakitoimistot, valmistus, vähittäis- ja tukkukauppa, voittoa tuottamattomat yhdistykset, kiinteistöala, kuljetusala ja telekommunikaatioala. Kyselyssä oli mukana PK-sektorin toimitusjohtajia ja senior-tason toimihenkilöitä eri teollisuuden aloilta. Yrityksissä työskenteli henkilöstöä 100-5000. Suurin osa yrityksistä (84%) oli 100-500 työntekijän kokoluokkaa. Yhteensä 862 johtajaa vastasi kyselyyn.

Yrityksiltä kysyttiin myös, kuinka kauan heidän kasvunsa kesti saavuttaa 100 työntekijän koon. 32% vastaajista sanoi tämän kestäneen 5-9 vuotta, 30% vastaajista arvio 1-4 vuotta, 14% vastaajilta tämä kesti 10-14 vuotta ja 17% vastaajista arvioi kestäneen yli 15 vuotta. 7% vastaajista kertoi kasvaneensa yli 100 henkilön yritykseksi vuoden sisällä aloittamisesta.

Kyselyssä yritysjohtajille annettiin viisi vahtoehtoa arvostella itseään ”IT-nörtin” ja ”osaamattoman” välillä. Kyselyllä etsittiin vastauksia kysymyksiin, kuinka kriittinen IT on yritysten menestymiseksi. Esimerkkivastaus oli: ”Olemme suuri yritys nyt, mutta yritys perustettiin yhden henkilön yrityksenä 1980 -luvulla jolloin myytiin tietokoneita ja lisälaitteita. IT toi lisää tehokkuutta asiakaspalveluun, jolla oli hyvin suuri osuus strategiassamme”. 22% vastanneista toimitusjohtajista luokitteli itsensä ”IT-nörtiksi” ja 59% tehokäyttäjiksi eli asteikolla yhden alemmas ”IT-nörtistä”. Vähemmän kuin 1% vastanneista oli arvioinut olevansa ”osaamattomia”.

73% itseään ”IT-nörtiksi” arvioineista toimitusjohtajista kertoivat saavuttaneensa kaksinumeroisen vuosittaisen kasvun liiketoiminnassaan viimeiset viisi vuotta. Lähes puolet, 48% ”IT-nörteistä” myös kertoi, että heidän liiketoiminta kasvoi yli 100 hengen yritykseksi viidessä vuodessa yrityksen aloittamisesta. IT:n huomioiminen liiketoimintastrategiassa oli kyselyn mukaan tärkeää. 98% vastaajista sanoi että heidän yrityksensä on määritellyt IT-strategiansa jo pienenä yrityksenä ja he jotka katsoivat IT:tä strategisena tai kilpailullisena tekijänä pääsääntöisesti kasvoivat nopeammin kuin ne, jotka panostivat ”juuri riittävästi” varmistaakseen ,että työntekijät voisivat tehdä työnsä. 18% vastanneista oli myös sitä mieltä että IT:n poisjättäminen yrityksen liiketoimintastrategiasta oli heidän suurin virheensä vuosien varrella.

IT:n tilanne Suomessa pk-sektorilla

Suomessa toimi alle 50 henkeä työllistäviä yrityksiä yli 98,8% koko yrityskannasta vuonna 2006, joita oli 247 393. Näiden osuus kaikkien yritysten henkilöstömäärästä oli 44,6% ja liikevaihto 31,5%. Maakuntien keskimääräinen yritysten henkilöstön kehitys oli 5,7% ja näiden liikevaihdon lisäys 9,3% vuoteen 2005 verrattuna. 2007 vuoden lukuja ei tätä kirjoitettaessa ollut vielä saatavilla (Lähde: Tilastokeskus).

Tilastokeskuksen mukaan vuonna 2007 Internetiä oli käytössä yrityksillä lähes 100%. Rakentamisessa käyttöaste oli 93%, Liikenteessä 86%, Moottoriajoneuvokaupassa, 94%, Majoitus- ja ravitsemustoiminnassa 87% ja vähittäiskaupassa 96%. Teollisuudessa aste oli 99%. Muut kuten posti, yrityspalvelut, agentuuri- ja tukkukauppa käyttöaste oli 100%.

Yrityksillä joiden henkilöstö vaihteli 5-9 välillä, internetin käyttöaste oli 93%. Yli 50 hengen yrityksissä käyttöaste oli 100%. (Lähde: Tilastokeskus: Tietotekniikan käyttö yrityksissä 2007).

Yrityksissä, joissa työskenteli 5-9 henkilöä, kotisivut löytyivät 57%, 10-19 hengen yrityksissä 73% ja 20-49 hengen yrityksissä 85% prosentilla. Karkeasti arvioiden voineen sanoa että keskimäärin alle 50 henkeä työllistävistä yrityksistä seitsemällä yrityksellä kymmenestä oli käytössään www-sivut (keskiarvoksi laskettu prosentti n. 72%) .Tämä ei kuvaa koko IT-käyttöastetta yrityksissä mutta mielestäni antaa suuntaa. Itse en käyttäisi sanaa ”kotisivut” koska tämä mielestäni antaa väärän ja jopa vähättelevän kuvan yritysten sähköisistä palveluista. Uskon että suurimmalla osalla yrityksiä www-sivut ovat tekstiä ja kuvaa, mutta paljon on myös sellaisia yrityksiä jotka tekevät liiketoimintaa verkkopalvelujensa kautta.

IT voi tuoda hyötyjä jos siihen panostetaan oikein

IT:n hyödyt jäävät vähäiseksi jos perusteet eivät ole hallussa. Tämä tarkoittaa ensimmäisenä perusasioiden kuten sähköpostin, toimisto-ohjelmien, web-selailun haltuunottoa. Vuosia IT-alalla työskennelleenä olen johtanut niin pienten kuin suurtenkin ohjelmistoratkaisujen ja järjestelmien käyttöönottoja ja tarpeen tullen rakentanut tai rakennuttanut erilaisia käyttöä helpottavia ratkaisuja tehokkuuden ja myynnin lisäämiseksi. Olen nähnyt kuinka yritykset eivät aina ole täysin varmoja tai eivät tiedä, mitä he IT:ltä haluavat (tai odottavat mahdottomia suhteessa kustannuksiin ja tehokkuuteen) ja tästä syystä voi syntyä tilanne, jossa IT-hankinnat eivät kohtaakaan yrityksen tarpeita. Uuden ohjelmiston käyttöönotto usein muuttaa myös yrityksen tapoja toimia ja ehkä silloin helposti aliarvioidaan se työmäärä, joka kuluu uuden teknologian haltuunottoon. Jos yritysjohto ei ole täysin sitoutunut uusien ohjelmistotyökalujen käyttöönottoon, työkalut voivat jäädä kokonaan tai osin käyttämättä .

Kokemukseni mukaan alla olevan esimerkin kaltainen tilanne on vielä nykypäivänäkin täyttä todellisuutta:

Yritys A päättää hankkia itselleen web-sivut, koska uskoo että tätä kautta voisi saada lisää kävijöitä myymäläänsä. Onhan tässä muutkin onnistuneet, joten asian ei pitäisi olla mikään ihmeellinen juttu. Web-sivusto teetetään sitten ”siskon veljen kaimalla” joka tekeekin sivuston nopeasti ja hyvin edullisesti. Ohjenuoraksi sivustontekijälle yrittäjä kertoi tavoittelevansa uusia maksavia asiakkaita myymäläänsä. Lopulta kun sivut valmistuvat, sivuston varaan on jo ladattu paljon odotuksia. Sivusto on usein web-sivu jossa on esitetty yrityksen yhteystiedot ja pieni esittely sekä tottakai palautelomake, josta voi lähettää palautetta, mutta sitä ei ole suunniteltu nimenomaan tarkoitustaan vastaavaksi, eli houkuttelemaan asiakkaita myymälään. Jos nyt sivuston kautta ei tulekaan yhteydenottopyyntöjä tai asiakasvirta ei kasva myymälässä, yrittäjä pettyy ja seuraavan IT-investoinnin toteutus onkin jo paljon vaikeampaa johtuen aiemmista huonoista kokemuksista.

Epäonnistumisen syy:

Yritys teetti sivut puolitutulla (eikä siinä mitään jos kyseessä on osaava henkilö joka ymmärtää myös mainonnan ja markkinoinnin päälle), mutta ei itse sitoutunut sivuston toteutukseen juurikaan. Yrittäjä korkeintaan lähetti kuvat ja tekstit eteenpäin, mutta ei sen kummemmin pohtinut, miten hänen pitäisi markkinoida yritystään ja miten sivustoa lähdetään tuomaan esille muissakin medioissa. Web-sivuhan yksinkertaisimmillaan on pysyvä mainos internetissä jota ei kukaan kuitenkaan näe jos sitä ei tuoda esille internetin hakukoneoptimoinnein ja/tai lehdissä

Ne yritykset jotka ymmärtävät sekä liiketoiminnan että IT:n jollakin tasolla (tai heillä oli IT-osaajia käytössään), pystyvät mielestäni kehittämään liiketoimintaansa nopeammin ja saavat todennäköisesti kasvatettua liikevaihtoaan muita nopeammin.

Katso video. Tuntuuko tutulta?

Read Full Post »