V první části seriálu jsme se zabývali tím, jak se můžeme dostat do nezdravé závislosti na našem dodavateli a hlavně tím, jaké problémy to může přinést naší společnosti.

Dnes se podíváme na to, co můžeme udělat pro to, abychom se takové závislosti vyhnuli.

1. Zachovejte si vlastnictví know-how procesů a systémů a plánů jejich rozvoje

Pokud se rozhodnete, že se o IT nechcete starat a dáváte obecné zadání svému IT dodavateli, jste na nejlepší cestě k závislosti. Co vás možná překvapí, tento přístup často způsobuje vrásky i samotnému dodavateli, protože požadavky klienta se začnou po nějaké době křížit a zaplétat a splnění nových požadavků začne být pro dodavatele zásadním problémem.

Pro firmu, která si chce udržet svoji konkurenceschopnost, je důležité, aby IT vnímala jako nástroj na podporu svých procesů, jejich zlepšování a měření. Jak na to není třeba složitě hledat, protože dnes máme dostatek metodologií a standardů, které nám umožňují si udržet přehled v procesech i provádět efektivní plánování:

  • Podniková architektura (Enterprise Architecture) – je způsob popisu cílů organizace, cest, jak jsou tyto cíle dosahovány pomocí podnikových procesů a jak mohou tyto procesy být podpořeny technologiemi. Bližší informace o ní můžete získat např. v článku „Neuvařte se“ špatnou architekturou podniku. Dva nejznámější přístupy k řešení podnikové architektury naleznete na stánkách The Open Group, a Zachmann.
  • Popisování procesů – nejznámější a nejužívanější standardy jsou vytvářeny sdružením Open Management Group (www.omg.org). Popis procesů dle specifikace BPMN (Business Process Model and Notation) umožňuje vedení společnosti jednoduše číst a zapisovat procesy, které probíhají v jejich společnosti.
  • Uživatelská dokumentace – to nemusí být dokument, který napíše dodavatel a dá se do šuplíku, kde na něj padá prach. Dobrou cestou je natáčení videí, která ukazují uživatelům, jak aplikaci využívat v každodenní práci a zjednoduší tak podporu produktu i zaškolení nových uživatelů. Videa jsou často jen v řádu minut a popíší vše, co je třeba k efektivnímu využití systému. Podívejte se například na návod pro využití Yammeru ve výzkumném projektu, nebo na návod, jak objednat zboží na eshopu.

U všech standardů a metodik existuje obsáhlá dokumentace a studijní materiály, které detailně popisují každou oblast. Dle mojí zkušenosti se vyplatí najmout si specialistu, který z metodik vybere ty části, které jsou vhodné pro konkrétní společnost.

Pokud svoje know-how zpracováváte standardizovanou formou, máte pak k dispozici nejenom nástroj pro diskusi nad tématy vedoucími ke zlepšování firmy, ale navíc získáte jistotu, že najdete společnou řeč s drtivou většinou svých současných i potenciálních dodavatelů.

Pokud budete chtít něco měnit v procesech a toku informací, nejdříve začněte s tím, že uděláte změny v organizaci práce, ať už na úrovni modelu nebo pilotním experimentem – vyzkoušíte si, jestli změna bude mít přínos, jaký očekáváte. Následně udělejte kalkulaci přínosu dané změny a nákladů na její zavedení. Pokud bude všechno jak má být, začněte s úpravou systémů a pokud ne, můžete akci bez problémů zastavit. Když toto svěříte kompletně externímu dodavateli, pak má málokdo odvahu zastavit projekt, do kterého jsme již investovali prostředky.

2. Data musejí být za každých okolností vaše

Data jsou uložena u našeho dodavatele, teď jsme se s ním pohádali a on nám řekl, že jsou data jeho… Tato situace bohužel není tak výjimečná, jak byste si mysleli. Nestává se to často u dodavatelů cloudových služeb a hostingu, jak se lidé často domnívají, ale nejčastěji u systémů vyvinutých na zakázku, kde jsou data uložena uvnitř černé skříňky plně pod kontrolou dodavatele.

Jedná se o tradiční cestu, jak udržet zákazníka pod kontrolou dodavatele. Problém lze obecně řešit dvěma cestami – přímou kontrolou dat nebo zajištěním spolehlivého způsobu jejich získání v použitelném formátu.

