Kako procijeniti softver prije nego što ga uvedete u svoju tvrtku

Usvajanje novog softvera u tvrtki može napraviti razliku između značajnog povećanja učinkovitosti i zaglavljivanja u troškovima, unutarnjem otporu i beskrajnim projektima koji se nikada u potpunosti ne realiziraju. Većina organizacija iskoristi priliku za korištenje "najnovijeg alata" ili bilo čega što drugi dobavljač preporučuje, bez prolaska kroz rigorozan proces evaluacije.

Pravilna evaluacija softvera prije implementacije ne odnosi se samo na usporedbu značajki u tablici; radi se o razumijevanju stvarnih problema, procesa, ljudi, ukupnih troškova te srednjoročnih i dugoročnih rizika. Ako to radite metodično, softver postaje strateška poluga za vašu digitalnu transformaciju; u suprotnom, na kraju postaje trošak koji se vuče godinama.

Zašto je evaluacija softvera ključna u poslovanju

Većina poslovnih rješenja (ERP, CRM , HR itd.) koristi se dugi niz godina i postaje temelj kritičnih procesa: financija, prodaje, logistike, upravljanja ljudima ili korisničke službe. To podrazumijeva vrlo visok ukupni trošak vlasništva (TCO), ali i ogroman potencijal za povrat ulaganja (ROI) ako se odaberu mudro.

Tržište softvera je ogromno i vrlo neujednačeno u pogledu kvalitete, fokusa i zrelosti, a svaki dobavljač obično nudi nekoliko proizvoda namijenjenih različitim segmentima i slučajevima upotrebe. Dodajte tome promjenjive potrebe, interese različitih odjela te vremenska ili proračunska ograničenja i dobit ćete savršeno tlo za brzoplete odluke.

Loš izbor nije primjetan samo u prvoj godini ; može ometati tvrtku desetljeće: kruti procesi, raspršeni podaci, skupe promjene i frustrirani timovi koji se vraćaju Excelu ili drugim paralelnim alatima. Zato je posvećivanje tjedana ili mjeseci temeljitoj evaluaciji jedno od najprofitabilnijih ulaganja u bilo koji projekt digitalizacije.

Ključ leži u kombiniranju strukturiranog procesa (s jasnim koracima, dokumentacijom i objektivnim kriterijima) s praktičnim razumijevanjem svakodnevnih potreba korisnika. Nije dovoljno usredotočiti se isključivo na 10-godišnju stratešku viziju, niti je dovoljno pozabaviti se samo neposrednim potrebama najglasnijeg odjela.

Okupite pravi tim za procjenu softvera

Evaluacija softvera nije zadatak jedne osobe, niti je to nešto o čemu može odlučivati ​​isključivo IT odjel ili uprava. Idealno bi bilo stvoriti multidisciplinarni projektni tim koji će predstavljati ključna područja koja će koristiti sustav i one koji su odgovorni za njegovo održavanje i integraciju.

Ovaj odbor za odabir trebao bi uključivati ​​ključne korisnike iz različitih odjela, IT osoblje i, ako je moguće, neutralnu osobu s arbitražnim mogućnostima: to bi mogao biti visokorangirani sponzor ili vanjski konzultant bez veza s određenim dobavljačima. Njihova je uloga uravnotežiti interese i spriječiti da odluka bude pristrana zbog osobnih preferencija ili "onoga što se oduvijek tako radilo".

Bitno je da članovi tima imaju temeljito razumijevanje organizacije , zdrav razum i potrebno vrijeme za posvetiti se projektu. Uobičajena pogreška je imenovanje ljudi s puno dobrih namjera, ali malo iskustva u procesima ili tehnologiji, ili onih koji su već preopterećeni poslom i na kraju biraju prečace.

Ovaj tim bit će odgovoran za cijeli ciklus : definiranje strategije, koordinaciju prikupljanja zahtjeva, razvoj i evaluaciju zahtjeva za ponudu (ako postoji), organiziranje demonstracija, provjeru referenci, izračun povrata ulaganja i sudjelovanje u pregovorima o ugovoru. Njihovo rano uključivanje uvelike povećava šanse za uspjeh.

