A gazdasági helyzet miatt sok országban változnak a jogszabályok (és az adózás). A meglévő alkalmazásaink számára ezek a változások rémálommal érnek fel: rövid idő alatt kell egy olyan változást végrehajtani, ami mögött nincs üzleti érték, nincs budget, viszont a határidő kőbe vésett.
A gazdasági helyzet miatt sok országban változnak a jogszabályok (és az adózás). A meglévő alkalmazásaink számára ezek a változások rémálommal érnek fel: rövid idő alatt kell egy olyan változást végrehajtani, ami mögött nincs üzleti érték, nincs budget, viszont a határidő kőbe vésett.
Hogyan lehet ezt mégis kezelni?
A legfontosabb a megelőzés! Vagy álljon rendelkezésre az alkalmazásaink forráskódja és a megfelelő erőforrások, vagy pedig az alkalmazásunkat támogató külső partner szerződésében külön pontként említsük meg a törvényi változásokat.
A legegyszerűbb megoldás az, ha a törvényi változások követése a támogatás része, azaz ingyenes. Miért is jó ez?
Mert amikor bekövetkezik a baj, akkor már késő lesz pénz után szaladgálni, és persze nem is terveztük az eseményt előre.
Az informatikai partner számára viszont a változás feltehetőleg nem nagy dolog, jó esetben csak egy táblában vagy konfigurációs fájlban kell átírni valamit. Jobb esetben ugyanazt a szoftvert más cégek is használják, tehát a partner elvégzi a munkát egyszer, és azt minden ügyfele megkapja.
A módszer további előnye, hogy a változást az fogja kivitelezni, aki pont az ilyen feladatokra specializálódott - egy könyvelési szoftver esetén logikus, hogy az azt fejlesztő cégtől várjuk el a megoldást az áfa változásra.
Hogyan néz ki egy ilyen projekt?
A törvényi változásokat a hagyományos változás kérelem folyamatba kell beilleszteni, azzal a különlegességgel, hogy ezeknél nincs ROI vagy NPV számítás - a munkát el kell végezni és kész. A rövid határidők miatt ezek rendszerint azonnal magas prioritásúak.
A változtatás elindítója és gazdája a megfelelő üzleti funkció, azaz pl. áfa változás esetén az adó manager vagy a pénzügyi igazgató. NEM az informatika. Az informatika csak végrehajtja a változtatást, úgy ahogyan az üzlet kérte.
Semmiképpen nem várható el, sőt hibás is lenne, ha az informatika önállóan vagy proaktivan kezelné ezeket. Már csak azért is, mert a megfelelőség nem mindig triviális.
A változás elkészítését természetesen az üzleti funkciónak ellenőriznie és jóváhagynia kell, és a törvény életbe lépésének napján az új szoftvert telepíteni kell. Szerencsére ezek a változások nem olyan nagyok, hogy az élesbe tétel gondot okozni.
Mire érdemes odafigyelni?
Egyrészt arra, hogy az üzlet legyen teljesen tisztában a részletekkel, és legyenek kész válaszai. Semmiképpen ne az legyen a válasz, hogy „ott a web site, olvassátok el és csináljátok meg".
A törvényi változásoknál a legnagyobb trükk a historikus adatok kezelése szokott lenni. Pl. az áfa kulcs 20%-ról 25%-ra emelkedik egy adott naptól. De mi van a korrekciós számlákkal, amelyek egy múltbeli számlára hivatkoznak? Mi van akkor, ha hibásan lett a múltban kiállítva egy számla, és „bele kell nyúlni" a rendszerbe? Az „adott nap" a számla kiállításának dátumára, vagy az árú szállításának napjára vonatkozik-e?
E kérdések egyszerűnek tűnhetnek, és egy áfa változás önmagában véve nem bonyolult, de nem csak az áfa tud változni. Szóval kell egy szakértő, aki érti a változást, van elképzelése az új üzleti folyamatról, és válaszokat tud adni.
Mi a teendő, ha a jogszabályi változás „túl nagy", több osztályt érint, és value stream folyamatokat érint?
Hagyni kell, hogy az érintett osztályok kidolgozzák az elvi megoldást. Nem szabad hagyni, hogy az informatika legyen a probléma gazdája, vagy hogy a megoldást az informatikától várják. A megoldás csakis az lehet, hogy az érintett osztályok előbb kidolgozzák az új folyamatokat, részletesen leírják a változáskérelmet, és rendbe teszik az összes homályos részletet.
Mi a teendő, ha a változásra túl későn figyelt fel a cég, és már „ketyeg az óra"?
Akármennyire is ég a talaj, az ilyen szituációt nem az informatikának kell megoldania. Ha a cég szoftverei nem felelnek meg egy törvényi előírásnak, az alapvetően nem informatikai hanem üzleti probléma. Amíg a változáskérelem nincs rendbe szedve, addig a labda az üzleti oldalon pattog - és a felelősség is ott van.
Mi a teendő, ha a nagy multinacionális cégünk fejlesztőközpontja nem akarja figyelembe venni a kis közép-kelet-európai ország jogszabályait?
Eszkalálni. A törvényeknek való megfelelés, a törvényi változások követése nem méret vagy döntés kérdése. Csakis két lehetőség van: megfelelni, vagy kivonulni az adott országból. Lehet hogy a piac mérete nem áll arányban a törvények komplexitásával (nyugati országok = nagy piac + egyszerű jogszabályok, kelet-európai országok = kis piac + bonyolult szabályok), de mint már említettem itt nincs helye ROI számításnak. Amíg a vezetőség nem dönt úgy, hogy kivonul az adott piacról, addig vitának helye nincs.
Utolsó kommentek