Kestävien ratkaisujen rakentaminen SAPpiin

Julkaisen tässä osan 2015 kickoffissa pitämästäni esityksestä. Tapahtuman otsikkona oli 'Kestävien ratkaisujen rakentaminen SAPpiin' ja sisältö keskittyi tähän päivään ilman hypeä - eli, miten asioita kehitetään hyvin SAPissa 2015. Lähes kaikissa SAPpia käyttävissä yrityksissä tekninen kehitys on ulkoistettu. Asiakkaan kannalta tekninen kehitys voikin olla lähes ”musta laatikko”, josta saadaan jollain hinnalla uusia ominaisuuksia ja prosesseja käyttöön. Asiakas asettaa kuitenkin vaatimukset. SAP- ja ohjelmointikehityksen periaatteiden noudattamatta jättäminen ei maksa ensimmäisen kehitystyön osalta oikeastaan juurikaan ylimääräistä. Ylimääräiset kustannukset tai vastaavasti säästöpotentiaali realisoituvat vasta seuraavien tehtävien mukana, kun ylläpito on vaikeaa ja aikaisemmin tehtyä ei voida hyödyntää. Aloitetaan kehityksen organisoinnista.

 

Konsultit tuntevat standardi SAPin nykyään varsin hyvin. Yleisin arvoitus konsultin kannalta on yleensä, että mitä järjestelmään on jo tehty. Konfiguroinnitsaa selville katsomalla esimerkkitositteita, mutta laajennukset ovat arvoitus. Lisäksi ohjelmoinnissa pitäisi pyrkiä ratkaisujen uudelleenkäyttöön eli välttää pyörän keksimistä uudelleen. Paras ratkaisu tähän on kehityksen paketointi toimintojen mukaan sekä erityisesti pakettien kiinnitys toisiinsa hierarkian avulla. Slidessa on esimerkki yhdeltä asiakkaalta. Moduulit ja prosessit muodostavat hyvän pohjan hierarkialle, mutta kehitystyön laajuudesta riippuu, kuinka hienojakoinen hierarkiasta kannattaa rakentaa. Objektien siirtäminen paketista toiseen on helppoa, jolloin tätä työtä voidaan tehdä myös jälkikäteen. Jaottelemalla kehitys sopivan kokoisiin paketteihin, kaiken löytäminen on helpompaa. Lisäksi kehittäjät voivat paremmin hyödyntää toistensa ratkaisuja.

 

Jossain 2005 tienoilla ECC:hen tuli toiminnallisuus nimeltä Checkpoint Group. Se mahdollistaa Break-pointien ja lokien aktivoimisen halutulle ajalle ja käyttäjille aina tuotannossa saakka. Olemme TMO Consulting Oy:sä määrittäneet tavaksi lisätä tällainen Checkpoint Groupiin perustuva Break-point jokaisen enhancementin (laajennuksen) alkuun. Prosessin tutkiminen on helpompaa, jos esimerkiksi aktivoimalla ZMM_ENHANCEMENT break-pointin itselleni, suoritus pysähtyy jokaiseen laajennukseen, joka on tehty ostoprosessiin. Lisäksi valitsemalla ’Where used’ kyseiselle Check-point groupille, näet listan kaikista vaikuttavista customer exiteistä, Badeista, Enhancement Spoteista ym. Vielä lisäksi edellisessä slidessähän määritettiin pakettihierarkia, jolloin muutenkin nämä enhancementit näkyvät paketin ZMM_PURCHASE alla.

 

Modularisointi on vanha idea sekä tuotesuunnittelun että ohjelmistokehityksen alueilla. SAPin ensimmäinen modularisointikonsepti olivat ABAP funktiot. BAPIfunktioita käytetään vieläkin kovasti hyödyksi ja käytännössä standardi SAP toimii funktioiden kautta. 40-vuoden aikana kehitetyn koodin muuttaminen uudeksi kestää eikä sitä välttämättä olla edes tekemässä. Kuitenkin käyttöliittymien osalta SAP on siirtynyt jo 20-vuotta sitten objektipohjaiseen kehitykseen. Esimerkkinä ovat MIGO ja muut vastaavan näköiset transaktiot.
Funktioiden ja luokkien välinen ero kehityksessä realisoituu seuraavasti:

  • Funktiolla suoritetaan yleensä yksittäinen tehtävää (esim. luo myyntitilaus, hae tuotatotilauksen komponentit)
  • Luokka luodaan alusta lähtien konseptiksi (esim. myyntitilaus, ostotilaus) ja luokan metodit taas vastaavat funktioita.

Funktioilla on toki takanaan ’funtioryhmä’ joka melkein vastaa teknisesti luokkatasoa. Tapa, joilla kehitystä tehdään poikkeaa kuitenkin toisistaan. 
Asiakkaan kannalta tämä merkitsee sitä, että nykyään kehitetään kertaalleen luokka vaikkapa tuotantotilausta varten ja sitä on tarkoitus käyttää kaikissa tuotantoon liittyvissä toiminnoissa. Tai siis ainakin pitäisi kehittää…