Například služba pro správu e-mailových kontaktů, které získáváme prostřednictvím registrace na webu našeho dodavatele. Prvním přístupem musíme zajistit replikaci dat do našich vlastních systémů a druhým jsou informace, které jsou uloženy v systémech dodavatele, pravidelně stahovány a ukládány u nás pro „strýčka Příhodu“.

Dokonce i v našem vlastním systému, kde je ukládání dat dobře zdokumentováno, může metodika exportu dat do standardní tabulky, databáze či XML výrazně ulehčit integraci nového systému. Je důležité stanovit postupy extrakce dat, ověření, že je export funkční a formát je dobře zdokumentován, protože v kritickou chvíli, kdy potřebujeme data získat, je přesně ten nejhorší okamžik, kdy zjistíme, že je export nefunkční nebo že dokonale exportované údaje jsou zakódovány ve formátu, se kterým neumíme pracovat.

Výše zmíněné požadavky by měly být ověřeny při převzetí jakékoliv nové funkcionality či změny v systémech od dodavatele.

3. Zachovejte si duševní vlastnictví k aplikacím

Vlastnictví aplikací spočívá ve vlastnictví zdrojového kódu nebo designu aplikace. Pokud nemáme zdrojový kód pod kontrolou, hrozí nám riziko, že v okamžiku, kdy budeme chtít změnit dodavatele, zjistíme, že stávající dodavatel vlastní kritickou část kódu a nebude ji ochoten bezplatně poskytnout. Tomu se můžeme vyhnout jasnou definicí o vlastnictví ve smlouvě, kde bude definováno, že kód vyvinutý v důsledku požadovaných změn je výlučně v našem vlastnictví, případně, že jsou tyto změny vytvořeny pod licencí, která nám umožní jejich další použití a rozšiřování zdarma.

I když máme vlastnictví zajištěno smluvně, neznamená to, že  dodavatel, se kterým se chystáme ukončit smlouvu, nám zajistí přístup ke kódu. Z tohoto důvodu je nanejvýš vhodné, aby správa kódu (source control system), wiki a další dokumenty byly ukládány u třetí strany a partner je zavázán k ukládání dat v daném místě a v určitém čase, abychom měli přístup k aktuálním verzím.

4. Integrace systémů spíše než rozšiřování funkcionality

API webových služeb (Application Programming Interfaces) jsou nyní běžnou funkcí v mnoha komerčních i open source aplikacích. To znamená, že všechny funkce nebo funkce, které jsou k dispozici uživatelům aplikace, jsou také k dispozici pro použití mezi různými systémy a aplikacemi.

Používáním protokolů a standardů k definování tohoto rozhraní jsou tyto služby jednotným komunikačním prostředkem a platformou; aplikace napsaná v jednom jazyce nebo v jednom operačním systému je přístupná systémy napsanými úplně jinak. Data jsou přenášena ve společném formátu, jako je XML nebo JSON, a základy kódů obou systémů zůstávají zcela nezávislé.

V dnešní době si dokáže představu o integraci systémů udělat již každý uživatel. Vždyť každý z nás používá služby webových aplikací, které jsou vzájemně integrovány – např. Google kalendář s Google kontakty a Gmail. Pokud se rozhodneme, že začneme místo stávajícího kalendáře používat jiný, provedeme pouze jeho napojení ke stávajícím datům. Takový způsob změny systému není možný v případě, že máme svůj vlastní systém, který jsme původně koupili pouze pro účetnictví a postupně nechali dodavatele vyvinout modul CRM, servisní modul atd.

Stejná logika platí pro integraci se systémy poskytovanými jako služba dodavateli cloudových služeb (SaaS – Software as a Service). Použití webových služeb odděluje jednotlivé aplikace od sebe a díky tomu je celý systém flexibilnější a přehlednější. Naopak pevné vazby mezi různými moduly usnadňují dodavateli zvyšovat naši závislost na něm, zvyšují komplexnost kódu a flexibilita systému je shodná s nejméně flexibilní částí.

5. Snažte se minimalizovat úpravy standardního systému

Pokuste se implementovat požadovaný systém s minimem úprav od standardní implementace. Pro dodavatele většinou nejste prvním zákazníkem. Snažte se při implementaci maximálně využít zkušeností dodavatele, které získal u jiných klientů. Je velmi pravděpodobné, že vás překvapí, o kolik je možné některé procesy realizovat efektivněji nebo že určitá data jsme dříve opomíjeli a stanou se naší konkurenční výhodou.

