Če citiram g. Mlakarja v odličnem komentarju (http://tvslo.si/predvajaj/studio-city/ava2.104254582/): »zakoni, ki so ali slabi, jih ni, se jih ne izvaja, ali pa so pisani kot blagodejno mazilo na kožo enih ter kot udarec z bičem na kožo drugih«. ZPrePN je primer takega zakona. Že 27.1.2011 (!) smo opozarjali na njegove pomanjkljivosti (http://www.finance.si/301153/Pro%E8-s-skrpucalom) pa nič. Niti en predlog upoštevan.
Danes vidimo rezultate. V prisilnem pobotu je sodelovalo 16-krat več podjetij kot pred enim letom. Prijavila so 7-krat več obveznosti in jih 8-krat več zaprla (vir:
www.ajpes.si). Kaj takoj ugotovimo:
1. Vsaj polovica podjetij je oddajala brez učinka (kar kaže razpolovitev uspešnosti). Torej je to zanje nepotreben dodaten strošek, kar pomeni, da bi bilo obveznost potrebno pametno zamejiti.
2. Odstotek uspešnosti se ni bistveno spremenil (delež nad priznanimi je padel za 1,5%, med vsemi narastel za 1,2%) kar je v nasprotju s pričakovanjem, da če v sistem vključiš več deležnikov, uspešnost naraste. Tule smo vzorec iz 2% gospodarskih družb dvignili na 26% z linearnim povečanjem deleža zapiranja! To pa pomeni samo da:
a. Nelikvidnost ni notranja – denarja v sistemu preprosto primanjkuje in noben pobot ne pomaga.
b. Da so ponori denarja skupni večini podjetij. Stavim na obveznosti države in gradbenega sektorja. Zanimivo bi bilo analizirati konce verig, a prepričan sem, da je bila nevključitev države (vključno z DDV in drugimi davki) kardinalna neumnost. Razen, jasno, če se insolventnost tu namerno zakriva.
c. Absolutno ne drži trditev Ministrstva za finance, da je zakon napisan, ker je gospodarstvo nemoralno in ne plačuje.
Koliko je ZPrePN gospodarstvo stal, lahko le ugibamo. Poleg pribl. 89,000€ prihodkov AJPES-u verjetno nekaj milijonov za pripravo programske opreme ter po moji oceni pribl. 3-10 mio € notranjih stroškov v računovodstvih.
Pa poglejmo, kaj je ta nebodigatreba povzročil nam. Če smo želeli narediti varno rešitev (glede na zagrožene kazni edina prava možnost), smo morali integrirati kompenzacije, račune in DDV modul. Brez avtomatizacije in povezanosti je možnost napak in količina ročnega dela prevelika. Poglejmo zgodovino izdaj: dva kritična builda: najprej 11.4. (na polovično uganjene pravilnike), popravek za prijavo terjatev v 555201 (rok oddaje 15.4.), nato še 19.4. izid 555202 s popravkom DDV (rok oddaje 30.4.). Kdaj so izšli pravilniki, vemo vsi. Preko 10 človek/mesecev (pribl. 120,000€, pribl. 8% celotnega letnega razvojnega budgeta!) je in še bo stala prilagoditev na to neumnost. To me jezi.
Še bolj me jezi, ker nam je kratek rok za implementacijo večinoma porušil načrt razvoja in zato stojijo že davno obljubljene izboljšave. Podjetjem ne dajejo tistega, kar potrebujejo za dvig produktivnosti, ker razvijamo nekaj, kar bo povečalo birokracijo v okolju. Bravo naši.
Najbolj me pa jezi, ker smo več kot leto izboljševali stabilnost, zmanjševali število napak, končno začeli spodjedati »strah pred nadgradnjo«. In bum, tresk – 55.52.xx ima napake na kritičnih funkcijah (carina, naročila idr.). V prejšnjih verzijah so bile napake manj opazne in boleče, saj smo pretežno čistili redko uporabljane funkcije, osnova pa je bila večinoma stabilna.
Kratek rok (včasih krajši od celotnega avtotestnega cikla), nedefiniranost, globina spremembe (praktično smo morali odpreti tri module!) ter »sprememba med letom« že začetih sprememb = ubijalski koktejl.
In spet se opravičujemo zaradi napak in smo vsi v razvoju na overburnu. MF, hvala za naše ne-praznike, upam da ste uslužbenci uživali na prigaranem dopustu. In nas je pošteno sram, ker v že tako težki situaciji povzročamo težave podjetjem še sami. Prizadevanja več kot dveh let dela celotne ekipe načeta z enim buildom ...
Ko smo analizirali, zakaj, je Matt (neumorni zagovornik uporabnikov) postavil vprašanje: »Kako bi se odločil, če bi moral še enkrat sprejeti isto odločitev:
a. Uporabil bi druge ljudi.
b. Ne bi dovolil bližnjic pri testiranju. Tudi če to pomeni pozen izid, saj je bolje pozno in stabilno.
c. Opusti vse nove izboljšave in se fokusiraj samo na zakonske probleme, ne glede na prelomljene obljube in razočaranja pričakujočih uporabnikov.«
Razmišljal sem in ne najdem pametne rešitve.
a. ne pride v poštev, saj menim da se ekipa res trudi in da glede na razmere čara. Bi jo pa z veseljem dopolnil, da bi imeli redundanco.
b. zaradi kratkih časovnih rokov in zunanjih faktorjev ni mogoče. 15.4.2011 je bil prvi pobot in z njim izguba vstopnega DDV. 30.4.2011 je bil rok za oddajo DDV. Glede na pozno pridobljene specifikacije mislim, da je bilo bolje stestirati, kar se je dalo, izdati in dati s tem 90% podjetjem možnost pravočasne izpolnitve zahtev.
c. smo morali narediti: dejstvo je, da večino najbolj motečih napak izhaja iz modulov, kjer so bile načrtovane, a zaustavljene izboljšave. Zaradi abruptne preusmeritve fokusa na zakonsko spremembo so določeni konci ostali nezavezani.
Verjetno bi se odločil enako. A takega releasea ne smemo ponoviti. V tej blaznosti moramo ostati zanesljiv in do uporabniškega dela spoštljiv partner. Edina rešitev je povečanje razvojne ekipe, da bomo lažje amortizirali take špice. Še sploh, ker nas čez 8 mesecev čaka fiskalizacija, vmes pa še bog-si-ga-vedi kaj. Izbljšave bodo tudi v prihodnosti pravočasno izdane, a bomo imeli stand-by ekipe. To je bila moja napaka, ker sem celotno podjetje pozval, da po napornem delu izkoristijo priložnost za daljši dopust in rekonvalescenco. Zanjo se vsem prizadetim opravičujem, dežurnim pa zahvaljujem! V primeru nenapovedane zaustavitve razvoja na določenem delu bomo le-tega dodatno testirali.
Pa smo se spet nekaj naučili. Šta ne ubija – jača :)
Vaši komentarji dobrodošli na Forumu.
Naj vam PANTHEON služi!
Andrej Mertelj
Izvršni direktor