Když už se organizace rozhodne pro digitalizaci, má jistě nějakou motivaci. Je ale stěžejní, aby se tato změna odehrála na základě racionální potřeby, která je v souladu například s marketingovou strategií, zvýšením efektivity provozu, splněním požadavků zákazníků a podobně. Tím jednoznačně určíte směr vašeho cíle.
Naopak mezi motivace, které se stávají hrozbou pro úspěšnost projektu digitalizace, můžeme zařadit například:
„Uděláme to, protože je to in.“, „Potřebujeme získat dotace.“, „Potřebujeme vykázat činnost.“
Digitalizace může proběhnout úspěšně co do funkčnosti řešení, ale možná digitalizujete něco, co má prachbídnou přidanou hodnotu. Tím akorát vyčerpáte zdroje, které mohly být využity užitečněji.
Když neznáte cíl a jeho „proč“, těžko se vám bude předávat kolegům, co od systému potřebujete.
Možná už jste slyšeli ono zakořeněné „Zákazník nikdy neví, co chce.“ Jsem opačného názoru. Zákazník chce vždy uspokojit svoji potřebu co nejefektivněji, ať je jakákoliv. Často ale není schopný optimální řešení najít. Chybí mu totiž kapacity:
Nemá znalosti ve vývoji softwaru a jeho procesu. A když ano, nemusí být dostatečné.
Jiné povinnosti mu zabírají tolik času, že není schopný vše definovat, zanalyzovat a navrhnout řešení sám, resp. v nějakém užším interním týmu bez specialistů na digitalizaci.
Žádný projekt se neobejde bez sběru požadavků. Pokud už v tomto kroku nemáte systém a předáte požadavky programátorům bez řádné nebo žádné analýzy, je selhání projektu digitalizace prakticky zaručeno. Vývoj totiž nebude
prakticky vědět, kde začít, a když ano, tak s čím pokračovat. Začne proto vyvíjet podle svého subjektivního pohledu „od stolu“.
mít dostatečnou znalost kontextu a jednotlivých souvislostí. Netuší, co je pro vás opravdu nezbytné, přínosné a co může počkat do další vývojové fáze.
To vede k nárůstu chyb a je nutné nadměrně opravovat. Čím víc se opravují chyby, tím se krátí čas na vývoj dalších částí. Ten se buď významně zpomalí, nebo zastaví. Samotní vývojáři tím budou frustrovaní. Jejich motivace k rychlému dodání toho, co mají naprogramovat, výrazně ochladne. Začnou z projektu odcházet. Projekt se prodražuje, neposouvá. Kompetence a kapacita vývojového týmu se snižuje.
Analýza mohla tomuto selhání zabránit. Jejím úkolem je totiž minimalizovat riziko vzájemného nepochopení zúčastněných stran dostatečným definováním požadavků, nalezením požadavků, které se vylučují, nebo mezer mezi požadavky. Také pomáhá zvážit, zda některé požadavky zcela neodstranit. Nakonec projektový tým bude mít lehkou práci s tím určit, v jakém pořadí podle důležitosti se mají požadavky vyvíjet.
Jestli nějaký požadavek definujete de facto jako řešení, můžete dostat něco, co vám bude práci s informačním systémem velmi komplikovat.
Původní požadavek zákazníka (ředitel odběrového centra):
„Potřeboval bych, aby mi přišel e-mail vždy, když se zaregistruje nový dárce, abychom ho mohli co nejdříve kontaktovat.“
Zákazník požadavkem navrhuje řešení. Pokud by se měl implementovat v původním znění, neslo by to s sebou další prostor pro chyby, navíc by řešení nebylo příliš efektivní – naopak. Proč?
Přijde e-mail na konkrétní adresu, nebo dle role?
Kdo bude registrované dárce obvolávat? Ředitel jen stěží.
Jak se o nově registrovaných dovědí další členové týmu?
Jak …?
…
Je potřeba rozeznat skutečný požadavek, a ten zní:
„Potřebujeme co nejrychleji informaci o nově registrovaném dárci, abychom ho mohli kontaktovat.“
Pak se řešení samo nabídne, např. označit všechny registrované a zároveň nekontaktované dárce v systému včetně času registrace a k dobru ještě rychlý filtr nad seznamem. Jistě, je možné vymyslet další funkce, ale základní potřeba je tím splněna, navíc poměrně snadno.
Tím se ušetří desítky minut až hodiny denně a zároveň se minimalizuje riziko, že někdo zapomene nového dárce kontaktovat. Efektivita týmu tak znatelně vzroste, aniž by se musel měnit proces samotný.
Na začátku vývoje a po celou dobu jeho trvání projekt digitalizace nezřídka selhává na nedostatečné komunikaci. Tedy než se jakýkoliv požadavek dostane do vývoje, mělo by být oboustranně potvrzené, že je management projektu na straně zadavatele i dodavatele na jedné lodi. Vývojáři vědí, co dělají a jaký to má splnit účel.
Zadání a popis pro vývoj by měly být v co nejjednoznačnějším formátu, ať je projekt sebekomplexnější. Pro takové vstupy mají IT a business analytici účinné nástroje. „Neanalytik“ se v tom ale může snadno brzy ztratit.
Často se setkáte s business analytikem jako členem týmu vývoje. Ale není to vždy optimální. Jasně, je lepší mít alespoň nějakého analytika než žádného. Pokud máte ale business analytika na své straně, ušetří vám to mnoho času a nákladů.
Budete přesně vědět, co chcete vyvinout.
Sami dodavatelé ztratí obavy z věty „Chtěli jsme tam ještě tohle, a to tam není!“.
Vytvoříte si mnohem bližší představu o konečných nákladech.
Nejste závislí na konkrétním dodavateli systému, aby vám s touto fází pomohl.
Předejdete tlaku na samotného analytika, který by ve vývojovém týmu mohl „osekat vaše řešení na kost“.
Pomiňme samotné řízení vývoje a architekturu. Jsou to neméně důležité body, ale vy jako zadavatel je ovlivníte spíše nepřímo ve formě požadavků. Kde ale naopak musíte působit, je testování – takzvané UAT (uživatelské akceptační testování).
Vytvořte si podmínky pro to, abyste mohli co nejvěrněji otestovat vaše procesy na doposud vyvinuté části ještě předtím, než nasadíte systém do ostrého provozu.
Lidé neradi adoptují nové nástroje v pracovních procesech z určitých obav. Pokud se vám nepovede systém vašim kolegům „prodat“, veškerá snaha a sebelepší systémové řešení přijde vniveč.
Míra adopce systému je přímo úměrná kvalitě systému, pochopení jeho přidané hodnoty a jeho podpoře. Navíc se musíte vrátit na začátek a zahrnout kolegy do analýzy. Ale o tom třeba zase jindy.
Digitalizace není jen o softwaru, ale o lidech, procesech a komunikaci. A právě tam většina projektů padá.
Pokud si nevíte rady, nebo nemáte dostatečné množství kapacit, ozvěte se nám.
