Ako plánovať nízkorizikové vývojové projekty

Objednávky z e-shopu prichádzajú, ale niekto ich musí každé ráno ručne prenášať do účtovného systému. Sklad vidí iné údaje o zásobách ako predaj, a v piatok traja ľudia zhromažďujú čísla pre manažérske správy. V takejto situácii otázka ako plánovať nízkorizikové vývojové projekty nie je primárne technologickou úlohou. Najprv je potrebné pochopiť, ako sa každodenná prevádzka stala tak závislou od ručného prenosu, tabuliek a znalostí jednotlivých kolegov.

Zníženie rizika neznamená, že spoločnosť by nemala robiť zmeny. Znamená to, že zmena má jasný obchodný dôvod, dobre vymedzené hranice a kontrolovateľné dôsledky. Aj počas dobre naplánovaného menšieho vývoja zostáva spoločnosť funkčná: faktúry sa pripravujú, objednávky sa plnia, výroba sa nezastaví a dotknutí zamestnanci vedia, čo sa deje.

Riziko vývoja je často už v procese

Mnohé organizácie robia chybu, že na nepríjemný symptóm okamžite hľadajú systém alebo automatizáciu. Ak fakturácia mešká, žiadajú nový fakturačný modul. Ak nie sú dobré správy, žiadajú nový dashboard. Ak je príliš veľa e-mailov, zaviedli by nový systém riadenia pracovných procesov.

Tieto riešenia môžu byť oprávnené, ale nie vždy. Napríklad fakturácia môže meškať, pretože údaje o objednávkach sú na troch rôznych miestach a nie je jasné, ktorý je dôveryhodný zdroj. Dashboard by len rýchlejšie ukazoval tie isté chybné alebo oneskorené údaje.

Najväčšie prevádzkové riziko často nie je samotný starý systém. Ale proces, v ktorom ľudia slúžia ako spojenie medzi systémami, oddeleniami a zdrojmi informácií. Ak zamestnanec ide na dovolenku, proces sa spomalí. Ak sa pomýli v čísle produktu, chyba sa prenesie do skladu, fakturácie alebo komunikácie so zákazníkom. Ak nie je k dispozícii vlastník tabuľky, nikto si nie je istý, ktorú verziu použiť.

Preto je vhodné začať nízkorizikový vývoj nie obrazovkou alebo technológiou, ale konkrétnym obchodným procesom.

Ako plánovať nízkorizikové vývojové projekty v praxi?

Dobrým východiskovým bodom je proces, ktorý je dostatočne bolestivý na to, aby sa oplatilo ho zlepšiť, ale dostatočne dobre vymedzený na to, aby neotvoril celú prevádzku spoločnosti naraz. Takým môže byť prenos objednávok z e-shopu do skladu, spracovanie dodávateľských dokumentov, evidencia servisných požiadaviek alebo pravidelne ručne zostavovaná manažérska správa.

Pri vybranom procese je vhodné sledovať, čo sa skutočne deje. Nie to, čo hovorí postup, ale čo kolegovia robia každý deň. Odkiaľ prichádzajú informácie? Kto ich kontroluje? Koľkokrát sa zadávajú tie isté údaje? Kde úloha čaká na schválenie? Ktorý krok si vyžaduje telefonát alebo e-mail, pretože systém niečo neukazuje?

Mapovanie procesu často rýchlo odhalí, že krok už nemá skutočný cieľ. Možno bola tabuľka zavedená pred rokmi, pretože vtedajší systém nedokázal spracovať určitý údaj. Medzitým sa systém zmenil, ale tabuľka zostala a dnes už len pridáva ďalšie kontroly, kopírovanie a neistotu.

Cieľ vývoja by mal byť formulovaný obchodným jazykom. Cieľom nie je „integrovať systémy“, ale napríklad to, aby údaje z objednávok z e-shopu bez ručného zadávania a kontrolovateľne dosiahli tím zodpovedný za plnenie. Nie je to „vytvoriť AI riešenie“, ale aby kolegovia rýchlejšie našli údaje potrebné na rozhodovanie v prichádzajúcich dokumentoch.

Menší rozsah, skutočný výsledok

Príliš veľký prvý krok robí projekt nepredvídateľným. Ak vývoj naraz ovplyvňuje predaj, sklad, nákup, fakturáciu a financie, počet rozhodnutí rýchlo rastie. Každá výnimka, staré pravidlo a odlišný pracovný spôsob si vyžaduje ďalšie konzultácie. Kým sa riešenie dokončí, samotná obchodná potreba sa môže zmeniť.

Je lepšie vytvoriť prvú fázu, ktorá sama o sebe prináša hodnotu. Napríklad neprepracovávajte celý reťazec správy objednávok ako prvý. Najprv zabezpečte, aby objednávky prichádzajúce z e-shopu boli automaticky zobrazené v internom operačnom systéme v jednotnom formáte. V ďalšej fáze sa môže riešiť rezervácia zásob, potom odovzdanie prepravcovi alebo notifikácie zákazníkom.

