---

I. Bevezetés

Egy középvállalkozás számára a munkaidő-nyilvántartó rendszer elengedhetetlen a modern, digitalizált környezetben. Az automatizált adatrögzítés és feldolgozás csökkenti a humán erőforrás adminisztratív terheit, miközben pontosabb és konzisztens információt biztosít – feltéve, hogy a rendszer megfelelően van megtervezve és felépítve. A piacon számos szoftver érhető el eltérő funkcionalitással és árazással, azonban egy vállalat egyedi szabályokat alkalmazhat, és speciális riportokat igényelhet. Az előre elkészített szoftverek ilyen esetekben költségesek lehetnek, ráadásul gyakran tartalmaznak olyan funkciókat is, amelyek nem relevánsak az adott cég számára. Ezek a tényezők indokolhatják, hogy egy szervezet saját, testreszabott munkaidő-nyilvántartó rendszert fejlesszen.

Fontos kiemelni, hogy komplex rendszerekről van szó; az Excelben vagy Access-ben vezetett jelenléti ívek nem minősülnek munkaidő-nyilvántartó rendszernek. Ilyen rendszernek tekinthető minden alkalmazás, amely a vállalat munkavállalóinak belépéseit és kilépéseit rögzíti, ezekből számított riportokat, például időtáblákat generál, kezeli a hiányzásokat és a szabadságokat, valamint lehetővé teszi a műszakbeosztások kialakítását. A különböző riportok és hatékonysági mutatók általában azok a pontok, ahol az egyediség és komplexitás eléri azt a szintet, hogy saját fejlesztésű megoldás indokolt.

Bár elsőre a feladat egyszerűnek tűnhet – belépések és kilépések rögzítése, majd ezekből a legdolgozott idő kiszámítása –, a valóság sokkal összetettebb. A műszakbeosztások, az éjszakai műszakokhoz tartozó nap-eltolások, a többszörös belépések, a különböző terminálokhoz kötött munkaidők, valamint a manuális korrekciók mind olyan tényezők, amelyek jelentősen növelhetik a rendszer komplexitását. Ezek a részletek csak a rendszer specifikációjának alapos feltérképezése után válnak láthatóvá.

A cikk nem egy demo alkalmazás bemutatására törekszik, hanem valós, üzleti környezetből származó tapasztalatokra épít. A cél a rendszer strukturális felépítésének, a rétegek és azok felelősségeinek, valamint az adatkezelési döntéseknek a bemutatása. Egy munkaidő-nyilvántartó rendszer jellemzően integrálódik más rendszerekkel, például HR rendszerekkel, beléptető terminálokkal és jogosultságkezeléssel. Ezért elengedhetetlen a stabil architektúra, amely biztosítja a rendszerek közötti együttműködést.

A cikk nem egy konkrét technológia bemutatására fókuszál, hanem arra a gondolkodásmódra, amely az üzleti szabályokból kiindulva vezeti le egy rendszer felépítését.

Első lépésként a funkciók és a felelősségi körök tisztázása szükséges.

---

2. Funkcionális bontás

Ebben a fejezetben áttekintjük a munkaidő-nyilvántartó rendszerek tipikus funkcióit. Később bemutatjuk, hogy ezek mely rétegekhez kapcsolódnak.

A rendszer működéséhez először adatgyűjtésre van szükség. Munkaidő-nyilvántartó esetében ezek jellemzően beléptető terminálok, amelyek az eseményeket adatbázisba rögzítik. Ezek az adatok gyakran külső, read-only adatbázisban tárolódnak, különösen, ha a terminálokat külső beszállító biztosítja. Alternatív megoldás lehet API vagy CSV import. A cikk példájában a nyers adatok egy külső adatbázisból érkeznek, amelyet a továbbiakban csak külső adatbázisnak nevezünk.

Szükség van továbbá egy belső adatbázisra is, amely a cég egyedi igényeit szolgálja ki. A belső adatbázis típusa független a külsőtől: példánkban a külső adatbázis SQLite, a belső MySQL. Az architekturális rétegezés biztosítja, hogy ez ne legyen a rendszer számára problémás. A Datamanagement réteg felel a két adatforrás integrációjáért és az eredmények visszaadásáért.

