Jeżeli decydujesz się na implementację systemu w modelu on-premises, powinieneś rozważyć podpisanie umowy wsparcia. Umowy tę najczęściej są opcjonalne – przez co mogą sprawiać wrażenie zbędnych, dlatego warto dobrze zrozumieć ich rolę.
Krytycznych i praktycznych powodów dla wdrażania systemu w trybie on-premises konsekwentnie ubywa. Z zeszłorocznych danych prezentowanych przez Accenture w raporcie z badań nad zagadnieniem chmury obliczeniowej w bankowości (link) – wynika, że nawet w tym konserwatywnym sektorze 80% organizacji miało, albo wkrótce miało mieć opracowaną strategię rozwoju swoich aplikacji w chmurze. Niemniej dalej występują okoliczności, które wymagają starego, sprawdzonego i nie budzącego większych kontrowersji modelu on-prem.
Patrząc od strony kosztowej, a statystycznie taka będzie początkowa optyka decydentów, zderzymy się z elementami, które będzie łatwo uzasadnić: koszt infrastruktury (dedykowanej lub dodatkowej), koszty licencji (tu im lepsza marka dostawcy, tym drożej, ale paradoksalnie łatwiej), koszty wdrożenia oraz szkoleń.
Z drugiej strony pojawia się element, którego opcjonalność, relatywnie wysoka cena oraz często brak zrozumienia celu – sprawiają, że ciężko argumentować za jego zakupem. Mowa o tytułowych umowach wsparcia. I chociaż zdarzają się umowy, które w ujęciu rocznym kosztują równowartość kilku procent wartości licencji, to częściej spotkamy się z rzędem wielkości 20-30%. Niejednokrotnie kwoty będą jeszcze wyższe.
Dostawca ma pełną swobodę w definiowaniu zakresu wsparcia oferowanego w ramach kontraktu, ale ramowo można mówić o elementach takich jak:
- Udostępnianie poprawek błędów
- Udostępniania łatek bezpieczeństwa, w przypadku wykrycia podatności
- Objęcie licencją kolejnych wersji oprogramowania, która pojawia się w okresie trwania utrzymania (przy czym samo techniczne wsparcie w procesie aktualizacji najczęściej będzie osobno płatne)
- Dostęp do kanałów obsługi klienta, możliwość zgłaszania problemów i pytań i uzyskiwania na bieżąco pomocy
- Pakiet konsultacji z konsultantami biznesowymi lub helpdesk (zazwyczaj pewna ograniczona ilość godzin)
- Określenie i gwarancja poziomów obsługi (SLA)
- Ustalenie stawek i trybu realizacji dodatkowych prac (np. dla celów ww. aktualizacji wersji, rozwoju lub nowych integracji)
Nie jest to kompletna lista, ale pozwala zrozumieć ideę.
Dostawca przez umowę utrzymania i fakt, że jest ona płatna – jest w stanie zarezerwować po swojej stronie odpowiednie zasoby do realizacji swoich zobowiązań. Zależność ceny od zawartości jest oczywiście wprost proporcjonalna – im więcej „w pakiecie” tym wyższa cena.
Cena wsparcia może wynikać również z powszechności wiedzy koniecznej do utrzymania systemu – czyli na pewnym poziomie abstrakcji, z jego otwartości. Ta zależność jest odwrotna – im wyższa popularność i otwartość technologii – tym niższa cena.
Aplikacje w SaaS, gdyby chcieć porównać ich koszty z ekwiwalentem hostowanym on-premises – zawsze wypadną drożej – nie tylko ze względu na oczywisty fakt konieczności utrzymania infrastruktury przez dostawcę, ale również przez konieczność wbudowania w cenę części zakresu usług umowy wsparcia.
Koszt wsparcia nigdy nie zniknie, może najwyżej zmienić miejsce. Oszczędzanie na umowie wsparcia jest strategią suboptymalną, chyba że planujemy zbudować i utrzymać komplet kompetencji niezbędnych do zapewnienia bezproblemowego działania systemu.