Definirajte ciljeve, strategiju i opseg projekta

Prije nego što pogledate kataloge ili zatražite demonstracije , morate iskreno odgovoriti na osnovno pitanje: koji problem želimo riješiti i kako ćemo znati da smo uspjeli? Bez te jasnoće, bilo koji alat može se činiti dobrim... ili lošim.

Projektni tim mora se složiti oko specifičnih ciljeva , i tehničkih i poslovnih. Na primjer, smanjenje vremena zatvaranja računovodstva, smanjenje pogrešaka u naplati, centralizacija raspršenih podataka, poboljšanje sljedivosti zaliha ili povećanje zadovoljstva zaposlenika HR procesima.

Uz ciljeve, potrebno je utvrditi strategiju odabira : koji se vremenski horizont razmatra, koji se stupanj standardizacije traži, kolika je margina za promjenu internih procesa radi prilagodbe softveru i koji dijelovi nisu predmet pregovora jer čine konkurentsku prednost tvrtke; te, usput, konzultirati karakteristike upravljanja projektima koje će olakšati upravljanje projektom.

Također je vrijeme za postavljanje približnog vremenskog okvira i proračuna: koliko će vremena biti posvećeno fazi analize, predodabiru, dokazu koncepta i pregovorima. Te koji raspon ukupnih ulaganja (licence, implementacija, obuka, održavanje) tvrtka je spremna poduzeti.

Identificirajte uobičajene izazove pri odabiru softvera

Gotovo svi projekti zapošljavanja imaju niz prepreka koje treba uzeti u obzir od samog početka kako bi se izbjeglo njihovo kasnije suočavanje. Predviđanje tih prepreka pomaže u osmišljavanju realističnijeg procesa.

Jedan od najčešćih izazova je razumijevanje troškova . Cijena licence ili pretplate (i upravljanje s upraviteljima softverskih licenci ) samo je vrh ledenog brijega: morate uzeti u obzir usluge implementacije, prilagodbe, integracije, migraciju podataka, početnu obuku, održavanje, moguća proširenja i interne troškove timskog vremena.

Druga prepreka je fokusiranje na pogrešnu razinu : koncentriranje isključivo na nejasnu, vrlo dugoročnu stratešku viziju ili, obrnuto, isključivo na gašenje požara u sadašnjosti. Nijedna perspektiva, sama po sebi, ne omogućuje pravilnu procjenu koliko dobro alat odgovara planovima rasta i trenutnim stvarnostima.

Napetosti između odjela također su česte . Svako područje brani svoje prioritete, neki voditelji projekata mogu imati preferencije za etablirane dobavljače, a naslijeđeni sustavi ili redovni integratori mogu lobirati za održavanje statusa quo. Sve to može utjecati na odluku ako se ne upravlja transparentno.

Analizirajte potrebe i definirajte softverske zahtjeve

Kritična faza je analiza potreba , gdje identificiramo koje procese treba podržati, koji problemi postoje danas i što se očekuje od novog sustava. Ovaj posao nije stvaranje beskrajnih kontrolnih popisa, već razumijevanje kako poslovanje funkcionira.

Preporučljivo je opisati procese na sveobuhvatan način , ističući volumen transakcija, operativnu složenost, specifičnosti po sektoru ili zemlji i one aktivnosti koje pružaju jasnu konkurentsku prednost. Upravo će se na temelju tih diferencirajućih čimbenika različiti pružatelji usluga uistinu razlikovati.

U ovoj fazi također je korisno primijetiti što dobro funkcionira u trenutnom sustavu (kako se ne bi izgubio), a što ne pokriva ili pokriva loše. Sve napravljene prilagodbe su rudnik informacija o prazninama koje bi novi softver trebao riješiti standardnom funkcionalnošću ili laganim prilagodbama, a ne skupim razvojem.

Za organiziranje svih ovih informacija, može se stvoriti matrica zahtjeva koja uključuje područja kao što su tehnička arhitektura, izvori podataka, administracija, sigurnost, UX, izvještavanje, analitika, integracije, troškovi i podrška. Svaki zahtjev može se klasificirati kao bitan ili poželjan i ponderirati prema svojoj važnosti.

