1. Úvod
Provozování softwaru jako služby není nic nového. I v oblasti ERP aplikací najdeme na českém trhu celou řadu příkladů, kdy se informační software dodává zákazníkovi jako řešení ASP (Application Service Providing). Většinou se však jedná o provoz desktopové aplikace na výkonném serveru a její zpřístupnění zákazníkovi prostřednictvím termináových služeb, jde tedy se vlastně jen o určitý outsourcing některých IT služeb. Ať už tomu budeme říkat jakkoliv, tato forma je velmi náročná na hardware, ceny licencí doprovodného softwaru a v neposlední řadě i na údržbu a technickou podporu. V některých konkrétních příkladech může takto provozovaná služba zajít až do neuvěřitelných extrémů: např. německá společnost DATEV spravuje ve svých výpočetních centrech v Norimberku přes 15 000 serverů, které pronajímá svým zákazníkům. Uživatel v tomto případě dostává za cenu kolem 1 000 Euro měsíčně prostor na dvou serverech - jednom aplikačním a jednom terminálovém.
Před několika lety se zrodil termín SaaS (Software as a Service), reprezentující technologie, které mají právě podobným extrémům zabránit. Výsledkem je software, který je architektonicky navržený tak, aby spojil výhody provozu jako služby a současného sdílení výpočetních kapacit. V praxi se však ukazuje, že to nestačí. Zákazník mnohdy od svého dodavatele požaduje i služby, které přímo s provozováním softwaru nesouvisí. Příkladem může být právě ERP, kdy se kromě běžné správy softwaru přímo nabízí dodávat zákazníkovi i služby ekonomického charakteru – od účetních až po třeba auditorské. Toto řešení dnes označujeme jako S+S (Software + Services) a, aby věc nebyla až tak jednoduchá, nikde není psáno, že vlastní softwarová část by měla být napsaná podle učebnice SaaS.
Výhodou jak staršího ASP, tak i S+S řešení, je užší vazba na zákazníka, kdy jednoznačně odpadá otázka, jak zákazníkovi opodstatnit v ERP tolik skloňovaný problém, jakým je účtování maintenance a postimplementačních služeb. Rovněž odpadá riziko neoprávněného užívání softwaru. Zákazník platí ve smluvních intervalech, a pokud by platit přestal, lze mu velmi jednoduše odebrat přístup. Další velkou výhodou SaaS řešení je jednoduchá správa a údržba základní aplikace, a tím i podstatně menší náklady na lidské zdroje pro hotline a technickou podporu. Současně mohou být náklady na doručení softwaru k zákazníkovi a implementaci řešení v ideálním případě prakticky nulové, omezují se pouze na doručení přístupového jména a hesla, zákazník aplikaci provozuje v internetovém prohlížeči. Příklady z evropské praxe ukazují i na větší dostupnost trhu, kdy je jedna společnost schopná prostřednictvím internetu snadno obsluhovat zákazníky z více zemí, bez nutnosti zřizovat lokální zastoupení. Omezujícím faktorem nasazování SaaS architektury může být nechuť zákazníků uložit klíčová citlivá data mimo společnost a opticky tak nad nimi ztratit kontrolu.
2. Základní rozdíly SaaS architektury a běžných desktopových aplikací
Pokusme se vyjít z výše uvedeného německého příkladu, kdy každý zákazník má nejen svoji aplikaci, ale i svůj server. Je zcela logické, že pokud jako dodavatel řešení budu chtít snížit náklady na provoz takového výpočetního centra, ideálním modelem je řešení, ve kterém všichni zákazníci používají jedinou aplikaci. Tím se dostáváme k základní charakteristice SaaS aplikací – jsou převážně jednoinstanční (single instance) a víceuživatelské (multi-tenancy). Právě tato architektura implikuje minimální náklady na údržbu – hoster v extrémním případě spravuje pouze jedinou aplikaci na jediném serveru.
Design aplikace je nutné plánovat s ohledem na předpokládanou zátěž. Velmi záleží na tom, o jakou aplikaci se bude jednat, a musíme se rozhodovat mezi bezpečností a škálovatelností – proto je nutné na počátku zvolit správný model pro ukládání dat.
2.1 Tři možné způsoby ukládání dat
2.1.1 Separace databází
U tohoto modelu jsou uživatelská data ukládána do vlastní databáze. Výhodou je vysoká bezpečnost (separace dat uživatelů), možnost uživatelských úprav, záloha a obnovení dat konkrétního uživatele. Oproti tomu škálovatelnost a budoucí rozšiřitelnost budou nákladné.
2.1.2 Sdílená databáze, separace pomocí schématu
Zde více uživatelů využívá jedné databáze a oddělení dat je zajištěno pomocí schémat. Můžeme využít výhod zákaznických úprav jako u separace databází, získáváme vyšší škálovatelnost. Naopak je u tohoto řešení těžší zálohování a obnova dat konkrétního zákazníka. Tento model je vhodný pro aplikace do 100 tabulek (seznamů) na zákazníka.
2.1.3 Sdílená databáze, sdílené schéma
V tomto třetím přístupu ukládáme data více uživatelů do stejných tabulek jedné databáze a data jsou rozlišena identifikátorem zákazníka, pomocí kterého dochází k odlišení dat. Toto řešení je ekonomicky nejvýhodnější. Je však nutné věnovat zvýšenou pozornost vývoji bussines vrstvy, která bude zajišťovat bezpečnost dat tak, aby každý zákazník viděl pouze svoje údaje.
2.2 Návrh ERP aplikace kategorie SaaS
Z výše uvedeného vyplývá, že před vlastním vytvářením ERP aplikace je důležité rozhodnout, které požadavky zákazníků chceme být schopni uspokojit. Pokud budeme připravovat vertikální řešení pro similární klientelu, u které se nepředpokládají zákaznické úpravy, lze použít architekturu se sdílenou databází. Naproti tomu, pokud chceme oslovit klientelu, u které se předpokládají individuální úpravy na úrovni datového modelu, je nutné pracovat s oddělenými a separátně spravovanými databázemi. Další vrstvy aplikace se odvíjejí od datového modelu a výběru technologií, které použijeme k vývoji. Zajímavou volbou může být .NET 3.5 ve spojení s Visual Studiem 2008 a Team Foundation Serverem 2008. Tyto nástroje přinášejí rychlý a bezpečný vývoj pro platformu .NET.
Další rozhodnutí, které musíme udělat, je, jaké poskytneme uživateli rozhraní. Můžeme volit mezi webovým a tenkým (smart) klientem, nebo můžeme řešit oba způsoby. Uživatelé jsou stále více zvyklí používat bohaté rozhraní aplikací, a proto může být zajímavou volbou vytvoření webového klienta pomocí technologie Silverlight. Ta přináší pro webové aplikace zajímavé možnosti bohatého uživatelského rozhraní a přitom využívá i výhod webového rozhraní (snadné doručení aplikace k zákazníkovi, aktualizace rozhraní apod.).
2.3 Architektura SaaS aplikace
Architektonický diagram čisté SaaS aplikace, která v maximálním rozsahu nabízí jak webové rozhranní, tak i tenkého (Smart) klienta, může vypadat podobně jako na obr. 1. Jak vyplývá z diagramu architektury, dalšími celky, které musíme v rámci aplikace řešit, jsou např. logování, monitoring, provisioning, billing. Tyto celky jsou závislé na konkrétním typu a řešení aplikace.
Obr. 1 Architektonický diagram čisté SaaS
(Klikněte na obrázek pro zvětšení)
2.4 Role hostera v S+S řešení
V praxi S+S se ukazuje jako rozumné oddělit roli vývojáře SaaS aplikace a hostera, tedy společnosti spravující servery a další IT infrastrukturu. Vývojářská společnost tak není zatížena činnostmi, které s vývojem softwaru souvisejí jen velmi vzdáleně, a může se plně soustředit na vývoj kvalitního produktu. Hoster dělá přesně to, co umí nejlépe: zálohování, údržbu, monitoring, provisioning.
Roli hostera u pronájmu ERP aplikací nelze podceňovat, v praxi se ukazuje jako klíčová. Pokud dojde k výpadku serveru, aplikace je nedostupná, což v praxi u ERP systému může znamenat velké ztráty. Standardní poskytovatelé internetu si dnes do smluv dávají 99 % dostupnost, což ale znamená, že tři až čtyři dny v roce ERP systém nepojede. A to je pro takové nasazení nepříjemné.
3. Příklad obchodního modelu S+S aplikace
Máme-li funkční ERP systém na bázi SaaS technologie, pak je S+S řešení v praxi velmi jednoduché.
Obr. 2 ERP systém na bázi SaaS
(Klikněte na obrázek pro zvětšení)
Jádrem všeho je webový portál (provozovaný v tomto příkladu buď přímo účetní společností, nebo hosterem). Na tomto portále je vystaven ERP systém napsaný v SaaS architektuře. Konečný zákazník přímo nebo prostřednictvím dealera, uzavírá smlouvu s provozovatelem serveru a získává přístupová práva. Přes tento portál si současně může objednávat i další služby – např. auditorské.
U portálů provozovaných hosterem může být jednou z pěkných funkcí třeba volba poskytovatele daňového poradenství nebo auditorských služeb. Celková úspěšnost řešení na trhu v každém případě závisí právě na vizuální a funkční jednoduchosti ovládání portálu.
Takový ERP portál umožňuje několik kombinací zpoplatnění, mezi ty základní patří:
- Zákazníci platí provozovateli měsíční paušál.
- Zákazník platí provozovateli za strávený čas.
- Zákazníci platí provozovateli za pořízená data.
- Provozovatel může platit zprostředkovateli (dealerovi) dohodnuté procento za získání zákazníka.
Provozovatel serveru má určité procento ze služeb, realizovaných portálem (např. procenta z plateb ze služeb objednaných u auditorských společností či daňových poradců). Sekundárním zdrojem příjmů může být samozřejmě obecná reklama na tomto portálu, měla by však být praktikována jen v rozumné míře (zákazník nakonec za služby platí) a na produkty a služby, které souvisí s náplní činnosti serveru a jejichž prodej nakonec server i může zprostředkovávat. Nebo je možné rozlišit zákazníky na platící a neplatící a jen při bezplatném užití portálu zobrazovat reklamu.
V pilotních fázích může být zajímavá možnost získání revenue spoluprací na pilotním projektu s některým ze současných lídrů trhu webových portálů. Zajímavým partnerem technicky může být i některá z větších bank, pokud by cílový segment aplikace na sebe mohl vázat další bankovní služby a zvýšit tak atraktivitu konkrétního bankovního domu.
4. Komerčně úspěšné evropské S+S projekty
Jeden z úspěšných projektů, postavených nad čistou SaaS architekturou, provozuje holandská společnost TwinField. Dnes operuje nejen v západních částech Evropy (Finsko, Holandsko, Irsko, Velká Británie), ale vstoupila i na maďarský trh. Zpočátku byly typickými klienty větší auditorské společnosti (projekt vznikl původně pro jednoho z nich), dnes však řešení společnosti TwinField využívají i firmy, jinak typicky užívající klasické desktopové aplikace.
Obr. 3 Aplikace TwinField
(Klikněte na obrázek pro zvětšení)
Aplikace TwinField má dnes řádově tisíce uživatelů, cena měsíčního pronájmu se pohybuje od 20 do 70 Euro za pojmenovaného uživatele. Cena závisí nejen na používané funkcionalitě, ale i na lokalitě.
Literatura
- Blog jednoho z předních architektů S+S: http://blogs.msdn.com/gianpaolo
- Microsoft S+S: http://msdn2.microsoft.com/en-us/architecture/aa699384.aspx
- Sodomka, P. Informační systémy v podnikové praxi. Brno : Computer Press, 2006.
O autorovi
Martin Cígler založil společnost Cígler Software již v březnu 1990. V současnosti patří tato společnost k největším českým výrobcům podnikových informačních systémů. Martin Cígler původně začínal jako programátor-analytik, od roku 1996 se profesně orientuje převážně na oblast marketingu a managementu. V roce 2007 získal prestižní titul Osobnost roku české informatiky a telekomunikací.
22.06.2008 - Martin Cígler