Živjo,

imam to srečo, da sta me Rok in Aljaž povabila k sodelovanju pri sistematizaciji Fitoplus in sem se zato odločil napisati eno tako "insajdersko" mnenje, kako sem jaz, iz prve roke, doživljal ta proces v zadnjih 6 mesecih.

V prvih 2 mesecih našega sodelovanja, sem v večini skrbel za sistematizacijo podjetja preko dokumentiranja procesov in pretty much vsega kar se je dogajalo.

Prav tako sem Roku pomagal pri (strateškem) vzpostavljanju tega sistema zato imam precej dober vpogled na to kako je vplival na samo podjetje.

1. Na začetku sistematizacije, ni nobena stvar pravilna ali napačna. Enostavno se moraš za nekaj odločiti, to stestirati, po vsej verjetnosti zapraviti 3 dni in šele potem imaš občutek katera rešitev je primerna zate (za firmo). Ni dovolj, da samo bereš reviewse po internetu, ker ima vsaka firma svoje potrebe in okoliščine. Edini način je "ouching".

Primer:

Ko smo se odločali o Project management platformi, smo imeli na voljo vsaj 6 platform (Asana, Freedcamp, Teamwork in še mnogo drugih). Naredili smo relativno hiter research in začeli uporabljati eno izmed teh platform. V roku 3 dni se je pokazalo, da enostavno ni za nas in zato smo potem prešli na drugo (Freedcamp), ki ga uporabljamo še zdaj.

Freedcamp ni bil najboljši na review straneh. Je pa bil najboljši za naše osebne potrebe.

Ampak to smo ugotovili šele, ko smo stestirali ostale preko dejanske vsakodnevne uporabe in videli kateri nam osebno najbolj ustreza.

Podobno je bilo pri blog sistemu za magento. Določen modul nam je deloval simpatično, ampak so se v preteklosti dogajali vdori preko njega.

Pregledali smo alternativo. Imel je dobre reviewe in smo se odločili za "ouching".

Iskreno sem mislil, da je "The One".

Po 3 dneh dejanske uporabe, nam je bilo jasno, da niti približno ni dovolj močan za naše potrebe in bomo pač morali "reskirati" s prvim modulom.

Kaj sem se naučil pri tej prvi točki?

Potrebno je dovoliti vaši ekipi (in sebi), da stestirajo zadeve in da je okej, da se celotni testi na koncu čisto ovržejo. To ni nekaj dni - tednov vrženih stran. Na podlagi teh testov smo dobili ideje kako zgraditi temelje katere zdaj uporabljamo že pol leta in jih bomo najverjetneje še več let. Kaj je nekaj "stran vrženih" dni v primerjavi z močnimi temelji na katerih lahko gradiš še leta.

1. Sistematizacija (za uporabnika) je večinoma dokumentiranje dela. Z drugimi besedami ... ekstremno je dolgočasna.

Tudi meni se je na začetku zdelo dolgočasno pisati o tem kam prihajajo obvestila ob x napaki. Nastavljati opomnike za določene člane ekipe, da preverijo določene zadeve na x dan. Napisati kako uporabljati Google Drive :D ...

Sem pa zelo kmalu videl moč tega "dolgočasnega" pisanja.

Bil je vikend in sem ravno bil na PCju, ko je priletelo obvestilo o neki cache napaki na strežniku. Programer ni bil dosegljiv in stran ni delovala. Še dobro, da je en mesec prej zelo natančo dokumentiral problem in rešitev. V roku 5 minut je bila stran back online in vse kar sem potreboval je bilo sledenje njegovim navodilom, ki jih je dokumentiral.

Takih primerov (pa ne samo s programerske strani) je bilo potem vse več in povsod se je izkazalo kako dobro je imeti vse dokumentirano.

Prišlo nam je v navado, da smo začeli takoj dokumentirati probleme. Ker smo enostavno dojeli koliko časa nam prišpara v prihodnosti.

1. Kljub temu, da je vse dokumentirano in lahko novemu članu samo prilepiš link, da si prebere kako vse deluje v firmi pa v praksi ljudje vseeno potrebujejo nekoga, da jih usmerja vsaj prvi teden.

Imel sem primer, ko sem razlagal našemu customer supportu, kako nastaviti UTM link v chatu (da lahko spremljamo prodajo z dejanskih pogovorov). Ni in ni šlo (customer support nima IT backgrounda).

Zato sem se odločil napisati preprosto skripto za naše interne potrebe in posneti video kako jo uporabljati.

Ko sedaj nekdo hoče (tudi če pride nova oseba na to pozicijo) uporabiti UTM link v pogovoru, samo pogleda video in uporabi skripto.

Vsi ogromno privarčujemo na času, ki bi bil potreben za razlago.

Zelo močno omejimo tudi možnosti napake.

1. Zaposlene je treba večkrat opomniti, da morajo uporabljati sistem.
   Ljudje smo bitja navad in težko je presedlati na nov sistem.
   Kako najlažje to storiti?
   Enostavno ne smeš biti na voljo zunaj sistema.

Primer:

Ukinili smo interne emaile, ker poberejo preveč časa in je vse porazgubljeno naokoli.

Vso komunikacijo smo opravljali v Freedcampu in pa na Slacku.

To se ni zgodilo čez noč, ker so se emaili še vedno pošiljali med seboj.

Enostavno nisem več odgovarjal na njih in sem vsem dal samo vedeti, kje je pravilno mesto za takšna vprašanja.

V roku dobrega tedna, ni bilo skoraj nič več email sporočil :)

1. Sam moraš biti največji enforcer in uporabnik sistema.
   
   Ko ostali vidijo, da sistem deluje, ga tudi oni začnejo uporabljati. Na začetku traja in je veliko pripomb. Po kakšnem mesecu pa si sploh ne znam več predstavljati kako je bilo pred sistemom (kaos).




2. Sistem se vedno razvija. Opazil sem, da nekje v roku vsakih 2 mesecov, sistem toliko zraste in dozori, da potrebuje dober pregled in izboljšave v strukturi. To pa seveda ni noben problem, ker je že vnaprej zastavljen tako, da se lahko širi.

Zaključek ...

Na začetku je zadeva zelo mukotrpna in zgleda ful odveč. Zdi se zapravljanje časa, ker ne prinaša direktno rezultatov.

Ko pa se enkrat začnejo pojavljati problemi, ki se jih spomniš, da si jih rešil že 2 mesca nazaj (ampak si iskreno pozabil kako) pa si zelo vesel, da si takrat zapisal in imaš rešitev v 5 minutah.

Potem kmalu sledijo tudi rezultati, saj vsak zaposleni točno ve kaj mora delati in kje najde informacije :)

Hvala še enkrat Rok, da si me naučil ne samo kako uporabljati sistem ampak tudi kako ga postaviti. :)