Najbolje prakse za dokumentiranje i određivanje prioriteta zahtjeva

Generičke kontrolne liste zahtjeva postoje oduvijek, ali rijetko pomažu u razlikovanju rješenja jer gotovo svi dobavljači jednostavno označavaju "da" osnove. Zato je važno prilagoditi ove kontrolne liste kako bi odražavale specifične okolnosti vaše tvrtke.

Ključno je uključiti sve dionike u prikupljanje zahtjeva: ako se jedno područje izostavi, vrlo je vjerojatno da će kasnije trebati zasebna rješenja za pokrivanje svojih potreba, što će dodatno fragmentirati krajolik sustava. Idealno bi bilo da rješenje pokriva cijelu organizaciju, čak i ako je implementacija u fazama.

Prioritizacija se također mora provesti s globalne perspektive . Uobičajeno je da svaki odjel daje prioritet vlastitim potrebama, ali ti prioriteti često nisu usklađeni s korporativnom strategijom. Projektni tim mora uskladiti te popise i odlučiti što je vitalno, važno ili jednostavno poželjno s gledišta tvrtke.

Još jedna nezgodna točka je razlikovanje između onoga što već postoji i onoga što je "obećano ". Mnogi proizvođači govore o značajkama koje će stići u budućim verzijama. Dobro ih je imati na umu, ali ne biste se trebali oslanjati na njih za pokrivanje kritičnih procesa dok ne budu zrele i dok ih drugi kupci ne koriste u proizvodnji.

Izračunajte povrat ulaganja i ukupne troškove vlasništva (TCO)

Gotovo svi veći softverski projekti zahtijevaju analizu povrata ulaganja (ROI) kako bi se osiguralo odobrenje i financiranje. Ispravno izvođenje znači gledanje dalje od početnih troškova i kvantificiranje izravnih ušteda i neizravnih koristi.

Povrat ulaganja trebao bi uključivati ​​ulaganje u licence ili pretplate , usluge implementacije, hardver (ako je primjenjivo), obuku, podršku, ažuriranja i moguća proširenja, uspoređujući to s trenutnim troškovima rada sa starim sustavom ili s ručnim procesima.

Prednosti se protežu daleko izvan uštede vremena : poboljšana kvaliteta podataka, manje pogrešaka, bolja korisnička podrška, veće analitičke mogućnosti, smanjeni rizik od neusklađenosti s propisima i povećano zadovoljstvo zaposlenika, između ostalog. Iako se ne može sve izmjeriti do posljednjeg centa, vrijedi pokušati ih procijeniti.

Također je preporučljivo analizirati dugoročne scenarije troškova : neki SaaS pružatelji usluga počinju s vrlo atraktivnim naknadama, a zatim agresivno podižu cijene; ​​drugi ograničavaju usluge uključene u održavanje ili nude malo pomoći pri svakoj većoj nadogradnji, što rezultira skupim projektima nadogradnje svakih nekoliko godina.

Zahtjev za ponudu i predodabir dobavljača

Nakon što su zahtjevi jasno definirani , uobičajena praksa u srednjim i velikim projektima je slanje RFP-a (Zahtjeva za ponudu) ograničenom broju dobavljača. Cilj nije pitati cijelo tržište, već odabrati desetak ili manje prikladnih kandidata.

Zahtjev za ponudu (RFP) dijeli s dobavljačima opis tvrtke, njezine ključne procese, što funkcionira, a što ne u trenutnom sustavu, te popis prioritetnih zahtjeva. Nakon toga se od njih traži da dostave prijedlog u kojem se detaljno opisuje kako će zadovoljiti potrebe, koji proizvod predlažu, njihovo iskustvo u sektoru i plan implementacije.

Kako bi se došlo do tog početnog užeg popisa, kombinira se nekoliko izvora : priče o uspjehu u specijaliziranim medijima, preporuke udruženja, reference kolega iz sektora, softverski direktoriji i, u nekim slučajevima, neovisni savjeti konzultantskih tvrtki bez komercijalnih veza s određenim proizvođačima.