Katsotaan alkuun, mikä luokka (class) on: Olio-ohjelmointi on kymmeniä vuosia vanha idea. SAP Abapissa luokat tulivat mukaan 2000-luvun alussa ja 2005 versiosta lähtien niiden käyttö on ollut lähellä nykypäivää. Me TMO Consuting Oy:ssä koemme, että juurikin luokkien käyttö mahdollistaa koodin uudelleenkäytettävyyden ja on nykyisen kehitystyön perusta. Luomme luokan vaikkapa Tuotantotilaukselle ja käytämme tätä luokkaa kaikkialla, jossa Tuotantotilauksen tietoja pitää käsitellä. Yleisesti käytettyjä metodeja ovat esimerkiksi is_released_and_active(), jota käytetään poissulkemaan vapauttamattomat, valmiit ja poistetut tilaukset. Metodilla read( ) saadaan luettua aikataulut, komponentit, ym. Tiedot luetaan useimmiten BAPI-funktioilla, mutta lisäksi myös asiakaskohtaisten tietojen käsittely tarvitsee kirjoittaa vain tähän yhteen luokkaan. Luokan pääasiallisia tietoja ovat:

  • Attribuutit (muuttujia/struktuureja/tauluja, jotka sisältävät tilauksen tms. tiedot)
  • Metodit (joita käytetään tietojen lukemiseen ja muuttamiseen)

Periytyvyys on tärkeä luokan ominaisuus. Periytyvyys tarkoittaa, että aliluokka perii kaikki superluokkansa attribuutit ja metodit, mutta lisäksi metodeja voi luoda myös lisää ja olemassa olevia metodeja voidaan ylikirjoittaa. Esimerkkejä periytyvyydestä ovat:

  • Tuoteterakenne: superluokka cl_bom ja sen aliluokat cl_material_bom sek cl_wbs_bom.
    • BOM itemin käsittely on samanlaista riippumatta siitä kuuluko rivi materiaali-, myyntitilaus-tai wbs-BOMmiin.
    • Read( ) ja save( ) metodit on ylikirjoitettu cl_material_bom ja cl_wbs_bom –luokissa, koska näiden käsittelyyn tarvitaan eri funktioita. Metodin kutsuvaiheessa ei tarvitse kuitenkaan määritellä, minkä luokan metodia pitää kutsua eikä myöskään määritellä monimutkaista if-else-rakennetta, vaan BOMmille kutsutaan automaattisesti oikeaa metodia.
  • Ostotilaus: superluokka cl_purchase_orderja sen aliluokka cl_stock_transport_order
    • Stock Transport Orderin luominen BAPI-funktiolla on muuten ihan samanlaista kuin Ostotilauksen luominen, mutta STO:lla ei ole toimittajanumeroa, vaan toimittava toimipiste. Lisäksi yrityksen sisäisissä tilauksissa voidaan käyttää saatavuustarkastusta tms. erikoisuutta

 

Hyvin tehtyä ohjelmaa on helppo lukea ja vaiheet noudattavat melkeinpä liiketoimintaprosessin yksityiskohtia. Lisäksi koodi dokumentoi suurelta osin itse itsensä. Sliden vasemmassa reunassa on määritelty prosessissa tarvittavat tiedot sekä tehtävät päivitykset. Näille vaiheille löytyy lähes 1:1 vastineet oikean reunan koodista.

 

Mitä hyötyä tästä on sitten asiakkaille? Nykyään aloitamme melkeinpä kaikki projektit kopioimalla työkalupakkimme asiakkaan ympäristöön. ”Työkalupakki” sisältää pääosin raportintiin ja lokiin liittyviä helpottavia toimintoja, mutta lisäksi siihen valmiiseen tarpeeseenkin löytyy yleensä ainakin valmiita luokkia (ostotilaus, tuotantotilaus, wbs, bom, tms.) pohjaksi. Näiden käyttö yksinkertaisesti tehostaa tekemistä ja nostaa laatutasoa.

 

Ratkaisun rakentaminen

Ratkaisut rakentuvat siis siten, että taustalle on rakennettu valmis objektimaailma (luokat), joiden metodeja sitten käytetään prosesseissa. Luokat ja metodit ovat uudelleenkäytettäviä. Tässä esimerkissä luodaan perustiedot köydelle / kaapelille. Katkaisua varten kaapelikela pitää siirtää katkaisukoneelle ja pätkä valmistuu asiakaskohtaiseen varastoon. Tämän tehtävän mallinnukseen käytetään tuotantotilausta, jolloin tarvittavat perustiedot ovat: - Material Master - Tuoterakenne (BOM), jossa nimike itse on myös komponenttina - Työvaiheluettelo (routing), jossa on katkaisuvaihe. - Konfigurointiprofiili pituuden ja pakkauksen kuvaamiseen myyntitilauksella. Uusia nimikkeitä tulee jatkuvasti, jolloin prosessin pitää olla nopea (yksivaiheinen). Ohjelmointimielessä nimikkeiden, BOMmien, ym. luonti on ihan samanlainen tapahtuma kuin kaikilla asiakkailla, joten tässä pystyi hyödyntämään suoraan olemasssa olevia luokkia ja metodit vaan listataan peräkkäin suorittamaan tehtävä.

 

Silloin tällöin konsulttina rakennetaan konsepteja, joita ei standardiSAPilla voi tehdä. Tämä on kuitenkin harvinaista. Suurin osa kehitystyötä liittyy siihen, että SAPin ratkaisua ei ole tehty pelkästään asiakkaan liiketoimintaympäristöön, jolloin tiedot ja toiminnot ovat hajallaan useassa transaktiossa. Näitä tietojen ja toimintojen käsittelyä siis pyritään tehostamalla rakentamalla uusia käyttöliittymiä ja kokoavia prosesseja. Lisäksi prosesseihin voidaan lisätä asiakaskohtaisia lisätietokenttiä. Nämähän olisivat jo lähtökohtaisesti jonkun kolmannen välilehden takana.