A cikk nagy vonalakban összefoglalja, hogy milyen szolgáltatások tartoznak bele a szoftverüzemeltetés mágikus kategóriájába. Megtudhatja, hogy mik azok a visszatérő, ismétlődő költségelemek, költségtípusok, melyekkel szembekerül, ha saját szoftver megirattatása mellett dönt. A bejegyzés természetesen nem fedi le a teljes képet, nem érinti a speciális eseteket, csak a leggyakoribb, legegyszerűbb költségfajtákat mutatja be.
Ügyféltámogatás, support kiadásai
Minél több felhasználói jogosultsági szinttel és userrel rendelkezik az adott ügyviteli, vállalatirányítási alkalmazás, annál több visszajelzés, vélemény és kérdés fogalmazódik meg a felhasználókban. Ezeket érdemes kiemelten kezelni, fontossági sorrendbe rendezni, és nyomon követni őket. Ehhez ajánlott valamilyen, a rendszertől független hibajegykezelő (ticketing system) szoftvert használni.
Telefonos support esetén ún. VOIP telefonközpont rendszert érdemes fenntartani, mely segíti a felhasználókat és a támogatási munkatársakat, hogy minél hamarabb megtalálják a választ a kérdéseikre.
Fejlesztési költségek
Kisebb szoftvereknél az üzemeltetés bevezethet kisebb funkciókat, módosításokat, azonban egy nagyobb projekt esetében ezt nem minden esetben ugyanaz a csapat végzi el, mint amelyik az üzemeltetést végzi. Ha így áll a helyzet, a fejlesztést és az üzemeltetést érdemes külön kezelni, felelős személyeket kijelölni a fejlesztési területekre. Üzemeltetési költségvetés tervezésekor, monitorozásakor, arra érdemes figyelni, hogy ha a szoftver bővül új funkciókkal, termékekkel, akkor annyival több munka hárul az üzemeltetési csapatra és ez kihatással lehet a kiadásokra is.
Szoftverdokumentációk
Ahogy folyamatosan fejlődik a szoftver, úgy változik az azt elmagyarázó, támogató dokumentáció is. Lehet, hogy valamelyik funkció első használati utasítása nem tartalmazza mindenki számára érthetően a funkció működését. Ilyenkor a visszajelzések alapján érdemes pótolni a hiányosságokat.
A (súgó) dokumentáció elhelyezhető tooltip-ben, vagy felugró ablakban is. Elképzelhető, hogy a felület nem annyira intuitív, vagy nagyon bonyolult a szoftver működése. Ebben az esetben a dokumentáció megjelenhet egy különálló wiki oldalon és/vagy akár letölthető pdf-ben, vagy ún. tutorial videóban.
Felhasználói bázistól függ, de gyakorlatban a videós dokumentáció nagyon hasznos tud lenni. Tud olcsó lenni, ha a belsős dokumentációt csak felvesszük lényegi "rendezés" nélkül. Azonban, ha nem csak a szervezet számára készül, hanem egy nagyobb publikumnak, akkor magasabb minőségű kell, hogy legyen, demo (anonimizált) adatokkal, jól vágva, megfelelő hangminőséggel, jellemzően scriptelve, rendezve. Ez a márkát, a szoftvert hivatott reprezentálni, így akár marketinganyagként is használható az audiovizuális dokumentáció. Ezek mind költségek, érdemes ezekkel is számolni előre.
Ha többnyelvű a dokumentáció, akkor számolni kell a fordítás munkadíjával is. Ezeket nem feltétlenül a fejlesztői csapatnak kell elkészítenie, hiszen kiszervezhető, így csökkentve a kiadásokat. Esetenként egyáltalán nincs szükség dokumentációra, annyira egyszerű és érthető (intuitív) az adott program.
Ami tíz évvel ezelőtt 2 oldal tömény szöveg volt, manapság másfél perces tutorial video a Youtube-on. Ma már egy jól megszerkesztett, felépített videó sokkalta hasznosabb, mint több oldal leírás.
Külső függőségek kockázatai és költségei
Az üzemeltetés része az is, hogy nyomon követjük az ún. függőségeket. Egy ilyen külső szoftveres függőség lehet például egy kommunikációs csatorna (API - alkalmazásprogramozási interfész), amely Google Maps-től kér le helyadatokat, például azért, hogy különféle távolságokat számoljon ki két pont között.
Ezek a kommunikációs csatornák időnként (jobb esetben) verzióváltáson, fejlődésen mennek keresztül, hiszen pl. a Google Maps is folyamatosan változik. Van, hogy ez a harmadik fél (3rd party) teljesen átalakítja, újraépíti a kommunikációs leírónyelvét, vagy egy bizonyos lekérésszám után fizetőssé teszi az elérését. Ilyenkor a szoftver üzemeltetőjének jelentenie kell a megrendelője felé a várható változásokat, illetve, az ehhez kapcsolódó plusz fejlesztési feladatokat, alternatívákat.
Szerver, hoszting
A szoftvert valamilyen gép "hajtja", ez nyilvánvaló. Azonban az a bizonyos gép valakinek a tulajdonában áll, és így már eltérő üzemeltetési stratégiák és költségnemek merülhetnek fel. Változó, hogy mire van szükség. Lehet, hogy egyszerű, kis erőforrásigényű számítást végez el a program, ezért elegendő egy PHP és MySQL környezet; jellemzően ezt a legtöbb hosztingcég tudja nyújtani, pl.: megosztott tárhelyen. Ha ez az erőforrás kicsi, akkor érdemes lehet dedikált erőforrással rendelkező virtuális privát szervert (VPS) bérelni, de ha ez is kevés, vagy hosszú távon költséges, akkor érdemes beruházni egy saját szerverbe.
Az alábbi kategorizálás bizonyos esetekben szakmailag vitatható, azonban szemléltetésre alkalmas. A kategorizálás célja, hogy a várható költségnemeket strukturáltan, leegyszerűsítve mutassuk be egy IT szakmán kívüli személynek.
Kis erőforrásigény esetén
- Jellemzően ERP, CRM rendszerek vagy valamilyen egyszerűbb ügyviteli rendszerek kisebb cégeknek
- Főleg adatbázis és tárhely igényük van, kevés memóriát fogyasztanak
- Nincs hardverberuházás
- Jellemzően egy szolgáltatótól be lehet szerezni mindent (licensek, egyéb szolgáltatások)
- Egy jó szolgáltatóval gazdaságosan lehet működtetni a programot, havonta költségelhető
- Későbbiekben skálázható
(felhasználói bázis növekedése esetén) - Sok szolgáltató közül lehet választani
- A szolgáltatásért havonta is lehet fizetni, nem szükséges egy teljes évre elköteleződni
Közepes kapacitásigényű szoftver
- Fontos a rendelkezésre állás
(Pl. 100%-os rendelkezésre állás esetén (cloud) úgy van felépítve a kiszolgáló rendszer, hogy minden esetben elérhető az azon futtatott szoftver) - Jellemző a program számára dedikáltan bérelt VPS
A Virtual Private Server előnye, hogy nem megosztott rendszerben helyezkedik el, mint pl.: a legtöbb kisebb tárhely szolgáltatási csomag, így egyedi futtatási környezetet lehet kialakítani a szerveren. Egyedi környezetre például akkor lehet szükség, ha a szerverre telepíteni kell valamilyen plusz programot. - VPS választásakor fontos szempont a tárhely-, memória mérete és a processzorok száma, erőssége
- Nincs hardverberuházás
- Jellemzően egy szolgáltatótól be lehet szerezni mindent (licensek, szolgáltatások)
- Egy jó szolgáltatóval gazdaságosan lehet működtetni a programot
- Rugalmas fizetési modell
- A szolgáltatásért havonta, negyedévente lehet fizetni, nem szükséges egy teljes évre elköteleződni
- Havonta költségelhető
Magas erőforrásigényű szoftver
- Fontos a 100%-os rendelkezésre állás (felhőbe szervezett elosztott szolgáltatás)
- Adatbázis-, tárhely-, memória- és processzor igénye magas
- Lehetőség szerint a használt hardver a későbbiekben bővíthető legyen
- Érdemes megvenni a szervert és berakni egy szerverközpontba (rack-helyet bérelni).
(vásárlásnál ügyelni kell, hogy a gépben "legyen még kapacitás", azaz fölé érdemes számolni a teljesítményt)
Adatbiztonság, adatkezelési jogszabályi megfelelőség miatt is sokszor a saját "vas" a legjobb megoldás - Rackszekrény helybérlet esetén külön áramdíjjal is szükséges kalkulálni, érdemes megfontolni a korszerűbb szerverek beszerzését, mert hosszú távon kevesebb áramot fognak fogyasztani, megtérülhet a beszerzés, eszközpark csere.
- Bérelni is lehet, jellemzően ez hosszú távon nem éri meg
- Legtöbb esetben több szolgáltatótól kell beszerezni a licenseket, szolgáltatásokat, szoftvereket, hardvereket
- Lehetnek olyan esetek amikor az operációs-, virtualizációs rendszer vagy annak támogatása fizetős
- Hardveres vagy szoftveres tűzfal, illetve vírusirtó szükséges lehet
- 3rd party backup szolgáltatóra szükség lehet, pl. Azure Backup
- Időnként karbantartás, eszközcsere vagy firmware frissítés szükséges, amely munkaerő igényes (szerver adminisztrátor)
Változó kapacitásigényű szoftver
- Időnként megugró terhelést kell kiszolgálnia
- Kapacitás alapú elszámolás jellemzi
- Álló időben nem fizet a kapacitás rendelkezésre állásáért (ha jól van beállítva)
- Jellemzően egy nagyobb, komoly szerverparkkal rendelkező cégtől lehet bérelni, mint például a Google Cloud vagy Azure
- Specifikus programok esetén, pl. szavazórendszer alkalmi futtatásához, vagy határidős jelentkezés beadására írt ügyfélkiszolgáló portál esetén hasznos ez a modell
Domain, fix IP cím, SSL
Webes szoftver esetében általában mindig fenn kell tartani egy-két domaint. Szervizdomaineknek, belső használatra, érdemes az olcsóbb domain végződéseket használni, legalábbis mi azt szoktuk. Sok esetben elengedhetetlen a fix IP cím is, ez is évente vagy havonta jelentkező költség. Érdemes a https kapcsolatot biztosító SSL tanúsítványok díjával is kalkulálni, itt, ha sok aldomain van a rendszerben, érdemes ún Wildcard SSL-t vásárolni, mert megtérül. Apró trükk, de több évre veszünk SSL tanúsítványt jobb árat tudunk kapni a szolgáltatóktól.
Bandwidth
Sok felhasználó esetén, vagy pl. több száz oldalas (.pdf) riportolások készítésekor komoly hálózati adatforgalma lehet az egyszerű ügyviteli programoknak is. Ilyen esetben elképzelhető, hogy az eredeti pl.: VPS csomagban elérhető havi sávszélesség limitet elérjük. A legtöbb szolgáltatónál lehet még a csomaghoz plusz szolgáltatásként dedikált sávszélességet vásárolni. Szolgáltató választásakor, üzemeltetésekor érdemes ezt is megnézni, hogy mennyibe kerül egy esetleges bővítés.
Szofverfejlesztő,
szoftverüzemeltető csapatot keres?
Meglévő desktop (DOS-os, Windows-os) vagy elavult webes ügyviteli rendszerét új SaaS technológiai alapokra írjuk át. Adatmigrálással, architektúraváltással mi megvalósítjuk Önnek.