Moguće je uključiti dobavljače koje preporučuju ključni klijenti ili sama poslovna grupa , ali oni uvijek moraju biti podložni istim kriterijima evaluacije kao i svi ostali. Samo zato što strateški partner koristi alat ne jamči da će on odgovarati vašem kontekstu.

Prva faza evaluacije: probir i bodovanje

Nakon što se prime odgovori na zahtjev za prijedloge (RFP) , započinje prvi krug detaljnije evaluacije. Cilj je eliminirati one koji ne odgovaraju i odabrati malu skupinu finalista koji će zatim proći kroz detaljniju evaluaciju.

Kako bi proces bio organiziran, vrlo je korisno izraditi tablicu bodovanja gdje se ocjenjuju glavni kriteriji: funkcionalna prikladnost, tehnološka prikladnost, iskustvo u sektoru, model cijena, podrška itd. Svaki kriterij može imati težinu, a svaki ocjenjivač dodjeljuje ocjenu na definiranoj ljestvici.

Preporučljivo je ostaviti prostora za komentare i pitanja , jer ćete morati tražiti pojašnjenje od dobavljača o mnogim točkama. Neka se pitanja mogu riješiti pismeno, dok se druga mogu detaljnije obraditi tijekom demonstracijske runde i intervjua.

Kada se zbroje ponderirani rezultati , obično se pojavi prva skupina jakih prijedloga, nakon čega slijedi srednja skupina, a zatim neki koji su očito neprikladni. Idealno bi bilo da se konačni uži izbor sastoji od tri do pet kandidata kako bi se omogućila detaljna procjena bez preopterećenja tima.

Pravedan tretman i objektivni kriteriji u preliminarnoj fazi

U ovoj ranoj fazi važno je održavati jednake uvjete za sve dobavljače. Prihvaćanje posebnih posjeta ili osobnih demonstracija samo od nekih može iskriviti percepciju i stvoriti sumnje u povlašteni tretman.

Dobra je praksa organizirati zajedničku sesiju (osobno ili online) gdje se projekt predstavlja svim ponuđačima i na pitanja se odgovara otvoreno. Na taj način svi imaju iste informacije i nema skrivenih prednosti.

Također je važno zapamtiti da je prijedlog poslovni dokument . Iako se pretpostavlja da je ono što piše istina, napisan je kako bi se istaknuli pozitivni aspekti i smanjili rizici. Mnoge tvrdnje trebat će kasnije provjeriti stvarnim referencama i praktičnim dokazima.

Konačno, vrijedi provjeriti gdje postoje značajne razlike u ocjenama između ocjenjivača za isti kriterij. Te razlike obično ukazuju na to da je netko primijetio nešto što drugi nisu ili da se neka točka tumači drugačije. Rasprava o tim razlikama može dovesti do prilagodbe ocjena i poboljšanja konačnog popisa.

Detaljna evaluacija i dubinska usporedba

Nakon zatvaranja užeg izbora , započinje najintenzivniji dio procesa: provjera obećanja dobavljača, razgovor s referentnim klijentima, detaljno proučavanje ugovora i upoznavanje s radom sustava na stvarnim slučajevima.

Ovo je dobar trenutak da zamolite kandidate da prilagode svoje prijedloge na temelju onoga što su naučili u preliminarnoj fazi: mogu postojati zahtjevi kojima se promijenio prioritet ili aspekti koje je potrebno jasnije specificirati, na primjer, razine usluga ili planovi razvoja proizvoda.

Preporuke drugih klijenata su neprocjenjive . Idealno bi bilo razgovarati s organizacijama slične veličine, u istom ili usporedivom sektoru, i pitati ih o njihovom iskustvu s implementacijom, stvarnim koristima i "ali": s kakvim su se iznenađenjima susreli, što bi drugačije učinili da kreću od nule.

Paralelno s tim, vrijeme je da se dublje istraži integracija, sigurnost i arhitektura : kako će se povezati s postojećim sustavima, koje su opcije dostupne za migraciju podataka, koja je razina prilagodbe moguća bez dodirivanja koda i koji se alati za upravljanje i praćenje nude.

Kako organizirati korisne demonstracije (a ne samo marketing)

