Tým Enehana ve Flowmonu nastavoval Salesforce nástroje, a tak Kemp využil dřívějších zkušeností a i pro dodání návrhu integrace s Flowmonem oslovil opět náš tým.  Se společností Kemp jsme dříve nespolupracovali, ale nakonec byla pro klienta rozhodujícím faktorem pozitivní zpětná vazba z předchozích zakázek a cena.

Projekt byl rozdělen do 4 fází:

1. Analýza

Cílem integrace bylo zachovat procesy v Kempu z větší části beze změny a transformovat aktivity Flowmonu bez negativních dopadů. Projekt začal analýzou, protože jsme potřebovali důkladně pochopit obchodní proces a implementaci Salesforce na obou stranách. Protože prvotní zjištění přineslo více otázek než odpovědí, rozhodli jsme se pokračovat komplexnější analýzou a vytvořit dokument s plánem, který by později sloužil jako rámec pro implementaci.

2. Návrh řešení

Projekt byl původně navržen jako Fixed-time-fixed-price, ale klient se později rozhodl převzít odpovědnost za rizika a projekt realizovat jako Time & Material. Tento režim poskytl klientovi o něco větší volnost, pokud jde o rozsah projektu, a celkovou flexibilitu.

3. Realizace

Během implementace jsme velmi úzce spolupracovali, abychom dosáhli cílů projektu spočívajících v úspoře zdrojů a včasném dodání. Při dosahování cílů se obě strany dohodly, že část administrativních prací na platformě dodá interní tým společnosti Kemp. Celková implementace byla rozdělena do 2 hlavních proudů: aktualizace v Salesforce a migrace dat. Migrace dat byla časově největší částí projektu. Pro ni jsme zvolili export všech dat Flowmonu do databáze, kde jsme spustili všechny transformační procesy a později je nahráli do Salesforce společnosti Kemp.

4. Hyper care

Po úspěšném nasazení všech změn a migraci všech dat jsme ve spolupráci s týmem klienta připravili školení a instruovali uživatele, aby používali pouze Salesforce Kempu. Náš tým zůstal ve střehu a sledoval veškeré opravy dat nebo chyby, které uživatelé nahlásili, aby umožnil co nejlepší uživatelskou zkušenost. Po dvou týdnech jsme projekt úspěšně dokončili.

Hlavní výzvy

Prodloužená počáteční analýza

Problém: Původní očekávání klienta bylo, že po krátkém zjišťování budeme schopni poskytnout návrh na implementaci FTFP. Vzhledem k vysoké složitosti procesů na obou stranách a vysokým sázkám jsme však tento požadavek nebyli schopni splnit. Zároveň jsme vzhledem k odchodu jednoho z našich kolegů byli nuceni udělat změny v týmu.

Řešení: Dohodli jsme se na pokračování analýzy a přípravě dokumentu s návrhem architektury, který by pokryl celý rozsah požadavků na migraci/integraci a pomohl by nám pochopit kroky potřebné k zahájení fáze implementace. Vybrali jsme také velmi zkušeného business architekta, který zanalyzoval procesy a nastavení Salesforce na obou stranách a vedl workshopy. Díky přípravě dokumentu “blueprint” (studie porveditelnosti) jsme byli schopni identifikovat klíčové změny, které bylo třeba implementovat, aby se uživatelé Flowmonu v organizaci Kemp přizpůsobili. Kromě toho jsme byli schopni analyzovat data, která bylo třeba převést, a take dát pokyny k vyčištění dat a připravit strategii deduplikace.  

‍

‍

Diskuse o Time & Material vs. FTFP

Problém: Spolu s plánem jsme klientovi dodali také návrh na implementační fázi projektu FTFP. V tuto chvíli jsme překročili hrubé počáteční odhady i očekávání klienta. Bylo to způsobeno především tím, že v projektech migrace dat, zejména v živém prostředí, existují rizika, která je třeba zohlednit v nabídkách s pevnou cenou. Klient však nebyl spokojen s konečnou navrženou cenou a zpochybnil náš rozpočet na nepředvídaná rizika.