A normalizálás során a nyers adatokat megtisztítjuk, párosítjuk, hibás adatokat kezelünk, duplikációkat szűrünk. Az ömlesztett adatok feldolgozását szintén a Datamanagement réteg végzi.

A rendszerben alkalmazott üzleti szabályok lehetnek általánosak vagy egyediek, például:

• Műszakbeosztások kezelése
• Szabadságok és hiányzások nyilvántartása
• Áthelyezések rögzítése

Az üzleti szabályok végrehajtását az Application Service és a Repository réteg biztosítja.

A következő lépés a riportálás, például időtáblák, hatékonysági mutatók és összesítések készítése. A riportokat a felhasználó felé kell megjeleníteni vagy letölthető formátumban biztosítani. Ez az UI/Controller réteg feladata.

Az adminisztrációs funkciók szabályozzák az adatokhoz való hozzáférést. A legtöbb vállalkozás hierarchikus jogosultságkezelést alkalmaz, például RBAC (Role-Based Access Control). Így biztosítható, hogy egy alacsonyabb szintű vezető csak a saját szintjéhez tartozó adatokat lássa, míg az írási jogok csak a megfelelő felhasználóknál legyenek. Az adminisztrációs feladatok a UI, Application Service és Repository rétegek együttműködésével valósulnak meg.

Összefoglalva, ebben a fejezetben áttekintettük a tipikus funkciókat és azok rétegekhez való kapcsolódását. A következő fejezetben a rétegeket mutatjuk be részletesen.

---

3. Üzleti nyelv és felelősségi határok

Ebben a fejezetben egy munkaidőnyilvántartó rendszer felépítését mutatom be üzleti nézőpontból.
Nem technológiákról, nem adatbázisokról, hanem felelősségi határokról lesz szó: arról, hogy egy rendszer mely része milyen kérdésekre válaszol. Ez a fajta rétegezés nem technikai, hanem üzleti felelősségek mentén történik, ahol minden réteg egy-egy jól körülhatárolt szerepet kap az üzleti nyelv használatában.

A részletes technikai megvalósításokat és mintákat későbbi cikkekben tárgyalom. Itt a cél az, hogy üzleti nyelven érthető legyen, hol születnek a döntések.

3.1. Presentation réteg – „Mit akar látni a felhasználó?”

A Presentation réteg azt a kérdést válaszolja meg, hogy mit és milyen formában szeretne látni a felhasználó. Ez a réteg felelős a megjelenítésért és az interakcióért, nem a számításért.

Itt adja meg a felhasználó például:

• az időszakot,
• a bontás módját (napi, havi),
• a szervezeti szűrőket (költséghelyek, területek),
• a besorolásokat (szellemi, produktív).

Fontos hangsúlyozni: a Presentation réteg nem hoz üzleti döntéseket. Nem tudja, mi számít jelenlétnek vagy hiányzásnak — csak megjeleníti azt, amit a rendszer már eldöntött.

A feladata:

• eredmények megjelenítése (táblázat, lista),
• exportálás,
• felhasználói beállítások kezelése.

3.2. Application Service réteg – „Mi történik most?”

Ez a réteg az üzleti műveletek menedzsere. Azt határozza meg, hogy milyen lépésekből áll egy folyamat, és milyen sorrendben kell azokat végrehajtani.

Például:

• egy havi munkaidő-riport elkészítése,
• egy adott időszak összesítése.

Az Application Service:

• összeállítja a szükséges adatokat,
• meghatározza a folyamat lépéseit,
• kijelöli a tranzakciók határait.

Ami nagyon fontos: nem hoz üzleti döntéseket. Még itt sem dől el, mi számít jelenlétnek vagy hiányzásnak — ez nem ennek a rétegnek a feladata.

3.3. Domain réteg – „Mit jelent ez a cég számára?”

A Domain réteg a rendszer üzleti magja. Itt születnek meg azok a döntések, amelyek egy adott cég szabályozását tükrözik.

Ebben a rétegben dől el például:

• mi számít jelenlétnek,
• mi minősül hiányzásnak,
• hogyan kell kezelni a kivételeket.