Komercijalne demonstracije obično su osmišljene da izgledaju impresivno , a ne nužno da demonstriraju kako sustav funkcionira u vašim složenim scenarijima. Zato je ključno da vaš tim postavi ton za ono što želite vidjeti.

Dobra je praksa pripremiti detaljan scenarij procesa i scenarija kojih bi se dobavljač trebao pridržavati tijekom demonstracije. Svi kandidati dobivaju isti scenarij kako bi se mogli ravnopravno uspoređivati, a tek na kraju im se daje vrijeme da predstave sve ključne značajke koje žele istaknuti.

Ovaj skript trebao bi uključivati ​​i standardne procese i uobičajene iznimke u vašem poslovanju: narudžbe za proizvode koji nisu na zalihi, prodaju kompleta, složene tijekove rada za odobravanje, specifična usklađivanja, detalje o plaćama, lokalne propise itd. Tu zaista vidite je li alat dobar za vas.

Kad god je to izvedivo, idealno je da demo koristi podatke vaše tvrtke ili barem skup podataka koji je što sličniji stvarnosti. To pomaže korisnicima da vizualiziraju svakodnevno iskustvo sa sustavom i identificiraju probleme koji bi ostali nezapaženi s fiktivnim podacima.

Izbjegavajte zasljepljivanje i iskoristite reference na licu mjesta

Osoba koja održava demonstraciju obično je visokokvalificirani profesionalac s puno karizme i uglađenom prezentacijom. Lako se zanijeti izvedbom i izgubiti iz vida glavnu poantu: kako alat rješava kritične procese i koji će napor biti potreban za njegovu prilagodbu.

Važno je da demonstracije potiču kritički stav i mnoga pitanja , čak i o neugodnim temama: poznata ograničenja, realni planovi, prošli neuspjesi, ovisnost o partnerima za bilo kakve promjene itd. Što se više pitanja odgovori sada, manje će iznenađenja biti kasnije.

Posjeti objektima ključnih klijenata još su jedan ključni trenutak. Ne radi se samo o tome da se sustav vidi u akciji, već o razumijevanju konteksta: kulture tvrtke, namjenskih resursa, razine potražnje i je li njegov uspjeh moguće ponoviti u vašoj organizaciji bez nemogućih uvjeta.

Važno je unaprijed se dogovoriti o tome što želite vidjeti i s kim ćete razgovarati : krajnjim korisnicima, voditeljima područja, IT-jem, menadžmentom… Svatko će ponuditi drugačiju perspektivu. I morate biti spremni pitati o najvećim izazovima, realnim rokovima i utjecaju na svakodnevno poslovanje tijekom implementacije.

Uloga upravljanja promjenama i sudjelovanja tima

Jedan od glavnih razloga neuspjeha implementacije softvera nije tehnički, već ljudski: otpor promjenama i nedostatak prihvaćanja. Ako ljudi osjećaju da im se alat "nameće" bez njihovog doprinosa, to će generirati otpor i potragu za prečacima.

Zato je toliko važno uključiti tim od samog početka u identificiranje problema, definiranje zahtjeva i procjenu opcija. Nije stvar u tome da svaka osoba donosi konačnu odluku, već u tome da se uključi njihova praktična perspektiva o tome što funkcionira, a što ne.

Jednostavnost korištenja je još jedan ključni faktor . Moćan, ali nezgrapan sustav može ostati nedovoljno iskorišten jer je krivulja učenja prestrma. Sučelje, logiku navigacije i jasnoću procesa trebali bi procijeniti stvarni korisnici, a ne samo tehnički stručnjaci.

Konačno, obuku i internu podršku treba planirati od samog početka: tko će biti kontakt osoba u svakom području, koje će se sesije održavati, koji će materijali biti dostupni i kako će se odgovarati na pitanja tijekom prvih mjeseci korištenja u produkciji.

Kritični aspekti: fleksibilnost, skalabilnost i sigurnost

Da bi softver rastao s tvrtkom , mora biti fleksibilan i skalabilan. Fleksibilnost znači mogućnost dodavanja modula, prilagođavanja tijekova rada, definiranja prilagođenih polja ili integracije novih alata bez potrebe za prepisivanjem polovice sustava.