Řešení: Společně s klientem jsme analyzovali potenciální rizika a jejich pravděpodobnost, spolu se snížením rozsahu některých položek a přidáním některých interních zdrojů klienta do projektového týmu, abychom snížili náklady. I přes naši snahu klient stále nebyl spokojen s cenou, proto jsme se rozhodli navrhnout přístup Time & Material. V případě T&M jsou všechna rizika přenesena na klienta, stejně jako odpovědnost za časový harmonogram a rozsah projektu. Navrhli jsme poskytnutí požadovaných zdrojů a řízení projektu, zatímco klient by musel jmenovat svého projektového manažera, který by včas vyřídil požadavky na načasování a zdroje, jakož i řízení rizik a nepředvídaných událostí. Klient s tímto návrhem souhlasil a stanovili jsme rámec spolupráce T&M.

Migrace dat v živém prostředí

Tento projekt byl pro nás trochu neobvyklý, protože vyžadoval rozsáhlou migraci dat v živém prostředí. Potřebovali jsme sloučit databáze Kempu a Flowmonu do jedné a zároveň co nejméně ovlivnit pracovní postupy uživatelů Kempu. Celková migrace se musela vypořádat s několika níže uvedenými problémy.

Deduplikace záznamů: Obě společnosti měly mírně odlišné produkty, ale ve svých systémech mohly mít stejné účty.  

Řešení: Provedli jsme předběžnou analýzu množství potenciálních duplicit, prošli jsme s klienty několik příkladů a připravili soubor pravidel pro deduplikaci záznamů. Zároveň jsme se dohodli, že upřednostníme vytváření duplicit před náhodným vynecháním jedinečných záznamů. Celkově deduplikace proběhla nejprve na testovacích datech, poté byla vyhodnocena a upravena na základě zpětné vazby a spuštěna na aktuálních datech.

Automatizace a integrace v systému Kemp: Vzhledem k tomu, že jsme migrovali do již fungujícího systému, který nebyl připraven na vkládání dat takového rozsahu, existovalo velké riziko, že se při vkládání dat spustí nějaká automatizace.  

Řešení: Důkladně jsme analyzovali veškerou automatizaci přítomnou v prostředí Kemp včetně všech process builderů, flows, workflow pravidel, apex triggers, validací a povinných informací. Na základě této analýzy jsme vytvořili zprávu o veškeré automatizaci, kterou jsme s klientem zkontrolovali a identifikovali všechny procesy, které bylo třeba pro načítání dat vypnout.  Později během načítání náš tým tuto automatizaci zapínal a vypínal, aby nedocházelo ke zbytečnému přerušení práce běžných uživatelů v cílové organizaci.

Migrace do organizací působících v různých časových pásmech: Protože bylo zřejmé, že v době načítání je třeba některé funkce vypnout, museli jsme čas načítání zvolit s rozmyslem. Kemp jako globální společnost má lidi, kteří pracují v podstatě nepřetržitě, takže neexistoval čas, kdy bychom nikomu nezasahovali do práce.  

Řešení: Po několika diskusích jsme se rozhodli, že zátěž musí běžet mimo evropskou a americkou pracovní dobu. Mohli jsme tedy proces migrace zahájit přibližně kolem 22. hodiny pražského času. Proces migrace začal vypnutím části automatizace a teprve poté se spustilo načítání do org. Migrace probíhala několik nocí, přičemž každá noc končila opětovným zapnutím automatizace kolem šesté hodiny ranní, aby byla umožněna bezproblémová práce uživatelů Kempu. Celkový proces byl únavný, ale naštěstí jsme se nesetkali s žádnými velkými problémy a podařilo se nám vše dokončit včas s co nejmenším dopadem na uživatele.  

‍