Jellemző domain szabályok egy munkaidőnyilvántartó rendszerben:

• műszak- és szalagbeosztások,
• munkaközi szünetek,
• speciális vagy egyedi esetek kezelése,
• szabályozások értelmezése.

Ez a réteg nem tud adatbázisról, képernyőről vagy riportformátumról. Csak azt tudja, hogy mi a helyes döntés a cég szabályai szerint.

Ebben a megközelítésben a Domain réteg hordozza azt a közös üzleti nyelvet és szabályrendszert, amely köré az egész rendszer szerveződik. Ez a központi szerep az, ami miatt a domain nem egy technikai részlet, hanem a rendszer szíve. Az üzleti szabályok és folyamatok központi szerepe a Domain rétegben illeszkedik Evans által leírt ‘Ubiquitous Language’ szemléletéhez, ahol minden fogalom a domainből származik. [1]

3.4. Infrastruktúra – „Honnan származik az adat?”

Az infrastruktúra feladata az, hogy a rendszer számára forrásadatokat biztosítson. Ezek az adatok több, egymástól független rendszerből érkezhetnek.

Tipikus adatforrások:

• beléptető kapuk,
• kártyaolvasó terminálok,
• külső HR rendszerek,
• adminisztratív rögzítések.

Az infrastruktúra nem hoz üzleti döntéseket, és nem is ismeri a szabályokat. A feladata kizárólag az, hogy az adatokat elérhetővé tegye a rendszer számára.

---

4. Rétegek bemutatása egy minta folyamaton keresztül

Ebben a fejezetben egy havi időtábla elkészítésének folyamatán keresztül mutatom be, hogyan működnek együtt a korábban bemutatott rétegek. A cél nem az implementáció részleteinek bemutatása, hanem annak szemléltetése, hogy hol születnek döntések, és hol nem.

A következő példa jól mutatja, hogyan válik egy üzleti kérdésből (egy havi időtábla elkészítése) lépésről lépésre egy végrehajtható folyamat, miközben az üzleti szabályok végig a domainben maradnak.

A folyamat a Presentation rétegben indul. Amikor a felhasználó elindítja az alkalmazást, ez a réteg jeleníti meg a felhasználói felületet: menüket, szűrőket, kiválasztási lehetőségeket. A felhasználó itt adja meg például, hogy:

• melyik hónap adataira kíváncsi,
• mely szervezeti egységek időtábláját szeretné látni

Amikor a felhasználó elindítja a lekérést, a kérés átkerül az Application Service réteghez.

Az Application Service réteg feladata ebben a folyamatban az, hogy összeállítsa a havi időtábla elkészítéséhez szükséges lépéseket. Meghatározza:

• milyen adatokra van szükség,
• honnan kell azokat beszerezni,
• milyen sorrendben történjen a feldolgozás.

A havi időtábla elkészítéséhez jellemzően az alábbi adatok szükségesek, amelyek különböző forrásokból érkeznek:

• dolgozók adatai: HR rendszer
• események: beléptető kapuk, kártyaolvasó terminálok
• műszak- és szalagbeosztások: adminisztrációs rögzítések
• távollétek: adminisztrációs rögzítések

Az Application Service réteg nem értelmezi ezeket az adatokat, és nem hoz üzleti döntéseket. A begyűjtött adatokat az üzleti folyamat logikája szerint továbbadja a Domain rétegnek.

A Domain réteg alkalmazza a cég munkaidő-nyilvántartásra vonatkozó szabályait, és elvégzi a szükséges számításokat. Itt dől el például:

• mi számít jelenlétnek és mi hiányzásnak,
• hogyan kell kezelni a késéseket vagy a korai távozást,
• hogyan befolyásolják a munkaközi szünetek a ledolgozott időt.

Egy havi időtábla esetén tipikus eredmények:

• nettó és bruttó ledolgozott idő,
• jelenlét és távollét minősítése,
• munkakezdés és munkabefejezés a műszakbeosztáshoz viszonyítva.

A Domain réteg a számítások eredményét visszaadja az Application Service rétegnek.

