Aplikace a podnikové systémy jsou v každodenním provozu firmy naprosto klíčové a každý výpadek se může během chvilky proměnit ve velmi nákladný problém. Technická podpora dodavatele softwaru či cloudové služby je zde od toho, aby tyto problémy pomohla rychle a efektivně řešit.
Zkusil jste to vypnout a zapnout? Typický první dotaz všech operátorů helpdesků po celém světě se díky seriálům a skečům z IT prostředí stal doslova kultovním. V každodenním provozu helpdesku ale není na legraci prostor a právě tato otázka neznamená, že vás chce operátor technické podpory odbýt, ale nevyhnutelně patří do celé série dotazů, prostřednictvím kterých se snaží diagnostikovat váš problém s používanou aplikací. Postupy operátorů helpdesku mají svá přesná pravidla, nastavená s cílem co nejrychleji vyřešit zákazníkův problém.
Standardní model fungování helpdesku je velmi prostý. Pracovník helpdesku přijme od klienta hlášení incidentu (telefonicky, e-mailem nebo třeba prostřednictvím speciální aplikace helpdesku), provede jeho analýzu a dále postupuje dle interní metodiky. Má-li tento pracovník na první úrovni podpory možnosti a znalosti k vyřešení nahlášeného incidentu, rovnou jej vyřeší. V opačném případě eskaluje incident k IT podpoře (pokud jde o problém s infrastrukturou), nebo jej nahlásí vývojovému týmu, odpovědnému za opravy chyb v aplikacích. Poté, co je problém odhalen a vyřešen, vrací se incident zpět k operátorovi helpdesku, který provede kontrolu a nahlásí vyřešení klientovi.
V tomto čistě reaktivním modelu technické podpory se po operátorech helpdesku nevyžadují nijak hluboké znalosti projektů a řešení dodaných klientům, ani byznys procesů na straně klienta. S rychle se měnící situací na trhu a značnou akcelerací vývoje podnikových aplikací a služeb se ale takový způsob technické podpory ukazuje jako nedostatečný, protože nijak nereflektuje prakticky nepřetržitý vývoj aplikací a služeb, jejichž úkolem je poskytovat jejich uživatelům konkurenční výhodu.
Vývoj podnikových aplikací a jejich podpory dnes musí reagovat nejen na změny na trhu, ale také na změny legislativní, oborové i technologické. I proto se zvyšují nároky na kvalitu a flexibilitu vývoje a z toho důvodu mnoho firem přechází na model Continuous integration / Continuous development. Tento model spolupráce mezi klientem a dodavatelem aplikací a služeb poskytuje větší prostor pro efektivní využívání potenciálu IT při podnikání. Předpokládá se v něm postupný rozvoj systému či aplikací agilní metodikou, tedy po menších, ale častěji uvolňovaných celcích, spíše než v rámci změnového řízení ve velkých dávkách aktualizací. Jelikož se aktualizace provádějí postupně, je možné u klienta nasazovat změny prakticky ihned po otestování kódu. Tyto aktualizace, nazývané též sprinty, se dodávají dle plánu dohodnutého s klientem. Vedle vývoje nových funkcionalit zahrnuje každý sprint i opravy a menší změny.
Po základní analýze požadavku a naprogramování požadované funkčnosti či změny se provede nasazení sprintu do testovacího prostředí, kde začíná práce pro testery. Ti ověří funkčnost změn i všech částí, které byly vytvořeny či upraveny. Po úspěšných testech dojde po schválení klientem k přenesení balíčku na produkční prostředí. Případné opravy či úpravy pak mohou být opět nasazeny v rámci následného sprintu, společně s nově naplánovanými funkčními požadavky – takže se celý koloběh neustále opakuje. Takto agilní proces vývoje sice vyžaduje intenzivnější vzájemnou komunikaci všech účastníků, ale zásadní výhodou je vyšší flexibilita změn a intenzivní zaměření aplikací na podporu podnikatelských cílů klienta.
Vývoj na bázi Continuous integration / Continuous development klade také mnohem vyšší nároky na sehranost celého projektového týmu. Každý klient má svého account managera, se kterým řeší záměry rozvoje svých aplikací. Dalšími nezbytnými účastníky jsou konzultanti a projektoví manažeři. Konzultanti spolupracují s klientem na rozvoji systému, projektový manažeři jsou pak zodpovědní za realizaci změn a vylepšení.
Nedílnou součástí projektového týmu agilního vývoje metodikou sprint je ale také servis, tedy služba poskytující klientovi dostupnost technické či konzultační podpory. Změny v aplikacích probíhají poměrně rychle, a proto je důležité, aby mohl klient, podle priority požadavku nebo závažnosti incidentu, komunikovat s projektovým týmem, a nacházet odezvu pro ekonomický a/nebo rychlý způsob řešení. Garantem této komunikace je projektový manažer, který musí nejlépe znát frontu požadavků, technické souvislosti i aktuální stav rozpracovanosti aplikace. Právě projektový manažer je tedy klíčovým kontaktem, zprostředkovávajícím technickou či aplikační podporu. V rámci agilního vývoje podstatným způsobem roste význam technické a aplikační podpory, protože s rychlým tempem změn dochází také k většímu počtu dotazů ze strany uživatelů aplikací. Operátoři helpdesku musí rovněž úzce spolupracovat s projektovým týmem, aby byli schopni co nejrychleji reagovat a uzavírat pokud možno co největší podíl incidentů bez jejich eskalace na projektového manažera.
Intenzivní spolupráce mezi klientem a projektovým týmem, včetně pracovníků technické podpory, je zárukou poznávání skutečných potřeb klienta a efektivního rozvoje jeho aplikací a systémů s cílem zvýšení jeho efektivity a konkurenceschopnost v podnikání, stejně jako snížení nákladů a rizik i zkrácení času pro nasazení potřebných funkcí.
Technická podpora Sprinxu je klientům k dispozici 24 hodin denně, 7 dní v týdnu a 365 dní v roce – v režimu určeném smlouvou a příslušným SLA. Smluvní dokumenty stanovují, kdy je konkrétnímu klientovi helpdesk k dispozici, kdo se jménem klienta může na podporu obracet a jaké jsou závazné termíny pro reakci a nápravu problému. Operátoři helpdesku jsou zde pro vás, ale dříve, než se na ně obrátíte, ať už telefonicky nebo e-mailem, ujistěte se, že:
Pro operátory helpdesku je velmi důležitý přesný popis problematického chování aplikace. S odhalením problému velmi pomůže například snímek obrazovky s chybovým hlášením nebo videozáznam postupu vedoucího k chybě. Použijte svůj mobil a přiložte fotky či videozáznamy k e-mailu na helpdesk.
Příčin incidentů hlášených klienty helpdesku může být celá řada. Analýza problému může odhalit, že jde chybu aplikace, kterou je nutné odstranit, opravu otestovat a následně nasadit do produkčního prostředí. Tento způsob nápravy problému vyžaduje především práci vývojáře, ale celkově je do řešení problému zapojeno hned několik členů našeho týmu:
Odhalení a řešení chyb u aplikací s uzavřeným vývojem není snadné, jelikož vývojář často opravuje cizí práci, nezřídka bez podrobné dokumentace a dokonalé znalosti všech souvislostí. O to důležitější je kompletní otestování opravy.
Práce na podpoře aplikací není pro vývojáře příliš atraktivní, protože se chtějí věnovat především vývoji nových vlastností a funkcí našich řešení. Ve Sprinxu proto nemáme vývojáře dedikované pouze na podporu aplikací, ale nastavili jsme systém, v rámci kterého zahrnujeme odhadovaný čas věnovaný podpoře do plánování našich vývojových kapacit a rozdělujeme jej mezi všechny vývojáře.
Divize Sprinx Pharma poskytuje obchodním reprezentantům farmaceutických společností online CRM systém, do kterého jsou zadávány objednávky lékáren a nemocnic. Obchodníci v terénu potřebují plně funkční systém s kontakty, prodejními daty a rychlou odezvou, na který se při své práci mohou spolehnout. Sprinx Pharma proto zajišťuje technickou podporou v režimu 24×7, dostupnou po telefonu a e-mailu:
Helpdesk pro zákazníky divize Sprinx Pharma podporuje při každodenní práci přibližně 1 500 uživatelů z více než 80 farmaceutických firem. Díky intuitivnímu prostředí a ovládání našich aplikací i rychlé reakci technické podpory, mohou tito uživatelé pracovat efektivně.
V některých případech vedou opakované supportní zásahy i ke vzniku nové funkčnosti. Například zpracování čistých prodejů (očištění hrubého obratu o různé formy slev a bonusů) výrobců léčiv byla tradičně činnost vyžadující na straně zákazníka i u nás velké množství opakované ruční práce. Lidský faktor s sebou vždy nese i vznik chyb, a následně potřebu zákaznické podpory. Snaha eliminovat tuto ruční práci i potřebný support v tomto případě vedla ke vzniku modulu e-Finance. Díky němu poklesl objem supportní práce, související se správou čistých prodejů, o 95 %. Na straně zákazníka jde typicky o úsporu desítek až stovek hodin práce ročně.
Vzdálené řešení problémů není vždy možné a někdy musíme vyrazit i do terénu. S klientem, který pro svůj tým pořídil nové ale ne příliš běžné tablety, které jsme neměli v naší správě, jsme řešili nespolehlivou funkčnost CRM při práci v terénu. Všechny vzdálené testy a kontroly proběhly, ale problémy se opakovaly. Proto jsme vyslali zástupce supportního oddělení do terénu, kde s jedním z obchodních zástupců strávil část pracovního dne. Díky tomu se přímo na místě podařilo zjistit, že se při ztrátě spojení tablet chová nestandardně. Přímo na místě jsme našli takové nastavení tabletu, které problémem vyřešilo. Během odpoledne proběhlo asistované přenastavení u ostatních uživatelů – tentokrát už vzdáleně podle časových preferencí jednotlivých uživatelů.
Bezpečnostní incidenty, které se často mohou na první pohled jevit jako běžný problém s dostupností aplikace nebo chyba systému, jsou našimi klienty hlášeny na helpdesk. Samozřejmě je nemohou vyřešit přímo naši operátoři technické podpory, ale jsou eskalovány na tým našich bezpečnostních specialistů.
Tak, jak se postupně přenáší provoz podnikových aplikací a systémů ze serverů ve vlastním datovém centru do cloudu, musí se nutně změnit i přístup k zabezpečení před útoky zvenčí i zevnitř sítě.
Cloudové služby typu Microsoft Azure jsou na kybernetické útoky dobře připravené, ale zároveň vyžadují odlišný přístup ke nastavení a monitoringu jejich zabezpečení. Na rozdíl od aplikací provozovaných na fyzických serverech nelze v cloudu jednoduše monitorovat abnormální zvýšení zátěže procesorů nebo čerpání kapacity operační pamětí, jako průvodní znaky probíhajícího kybernetického útoku. V cloudové infrastruktuře běží v každém okamžiku celá řada funkcí a služeb, u kterých je nutné dohledávat anomálie, například v podobě zhoršení odezvy nebo nedostupnosti.
V rámci podpory našich aplikací běžících v cloudu proto pracujeme na monitoringu jednotlivých funkcí cloudové infrastruktury, abychom byli schopni případné problémy, které mohou indikovat probíhající kybernetický útok, včas detekovat a reagovat na ně dříve, než způsobí našemu klientovi problémy.