| title | H1K |
|---|---|
| permalink | H1K |
Harjutus 1 Kokkuvõte töödest
noppeid töödest koos kommentaaridega
(motto asemel) Ühe ministeeriumi ametnik ütles mulle usalduslikus vestluses, et vahel on küsimus inimeste leidmises, kes suudaksid üldse sõnastada, milles on probleem, rääkimata nende kohesest ja lihtsast lahendamisest..
TL;DR KOKKUVÕTE
Kahes erinevas töös:
-
Kuna üksteisele antavad ülesanded on kirjas ainult e-mailides on keeruline jälgida töö staatust ning raske on tuvastada kes midagi tegi ning näiteks miks projekt toppama jäi"
-
"Kui osadele meilidele ei pea või pole võimalik koheselt reageerida, siis on inimfaktoril liiga suur roll ja lahendus võib toppama jääda."
Toppamajäämise küsimust võiks edaspidi lähemalt uurida.
"iseteeninduskeskkonna idee seisneb selles, et paki saatmine võib olla lihtne. Ettevõtte infosüsteeme arendatakse pidevalt, sest info liikumise kiirus ja kvaliteet on ettevõttele väga olulised."
TNT (https://www.tnt.com/express/et_ee/site/home.html) on hea kinnitus teesile, et ka lihtsat süsteemi saab (peaaegu alati) teha veel lihtsamaks. (Teisiti öeldes, lihtsana näiv süsteem võib olla keerukam kui välja paistab).
(Vana süsteemi kuvapildistustes torkavad silma mitmed "Halda" tegevused. See ei ole väga tänapäevane stiil.)
TNT tellimisprotsess on sujuv. Kasutajaliidese ülesehitus ja kujundus on väga hea. Väärib kindlasti uurimist ja eeskuju võtta.
Siiski võiks juurelda, miks uues süsteemi (myTNT 2 BETA) kasutuselevõtmisel vana süsteem (myTNT) jäeti paralleelselt tööle (https://www.tnt.com/express/et_ee/site/home/compare-mytnt.html)? Kummalgi süsteemil on eraldi sisselogimine. Need oleks saanud ühitada. Ilmselt maandati ülemineku riske. (Vrdl TLÜ uus ÕIS - see töötab kõrvuti vanaga. Risk on selles, et uus on nii harjumatu - ja vahel ka inferior omaduste poolest! - et "kangi tõmbamise" meetodil üleminekut korraldada ei saa. Uue ja vana paralleelkasutuse oht on selles, et kui kindlat tähtaega vana süsteemi kinnipanekuks ei seata, siis osa kasutajaid venitavad üleminekuga. Kahe süsteemi ülalpidamine on aga alati mingi koormus.)
FexExi ja TNT ühinemise osas pakuvad huvi suhtarvud (http://www.fedex.com/ee/ee/connect/). FedEx-i töötaja toimetab päevas keskmiselt 3.4 pakki. TNT töötaja 1.8. Millest tuleb vahe? Juba aastaid tagasi leidsin FedEx-i ja UPS-i IT kulude võrdluse. FedEx-i IT kulu käibest 5%, UPS-il 3%. Päris suur vahe. http://2.bp.blogspot.com/-MRlpEQ3P7SU/UlUNqz4utmI/AAAAAAAAFa4/V3bNa3qOf8Q/s1600/image003.gif
"Probleemseks võib osutuda võimsus ehk maksimaalne kasutajate arv iseteeninduses samaaegselt." IT arhitekt ja teenust haldav IT osakond peavad kindlasti tegema jõudluse planeerimise, paika panema SLA (teenustaseme leppe) eesmärknäitajad ja teenuse kasutamise jälgima. 1 000 000 pakki päevas võiks tähendada kuni 1000 samaaegset kasutajat süsteemis. Arvestades, et suuri andmemahte ei liigutata, on see kindlasti saavutatav.
"Analüüsitavas ettevõttes toimub kommunikatsioon peamiselt e-maili ja telefoni teel. Keskmiselt peavad enamus töötajatest päevas haldama ligikaudu 100-150 e-maili."
See on mõtlemapanev. E-maile on suhteliselt raske töövoogudesse hõlmata ja automatiseerida. Tavaline kontoritöötaja ei saa sellega kindlasti hakkama. Ta saab oma Outlookis teha reegleid, mis e-kirju kaustadesse (või ka otse prügikasti) saadavad. Enama tegemine nõuab spetsiaalseid IT-oskusi ja ka ligipääse IT-taristule, mida lihtkasutajale ei anta. E-kirjade koostamise ja väljasaamise automatiseerimine on võimalik, kuid see on ainult üks tükike. Automatiseerimist raskendab ka see, et kiri on reeglina vabas vormis.
"Kui osadele meilidele ei pea või pole võimalik koheselt reageerida, siis on inimfaktoril liiga suur roll ja lahendus võib toppama jääda."
"umbes 50-70% infost on ebaoluline või ei vaja kohest sisendit töötaja poolt." Avo Raup,tuntud ITIL-i (IT-teenuste haldamise raamistik), Lean IT (Jaapani tootmiskorraldusfilosoofiast inspireeritud IT haldamise viis) ja DevOps (moodne käsitlus IT-st, mis ühitab süsteemide arendamise ja haldamise üheks, korduvaks protsessiks) koolitaja kasutab reeglit, et loeb ainult neid kirju, kus ta on pandud põhiadressaadiks, mitte cc-ks. Meie organisatsioonis ühe üksuse juht üritas kehtestada reegleid efektiivsema e-kirjavahetuse saavutamiseks (kuidas sõnastada kirja teemat jne). Väga hea üritus, kuid kahjuks millegipärast kohtas inimestes vastuseisu.
"Suurimaks boonuseks on see, et minu osakond asub IT korrusel, mis tähendab seda, et probleemide või küsimuste korral saab paari sammuga kohe minna muret kurtma" Ma ei ole selles asjatundja, kuid infotöötluse (ja kommunikatsiooni) füüsiline külg on minu arvates paljudes organisatsioonides alahinnatud. Lähemalt sellest loengus. Üks näide: arutasime tulevast arendushanget ja leidsime, et tõenäoliselt me ei leia Eesti turult arendajaid, kes oleksid nõus töötama meie kontoris. Minu arvates see on indikatsioon, et midagi IT-turul, täpsemini - IT tellimises - ei ole paigas.
Maylor H (2013) How Hard Can It Be? Actively Managing Complexity in Technology Projects. Research-Technology Management.
Võttes kõrvale Maylori "The Complexity Assessment Tool" võib teie arenduste riskitaset hinnata madalaks (turult ostetud parimad IT-spetsialistid, arendajatel pole teisi projekte, koospaiknemine). Seetõttu ei ole ka ime, et arendused on õnnestunud.
Helsingis detsembris 2016 oli ühe tudengi juhtumiuuring samuti ehitusvaldkonna ettevõttes (rahvusvaheline ettevõte, käive samuti 50 milj EUR). Probleemid paistavad vägagi sarnased. Võib-olla on põhjuseks ehitamise omapära. Ehitamisel on väga palju planeerimist, koordineerimist, jälgimist. Tegevus ei toimu ühes kohas ega pelgalt kontorites, vaid hajutatult. Tegevusele on iseloomulik suur osapoolte arv, keerulised seoses osapoolte tööpanuste vahel. Need põhjused ilmselt on mõjutanud seda, et ehitusplatsi ja kontori infotehnoloogiline lõimimine, mida seati eesmärgiks juba 15-20 a tagasi, ei ole kaugeltki lõpule viidud.
Sellise suurusega ettevõttes on raske hakkama saada üheainsa suure süsteemiga. Paratamatult on kasutusel mitu süsteemi (tüüpiliselt 5-9), nende liidestamine on probleem. Siiski, kui olukorda vaadata, võib leida süsteemi (või suuremate süsteemide osi), mis töötavad teistest paremini. Soome magistrandil oli hea näide töömaa planeerimisvahendist, mida loeti õnnestunuks. Võtmesõnadeks lihtsus, fookus ja tarkvaras teostatavast protsessidest adekvaatne arusaamine.
"üle sektori tekkinud aktiivsust, et leida ühtne lahendus ka veosekorralduse osas" Siin on hea näide Eesti Metsatööstuse Liidu veoselehtede süsteem ELVIS (https://www.veoseleht.ee/Web/et/EE/Home.mvc).
"Mitme osakonnaga seotud projektide juhtimine excelis" Siin on kindlasti häid, lihtsaid tarkvarasid olemas. Alustades Trellost, Asanast (https://asana.com/)
"Kuna ülemustelt tulevad ülesanded ja koosolekutel jagatud rollid e-mailides puudub täielik ja lihtne ülevaade nii ülemusel iga alluva tegemiste kohta kui ka alluval on raske otsida ja omada lihtsat ülevaadet kõigi projektide, kohustuste ja tähtaegade kohta." Karjub workflow- v projektijuhtimissüsteemi järele.
"Kuna üksteisele antavad ülesanded on kirjas ainult e-mailides on keeruline jälgida töö staatust ning raske on tuvastada kes midagi tegi ning näiteks miks projekt toppama jäi" Oluline küsimus: Mis toppab? Kus toppab? Miks toppab?
EBS tudengite tagasiside kogumine-haldamine
Teil on väga hea ja usun, et adekvaatne pilt EBS-i süsteemist.
See on huvitav teema. Näiliselt jällegi lihtsam, kui asi tegelikult on. Protsessis osalejana oleks mul teemal palju öelda. Siin aga vaid paar mõtet. 8)
Tudengite tagasiside kogumise formaalset (reeglistatud) süsteemi vajate juba sellepärast, et hoida akrediteeringut. Süsteemi vajalikkus ei tekita kahtlust.
Minu jaoks on võtmeküsimus selliste hinnangute juures millal neid kasutada ja millal mitte. Loomulikult on akadeemiline traditsioon, üldine respekt, viisakus, hoolsuskohustus - ja need on elementaarsed asjad.
Huvitava kokkusattumisega üks minu kolleeg meie asutusest õpib samuti EBS-is (bakalaureuseprogrammis). Kristjan saatis mulle oma analüüsi, kuidas EBS-i hindamissüsteemi võiks parendada. Tsiteerin:
Kristjanilt: „Kujutage ette, et õppematerjalide kaalutud aritmeetilise keskmise hindamisel on esimese õppejõu tulemus 5,88 ja neljandal kohal oleva õppejõu tulemus 5.0. Kuidas sa ütled või sead eesmärke 0.88 pügala tõstmiseks?“ [EBS-s kasutatavas 7-palli süsteemis]
Agiilarenduse pooldajana - olles näinud ja ise teinud plaane, projekte, juhendeid "over-the-top" ehk "üle võlli" - ja mida kinnitab ka statistika - 40% väljatöötatud tarkvarast ei leia kasutust - ma paneksin siia kõrvale ehk brutaalsed, kuid vaagimist väärivad hüpoteesid:
pidev täiustamine (Continuous Improvement) on ilus abstraktsioon, kuid praktikas peab sellega piiri pidama:
- sest 0.88 pügalat ei ole erilist mõtet tõsta
- sest siis peaks tõusma ka õppemaks (eksponentsiaalselt)
- elus on palju muudki kui 0.88 tagasiside upitamine
- 80/20 reegel e Pareto printsiip: enamus kliente on juba rahul.
YAGNI printsiip (https://agiil.github.io/sonastik/#YAGNI)
Lähemalt ehk saame loengus seda teemat veel käsitleda.
"Üldiselt on ettevõttes [..]]infohaldus hästi korraldatud. Kvaliteedijuhtimissüsteem tagab selle, et info on ajakohane ja süstematiseeritud. Kõik ettevõtte töötajad on varustatud vajaliku infoga."
Ütlen ausalt, et raske on seda uskuda. Võib-olla on tegu väga väljapaistva ettevõttega. Infohaldus on üks ettevõtte tugiprotsesse. Kvaliteedisüsteem nõuab kõigi protsesside regulaarset hindamist. Hea olekski järgmisel hindamisel küsida töötajatelt (ja miks mitte ka partneritelt), kuidas infohaldusega rahul ollakse. Empiirilisel andmestikul on suurem veenmisjõud.
Inseneribüroo
"ettevõttes on probleemid jooksvate projektide ajakavas ja eelarves püsimisega."
Tsiteerin siin üht tuntud, suurte kogemustega IT-firmajuhti, kes ministeeriumis koosolekul ütles, et "Eesti väikestes ehitusfirmades pole tööde planeerimise võimekust. Tööd saavad valmis siis, kui nad saavad". Projekteerimisfirmades on see võimekus arvatavasti tugevam.
Ilmselt saaks kui mitte kohe kasutatavaid lahendusi, siis vähemalt ideid agiilarendusest. Lähemalt loengus.
Mäletan, et juba 15-20 oli Soome ehituses kasutusele agiilehitamise (Lean Construction) meetod. Väga lähedane Lean IT ("kasina IT") suunale. Selle kohta oli juba siis huvitavat inglisekeelset kirjandust.
Töötleva tööstuse ettevõte
"mitukümmend seadet, mille andmeid on vaja töödelda. Olukorra keerukus on selles, et andmed on kõik erineval kujul ja nende analüüsimiseks tuleb saadud informatsioon viia sarnasesse formaati, mis nõuab spetsiaalseid programme." See nõuab palju tööd, kuid on teostatav.
Infotehnoloogia haldamiseks on ettevõttel olemas oma tegevus– ja arengukava, mis on dünaamilises protsessis ehk vastavalt vajadustele ja olukordadele muudetav. Rõhutaksin: 1) IT tegevuskava olemasolu; 2) tegevuskava dünaamilist muutmist vastavalt muutuvatele vajadustele ja olukordadele. Vähe on organisatsioone, kes neid kahte asja korraga suudavad teha.
"Kogu infotehnoloogiat aitab ettevõttel hallata IT teenus pakkuv firma, kellel on olemas väga laia kvalifikatsiooniga spetsialistid erinevate probleemide lahendamiseks." Rõhutaksin: lai kvalifikatsioonide spekter. See ei ole Eesti IT-turul väga tavaline.
Reklaamiosakond
Minu ettekujutus oli, et need protsessid on ammu automatiseeritud. Selgub, et ei ole. Kontseptuaalselt on asi selgejooneline: ühel pool on reklaamiks sobivate meediapindade valdaja. Teisel pool on potentsiaalne reklaamiandja. TLÜ IT-tudengitega olema kavandanud süsteeme, kuidas kaks poolt dünaamiliselt kokku viia. Asja alus on läbianalüüsitud protsess.
"VPN ei tööta." Déjà vu. Siin on mingi sügavam probleem - millest IT-inimesed ise ka aru ei saa.
"Müügi protsessis pakutud teenus ei ole müügi ajal täielikult valmis." Võib-olla peabki müüki alustama varem? Meil on lõppemas mitmeaastane tarkvaraprojekt. Müüki alustasime õige varakult. Müügi kõrgpunkt on juba möödas, aga tarkvara alles hakatakse kasutusele võtma.
"Lõppkliendi telefoni abiliini meeskond kuuleb, et tarkvara uuenduste osakond on teinud muudatusi lõppkasutaja kaudu. (Kommunikatsioon lõppkasutaja tarkvara uuendamise korral. [..] aga piisab sellest, et inimene, kes suurkliendiga muudatuse jaoks suhtleb, kommunikeerib olulisi muudatusi ka telefoniteeninduse meeskonnale."
Selle saavutamiseks sobiks rakendada formaalne Muudatuste halduse protsess (üks ITIL-i protsessidest).
"Töötajate tööülesannete ja kalendrite täitmine. Ettevõte nõuab, et kõik töötajad annaksid oma ajakasutusest aru, täites igapäevaselt kalendrit. Lisaks on isikliku produktiivuse moodulis tööülesannete register ja graafiline töövoo vaade, mis võimaldab ülesannete täitmist jälgida. Tihti ei kajasta tööülesannete register reaalset tööde nimekirja ja kalendrit täidetakse harva."
Ja võib-olla ongi nii hea. Mingi uue asja väljamõtlemine, keerulise tehnoloogilise probleemi või bugi uurimine võib võtta palju aega. Vrdl Bruce Mau (1998) Incomplete Manifesto for Growth http://www.industrialbrand.com/wp-content/uploads/2014/02/Bruce-Mau-Incomplete-Manifesto-For-Growth.pdf
Selliste kõikehõlmavate aktsioonidega kipuvad tekkima erikategooriad - tavaliselt aktsioonide korraldajad - kes ise ei täida. Tippjuhi aeg on väga hinnaline. Kas ka tema peaks iga päev kalendrit pidama? Ajakasutuse uuringuid v-o oleks parem teha fokusseeritult, perioodiliselt.