Pokud budeme vyžadovat zásadní zásahy do funkcionality aplikace, může to do budoucna zásadně zkomplikovat možnosti přechodu na nové verze a jakýkoliv přechod bude náročný z hlediska vývoje i nasazení.

6. Využívejte více dodavatelů

Snažte se celý systém návrhu, vývoje, nasazení a provozu řídit a nenechávejte jej na dodavateli. Je dobré, pokud oddělíte např. business analytiky od vývojářů. Dobrým krokem je, že systém je testován testery, kteří jsou mimo vývojový tým. Práci udělají efektivněji a pravděpodobnost, že získáte bezchybný produkt, je pak mnohem větší. Pokud bude jiná strana zajišťovat provoz (např. dodavatel cloudových služeb, buďte si jisti, že bude tlačit vývojáře do dodání produktu, který bude minimalizovat problémy s provozem systému.

7. Ve smlouvě specifikujte proces jejího ukončení, včetně sankcí pro dodavatele

Jak máte ve smlouvě specifikováno ukončení spolupráce? Výpověď s tříměsíční lhůtou, po které vy přestáváte platit a dodavatel podporovat? To je žalostně málo.

Je třeba specifikovat, jaké podklady a v jaké kvalitě musí dodavatel v průběhu výpovědi dodat vám, případně rovnou novému dodavateli. Pokud máte zajištěno duševní vlastnictví k návrhu, zdrojovému kódu a dalším částem dokumentace, o kterých píšu v bodě 3, tím lépe. Je dobré již v okamžiku uzavírání smlouvy s dodavatelem ověřit si u firem, které skončily na 2. a 3. místě, co budou potřebovat v případě, že by měly převzít vývoj a údržbu od vítěze.

8. Seznamte dodavatele se záměry rozvoje v budoucnu

Pracujte na dlouhodobém partnerství se svými dodavateli. Pokud s nimi budete pravidelně diskutovat svoje plány rozvoje a strategické otázky a ne jenom aktuální změny funkcionality, může dodavatel přicházet s návrhy, které vytvoří architekturu systému tak, aby byla stabilní, efektivní a nákladově přiměřená nejenom k vašim současným požadavkům, ale i požadavkům budoucím. Pro zpřehlednění požadavků můžete využít např. Metodu MuSCoW, která požadavky rozdělí do následujících kategorií:

  • Must have – musí mít
  • Should Have – mělo by mít
  • Could Have – potěšilo by, kdyby mělo
  • Won’t Have This Time – zatím mít nemusí

9. Získávejte myšlenky a názory dalších stran

Neustrňte na jednom místě, sledujte trendy, hledejte nejlepší přístupy a praktiky a na všechno se dívejte. Najměte si společnost, abyste získali třetí názor – ta zhodnotí vaše rozhodnutí po stránce technické i strategické. Nemusí to vůbec být drahá záležitost. A taková konzultace se vyplatí, protože vám pomůže vyvarovat se chyb. Ze své praxe znám případ, kdy dodavatel nutil zákazníka investovat částku několika milionů korun do řešení problému, které sám způsobil a konzultant zjistil, že by daná investice vůbec řešení nepřinesla, protože problém byl úplně jinde.

Konzultant vám může pomoci definovat strategii, vytvořit poptávku, zhodnotit možnosti a podívat se na věci z úhlu, který nečekáte. Také vám může pomoci udělat audit dodavatelů a zajistit pro vás nejlepší možný výsledek. Konzultant by měl mít stále na zřeteli, že chcete být nezávislí na konkrétním dodavateli a že si uvědomujete cenu svého know-how jako konkurenční výhody.

Správný výběr dodavatelů spočívá v řízení rizik

Věřím, že po přečtení tohoto článku je vám jasnější, jak udělat ze svých dodavatelů partnery vašeho úspěchu a nestat se jejich vazalem. Předcházení nepříjemným situacím spočívá v důsledném řízení rizik a volbě takových řešení, která jsou v rovnováze mezi současnými požadavky a budoucí flexibilitou. Dodržováním výše zmíněných principů zajistíte správnou volbu dodavatelů i nových systémů.