Skalabilnost se odnosi na podršku većem broju korisnika , većim količinama podataka i većoj organizacijskoj složenosti bez žrtvovanja performansi ili povećanja troškova. Mnoga rješenja dobro funkcioniraju s malim brojem korisnika, ali imaju poteškoća kako tvrtka raste.

Sigurnost i povjerljivost informacija su neizostavne. Preporučljivo je provjeriti koji se protokoli koriste (SSL/TLS enkripcija u prijenosu, enkripcija u mirovanju, upravljanje sesijama i kolačićima, sigurni API-ji, zaštita od SQL injekcije itd.) i koje sigurnosne i usklađene certifikate ima davatelj usluga; te kako upravljaju telemetrijom i privatnošću podataka .

U modernim okruženjima, rješenja u oblaku često pružaju značajne prednosti u izradi sigurnosnih kopija, oporavku od katastrofe i kontinuitetu poslovanja, pod uvjetom da pružatelj usluga ima robusnu infrastrukturu i jasne politike zaštite podataka, uključujući kako šifrirati i sinkronizirati sigurnosne kopije u oblaku.

Upotrebljivost, centralizacija podataka i analitika

Intuitivno sučelje skraćuje vrijeme usvajanja i smanjuje ovisnost o priručnicima i dugotrajnoj obuci. To ne znači žrtvovanje funkcionalnosti, već organiziranje tako da korisnici mogu pronaći ono što im je potrebno bez da se izgube u beskrajnim izbornicima.

Centralizacija podataka još je jedan ključni zahtjev u tvrtkama gdje više odjela treba surađivati ​​i dijeliti informacije. Dobar sustav trebao bi omogućiti pohranu svih relevantnih informacija u jednom repozitoriju, dostupnom s odgovarajućim dozvolama i bez dupliciranja.

Mogućnost generiranja izvješća i analize podataka više nije opcionalna. Softver mora omogućiti stvaranje jasnih, kvantificiranih izvješća usklađenih sa strateškim ciljevima i, idealno, u stvarnom vremenu. To uključuje sve, od operativnih nadzornih ploča do upravljačkih nadzornih ploča.

U području ljudi, koncepti poput HR analitike ili analize ljudi omogućuju nam da razumijemo utjecaj upravljanja talentima na poslovne rezultate. Uključivanje ovih mogućnosti u evaluaciju pomaže HR-u da igra strateškiju ulogu.

Troškovi, model licenciranja i „sitni tisak“

Prividna cijena softvera rijetko govori cijelu priču . Ključno je pitati što je točno uključeno u osnovni paket, a što se dodatno naplaćuje: podrška, održavanje, ažuriranja, dodatni moduli, dodatna pohrana, integracije itd.

Uspoređivanje ponuda treba provoditi na temelju doživotne cijene rješenja , a ne samo početne cijene. Vrlo jeftin proizvod može vas prisiliti da plaćate svaku malu nadogradnju ili značajke koje uzimate zdravo za gotovo, što značajno povećava stvarnu cijenu nakon nekoliko godina.

Model implementacije također treba preispitati : rješenja na lokaciji nude veću kontrolu, ali zahtijevaju vlastitu infrastrukturu i održavanje; rješenja u oblaku/SaaS-u obično su fleksibilnija, sama se ažuriraju i bolje raspoređuju troškove tijekom vremena.

Ključna je točka razumijevanje kako će se razvijati naknade za održavanje ili pretplatu , postoje li godišnja ograničenja nadogradnje, što se događa prilikom dodavanja korisnika, što se događa ako želite napustiti uslugu i kako se upravlja glavnim nadogradnjama verzija.

Integracije, razvojna platforma i vrsta implementacije

U praksi gotovo nijedna tvrtka ne koristi samo jedan sustav . Normalno je koristiti ih nekoliko: ERP, CRM, rješenja za upravljanje troškovima, HR, alate za analitiku i tako dalje. Zato je ključno da se novi softver dobro integrira s postojećim sustavima.