Az Application Service réteg az egyes részeredményeket egységes struktúrába rendezi, majd az elkészült eredményt továbbítja a Presentation réteg felé. A Presentation réteg a havi időtábla adatait a felhasználó számára jól értelmezhető, táblázatos formában jeleníti meg, és lehetőséget biztosít az exportálásra különböző formátumokban.

A rétegek szétválasztása védi a domain logikát, amit Fowler is ajánl a komplex üzleti rendszerek esetén. [3]

Ez a példa jól mutatja, hogy egy munkaidőnyilvántartó rendszer központi eleme a riportok előállítása. A rendszer valódi értéke abban rejlik, hogy az üzleti szabályok következetes alkalmazásával megbízható, értelmezhető kimutatásokat készít. A következő fejezetben részletesebben is kitérek a riportálás szerepére és jelentőségére.

---

5. Riportok, mint üzleti termékek

Az előző fejezetek bemutatták, hogyan érdemes egy munkaidőnyilvántartó rendszert felépíteni, és milyen rétegek mentén érdemes elválasztani a felelősségeket. Ebben a fejezetben arra a kérdésre keresünk választ, hogy miért tekinthetők a riportok a rendszer legfontosabb üzleti kimenetének. Ebben a megközelítésben a riportok nem technikai kimenetek, hanem az üzleti domain által előállított termékek.

A munkaidőnyilvántartó rendszerek alapvetően adatokat gyűjtenek: belépéseket, kilépéseket, beosztásokat, távolléteket. Ezek az adatok önmagukban azonban nehezen értelmezhetők, és közvetlenül nem alkalmasak döntéshozatalra. A riportok szerepe az, hogy a nyers adatokat üzleti kontextusba helyezzék, és azokat értelmezhető, összehasonlítható formában jelenítsék meg.

Bár egy ilyen rendszer kivált bizonyos adminisztratív feladatokat (például papíralapú jelenléti íveket), valódi értéke abban rejlik, hogy üzleti döntéseket támogat.

Tipikus döntési helyzetek, amelyeket a riportok kiszolgálnak:

• létszámtervezés
• túlórák kezelése
• hatékonyság mérése
• bérszámfejtés előkészítése
• vezetői döntések támogatása

Riportok és célcsoportok

A riportok jellemzően ugyanazokra az alapadatokra épülnek, mégsem ugyanabban a formában kell megjelenniük minden felhasználó számára. Egy csoportvezetőnek más információkra van szüksége, mint a HR-nek vagy a felsővezetésnek. Ugyanilyen fontos szempont az is, hogy ki milyen adatokhoz férhet hozzá, és milyen bontásban.

Ezért a riportálás szorosan összefügg a jogosultságkezeléssel. A gyakorlatban ez leggyakrabban szerepkör alapú hozzáférés-szabályozással (RBAC – Role Based Access Control) valósul meg, ahol a felhasználók különböző szerepekhez tartoznak. A szerepkör nemcsak azt határozza meg, hogy egy felhasználó milyen riportokat érhet el, hanem azt is, hogy az adott riport milyen részletezettséggel jelenik meg számára. A jogosultságok ilyen módon történő kezelése nemcsak biztonsági kérdés, hanem az üzleti szerepek és nézőpontok tudatos szétválasztása is. [3]

Míg a HR számára a ledolgozott órák, jelenlétek és távollétek a legfontosabbak, addig a vezetőség számára ezek mellett már hatékonysági mutatók, trendek és összesítések válnak hangsúlyossá.

Mitől lesz egy riport értelmezhető?

A riport nem egyszerű lista vagy adatkinyerés. Egy jól elkészített riport konkrét üzleti kérdésekre ad választ, és segíti a döntéshozatalt. Egy jó riport:

• áttekinthető,
• könnyen értelmezhető,
• kontextust ad a számok mellé,
• és képes „megmagyarázni önmagát”.

Nem elegendő pusztán az eredményeket megjeleníteni; fontos az is, hogy a riport bemutassa azokat az adatokat és körülményeket, amelyek az eredményekhez vezettek.

