Kdaj izbrati rešitev po meri in kdaj preverjeno rešitev

1. Prava izbira je odvisna od procesa

Rešitev po meri ni vedno boljša od preverjene rešitve in obratno. Odločitev je odvisna od tega, kako poseben je vaš proces, kako hitro želite rešitev uvesti ter koliko prilagoditev in povezav potrebujete.

Če je način dela podoben običajnim praksam v panogi, je preverjena rešitev pogosto najhitrejša pot. Če pa proces pomembno vpliva na kakovost storitve, učinkovitost ali razlikovanje od konkurence, je smiselno preveriti razvoj po meri.

2. Hitrost uvedbe

Pri preverjeni rešitvi je osnovna funkcionalnost že razvita. Večina dela je zato namenjena nastavitvam, pravicam, uvozu podatkov in manjšim prilagoditvam. Čas in obseg uvedbe sta praviloma bolj predvidljiva.

Pri rešitvi po meri je treba najprej natančno opredeliti proces in zahteve. Pri projektih BizIT klikljiv prototip običajno pripravimo v enem do dveh tednih, celotna pot od ideje do uvedbe pa praviloma traja od šest do dvanajst tednov. Obseg je seveda odvisen od zahtevnosti rešitve in integracij.

Najhitrejša možnost ni nujno tudi najhitrejša pot do rezultata. Če standardna rešitev procesu ne ustreza, lahko uporabniki veliko dela še naprej opravljajo zunaj sistema.

3. Stroški: poglejte celotno obdobje uporabe

Preverjena rešitev ima pogosto nižji začetni strošek, ker je bil razvoj osnovnih funkcij že opravljen. Pri primerjavi pa je treba upoštevati tudi naročnine, število uporabnikov, dodatne licence, stroške prilagoditev in delo, ki bo kljub uvedbi ostalo ročno.

Pri rešitvi po meri je začetni vložek praviloma višji, vendar je rešitev zasnovana okoli konkretnega procesa. Pomembno je oceniti stroške razvoja, vzdrževanja in prihodnjih sprememb, ne le prve ponudbe.

4. Prilagodljivost in integracije

Preverjeno rešitev je mogoče prilagajati znotraj možnosti, ki jih omogoča njena zasnova. Manjše spremembe so lahko hitre, večje posebnosti pa pogosto zahtevajo obvode ali dodatne korake.

Pri rešitvi po meri se funkcionalnosti določijo glede na poslovne zahteve, proračun in čas. To omogoča več nadzora nad uporabniško izkušnjo, pravili in povezavami z drugimi sistemi, vendar zahteva tudi več odločitev med načrtovanjem.

Praktičen znak

Če morate pri predstavitvi standardne rešitve pogosto pojasnjevati, da bo pomemben del procesa še vedno potekal zunaj nje, je smiselno primerjati tudi možnost razvoja po meri.

5. Dolgoročno vzdrževanje

Pri preverjeni rešitvi za osnovne nadgradnje praviloma skrbi ponudnik. Prednost je manj operativnega dela za naročnika, omejitev pa manj vpliva na razvojno smer produkta in čas uvedbe novih funkcij.

Pri rešitvi po meri je treba vnaprej določiti, kdo bo skrbel za podporo, spremembe, dokumentacijo in prenos znanja. Kadar je rešitev zgrajena v obstoječem okolju Microsoft 365, za platformo skrbi Microsoft, za poslovno rešitev pa dogovorjeni izvajalec ali interna ekipa.

Pred odločitvijo zato vprašajte: kdo bo rešitev vzdrževal čez tri leta, kako se bodo izvajale spremembe in kako lahko nadaljujemo, če zamenjamo izvajalca?

6. Pet vprašanj za odločitev

Rešitev po meri je verjetnejša izbira, če na več spodnjih vprašanj odgovorite pritrdilno:

• Ali je proces pomemben del naše konkurenčne prednosti ali kakovosti storitve?
• Ali vsebuje več pomembnih posebnosti, ki jih standardne rešitve ne podpirajo?
• Ali se mora rešitev povezati z več obstoječimi sistemi?
• Ali pričakujemo, da se bo proces v naslednjih letih načrtno spreminjal?
• Ali podatki iz procesa pomembno vplivajo na poslovne odločitve?

Če so odgovori večinoma nikalni, bo preverjena rešitev pogosto hitrejša in stroškovno učinkovitejša.

7. Najpogostejša napaka

Največja napaka je odločanje na podlagi predstavitve izdelka, še preden je jasno opisano, kako proces danes dejansko poteka in kaj mora biti po uvedbi drugače.

Najprej opredelite problem, uporabnike, izjeme, potrebne podatke in merila uspeha. Šele nato je mogoče pošteno primerjati preverjeno rešitev, razvoj po meri ali izboljšavo procesa brez novega informacijskega sistema.

8. Iz prakse BizIT

V praksi je pogosto primerna kombinacija obeh pristopov. Preverjena rešitev lahko pokrije standardni del procesa, po meri pa se razvijejo funkcije, s katerimi se organizacija razlikuje ali povezuje svoje obstoječe sisteme. Odločitev sprejmemo po analizi procesa, ne vnaprej.