Toto nie je pomalší prístup. Často prináša rýchlejšie hmatateľné výsledky, pričom znižuje pravdepodobnosť, že celý projekt sa kvôli predpokladu vydá nesprávnym smerom. Počas používania prvej fázy sa totiž ukáže, či pôvodná predstava bola správna a s akými výnimkami treba skutočne počítať.

Zúženie rozsahu neznamená ignorovať neskoršie rozšírenie. Riešenie musí byť navrhnuté tak, aby sa neskôr nemuselo zahodiť. Preto je už na začiatku potrebné objasniť vlastníkov údajov, systémové prepojenia, oprávnenia a čo sa považuje za oficiálne obchodné údaje.

Riziko je možné riadiť pomocou meracích bodov

Vývoj je riaditeľný, ak vedenie vidí nielen to, že sa „pripravuje“, ale aj to, či sa zlepšuje prevádzka. Na to nie je potrebný zložitý systém ukazovateľov. Pri procese objednávania možno merať čas venovaný ručnému zadávaniu údajov, počet chybných objednávok, čas spracovania a koľko výnimiek musí riešiť človek.

Meranie musí začať ešte pred zmenou. Ak nie je východisková hodnota, neskôr sa dá len na základe dojmov diskutovať o tom, či sa vývoj oplatil. Môže sa stať, že nový proces sa spočiatku zdá pomalší, pretože zviditeľňuje kontroly, ktoré sa predtým vykonávali neformálne alebo nekonzistentne. To nemusí byť nevyhnutne neúspech. Je potrebné pochopiť, že spomalenie je prechodný efekt učenia, potrebná kontrola alebo skutočný problém v návrhu.

Podmienky úspechu je potrebné vopred stanoviť. Napríklad: 95 percent denných objednávok je možné spracovať bez ručného kopírovania; sklad vidí rovnaký stav ako zákaznícky servis; príprava finančnej správy sa skráti z troch hodín na tridsať minút. Konkrétny cieľ pomáha rozhodnúť, kedy je možné postúpiť ďalej a kedy je potrebné ešte zlepšiť.

Zavedenie: všetko sa nerozhodne v deň inštalácie

Technicky dokončené riešenie ešte nemusí byť funkčným obchodným riešením. Počas zavádzania sa ukáže, či sú výnimočné prípady, zodpovednosti a denný pracovný rytmus skutočne zvládnuteľné. Preto je vhodné najprv použiť nový proces v obmedzenom rozsahu: v jednej produktovej skupine, na jednom mieste, pre jeden typ zákazníka alebo v jednom určenom tíme.

Paralelná prevádzka je v niektorých prípadoch oprávnená, ale nesmie sa udržiavať neobmedzene dlho. Ak starý a nový proces žijú príliš dlho vedľa seba, zamestnanci pracujú dvakrát, údaje sa môžu líšiť a nikto nevie, ktorému systému veriť. Je lepšie vopred určiť, ako dlho trvá kontrolované skúšobné obdobie, kto schvaľuje jeho výsledok a kedy sa nový postup stane prioritným.

Plán obnovy je tiež súčasťou riadenia rizík. Nie preto, že by sa očakávalo, že vývoj zlyhá, ale preto, že je potrebné chrániť obchodnú činnosť. Ak integrácia pošle chybné údaje, je potrebné vedieť, ako ju zastaviť, ako identifikovať dotknuté transakcie a kto rozhodne o náprave. Dobre zdokumentovaná možnosť obnovy zvyšuje dôveru v zavedenie.

Znalosti ľudí by nemali zostať skrytou súčasťou systému

V rastúcich spoločnostiach je bežné, že kľúčová osoba si pamätá výnimky: akému zákazníkovi je potrebné poslať dokument v akom formáte, ktorého dodávateľa je potrebné osobitne skontrolovať alebo prečo by sa určitá objednávka nemala automaticky odovzdať. Toto je cenná skúsenosť, ale obchodné riziko, ak existuje iba u jednej osoby.

Cieľom nízkorizikového vývoja nie je nahradiť tohto kolegu. Skôr je to, aby jeho znalosti boli vyjadrené v kontrolovateľných pravidlách, viditeľných stavoch a spoločne použiteľnom pracovnom procese. Takto trávi menej času opakujúcou sa administratívou a viac tam, kde je skutočne potrebné zváženie, znalosť zákazníka alebo odborné rozhodnutie.

Dokumentácia by mala byť krátka, ale použiteľná. Pri novom procese musí tím vedieť, čo sa zmenilo, čo robiť v prípade chyby, na koho sa obrátiť a aké údaje nesmie voľne meniť. Jasné stanovenie prevádzkovej zodpovednosti je rovnako dôležité ako samotný zoznam úloh vývoja.

Najlepší prvý vývoj nemusí byť najpôsobivejší. Často je cenné to, čo odstráni každodenné polhodinové kopírovanie, zviditeľní zaseknutú objednávku alebo oslobodí proces od jednej tabuľky. Tieto kroky nielenže šetria čas: poskytujú dôkaz, že prevádzka spoločnosti môže byť kontrolovane rozvíjaná bez rizika ďalšieho veľkého skoku.