Razprave
Navision in koncept celovitim rešitev z odprto poslovno logiko
Aleš Zaje
Povzetek
Navision Attain je v svetovnem merili! ena od vodilnih celovitih rešitev, namenjenih srednje velikim podjetjem. Hkrati je verjetno tudi najbolj razširjena celovita rešitev, ki uvajalcu skoraj v celoti dovoljuje spreminjanje obstoječe in dodajanje nove funkcionalnosti. Uvajalec, ki nastopa kot partner proizvajalca, ob tem prevzema celotno odgovornost za uspešno dokončanje projekta. V prvem dolu pričujočega prispevka smo analizirali Navision-ov poslovni model, način delitve odgovornosti med proizvajalcem in uvajaIcem ter prednosti tega modela za naročnika. V nadaljevanju smo ocenili prednosti in slabosti tovrstnih rešitev z vidika njihove učinkovitosti. To smo ocenjevali na podlagi ustreznosti nove funkcionalnosti in skupnih stroškov lastništva, med katerimi smo izpostavili stroške uvajalnih storitev in vzdrževanja ter internih resursov. V zadnjem delu prispevka obravnavamo različne vidike uvajanja tovrstnih rešitev, predvsem ustrezen pristop k analizi in dizajnu ter k razvoju novih funkcionalnosti.
Abstract
NAVISION AND THE CONCEPT OF ERP SOLUTIONS WITH OPEN BUSINESS LOGIC
Besides being one of leading ERP solutions for mid-size companies, Navision Attain is probably the most widespread ERP in which the implementing partner is able to change all of the existing and add new functionality using the integrated development environment. On the other hand implementing partner also take s full responsiblity for a successful completion of the Implementation project. In the first part of this article the Navision business model is presented and its advantages for the customer and other stakeholders are discussed. The second part analyses the efficiency of Navision and similar ERP solutions using as criteria the appropriate functionality and total costs of ownership among which costs of implementation services and interna/ resources are the most significant. In the last part of the article different aspects of implementations of Navision and similar ERP solutions are discussed, in particular the design and development of additional functionalities.
1 Uvod
Razvoj strojne in sistemske programske opreme omogoča učinkovito obvladovanje velikega števila podatkov. Večja dostopnost infra strukturne opreme tako tudi srednje velikim in manjšim podjetjem omogoča uvedbo celovitih informacijskih sistemov, t.i. celovitih rešitev (enterprise resource planning, ERP), kr podpirajo celoten ali večji det poslovnega procesa.
V primerjavi s klasičnimi informacijskimi sistemi, ki so namenjeni zgolj podpori na istih standardih temelječem računovodskemu evidentiranju (vsaj v isti državi), se pri podpori celotnega poslovnega procesa soočamo z zelo Širokim spektrom najrazličnejših specifičnih zahtev. Medtem ko je samo računovodstvo primerljivo, pa je organizacija poslovanja odvisna od panoge in velikosti podjetja, zgodovinskih dejavnikov, poslovnega okolja, tehnologije ipd.
Ponudniki celovitih rešitev (predvsem v razredu rešitev za »velike« stranke), sn na specifične zahteve odgovorili s pripravo t.i. »panožnih« rešitev, ki so nastale iz izkušenj (in dograditev), pridobljenih pri uvajanju v posameznih panogah. Večina teh rešitev je
zelo kompleksnih in izhajajo iz razmeroma velikih projektov pri naročnikih s podrobno obdelanimi poslovnimi procesi,
V podjetjih, ki z vidika celovitih rešitev sodijo v t.i. segment srednjih podjetij (za slovenske razmere so to seveda »velika« podjetja z npr, 500 zaposlenimi in 50 Uporabniki sistema ERP), so procesi velikokrat drugače organizirani kot v nekaj desetkrat večjih multi-nacionalkah. »Velike« rešitve ERP se temu prilagajajo /. vnaprej ko n figuri ranimi različicami, ki za ceno nekoliko omejene funkcionalnosti zmanjšujejo kompleksnost potrebne parametrizacije. Nekateri drugi (zlasti manjši in lokalni) ponudniki celovitih rešitev pa so prav segment srednjih podjetij razumeli kot svojo tržno nišo in ponudili manj kompleksne rešitve, ki naj bi pri uvajanju zahtevale manj resursov.
Vendarle pa srednjih podjetij v informacijskem smislu ne gre vedno razumeti kot »pomanjšane« različice velikih. Običajno so podjetja v srednjem segmentu specializirana za določeno storitveno dejavnost ali pa so kot specializirano proizvodno podjetje vpeta v eno ali več preskrbovalnih verig. Gre torej za
2002 Številka 4 - leinik X
iijxmibniAnformatik a 235
Aleš Zaje: Na vi slon In koncept celovitih režitev z odprto poslovno logiko
podjetja, ki pokrivajo določeno tržno nišo in v kateri so uspešna prav zaradi posebnih postopkov in organizacije. Te posebnosti v ključnem delu poslovanja srednjih podjetij pa od celovitih rešitev velikokrat zahtevajo tudi posebej prilagojeno funkcionalnost.
Večina konkurenčnih celovitih rešitev v srednjem segmentu nudi le omejene možnosti prilagajanja in dograditev. Nekatere rešitve (pri nas prilagojena in v Evropi med najbolj uspešnimi je danska rešitev Navi-sion Attain) pa omogočajo prost dostop oz. spreminjanje in dograjevanje celotnega podatkovnega modela in vse poslovne logike. V nadaljevanju bomo analizirali vidike uvajanja tovrstnih rešitev (imenujmo jih celovite rešitve z odprto poslovno logiko), še prej pa bomo v kratkem predstavili za uspešno uvedbo zeio pomembno razdelitev odgovornosti med proizvajalcem in uvajalcem rešitve (partnerjem).
2 Delitev odgovornosti med proizvajalcem in uvajalcem
K širitvi rešitve Navision Attain in njenih predhodnih različic je močno pripomogel poslovni model, s katerim je urejeno »partnerstvo« med proizvajalcem in uvajalcem. Proizvajalec oz. njegov lokalni distributer, ki skrbi za prilagoditev lokalnemu tržišču (običajno je pristojen za eno državo ali za regijo), preprosto proda standardno različico rešitve kot polproizvod uvajalen (Centru za rešitve Navision) po načelu »videno kupljeno«. Morebitne napake v poslovni logiki standardne rešitve se seveda sporočajo proizvajalcu, ki jih odpravi v naslednji različici. Neke vrste »garancijo«za poslovno logiko zagotavlja sistem prodaje, ki od kupca zahteva obvezno doplačilo za brezplačno migracijo na vse v enem letu od nakupa licence izdane različice, v katere so seveda vključeni tudi vsi popravki. Razen pri večjih mednarodnih projektih proizvajalec ne skrbi za nikakršno poprodajno podporo oz. ne prevzema nobene odgovornosti za potek projekta. Le v primeru morebitnega konflikta med uvajalcem in naročnikom posreduje lokalni distributer, ki načeloma varuje interese naročnika in po potrebi uredi sodelovanje z drugim uvajalcem. Prav možnost zamenjave uvajalca močno povečuje varnost naložbe v Navision-ovo licenco, saj v primerjavi z običajnim modelom, kjer je uvajalec kar proizvajalec rešitve (oz, njegov ekskluzivni distributer), naročnik ni odvisen zgolj od enega dobavitelja uvajalnih storitev.
Zaradi prepustitve odgovornosti za celoten projekt lahko proizvajalec uvajalcu brez omejitev prepusti tudi dostop do celotne poslovne logike. Izvajanje sprememb brez »odobritev« proizvajalca po eni strani znatno poceni pripravo morebitne dodatne funkcionalnosti, hkrati pa projekt oz, naročnika močno izpostavi sposobnostim in razpoložljivosti Uvajalske
ekipe. Nakup rešitve Navision lahko torej primerjamo z nakupom MS Access-a z demo »Northwind« bazo. Microsoft je prodal zgolj produkt, odgovornost za končno funkcionalnost pa je na strani razvijalcev oz. uporabnikov.
Pri gradnji partnerske mreže je Navision v začetku izbral izrazito »liberalen« pristop. Vstop v partnerstvo je bil razmeroma preprost in trg naj bi sam izbral boljše ekipe od slabših. S prihodom prve različice Windows se je partnerska mreža začela hitro širiti. Kljub tveganju zaradi minimalne podpore proizvajalca, je bi! namreč Navision ena boljših alternativ za vse tiste ponudnike aplikacij v okolju DOS (npr. rešitev razvitih v Clipper-ju), ki niso zmogli financirati prehoda svoje obstoječe rešitve v okolje Windows in katerih glavni »kapital« je bilo podrobno poznavanje poslovanja nekaj ključnih strank.
V	zadnjih letih se Navision-ov partnerski sistem bolj zapira, saj proizvajalec postopoma viša »vstopni prag«. K temu je posredno pripomogla tudi vse večja kompleksnost rešitve, saj se je npr. obseg vrstic kodo poslovne logike v treh letih več kot podvojil Potrebna specializacija strokovnjakov po vzoru »večjih« rešitev zahteva zadostno velikost uvajalske ekipe. Uveden je bil tudi poseben sistem certifi oranja. Število Centrov za rešitve Navision se je tako nekoliko zmanjšalo, saj se manjši pridružujejo k večjim. Na dovolj velikih »zrelih« trgih se je uveljavila tudi na neki način »naravna« delitev trga po panogah.
Posamezne razvojne ekipe so na podlagi standardne rešitve Navision razvile tudi povsem specializirane pano/ne rešitve, ki le v manjši meri uporabljajo standardno funkcionalnost in katerih dodana vrednost je zlasti v dobro strukturi ranem poslovnem procesu in vanj vgrajenem organizacijskem znanju {»best practice«). Te rešitve lahko uvajajo le posebej usposobljeni Centri za rešitve Navision ali pa sami proizvajalci. Tipični in mednarodno razširjeni tovrstni rešitvi sta Incadea za avtomobilsko servisno in prodajno dejavnost in NaviMeat za mesno predelovalno industrijo.
Zaradi velikega Števila Centrov za rešitve Navision se je razvil tudi trg dodelav (»add-on«), ki podpirajo za splošne ERP rešitve manj pogoste procese. Tako Centri za rešitve Navision tržijo dodelave za leasing podjetja, za podrobno stroškovno računovodstvo, vmesnike /a poročanje davčni upravi ipd. Nekatere od teh dodelav, npr. podporo proizvodnji in .servisu, je Navision odkupil in jih postopno vključil v standardno različico rešitve.
V	Sloveniji so bile razvite predvsem dodatne rešitve, ki dopolnjejo standardno funkcionalnost s podporo lokalnim posebnostim. Tako sta na voljo dve različici obračuna plač, podpora za poenostavljene carinske postopke in carinsko skladišče, slovenski
236 "f*,'"'"'"INF0RMATIKA
2002 številka 4 letnik X
Aleš Zaje: Na vi slon In koncept celovitih režitev z odprto poslovno logiko
praksi prilagojena kadrovska evidenca, lokacijsko skladišče, (sedaj neobvezna) revalorizacija osnovnih sredstev in druge manjše dodelave.
Analizo Navision-ovega poslovnega modela bomo zaključili z ugotovitvijo, da za ponudnike običajnih (»tipskih«) celovitih rešitev posebne zahteve naročnikov v splošnem predstavljajo težavo in odmik od nadaljnjih razvojnih načrtov, medtem ko so za ponudnike celovitih rešitev z odprto poslovno logiko morebitne posebne zahteve naročnikov in lokalne posebnosti predvsem priložnost za trženje lastnih storitev. Razumljivo je, da je običajno funkcionalna ustreznost dobro uvedene celovite rešitve z odprto poslovno logiko boljša od enakemu obsegu poslovanja namenjene »tipske« rešitve PRP, po drugi strani pa se lahko naročnik v prvem primeru sooči tudi z večjimi (in včasih nepotrebnimi) stroški uvajaIskih storitev.
3 Učinkovitost celovitih rešitev z odprto poslovno logiko
Učinkovitost celovitih rešitev poskušamo po eni strani ocenili s skupnimi stroški lastništva, po drugi strani pa / ustreznostjo nove funkcionalnosti.
Na skupne stroške lastništva vplivajo predvsem nakupne cene licenc in morebitne dodatne strojne in programske opreme, stroški uvedbe ter stroški vzdrževanja. Velikokrat pa pozabljamo upoštevati v skupnih stroških lastništva stroške internih resursov podjetja, ki so potrebni za vzpostavitev in delovanje sistema.
3.1 Stroški računalniške opreme
V cenovno primerjavo stroškov licenc se v tem prispevku ne bomo spuščali, saj načeloma proizvajalci (oz. trg) skrbijo za to, da je njihova rešitev glede na zmogljivosti cenovno dovolj konkurenčna, V splošnem pa velja, da je licenca po uporabniškem mestu za rešitve, namenjene srednjim podjetjem, cenejša kot /.a rešitve namenjene velikim. I Ikrati morebitne «posebej ugodne« ponudbe manjših lokalnih ponudnikov kažejo na njihova omejena sredstva za dolgoročni razvoj in s tem na visoko tveganost naložbe v rešitev, ki jo ponujajo,
Prav tako ne bomo analizirali stroškov potrebne infrastrukturne opreme, saj načeloma majhna razlika v potrebni konfiguraciji strežnika dolgoročno ne sme pomeniti ključnega dejavnika pri izbiri celovite rešitve. Seveda pa tudi In velja, da so rešitve namenjene srednjim podjetjem v splošnem glede infra strukturne opreme manj zahtevne od rešitev, ki so namenjene velikim. Hkrati so »svetovne« rešitve z vidika infra-strukturnih zahtev večinoma bolj optimizirane od enakemu obsegu poslovanja namenjenih rešitev manjših lokalnih proizvajalcev.
3.2	Stroški uvajalskih storitev
Stroški zunanjih uvajalskih storitev se običajno ocenjujejo na med 50% in 400% vrednosti izhodiščne licence (odvisno od cene storitev na lokalnem trgu in vrste projekta). Cc k temu dodamo še zelo pomembne a težko merljive stroške notranjih resursov in potencialne stroške neuspešne uvedbe (ponoven proces izbire, omajana avtoriteta vodstva in oddelka informatike) vidimo, da je v splošnem ključna razlika v skupnih stroških lastništva pri konkurenčnih rešitvah prav v stroških »mehkega« dela projekta. Te stroške (tudi potencialne) bomo torej v nadaljevanju upoštevali kot enega od dveh ključnih kriterijev učinkovitosti celovitih rešitev.
Izkušnje uvajanja rešitve Navision v Sloveniji in na Hrvaškem kažejo, da se obseg svetovalnih storitev pri manjših projektih (npr. storitveno ali razmeroma preprosto trgovsko podjetje) giblje med 150 in 500 svetovalnimi urami, V takih implementacijah so prilagoditve seveda omejene bolj ali manj zgolj na »standardne« dodelave, ki jih je uvajalec razvil tudi za svoje ostale stranke. V primeru ustrezne razpoložljivosti kadrov na obeh straneh je čas priprav na začetek dela v živo lahko tudi zelo kratek, od nekaj tednov do dveh ali treh mesecev. Ob tem dodajmo Še, da pogosto znaten del stroškov svetovalnih storitev v »manjših« projektih povzročijo procesi, ki niso ključna dejavnost podjetja, vendar so zahtevni za uporabnike (npr, obvladovanje osnovnih sredstev, obračun plač ipd.).
V primeru zahtevnih uvajanj (storitveno podjetje z veliko dejavnostmi, proizvodno podjetje na več lokacijah in z MRP II planiranjem proizvodnje, povezave z drugimi informacijskimi rešitvami, znaten obseg povsem specifičnih prilagoditev, veliko število uporabnikov) pa je za uspešno dokončanje projekta lahko potrebnih tudi 300 ali več svetovalnih dni. Projekti takega velikostnega razreda v splošnem zahtevajo vsaj pol leta priprav do začetka dela »v živo«, nato pa še enak čas za stabilizacijo obvladovanja procesov z novo rešitvijo. Ti časovni okviri pa se lahko znatno podaljšajo v primerih, ko se v podjetjih posamezni procesi tudi vsebinsko razvijajo šele hkrati z implementacijo nove rešitve.
3.3	Ustreznost
Ustreznost implementirane funkcionalnosti je povezana s samo strategijo informacijske funkcije. Podjetje mora svoje resurse usmerjati na tiste poslovne funkcije oz. njihove dele, kjer je korist od tega največja, Uporaba kompleksne celovite rešitve za podporo klasični prodajni in nabavni funkciji s skladiščem na eni lokaciji in nekaj deset transakcijami dnevno seveda ni smiselna investicija. Pogosto velja, da je bolje v celoti in temeljito uvesti manj zahtevno (in cenejšo) ERP rešitev, kot investirati v nakup kompleksnejše in
2002 Številka 4 leinik X
i ifxmib> ifrf nform ati ka
Aleš Zaje: Na vi slon In koncept celovitih režitev z odprto poslovno logiko
dražje ter ostati brez sredstev za uvedbo kaj več kot le osnovnih funkcionalnosti.
3.4 Prednosti in slabosti z vidika investitorja
Če torej kot ključna kriterija učinkovitosti izberemo stroške uvajalskih storitev in ustreznost nove funkcionalnosti, lahko v primerjavi z drugimi, enakemu velikostnemu razredu podjetij namenjenimi celovitimi rešitvami z Vidika investitorja opredelimo naslednje prednosti in slabosti rešitve Navision, v splošnem pa tudi drugih celovitih rešitev z odprto poslovno logiko:
Prednosti:
1.	Dobra uvajalska ekipa lahko v celovitem razvojnem okolju hitro spreminja vso obstoječo in dodaja poljubno novo funkcionalnost v skladu s specifičnimi zahtevami naročnika {doseči je moč zelo visoko funkcionalno ustreznost).
2.	Odprtost sistema omogoča razmeroma enostaven razvoj vseh potrebnih dodelav, kar je še posebej pomembno na z vidika celovitih rešitev majhnih trgih.
3.	Razvojno orodje je posebej prilagojeno poslovni naravi rešitve, zaradi česar je razvoj specifične funkcionalnosti običajno hitrejši kot v »splošnih« orodjih. Med prednostmi Navision-ovega razvojnega okolja posebej izstopa učinkovito definiranje sumarnih indeksov po prometnih tabelah,
4.	Možno je postopno prilagajanje funkcionalnosti spremembam v podjetju, s čimer je zagotovljeno dolgoročno spremljanje razvoja podjetja;
5.	Uvajanje lahko poteka postopno in z manj tveganja, Zaradi prilagodljivosti rešitve je razmeroma enostavno podpreti z novim sistemom zgolj omejen del poslovnega procesa (npr. glavna knjiga in nabava), preostale podatke pa črpati še iz starega informacijskega sistema. Manjše tveganje posledično pomeni tudi nižje stroške testiranja (vzporednega teka) in s tem nižje stroške internih resursov.
6.	Prilagodljivost sistema omogoča večjo obvladljivost tveganja neuspešnosti projekta (npr. uporabniške zavrnitve sistema) tudi v »slabo organiziranih« podjetjih, kjer management nima ustreznega vpliva na posamezne poslovne funkcije.
7.	V manjših podjetjih je možna »hitra« uvedba, ker se sistem v fazi testiranja sproti prilagaja šele takrat ugotovljenim specifičnim zahtevam.
8.	Dobra povezljivost s drugimi sistemi. Poleg posebne funkcionalnosti za uvoz, izvoz in ustrezno obdelavo podatkov iz drugega sistema je moč v obstoječi podatkovni model in poslovno logiko rešitve Navision vgraditi tudi vse morebitne potrebne referenčne podatke.
Slabosti:
1.	Tveganje neuspešnega razvoja dodelav, ki so ključne za uspešnost uvedbe. Za obvladovanje tovrstnega tveganja je pomembna temeljita in za obe Strani povsem razumljiva specifikacija, z vidika naročnika pa tudi izbira uvajalca, ki razpolaga z ustreznimi vsebinskimi in tehničnimi znanji.
2.	Tveganje nepotrebnega razvoja (in močno povečanih uvajalskih stroškov) zaradi prilagodljivosti rešitve. V primeru neustreznega internega projektnega vodenja ali premajhnih pooblastil internega projektnega vodje, lahko uporabniki na nižjih ravneh v zadnjih fazah uvajanja izsilijo razvoj nepotrebnih funkcionalnosti, saj s tem pogojujejo svoje sodelovanje pri projektu. Uvajalec, ki ima običajno nasproti uporabnikom na nižjih ravneh le omejeno pogajalsko moč, pod Časovnim pritiskom bližnjega pričetka dela v živo »čez noč« razvije zahtevano dodatno funkcionalnost, ki običajno na dolgi rok zahteva preccj popravkov in vzdrževanja. Če je prilagodljivost celovite rešitve manjša in se mora poslovanje prilagajati vgrajeni poslovni logiki, je tovrstno tveganje za investitorja precej manjše.
Povzamemo lahko, da so Navision in druge celovite rešitve z odprto poslovno logiko zelo učinkovite z vidika funkcionalne ustreznosti in so nedvomno tudi stroškovno najboljša izbira v primerih, ko naročnik v analizo možnih alternativ resno vključi tudi lasten razvoj. Iz prilagodljivosti tovrstnih rešitev pa izhajajo tudi ključne slabosti oz. tveganja, ki jih je moč omejiti predvsem z dobrim projektnim vodenjem pri naročniku in z ustreznim operativnim nadzorom poslovodstva nad poslovnimi funkcijami v podjetju. Verjetnost uspešne uvedbe je torej tudi pri rešitvah z odprto poslovno logiko večja v podjetjih z dobro organizacijo in z dobro kadrovsko strukturo ter z jasno definiranimi cilji projekta. Prilagodljivost teh rešitev pa omogoča, da lahko ob večjih naporih uvajaIske ekipe in daljši dobi uvajanja postopno zaživijo tudi v bolj togih in že desetletje nespremenjenih poslovnih okoljih, kjer je uvajanje celovitih sistemov izrazito tvegano.
4 Vidiki uvajanja rešitev z odprto poslovno logiko
4.1 Analiza in dizajn
Uvajanje rešitev z odprto poslovno logiko lahko pomeni zgolj parametrizacijo rešitve v okviru standardne funkcionalnosti (izvzemši prilagoditve izpisov poročil), lahko pa gre za zahteven razvojni projekt, ki se le v omejenem obsegu navezuje na standarno funkcionalnost.
i qxMtbi Kil N FO R M ATIK A
2002 številka 4 - letnik X
/WeS ¿ajc: Navision in koncept celovitih reši lev i odprto poslovno logiko
RazVbj dodatne funkcionalnosti v okviru projekta uvajanja celovite rešitve zahteva tudi ustrezen pristop. Tako imenovana »gap-fit« analiza mora voditi k specifikaciji sprememb obstoječe funkcionalnosti oz. specifikaciji funkcionalnosti, ki jo je potrebno dodatno razviti.
Ključna razlika med običajnimi razvojnimi projekti in razvojnimi projekti v okviru celovitih rešitev z odprto poslovno logiko je vpetost razvoja v obstoječ podatkovni model in logiko. Slednja običajno dovolj dobro pozna zgolj uvajalec, ne pa tudi vodja projekta pri naročniku in investitorji. Tako specifikacija dodelav, ki jo pripravlja uvajalec, ne sme temeljiti zgolj na opisu sprememb oz. dodatkov k podatkovnemu modelu in logiki s tem povezanih procesov, temveč mora nujno definirati funkcionalnost celotnega »novega« sistema, torej »predelane« različice celovite rešitve in po potrebi izrecno navesti tudi funkcionalnosti, ki jih načrtovana rešitev ne bo podprla. Le na ta način se lahko obe strani zadovoljiva zavarujeta pred neugodnimi presenečenji. Še pred pripravo specifikacije (in morda tudi pred sklenitvijo pogodbe) je priporočljivo splošno izobraževanje vodje projekta in izdelava preprostih pilotnih rešitev (še zlasti če je potencialni naročnik pripravljen v to investirati).
4.2 Razvoj
Navisionov podatkovni model in poslovna logika sta zgrajena iz posameznih »objektov«: tabel, form, poročil, objektov za uvoz in izvoz podatkov (»da ta ports«) in objektov s programsko kodo (»code-units«), Ob izdaji novih različic rešitve Navision se spremenita podatkovni model in poslovna logika (struktura tabel in programska koda) v nekaterih, ob menjavi »generacije« rešitve pa celo v večini »objektov«.
Navisionova običajna licenca omogoča naročniku {oz. njegovemu internemu oddelku informatike) dostop do razvojnega okolja in oblikovanje dodatnih tabel, form in poročil. Določeno doplačilo je potrebno le glede na število uporabljenih novih »objektov«. Vso samostojno razvito funkcionalnost lahko naročnik povezuje s standardnim podatkovnim modelom, ki pa ga ne sme spreminjati oz. posegati v poslovno logiko. V primeru tovrstnih žalitev se mora Obrniti na Center za rešitve Navision.
Uvajala (Centri za rešitve Navision) razpolagajo z licenco, ki omogoča tudi poljubno spreminjanje »objektov« standardne rešitve in delo z istim razvojnim orodjem, kot ga uporabljajo tudi razvijalci poslovne logike samega proizvajalca.
Standardna različica rešitve Navision je neke vrste polprodukt. Večji Centri za rešitve Navision projekta namreč običajno ne začnejo s povsem standardno različico, temveč že vgradijo nekatere svoje »običajne«
dodelave, ki so povezane s panogo naročnika ali splošno poslovno prakso, V Sloveniji so takšne tipične dodelave povezane z obračunom DDV, s kompenzacijami, z analitike danih posojil, z gotovinsko blagajno, s poročanjem Banki Slovenije ipd.
Pri razvoju dodatne funkcionalnosti morajo razvijalci slediti naslednjim načelom: m popolne dokumentiranosti vseh posegov v kodo in tabele (v praksi se to izvaja predvsem z obilico komentarjev v kodi in sistemom označevanja sprememb);
■	dodatno funkcionalnost kar najbolj razvijali v ločenih (»lastnih«) objektih in spreminjati standardne objekte zgolj tam, kjer je to nujno potrebno;
■	dodatna funkcionalnost mora čimbolj podpirati vse standardne funkcionalnosti, ki so razpoložljive v celotnem sistemu (npr. stroškovna mesta, tuje valute, vrtanje po sumarnih podatkih ipd.) tudi če njihove uporabe v trenutku dizajna dodatne funkcionalnosti ne pričakujemo (z vidika uporabnika mora biti dodatna funkcionalnost povsem integrirana).
Razvoj funkcionalnosti v ločenih objektih ima za razvijalce več prednosti:
■	manjše tveganje, da »povozimo« ali na nek način narobe uporabimo obstoječo standardno funkcionalnost (razvijalci ne potrebujejo tako podrobnega poznavanja standardne programske kode);
m lažje migriranje na novo različico rešitve (lastni objekti se enostavno uvozijo, spremembe v programski kodi v standardnih objektih pa je potrebno prenesti bolj ali manj ročno);
■	lažje testiranje nove funkcionalnosti.
Tipična značilnost celovitih sistemov je velikansko število možnih sosledij interakcij uporabnikov s sistemom. Enako velja tudi za dodelave in spremembe poslovne logike v odprtih celovitih sistemih. Ob omejenih resursih naročnika in izvajalca je popolno testiranje vseh možnih sosledij interakcij uporabnika s prilagojenim sistemom praktično nemogoče (oz. naročnik običajno tega ne financira). Če se zanesemo na to, da je proizvajalec standardne rešitve ustrezno testiral vso funkcionalnost, potem nam ne preobsežen uporabniški vmesnik nove dodelave in njena strogo omejena interakcija s standardno funkcionalnostjo močno zmanjšata potrebni obseg testiranja.
Eno od najpomembnejših in zelo učinkovitih orodij pri razvoju v Navision-ovem Okolju je sistem »pla vajočih polj« (»flow fields«). Tako lahko npr, saldo v tabeli »konto glavne knjige« definiramo kot sumarno polje vsote postavk na tem kontu, ki so znotraj želenega datumskega obdobja (plavajočega filtra), definiranega na kartici konta. Sistem nam ob prikazu plavajočih polj omogoča tudi vrtanje v globino: dostop do
2002 - Številka 4 - letnik X
upombi i/il n fo-rm ati k a
Aleš Zaje: Na vi slon In koncept celovitih režitev z odprto poslovno logiko
postavk, ki ustrezajo datumskemu obdobju in ki tvorijo saldo. Vmesne salde sistem vodi sproti (kot surname indekse), zato je prikaz in aplikacija filtrov praktično trenutna tudi v veliki zbirki podatkov.
4.3 Povezljivost
Velikokrat naročnik v določenem delu svojega poslovanja že uporablja neko specifično aplikacijo, ki je narejena na podlagi ene od »standardnih« podatkovnih baz. (Oracle a!i MS SQL) in evidentira določene analitične transakcije. Tovrsten primer je npr. sistem za spremljanje borznega poslovanja, ki v bistvu vodi analitično evidenco zalog, terjatev in obveznosti.
Za zagotovitev prave integracije ERP rešitve in dodatnega informacijskega podsistema je poleg samega tehničnega prenosa podatkov {za kar je še posebej primerna verzija Navision-a na MS SQL bazi) potrebno ustrezno prilagoditi tudi poslovno logiko. Tipično je npr. potrebno sporočati dodatnemu podsistemu, katere od postavk terjatev, ki jih je predhodno posredoval osrednji ERP rešitvi se zapirajo z današnjimi plačili. Odprtost Navision-a v takem primeru omogoča vgradnjo referenčnih podatkov za dodaten podsistem v podatkovni model in definiranje ustrezne poslovne logike za te podatke znotraj logike standardnih transakcij knjiženja.
5 Zaključek
NaViSion je verjetno najbolj razširjena celovita rešitev, namenjena srednje velikim podjetjem, ki temelji na konceptu odprte poslovne logike. Uvajalcc, ki nastopa kot lastniško neodvisen partner proizvajalca, po eni strani prevzame celotno odgovornost za uspešno dokončanje projekta, po drugi strani pa dobi dostop in možnost spreminjanja in dograjevanja celotnega podatkovnega modela in poslovne logike, za kar ima na voljo tudi posebno finančnim aplikacijam prilagojeno razvojno orodje.
Učinkovitost rešitve Navision in podobnih ERP rešitev smo ocenjevali na podlagi ustreznosti uvedene funkcionalnosti in skupnih stroškov lastništva, med katerimi Smo izpostavili stroške uvajalskih storitev in vzdrževanja ter internih resursov. Ob tem smo pou-
darili, da poslovnih procesov v srednjih podjetjih zaradi njihove vse večje specializiranosti in vpetosti v poslovno okolje ne gre več razumeti zgolj kot pomanjšane različice procesov v velikih podjetjih, iz česar izhajajo Itidi povsem specifične funkcionalne zahteve.
Ugotovili smo, da so Navision in druge celovite rešitve s povsem odprto poslovno logiko zelo učinkovite z vidika ustreznosti in zmožnosti uvajanja 1er so verjetno najboljša alternativa v primerih, ko naročnik razmišlja tudi o razvoju lastne rešitve. Iz prilagodljivosti tovrstnih rešitev pa izhajajo tudi ključne slabosti oz, tveganje, ki ga je moč omejiti predvsem z dobrim projektnim vodenjem na strani naročnika in izvajalca ter z ustreznim operativnim nadzorom poslovodstva nad poslovnimi funkcijami v podjetju. Za učinkovito uvedbo mora biti naročnik dobro organiziran in imeti ustrezno kadrovsko zasedbo ter jasno definirane cilje projekta. Hkrati pa velika prilagodljivost tovrstnih rešitev omogoča, da lahko ob večjih naporih uvajalske ekipe in daljši dobi uvajanja postopno zaživijo tudi v bolj togih in že desetletje nespremenjenih poslovnih okoljih.
Reference
1.	Kindermann TCV GmbH:
Ex perte nwtssen zu Navision Financials. SPC Le h r bue h Verlag, Berlin, 1999.
2.	Navision a/s:
Navision Attain Essentials. Navision a/s, Vocdbek, 2001.
3.	Akkermans, Henka A.;
The impact of ERP on supply chain management: exploration findings from a European Delphi study. Fontainbleau: 1NSEAO, 1999.
4.	Ahlin Tomai:
Uvajanje celovitih programskih paketov. Organizacija, letnik 34, št. 5 (maj 2001) Str. 283-289.
5.	Ptak, Carol A.
ERP: tools, techniques and applications for integrating the supply chain. St. Lucie Press, Falls Church, 2000. 424 str.
6.	Donovan Mike:
Why the Controversy over ROf from ERP? h tt p :/Aww. rm do n ova n, com.
7.	Mello Adrian:
ERP Fundamentals, http://techupdate-zdnet.com
8.	Harold Dave:
How Manufacturing Benefits by Understanding ERP and IT. hllp^/techupdate-zdnet.com
*
Mag. Aleš Zaje je diplomiral leta 1996 in magistriral leta 1999 na Ekonomski fakulteti v Ljubljani, kjer je asistent na katedri za računovodstvo. V času študija seje izpopolnjeval tudi v tujini. Od leta 2000 je zaposlen v podjetju Adacta programska oprema d.o.o. kot direktor področja »Poslovne rešitve«. Aktivno je vodil več vsebinsko in razvojno zahtevnih projektov uvajanja rešitve Navision v Sloveniji in v tujini.
♦
i tfxïnibi ml NFQ RM AT IKA
2002 - številka 4 - letnik X