Efektivní spolupráce mezi IT dodavateli bývá vzácností
Tlak na cenu a konkurenční tření brání efektivní modernizaci
Řada společností se v současnosti potýká s problémem, kdy se celý jejich IT systém skládá z aplikací a programů, které jim dodávají různé firmy. Některé ke strategii vyššího počtu dodavatelů přistupují dobrovolně s heslem více dodavatelů snižuje riziko závislosti. Jiné vnímají své robustní systémy jako přirozený výsledek technologického vývoje, kdy jednotlivé části jejich architektury postupně zastaraly a nová doba si žádala modernější řešení, která se postupně nabalovala na jejich jádrové systémy. Tlak na čas a finance střídal argument, že když budou mít dodavatelé větší konkurenci, budou se sami více snažit poskytnout firmě co nejlepší řešení. Jenže co když vyvstane potřeba modernizace, která vyžaduje souhru všech částí systému?
Velké společnosti s robustními IT systémy lze těžko vinit z toho, že jejich technologie a části softwarové infrastruktury pocházejí od různých dodavatelů. Nichové specializace, bezkonkurenční cenové nabídky, dlouhodobé dobré zkušenosti či obava z vendor lockingu jsou validní argumenty, proč nenechat vývoj celého kolosu na jediné firmě. Navíc hrají roli i kapacity dodavatelských firem, protože zákazník v dnešní uspěchané době vyžaduje okamžité dodání služeb a jejich neustálé vylepšování.
Z pohledu zadavatelské firmy je diverzifikace vývoje systémů logickým krokem, který má snížit šanci na to, že někde dojde k zásadní chybě, která by mohla ochromit její byznys. To vše však dává smysl jen do chvíle, kdy celý ekosystém potřebujete modernizovat nebo zásadně modifikovat a zjistíte, že se bez komplexních a finančně velmi nákladných změn neobejdete.
„Lépe to udělat nešlo“
Představte si například situaci, kdy softwarové řešení jedné firmy zahrnuje návrh UX/UI strategie pro web a mobilní aplikaci, webový frontend, webovou administraci (CMS), backendové řešení a optimalizaci celkové IT infrastruktury. V takovém případě firmy často začínají u výběrového řízení, jehož hlavním kritériem je přirozeně cena. Nedívají se přitom na to, zda expertiza IT dodavatele zahrnuje více odborných kvalifikací. Když pak v tendru vyhraje firma, která tvoří primárně web, neznamená to, že tatáž společnost dokáže vyvíjet stejně kvalitní mobilní aplikace.
Obvykle se jako první tendruje část designu. Ten však může vyhrát, a nakonec řešení dodat firma, která má sice zkušenosti s designem a webovým řešením, už však ne s návrhy mobilních aplikací. A proto třeba nedomyslela, že mobilní aplikace jsou o hodně náročnější co do stavů aplikace (protože často funguje offline, což se u webu v podstatě neděje), nebo že má na každé platformě trochu jiné patterny. Správně by se v tendrech měly najímat firmy, které ovládají nejvíce řešení a expertiz najednou. Takové, které dokážou nad designem i vývojem myslet nejen programátorsky, ale i byznysově, strategicky, technologicky a z pohledu finanční návratnosti. Jenže v našem případě hrála roli nízká cena.
Tím ale řetězení problémů teprve začíná. Výherce tendru dokončil design i konkrétní technickou specifikaci. Protože však má někde mezery, poptá si dalšího dodavatele – a tomu už ony podklady nemusí vyhovovat a vidí v nich slabiny s dopadem na vývoj mobilní aplikace. Kvůli investovaným financím už se však firmě nechce nic předělávat a s pocitem nedostatečné flexibility nebo přehnané kritičnosti druhého dodavatele se pokračuje s předurčeným designem. Další studia tak sice vytvoří kusy webového frontendu, webového CMS nebo mobilní aplikace, kompromisním řešením jsou však limitovaná. A pokud v dané oblasti nejsou experti, dochází k dalšímu tříštění tím, že si na vývoj aplikací najímají další společnost. Do toho firma-zadavatel najde externího dodavatele backendového řešení a věří, že když vytvoří specifikaci API, vše se jen propojí a bude fungovat, jak má…
Cena za snahu ušetřit
Ve chvíli, kdy systém skládáte z částí od různých dodavatelů, zásadně zvyšujete riziko vzniku chyb, které pak může být složitější nejen odhalit, ale také opravit, aniž mají kaskádový efekt na další části systému. Uhlídat komplexní vývoj softwaru je výzva v rámci zkušené firmy, natož řídit komunikaci mezi jednotlivými dodavateli. Pokud je však cílem projektu modernizace IT systémů a tvorba inovativních webových i mobilních aplikací je vedena koncepčně, zvolte raději jediného dodavatele. Proč? Jestliže takový projekt sleduje jednu byznysovou linku a stojí na podstatě toho, že web, CMS, aplikace a backend mají komunikovat stejná data, diverzifikace rizik zde nedává smysl. Cílem je totiž konsolidace jednotlivých částí systémů tak, aby dohromady vedly k žádoucímu výsledku.
Větší množství IT dodavatelů v takovém případě vede k riziku, že dodávka bude nekvalitní, neucelená, zdlouhavá a ve výsledku se třeba kvůli průtahům a nedostatkům prodraží. Pokud tvoříte jeden produkt, který sestává z několika webů, aplikací a dalších aplikací pro různé nástroje, vsaďte raději na jednoho dodavatele. Současný trh nabízí desítky firem, které dokážou dodat celkové řešení a které firmám ušetří bolehlav s komunikací. Například největší online knihovna divadelních záznamů Dramox zvolila pro svůj core byznys externí vývoj a ušetřila tím 40 % výdajů na IT infrastrukturu.
Jak tedy na to?
Pokud tedy nad zadáním vývoje přemýšlíte, odpovězte si na otázku, zdali vytváříte několik různých koherentních, avšak oddělených celků, či různé produkty nebo aplikace, které však spoluvytvářejí jeden produkt. Ve snaze přijít s novým skvělým řešením totiž mají zadavatelé (ale i dodavatelé) občas tendenci znovu vymýšlet kolo. Například při vývoji online pojišťovací platformy Srovnátor bylo potřeba vyřešit, kam uložit velké množství údajů o reálných i potenciálních klientech kvůli možnosti retargetace. Jako nejjednodušší řešení se nakonec ukázalo kvalitní CRM, v tomto případě Salesforce. Stejně tak nebylo pro fanouškovskou aplikaci klubu AC Sparta Praha třeba vyvíjet od píky rezervační systém lístků na zápasy, ale stačilo integrovat již jimi využívané Enigoo.
Výjimkou by mohla být situace, kdy klient potřebuje B2C prostředí pro své zákazníky a B2B/B2E pro dealery či importéry. Zde by hypoteticky šlo jednotlivé vývoje rozdělit mezi dvě firmy. V případě prodejce vodních skútrů Jetsurf byl potřeba systém zahrnující B2C mobilní aplikaci, backend, infrastrukturu B2B portálů pro dealery, plánování výroby, propojení skladových zásob, tracking reklamací a podobně. Nakonec však díky jednotnému backendu probíhal vývoj na jednom místě, což se díky komplexitě projektu ukázalo jako výhoda. Jeden funkční ekosystém v podobě více aplikací se stejným účelem a kontextem bude vždy rychlejší, efektivnější a dříve hotový, takže na sebe může tím spíš začít vydělávat a přinášet důležitá data o zákaznickém chování. Není totiž nic horšího než strávit půl roku vývojem „dokonalého“ řešení, které se v praxi ukáže jako katastrofa, a utratit za něj balík peněz.
Diverzifikace dodavatelů může ve výsledku firmu stát hodně peněz a v nejhorším případě se může jednat o prodělečnou investici. Existuje mnoho případů, kdy ve spolupráci s více IT dodavateli vznikly produkty, které ani nespatřily světlo světa a musely se vytvářet znova, od nuly. Chce to jistě odvahu outsourcovat digitální byznys prostřednictvím jediné firmy, výsledek ale může být daleko uspokojivější.
 |
Daniel Jay Lett Autor je spoluzakladatelem a CEO vývojářského studia elevup. |
