Saját termék — önkormányzatok, városok és társulások
MuniPass — lakossági parkolás és bérletkölcsönzés önkormányzatoknak
A parkolási engedély egyszerre döntés egy kontingensről, fizetési ügylet, és olyan válasz, amire az utcán másodpercek alatt szükség van. A MuniPass ezt a hármat ugyanazokon az adatokon tartja össze — mellette pedig viszi ugyanannak az önkormányzatnak a bérletkölcsönzését.
A feladat
A parkolási engedély űrlapnak néz ki, és egyszerre három dolog: döntés arról, hány engedély juthat egy címre; fizetési ügylet, amelyben az önkormányzatnak kell a kedvezményezettnek maradnia; és felvilágosítás, amire a közterületi ellenőrnek a szélvédőnél másodpercek alatt szüksége van. A hivatali gyakorlatban ez a három külön rendszerben van — vagy egyikben sem.
A megoldás
A címkontingenst a hatósági épület- és lakásnyilvántartás, valamint a szövetségi címadatok ellen ellenőrizzük, nem egy kézzel begépelt sor ellen. A fizetés az önkormányzat saját acquirer-szerződésén megy, így a MuniPass egyetlen ponton sem kedvezményezett; az ismétlődő díjakból SEPA-beszedési fájl készül a hivatal saját netbankjához vagy a k5-höz. A helyszíni ellenőrzés külön képernyő, külön szerepkörrel, amely pontosan egy kérdésre felel.
Az eredmény
Az engedély, a fizetés és az ellenőrzés ugyanazokon az adatokon függ: aki ellenőriz, nem lát lakcímet, aki pedig igényel, nem számol utána kontingenst. A parkolási modul elkészült, és bevezetésre kész.
Közelebbről
Aki lakossági parkolást vezet be, ritkán egy problémára vesz szoftvert. Háromra veszi, és ez a három egymás útjában áll.
Az első hatósági döntés. Hogy egy címre hány engedély juthat, az címenként egy szám — és a gyakorlatban éppen a cím az, ahol ez elromlik. A MuniPass ezért a hatósági épület- és lakásnyilvántartás, valamint a szövetségi címadatok ellen ellenőriz, nem az ellen, amit valaki begépelt egy mezőbe. Ha a kontingens elfogyott, azt az alkalmazás megmondja, mielőtt bárkinek utána kellene számolnia; az igénylés pedig még nem engedély, hanem elbírálásra vár a hivatalban, és az elutasítás az ügyiratban viszi az indokolását.
A második a pénz, és itt van az a döntés, amely a terméket a leginkább
meghatározza. Az acquirer-szerződés az önkormányzatnál marad — a MuniPass
soha nem kedvezményezett. Ezt kényelmetlenebb megépíteni, mint a szokásos utat,
ahol a platform beszed és továbbutal, és egy közintézmény számára ez az egyetlen
út, amely mellett a polgárok letétben tartott pénzének kérdése fel sem merül. Az
ismétlődő díjak SEPA-beszedéssel mennek: az alkalmazás pain.008 formátumú
beszedési fájlt állít elő, amelyet a hivatal a saját netbankjába vagy a k5-be
tölt fel. Az első és az ismétlődő beszedés külön blokkban áll, mert a bank
másként dolgozza fel őket, és a fájl két sémaverzióban készül, mert ezt a bank
dönti el, nem mi.
A harmadik az utcán történik, és másodpercekig tart. Egy képernyő pontosan egy kérdésre felel — állhat-e itt ez a jármű? — rendszám, engedélyszám vagy a rányomtatott QR-kód alapján. A közterületi ellenőrök ehhez saját szerepkört kapnak, amely kizárólag ezt a képernyőt látja: se foglalásokat, se tagságokat, se lakcímeket. Az adattakarékosság itt nem beállítás, hanem maga a szerepkör meghatározása. Ha egy engedély két járműre szól, az autóban lévő NFC-címke váltja az érvényes rendszámot — elég hozzáérinteni, kamera és bejelentkezés nélkül —, és minden váltás időponttal naplózódik.
A bérletkölcsönzés, amellyel a platform indult, második modulként megmaradt mellette. Annak az önkormányzatnak, amelyik három Klimaticketet birtokol és kikölcsönzi a lakosainak, nincs szoftverproblémája — a második, ugyanarra a hétre érkező kérésig. Nyilvános naptár mutatja a tényleges szabad kapacitást, az átadást és a visszavételt aláírható PDF dokumentálja, a várólista pedig a felszabadult napot automatikusan felajánlja a következő igénylőnek.
Az, hogy mindkét modul ugyanazon a több-bérlős platformon fut, nem technikai öncél. Minden önkormányzat saját arculattal, saját logóval és színnel jelenik meg — mert az önkormányzat szolgáltatása nézzen ki az önkormányzatnak, ne egy szolgáltatónak.