Vrijedi provjeriti koji standardni konektori postoje , koje API-je nudi proizvođač, dopušta li dvosmjerne integracije i kako se upravlja promjenama kako se integracije ne bi prekidale sa svakim ažuriranjem; a također i koje su opcije dostupne za automatizaciju instalacije softvera u klijentskim okruženjima.

Temeljna razvojna platforma također je važna . Što je prilagodljivija i otvorenija (bez stalnog oslanjanja na prilagođeni razvoj), to će biti lakše prilagoditi sustav specifičnim potrebama tvrtke bez propuštanja ažuriranja.

Proces implementacije treba detaljno raspraviti : faze, rokove, metodologiju (agilnu, vodopadnu, hibridnu), kako će se upravljati pogreškama, koji će se testovi provoditi, kakva će okruženja postojati (razvoj, testiranje, produkcija) i kakvu predanost dobavljač mora preuzeti u tim koracima.

Podrška, korisnička služba i dokaz koncepta

Mnogi projekti ne propadnu zbog samog proizvoda , već zbog kvalitete podrške i smjernica od strane dobavljača ili implementacijskog partnera. Zato je ključno razumjeti koji se kanali podrške nude, njihovo radno vrijeme, SLA i što je uključeno u ugovor o održavanju.

Preporučuje se zahtijevati testno okruženje (besplatno probno razdoblje, sandbox ili kontrolirani pilot) gdje tim može raditi s vlastitim podacima i procesima ograničeno vrijeme. Ovo testiranje pomoći će u validaciji hipoteza i identificiranju potrebnih prilagodbi prije početka testiranja; u nekim slučajevima preporučljivo je implementirati virtualne mreže za testiranje koje simuliraju stvarno okruženje.

Ovisno o složenosti proizvoda , potpuni dokaz koncepta mogao bi biti izvediv samo s jednim od finalista; u drugim slučajevima, mogla bi se testirati dva ili tri. Važno je da svi uključeni odjeli dokumentiraju svoje nalaze i koriste alate za testiranje aplikacija za procjenu stabilnosti i performansi.

Ovi rezultati bit će uključeni u konačnu strukturiranu evaluaciju koja kombinira korisničko iskustvo, funkcionalnu usklađenost, troškove i uočene rizike, utirući put konačnoj odluci i pregovorima o ugovoru.

Pregovori o ugovoru i dugoročno planiranje

Nakon temeljite procjene, obično postoje dvije ili tri opcije koje zadovoljavaju uvjete. Nakon toga, konačni izbor i pregovori o ugovoru postaju ključni kako bi se izbjeglo ugrožavanje budućnosti tvrtke.

Iako pregovaračka moć obično leži u rukama klijenta u ovoj fazi , preporučljivo je dobavljača promatrati kao dugoročnog partnera, a ne kao suparnika kojeg treba pobijediti. Uravnotežen sporazum pruža poticaje objema stranama kako bi se osigurala uspješna provedba.

Ugovor mora detaljno opisati sve relevantne aspekte : licence ili pretplate, hardver ako je primjenjivo, opseg implementacije, troškove pilot-projekta, početnu i kontinuiranu obuku, razine podrške, migraciju podataka, integracije, sigurnost, prilagodbe i upravljanje budućim verzijama.

Također je mudro držati alternativne opcije otvorenima , bez proglašavanja "definitivnog pobjednika" dok se ne riješe svi nedovršeni detalji. Relativno je uobičajeno otkriti iznenađenja u ovoj fazi (skriveni troškovi, ograničenja, neprihvatljive klauzule) koja prisiljavaju na preispitivanje izbora.

Na kraju cijelog ovog procesa, tvrtka neće samo odabrati softver koji odgovara njezinim trenutnim i budućim potrebama, već će steći i neprocjenjivo interno iskustvo u procjeni, odabiru i upravljanju tehnološkim projektima, što će postati sve važnije za održavanje konkurentnosti.

Usvajanje novog sustava uključuje puno više od instaliranja aplikacije : radi se o preispitivanju procesa, koordinaciji područja, upravljanju očekivanjima i pripremi ljudi za drugačiji rad. Kada se pristupi metodično, realizmično i uz sudjelovanje, softver od "obaveznog troška" postaje pravi motor kontinuiranog poboljšanja u tvrtki.