Pro větší firmy to platí už dávno: Speciální programové vybavení si nepořizují po krabicích, ale vyžadují pro sebe řešení vyvíjená na zakázku přesně podle svých požadavků. Zdá se, že stejný postup stále častěji volí už také krajské a magistrátní úřady i radnice dalších měst.
Jak je to však se servisem zakázkových aplikací, ve kterých IT oddělení města nemůže být tak zběhlé jako v případě aplikací majoritních softwarových společností a s nimiž chod magistrátu doslova stojí a padá? Pojem "servis" je velmi široký a představy o tom, co se v IT společnosti, která se zabývá vývojem rozsáhlých zákaznických řešení a aplikací, pod tímto slovem chápe, bývají značně rozdílné.
Začněme otázkou, která se obvykle interně hodně diskutuje, ale odpovědi na ni navenek zůstávají pokud možno zamlženy: Má se oddělit servis od vývoje? Má se projekt po dokončení předat "novým" lidem?
NASTAVTE VYROVNANÝ VZTAH
S nárůstem vývojářské společnosti a s počtem projektů předaných do režimu servisu potřeba oddělit servis od vývoje, tj. vytvořit samostatnou skupinu lidí, kteří nevyvíjejí nové aplikace, ale primárně se starají o zákazníky, nepochybně vzniká. Servis přijímá požadavky zákazníků, pracovníci servisu jsou schopni poskytnout rady jak ohledně již nasazené funkcionality, tak vzhledem k možnostem rozvoje řešení.
Je však model "nových" lidí na právě nasazeném projektu pro zákazníka přínosný a také příjemný? "Projektoví" lidé z obou stran spolu pracovali řadu měsíců se stejným cílem, mají společné vnímání problémů, znají historii projektu, navázali vztahy. A najednou od dodavatele přichází úplně jiná skupina lidí, která projekt přebírá od vývoje. Neplatí už nepsaná pravidla spolupráce? Nestane se péče o zákazníka neosobní? Ne-přestává to být "to", co bývalo?
Aby k podobným rozčarováním nedocházelo, je nutno předem dobře stanovit pravidla jak mezi zákazníkem a dodavatelem, tak uvnitř vývojářské firmy. Na kvalitní servisní smlouvu by se pokaždé mělo myslet už při přípravě smlouvy o dílo. Jsou-li přesně definována SLA (Service Level Agreement - dohoda o úrovni poskytovaných služeb, kterou známe například i z praxe mobilních operátorů), je-li exaktně nastaven měřitelný proces řešení požadavků zákazníka, bude vztah objednatele a dodavatele vyrovnaný. Pak město bude mít značnou šanci na bezproblémové zajištění servisu. Naopak vytvoří-li se na obou stranách příliš velký prostor pro různou interpretaci smlouvy, hrozí spory, které neprospějí žádné z nich.
ZA RYCHLOU JÍZDU ZAPLATÍTE
Jak tedy postavit vyrovnaný a partnerský vztah mezi odběratelem a dodavatelem? Především je nutné zvážit, co přesně od servisu své aplikace reálně očekáváme, jaké eventuální škody nám může přinést nefunkčnost celého systému nebo jeho částí. Jak rychle potřebujeme mít všechny informace, které nám aplikace poskytuje.
Při nastavování parametrů služby nový zákazník často v prvním návrhu SLA vznáší náročné požadavky na reakční dobu poskytovatele. Reakce na závadu by měla být okamžitá - nejlépe do pěti minut, vyřešení požadavku do hodiny, pohotovost 24 hodin denně a sedm dní v týdnu.
Jenže všechno má svou cenu a tvrdě postavené podmínky budou velmi drahé a často je ani nebude možné reálně dodržet.
Zkušená firma se zavedeným systémem na podporu zákazníků určitě městu navrhne podmínky, které bude schopna plnit a jež by mu měly vyhovovat. Na radnici bude domluvit se na rozumné ceně za tuto službu. Nej-dražší položku servisu představuje výjezd k zákazníkovi. Zásahy tohoto typu lze minimalizovat vzdáleným připojením. Druhou nejdražší položkou bývá rychlost reakce. Servisní organizace totiž musí alokovat dostatečný počet odborníků tak, aby vyhověla všem zákazníkům v požadovaném čase. Budete-li tedy trvat na velmi rychlé reakci, počítejte s výrazně vyšší cenou, neboť tím si vlastně předplácíte pracovní dobu odborníka.
Obecně by ve smlouvě v rámci SLA neměly být opomenuty tyto faktory:
Infrastruktura - kdo za ni zodpovídá, konektivita obecně, technologie a možnosti její integrace.
Správa systémů - noví uživatelé, upgrade systémů, údržby logů apod.
Záruky chodu aplikací - proces řešení závad, nových požadavků, konzultací... (vše v kontextu s nastavením reakčních dob pro různé typy požadavků, dob odezev aplikací).
Zatímco třetí oblast bývá ve smlouvách obvykle poměrně dobře formulována, předchozí dvě se opomíjejí. Propojení všech tří oblastí však často z hlediska formulací SLA je i zcela vypuštěno. Jak se tedy zachovat, jestliže problém vzniká někde na rozhraní dvou systémů, na hardwaru, který udržuje další subjekt, a systém je propojen přes síť, která je ve správě objednatele?
O každé z výše uvedených položek lze široce diskutovat, stále je však třeba mít na paměti ono staré známe "cena/výkon". Proto je-li SLA smlouva zformulována tak, aby obě smluvní strany byly transparentně motivovány k jednoznačné spolupráci a staly se opravdu partnery se společným cílem, získá město největší šanci na bezproblémový chod svých klíčových aplikací.
VÝHODY GENERÁLNÍHO DODAVATELE
Pro zákazníka je asi nejvýhodnější, pokud má jednoho generálního dodavatele, který smluvně odpovídá za všechny prvky systému. Generální dodavatel, nebo chcete-li systémový integrátor, řeší vzniklé problémy s ostatními dodavateli. Zákazník má smluvní vztah pouze s jedním a nemusí se zabývat tím, kdo za co může a kde je vlastně chyba.
Tento model na druhou stranu bude méně pružný, neboť požadavek na zásah bude přebírat vždy generální dodavatel, který jej až pak přeposílá na příslušná místa a stará se i o zpětnou vazbu. Proto uvedený model bude zároveň i o něco dražší než při variantě servisních smluv s každým dodavatelem zvlášť.
Vráťme se však ještě k lidskému faktoru, který je v IT stejně neopomenutelný jako v jiných oborech lidské činnosti Záleží skutečně na tom, zda se naší aplikaci věnuje i nadále člověk, který ji pro nás vyvíjel? Jsou-li dopředu a jasně formulována pravidla, je předání aplikace do servisu "novým" lidem ideální. Tito lidé jsou tu totiž od toho, aby zákazníkovi pomáhali, nesdílejí svoji kapacitu s vývojovými projekty, mají zkušenosti z mnoha jiných podobných situací v provozu, mají na vás čas a jsou pro pomoc zákazníkovi jednoznačně motivováni.
MARTA SVOBODOVÁ
ecommerce.cz