Vegyünk egy példát. Ha egy vezető egy adott napra vonatkozóan azt látja, hogy egy csoport teljesítménye mindössze 40%, könnyen arra a következtetésre juthat, hogy a csoport alulteljesített. Ha azonban a riport kiegészül további információkkal – például a heti átlagos teljesítménnyel, betegállományokkal vagy továbbképzésekkel –, akkor már egészen más kép rajzolódik ki. Elképzelhető, hogy az átlagos teljesítmény 80% körül van, de az adott napon a dolgozók jelentős része hiányzott, így a 40% nem teljesítményprobléma, hanem egyedi körülmények következménye.

Riportok és üzleti szabályok

Fontos hangsúlyozni, hogy a riportok nem objektív igazságokat mutatnak, hanem a vállalat üzleti szabályai mentén készülnek. Az, hogy mi számít jelenlétnek, túlórának vagy hatékony munkavégzésnek, mindig szervezeti döntések eredménye.

Ezek a szabályok a rendszer domain rétegében kerülnek megfogalmazásra és alkalmazásra. Mivel az üzleti szabályok idővel változnak, a riportálási igények is folyamatosan módosulnak. Egy jól megtervezett rendszernek képesnek kell lennie ezeknek a változásoknak a kezelésére, miközben megőrzi az adatok következetességét.

Ez egyben azt is jelenti, hogy nem lehet mindent előre tökéletesen megtervezni. A következő fejezetben azt vizsgáljuk meg, hogy mit érdemes előre lefektetni egy rendszer tervezésekor, és mely területeken szükséges tudatosan teret hagyni a későbbi változásoknak.

---

6. Záró gondolatok

A fentieket összefoglalva jól látható, hogy egy munkaidőnyilvántartó rendszer megvalósítása nem elsősorban technológiai probléma. Az első kérdéseket nem úgy érdemes feltennünk, hogy:

• „Milyen programozási nyelvet használjunk?”
• „Milyen adatbázisban tároljuk az adatokat?”
• „Milyen oszlopai legyenek az adatbázis tábláknak?”

Hanem inkább így:

• Mit nevez a cég jelenlétnek?
• Kinek, mit kell látnia – és miért?
• Miből áll össze egy riport, amely valóban döntést támogat?

Egy jól működő rendszer az üzleti nyelvből indul ki. A végtermékek a riportok, amelyek valójában üzleti termékek. A belépési és kilépési adatok csupán alapanyagok: önmagukban keveset mondanak, de megfelelő feldolgozással segítik a döntéshozatalt és az információk értelmezését. Egy jó riport nem pusztán számokat mutat meg, hanem „elmeséli” az adott időszak történetét.

Az igény ezekre az eredményekre jellemzően nem változik. A szabályozások, a szervezeti struktúrák és a döntési mechanizmusok viszont igen. Éppen ezért nem a részletek merev rögzítése a cél, hanem egy olyan gondolkodásmód kialakítása, amely képes alkalmazkodni a változásokhoz. Egy szoftver nem attól lesz jó, hogy Pythonban vagy Java-ban készült, hanem attól, hogy a vállalkozás nyelvén szólal meg.

Egy fejlesztő akkor tud igazán hatékonyan dolgozni, ha érti az üzleti szabályokat és a mögöttük álló szándékot. Egy vezető pedig akkor tudja jól megfogalmazni az igényeit, ha ezt nagyrészt a saját nyelvén teheti meg – nem technológiai, hanem üzleti fogalmak mentén.

A fenti gondolkodásmód szorosan kapcsolódik a Domain-Driven Design (DDD) szemléletéhez, amelyet Eric Evans írt le részletesen. A cikk nem a DDD fogalmaiból indult ki, hanem egy konkrét üzleti probléma megértéséből — ez pedig jól mutatja, hogy a DDD nem egy módszertan, hanem egy természetesen kialakuló szemlélet.

A következő cikkekben konkrét részterületeket vizsgálok meg részletesebben – például az adatkezelést, a riportálási mintákat és a változó üzleti szabályok kezelését –, mindig ugyanebből az üzleti szemléletből kiindulva.

---

Források

[1] Evans, E. (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley.
[2] Kimball, R. & Ross, M. (2013). The Data Warehouse Toolkit. Wiley.
[3] Sandhu, R. et al. (1996). Role-Based Access Control Models. IEEE Computer, 29(2), 38–47.