TSENTER viis läbi eksperimendi, mille käigus aitasime ühel 2 miljoni eurose käibega ja 20 töötajaga tootmisettevõttel valida tootmisjuhtimise tarkvara. Mida me teada saime? Mis on kõige parem tarkvara väikesele tootmisettevõttele?
Väikese või keskmise suurusega tootmisettevõtte jaoks on uue tootmisjuhtimise tarkvara leidmine üsna keeruline ülesanne. Kui suurtel ettevõtetel on tavaliselt omad IT spetsialistid, tarkvara eelarve ning IT-firmad käivad ise lahendusi pakkumas, siis väikese ettevõtte puhul peab ettevõtte juht sageli ennast ise harima, et suuta olla tark ostja.
Väiksemal ettevõttel teeb tootmisjuhtimise tarkvara hankimise keerukaks ka senise kogemuse puudumine. Aga kui ettevõtte juht tahab vaatamata nendele raskustele paberil või Excelis planeerimiselt minna üle tarkvarale, siis mis valikud tal on? Väiksemas ettevõttes on tootmisprotsessid, planeeritavate inimeste ja masinate hulk väike ning seetõttu tahab ettevõtte juht suhteliselt lihtsat tarkvara funktsionaalsust ja enam-vähem valmis tarkvara, mida ei peaks nullist arendama hakkama. Seega sooviks taolise ettevõtte juht n-ö karbitoodet või poolvalmis tootmisplaneerimise tarkvara, mida saab sobivaks seadistada.
Ühe esimese asjana tuleb ettevõttel hinnata oma senist taset ning seda, kui suurte võimalustega tarkvara suudetakse kasutusele võtta ja millised asjad tuleb maja sees ära teha enne, kui tarkvara üldse kasutama saab hakata. TSENTRI teemahommikul tootmisjuhtimise tarkvarade juurutamisest soovitas Erkki Leego ettevõtetel kasutada COBIT tasemeid, et hinnata ettevõtte võimekust ning saada teada, mis võiks olla järgmine samm.
| TASE | LÜHIKIRJELDUS |
| 0 – Puudulik | Ettevõttes puuduvad protsessid
Ettevõttel puudub teadlikkus, et protsesside puudumine on probleem |
| 1 – Esmane | Ettevõte on probleemidest teadlik
Standardiseeritud protsessid puuduvad Puudub süsteemsus, olukordi lahendatakse iga kord nullist |
| 2 – Korratav | Olukordade lahendamiseks on tekkinud protsessid
Protseduurid pole kirjeldatud |
| 3 – Defineeritud | Protseduurid on standardiseeritud ja dokumenteeritud
Rakendamist ei kontrollita |
| 4 – Hallatud | Protseduuride täitmist jälgitakse
Protsesse uuendatakse pidevalt |
| 5 — Optimeeritud | Protsessid on saavutanud efektiivsuse ja vastavuse headele tavadele
IT on loomulik ja märkamatu osa tööprotsessist |
Allikas: https://www.isaca.org/Knowledge-Center/cobit/Documents/COBIT4.pdf ; Erkki Leego teemahommik
Ka on TSENTER korraldanud teemahommiku “Kuidas saada targaks tarkvara tellijaks”, kus erinevad esinejad jagasid näpunäiteid tarkvara valiku tegemiseks.
Oma olukorrast ning teiste soovitustest lähtudes tuleb ettevõtte juhil koostada lähteülesanne tarkvara pakkujatele. Lähteülesandesse läheb kirja see, mida tarkvara ettevõtte jaoks tegema peaks ning selle põhjal saavad tarkvara firmad hinnata, kas nende tarkvara tooted või teenused üldse sobivad tootmisettevõttele või mitte. Isegi kui keegi kiidab mõnd tootmistarkvara taevani, ei pruugi see teise ettevõttesse üldse sobida, sest selle soovid ja eesmärgid võivad olla hoopis teised.
Kui ettevõttel ei ole oma IT spetsialisti, tuleb esimene lähteülesanne panna kokku omaenese tarkusest lähtudes. Iga ettevõtte juht suudab lähteülesandesse panna kirja järgmised asjad:
- Mis on mõõdetav eesmärk? Milliseid probleeme peab tarkvara aitama lahendada ning milline peaks olema tarkvara kasutusele võtust saadav numbriline kasu (soovitavalt rahas mõõdetav).
- Milliseid protsesse tahan tarkvara abil juhtida? Hea oleks, kui suudaks protsessid pildina ära kirjeldada.
- Mis infot ma praegu paberile või Excelisse kogun ja kuidas seda kasutan?
- Kes saavad olema tarkvara kasutajad, kui palju neid on ning mis infot nad tarkvarasse sisestavad või sealt vaatavad?
- Milliste raamatupidamise või laohalduse tarkvaradega peab tootmisjuhtimise tarkvara ühilduma?
- Kas ma soovin, et tarkvara oleks minu ettevõtte arvutis või sobib mulle, et tarkvara kasutab pilvetehnoloogiat ning on kättesaadav üle interneti?
Tarkvarafirmadel on mitmeid lähenemisi, mille järgi nad ise lähteülesannet hindavad ning koostavad. Kuigi tellijana ei pea tootmisettevõte ise kõiki neid aspekte enda koostatud lähteülesandesse kirja panema, on siiski kasulik, kui IT-maailma mõtlemisega veidi kursis oled:
- Eesmärgid (design goals).
- Korrektsus – kuidas teada, kas tarkvara teeb seda, mida ta tegema peab?
- Efektiivsus — ajaliste ja mahuliste piirangute arvestamine. Kui kiiresti peab tarkvara suutma arvutada tellimuste tootmisjärjekorda?
- Usaldatavus – (reliability, tihedalt seotud terminiga robustness). Kuidas peab tarkvara käituma ootamatute sisendite korral? Kuidas teha tarkvara töökindlaks kasutaja vigade korral?
- Kohandatavus ja skaleeritavus – kuidas peab tarkvara olema edasi arendatav (riistvara, tarkvara). Kas on ette näha, et kasutajaid tuleb hulgaliselt juurde?
- Taaskasutatavus – võimalus kasutada sama nn komponenti mõnes muus kontekstis. See on oluline asjaolu, kui ettevõttel on soov erilahenduse tegemiseks. Karbitoote pakkuja hindab enamasti sellisel juhul seda , kui paljudel ettevõtetel võiks veel sama soov olla. Kui soovijaid on palju, on arendus soodsam või suisa tasuta.
- Kasutuslikkus – kas tellija (kasutaja) on võimeline asja kasutama, kas tal on meeldiv seda teha.
- Hooldatavus – kuidas lahendatakse tarkvara kasutamisel tekkivaid probleeme?
- Modulaarsus – kas tarkvara erinevaid osi on võimalik välja vahetada?
- Avatus – kas tarkvara on võimalik muuta ja edasi arendada?
TSENTER aitas ühel suhteliselt lihtsaid puittooteid tootval 20 töötajaga ettevõttel tootmisjuhtimise tarkvara valida. Tooteid toodetakse ainult tellimuse peale ning need on enamasti eri mõõtudes. Teatud mõõdud on siiski sagedamini tellitavad. Lähteülesande koostamiseks vastasime ülaltoodud kuuele küsimusele ja koostasime ka lihtsa protsessi joonise. Joonise koostamisel lähtusime tootepõhisest lähenemisest: kuidas erinevad tooted liiguvad läbi seadmete. Alternatiivne lähenemine on panna kirja seadmete kaart: millistel seadmetel töödeldakse milliseid tooteid.
Ootused tarkvarale olid lihtsad: see pidi võimaldama tellimusi hallata, hinnata sisse tulnud tellimuse puhul prognoositavat tarneaega ja hallata ladu. Ainus soovitud keerukus oli toorme algoritm: sisse tulnud tellimuse puhul oleks vaja hinnata, kas olemasolevast eri mõõtudega toormaterjalist saab tellimuse ära täita ning mis mõõduga tooret on juurde vaja tellida.
Lähteülesanne oli kokku kuuel lehel (koos joonise ja ühe müügiarve näidisega).
Joonis. Tootmisprotsessi skeem.
Koostasime tootmise juhtimise tarkvara pakkujatest järgmise nimekirja (tähestiku järjekorras):
- Columbus IT
- Directo
- Epicor
- Eziil
- LeanEST
- Monitor
- MRP Easy
- Prodmaster
- Woodpecker
- Woodware
Nimekiri ei ole lõplik, sest näiteks Microsofti erinevate tootmisjuhtimise ERP lahenduste pakkujaid on lisaks Columbus IT-le veel. Kõigile ülaltoodud ettevõtetele saadeti lähteülesanne.
Lähteülesande laialisaatmise tulemused olid järgmised:
- üks tarkvarafirma ei vastanud üldse;
- üks tarkvarafirma küsis pakkumise tegemiseks lisaaega, aga ei vastanud ka enda poolt pakutud tähtajaks;
- kaks firmat vastasid, et nende lahendused on suurematele ettevõtetele ja investeering algab alates 100 000€;
- üks firma vastas, et nende lahendus ei võimalda arvutusi, mida ettevõte vajab;
- üks firma saatis meeldetuletuse peale vastuse, et nende tarkvara ei sobi protsessipõhiseks tootmiseks, kuid sobib paremini diskreetseks tootmiseks (etteantud materjal ja tooted);
- neli ettevõtet soovisid kohapeal käia, et pakkumist teha: kolm tegid pakkumise, üks loobus pakkumise tegemisest pärast kohapeal käimist.
Olulisemad küsimused, mida tarkvarafirmad lisaks küsisid, olid järgmised:
- Mis riistvaral ja operatsioonisüsteemidel peab tarkvara töötama: Windows, Linux, MacOS, nutiseadmed?
- Kui kiirelt peab info süsteemis uuenema? Kas info peab olema minuti pealt õige või piisab tunni/päeva täpsusest?
- Kui palju peavad kasutajad saama süsteemi ise kohandada?
- Kuidas info täna ettevõttes liigub?
- Kui suur on tarkvara juurutamise meeskond?
Pärast kolme hinnapakkumise saamist tuli teha valik. Kriteeriumiteks seadis ettevõtte juht järgmised näitajad:
| Tarkvara võimekus pakkuda materjaliga kaetusest ülevaadet (prioriteet number 1) |
| Ühilduvus olemasoleva raamatupidamisprogrammiga |
| Tarkvara kasutama õppimise lihtsus |
| Juurutamise tugi |
| Referentsid (millised sarnased ettevõtted seda tarkvara kasutavad) |
| Konsultatsiooni ja juurutamise tunnitasu ning hind |
| Arendustöö hind |
| Hilisem iga-aastane hooldus- ja/või litsentsitasu (kuutasud) |
| Pakkuja võimekus tarkvara edasi arendada (kui suur on arendusmeeskond) |
| Tarkvarasse lukustumise risk (s.o kui lihtne on mõnele teisele tarkvarale üle minna) |
| Andmete varundamine ja turvalisus (kus asub andmebaas) |
| Tarkvara sõltumatus operatsioonisüsteemist (kasutatav erinevates seadmetes) |
Nendest kriteeriumitest lähtudes valiti välja üks pakkuja, kellega alustati läbirääkimisi tarkvara juurutamiseks.
Soovitused targa ostjana läbirääkimisteks ja otsustamiseks
- Kõige tähtsam on kirjeldada tarkvara juurutamisest saadav kasu. Sellest lähtudes oskavad tarkvarafirmad hinnata, kas nende lahendus on mõistlik, liiga keerukas või kallis.
- Lähteülesandes tuleb kirjeldada tänane probleem, tarkvarast loodetav kasu ning ettevõtte tootmise keerukus. Lähteülesanne peab olema pikem kui üks lehekülg, aga ärge üritage tarkvarafirma eest süsteemi analüüsi ära teha. Ka nt 30 lehekülge ettevõtte analüüsi ei aita tarkvarafirmat ning te olete kulutanud liiga palju aega tühja töö tegemiseks. Tarkvaraettevõtetel on omad analüüsi loogikad ning nad tahavad ise veenduda, kas asjad käivad tegelikult ka nii, nagu on paberile pandud. Isegi kui koostate hea lähteülesande, küsivad nad küsimusi juurde ning kindlasti tahavad nad veenduda, et lähteülesandes toodud asjad on õigesti kirja saanud. Mahukamate tarkvarainvesteeringute puhul tasub lähteülesande koostamiseks palgata spetsialist.
- Tarkvaraettevõtetega suhtlemine võtab aega ning tootmisettevõte peab olema ise aktiivsem pool, et asjad kiiresti sujuksid. Seetõttu peab ettevõtte juht valima lähteülesande väljasaatmiseks perioodi, kus tal on aega tarkvarafirmadele oma probleemi selgitamisega tegeleda.
Artikli autor: kalev Kaarna
Allikad:
- Writing Good Requirements: Checklist. John Hopkins Whiting School of Engineering. https://ep.jhu.edu/about-us/news-and-media/writing-good-requirements-checklists
- Andrew Stellman. Using non-functional requirements to build better software. https://www.stellman-greene.com/2009/10/03/using-nonfunctional-requirements/
- Donn Le Vie, Jr. Writing Software Requirements Specifications (SRS) https://techwhirl.com/writing-software-requirements-specifications/
- How to Write a Software Requirements Specification. https://microtoolsinc.com/papers/how-srs/
- Jaanus Pöial. Tarkvaratehnika elemendid. http://enos.itcollege.ee/~jpoial/oop/loeng/tarkvaratehnika_elemendid.html
Raamatud:
- Davis, Barbara. Mastering Software Project Requirements: A Framework for Successful Planning, Development and Alignment, J. Ross Publishing, 2013.
- Dumas, M., La Rosa, M., Mendling, J., & Reijers, H. A. (2013). Fundamentals of Business Process Management. Springer.
- Goldsmith, R. (2004). Discovering real business requirements for software project success.
- Lauesen, S. (2002). Software Requirements. Pearson Education.
- Ries, E. (2011). The Lean Startup. Crown Business.
- Schragenheim, E., & Dettmer, H. W. (2001). Manufacturing at Warp Speed. Optimizing Supply Chain Financial Performance. CRC Press.
- Schleier, J. (2010). Theory of Constraints Handbook. (J. Cox III & J. G. J. Schleier, Eds.). McGraw-Hill.
