Miért nem elég már az Excel-tábla?
Hétfő reggel, kilenc óra. A projektvezető megnyitja a „Projektek_2026_VÉGLEGES_v3.xlsx” fájlt, és rájön, hogy a kolléga a múlt héten egy másik verziót frissített. A felelősök neve egy háromhetes e-mail-láncban van, a határidő-módosítás pedig valahol a csapatchat 400 üzenete között.
Ez a tipikus magyar kkv-s állapot.
Nem lustaság vagy hozzá nem értés okozza. Egyszerűen a cég kinőtte azokat az eszközöket, amelyekkel öt fővel még remekül működött.
A gond az, hogy az információ három helyen él, és egyik sem teljes. Ebből felelősségi hézagok születnek: mindenki azt hiszi, a feladat valaki másnál van.
A feladatok csendben elmaradnak, a határidők csúsznak, és a vezető csak akkor szembesül a problémával, amikor az ügyfél telefonál.
Az Excel nem a projekteket kezeli, hanem a projektekről készült, gyorsan elavuló pillanatfelvételeket.
Egy jól megválasztott projektmenedzsment szoftver ezért nem egy szebb feladatlista.
Ez a projekttervezés, a projektkommunikáció, az erőforrás-tervezés és a riportolás közös rétege, ahol minden adat egyetlen helyen, naprakészen érhető el.
Ebben a cikkben végigvesszük, mi is pontosan egy ilyen rendszer, mely funkciói oldanak meg valódi problémákat, hogyan válassz és vezess be eszközt, és mikor érdemes egyedi fejlesztésben gondolkodni. A végén egy ma elvégezhető első lépést is kapsz.
Mi a projektmenedzsment szoftver valójában?
A legtöbb cég ott hibázza el a választást, hogy feladatkezelőt keres, miközben projektkezelésre lenne szüksége. A kettő hasonlít, de nem ugyanaz.
A különbség pedig pénzben mérhető.
A projektmenedzsment szoftver olyan rendszer, amely a projekteket, feladatokat, felelősöket, határidőket, erőforrásokat és dokumentumokat összekapcsolva kezeli egyetlen felületen. A kulcsszó az összekapcsolt: ha egy feladat csúszik, a rendszer tudja, mely további feladatokat és mely mérföldkövet érinti.
Gondolj rá úgy, mint egy építkezés helyszíni irodájára. Ott nemcsak a teendők listája lóg a falon, hanem a tervrajz, a beosztás, a szállítási ütemterv és a költségvetés is.
Mindenki ugyanarra a táblára néz.
Feladatkezelő vagy projektmenedzsment rendszer?
Egy egyszerű feladatkezelő (a klasszikus to-do lista vagy egy alap Kanban-tábla) arra válaszol, hogy mit kell megcsinálni. Egy valódi projektmenedzsment rendszer arra is, hogy milyen sorrendben, ki által, mennyi idő alatt, és mi történik, ha valami késik.
Négy funkció választja el a kettőt egymástól:
- Feladatfüggőség: a „B” feladat nem indulhat, amíg az „A” nincs kész, és ezt a rendszer kezeli is, nem csak jelzi.
- Mérföldkövek: az ügyféllel vagy vezetőséggel egyeztetett, ellenőrizhető állomások, amelyekhez feladatcsoportok kötődnek.
- Kapacitás: látható, hogy egy kolléga heti 40 órájából mennyi foglalt már, mielőtt újabb munkát kapna.
- Riportok: terv-tény elemzés, csúszások, ráfordítások, kézzel összerakott táblázatok nélkül.
Ha a csapatod munkájában ezek egyike sem jelenik meg, elég lehet egy feladatkezelő. Ha viszont rendszeresen egymásra épülő, határidős munkákat végeztek, a to-do lista hamar szűk lesz.
Hol húzódik a határ CRM és ERP felé?
A CRM (ügyfélkapcsolat-kezelő rendszer) az értékesítés előtti és körüli folyamatokat kezeli: érdeklődők, ajánlatok, ügyféltörténet. Az ERP (vállalatirányítási rendszer) a cég egészének erőforrásait fogja össze, a készlettől a könyvelésig.
A belső alkalmazások pedig egy-egy konkrét folyamatot szolgálnak ki, például szabadságkérést vagy eszköznyilvántartást.
A projektmenedzsment réteg ezek között helyezkedik el. Onnan indul, ahol a CRM véget ér (az ügyfél igent mondott), és addig tart, amíg a leszállított munka bekerül a számlázásba.
Vegyünk egy webfejlesztő ügynökséget.
A CRM-ben lezárul egy 4,5 millió forintos ajánlat, ami automatikusan projektet hoz létre a projektmenedzsment rendszerben, előre beállított sablonnal és mérföldkövekkel. Amikor a második mérföldkövet az ügyfél jóváhagyja, a rendszer API-integráción keresztül jelez a számlázónak, amely kiállítja a részszámlát.
Senki nem másol adatot kézzel, és senki nem felejti el a számlát.
Ez az összeérés a valódi érték.
A projektmenedzsment szoftver nem helyettesíti a CRM-et vagy a számlázót, hanem összeköti őket a tényleges munkavégzéssel.
Funkciók, amik valódi problémákat oldanak meg
Egy átlagos eszköz funkciólistája 80-100 tételből áll. A csapatod ennek talán a negyedét fogja ténylegesen használni.
Ezért érdemesebb fordítva gondolkodni: először a problémát nevezd meg, aztán keresd hozzá a funkciót.
Az alábbi táblázat a kkv-knál leggyakrabban előforduló működési hibákat köti össze azokkal a funkciókkal, amelyek kezelik őket.
| Funkció | Megoldott probléma | Hogyan működik a gyakorlatban | Prioritás kezdő csapatnak |
|---|---|---|---|
| Jóváhagyási munkafolyamat | Jóváhagyási késés: egy anyag napokig áll valakinek a postafiókjában | A feladat automatikusan a jóváhagyóhoz kerül, határidővel; 48 óra után emlékeztető, majd eszkaláció a vezetőhöz | Kötelező, ha van ügyféloldali vagy vezetői jóváhagyás |
| Felelősrendelés (egy feladat, egy felelős) | Felelősségi hézag: „azt hittem, te csinálod” | Minden feladatnak pontosan egy felelőse van, a többiek csak közreműködők vagy megfigyelők | Kötelező |
| Mérföldkövek és feladatfüggőségek | Csúszó határidők, amelyek csak az utolsó héten derülnek ki | A projektütemezés a kritikus úton lévő feladatokat kiemeli, így egy kétnapos csúszás azonnal látszik a végső határidőn | Kötelező határidős projekteknél |
| Kapacitásnézet | Kapacitásütközés: egy kolléga egyszerre három projektben „teljes időben” | Heti bontásban mutatja a lefoglalt és a szabad órákat, színkóddal jelzi a túlterhelést | Hasznos 8 fő felett |
| Értesítések és projektkommunikációs napló | Ügyfélkommunikációs hiba: elveszett kérés, kétféle információ | A megjegyzések a feladathoz kötődnek, nem e-mailben vagy chaten; a változásokról az érintettek célzott értesítést kapnak | Kötelező |
| Dokumentumkezelés verziózással | Rossz fájlverzió kerül az ügyfélhez | A dokumentum a feladathoz csatolva él, minden verzió visszakereshető | Hasznos |
Figyeld meg, hogy a „kötelező” sorok egyike sem bonyolult technológia. Inkább fegyelmet kényszerítenek ki, amit az Excel nem tud.
Kanban, Gantt vagy a kettő együtt?
A Kanban-tábla oszlopokba rendezi a feladatokat („Teendő”, „Folyamatban”, „Ellenőrzés”, „Kész”), és a folyamatos, ismétlődő munkákhoz ideális. Ügyfélszolgálati jegyek, marketingtartalmak, karbantartási feladatok: ezeknél nincs igazi végpont, csak áramlás.
Itt a kérdés az, hol akad el a munka.
A Gantt-diagram idővonalon mutatja a feladatokat és azok függőségeit. Határidős, egymásra épülő projekteknél nélkülözhetetlen, például egy irodaköltözésnél vagy egy szoftverbevezetésnél, ahol a munkalebontási struktúra minden eleme hatással van a következőre.
A legtöbb kkv valójában hibrid projektmenedzsment szerint működik, csak nem nevezi így. A nagy ívet mérföldkövek és Gantt-nézet adja, a mindennapi munkát pedig kéthetes sprintekben, Kanban-táblán viszitek.
A jó eszköz ugyanazt az adatot mindkét nézetben megmutatja, így nem kell két rendszert karbantartani.
Kapacitás, munkaidő és profitabilitás egy helyen
Melyik projekten keresett ténylegesen pénzt a cég tavaly? A legtöbb ügyvezető erre csak becslést tud mondani.
Pedig a válasz ott van az adatokban, csak szét vannak szórva.
Ha a rendszer tartalmaz időráfordítás-követést, minden ledolgozott óra egy feladathoz, így egy projekthez kötődik. Az órákhoz óradíj vagy belső önköltség rendelhető, a projekthez pedig projektköltségvetés.
Ebből automatikusan előáll a terv-tény elemzés: 120 órát terveztetek, 165 lett, a fedezet 32%-ról 9%-ra esett.
Ha ehhez még a számlázás is hozzá van kötve, a projektprofitabilitás valós időben látszik, nem a negyedéves zárás után. Ekkor derül ki például, hogy egy „kedvenc” ügyfél valójában veszteséges, mert minden körben háromszor annyi módosítást kér.
Kezdő csapatnak a priorizálás így néz ki: kötelező a felelősrendelés, a határidők, a feladathoz kötött kommunikáció és az alap dokumentumkezelés.
Hasznos az időkövetés, a kapacitásnézet és a sablonok.
Felesleges az elején a projektportfólió-kezelés, a többszintű egyedi mezőrendszer és a bonyolult workflow-automatizálás, mert ezek csak akkor hoznak értéket, ha az alapokat már mindenki következetesen használja.
Hogyan válasszunk és vezessünk be rendszert
A szoftverbevezetések többsége nem a technológián bukik el.
Azon bukik el, hogy a csapat a harmadik héten visszaszokik az Excelhez.
A választás és a bevezetés ezért egyetlen folyamat, nem két külön döntés.
Döntési szempontok cégméret és folyamat szerint
Mielőtt bármilyen demót megnéznél, válaszolj meg néhány kérdést. Ezek leszűkítik a mezőnyt néhány reális jelöltre.
- Mérd fel a csapatméretet. 3-10 fő alatt egy egyszerű, Kanban-alapú eszköz is elég lehet; 10-50 fő között már kell kapacitásnézet és jogosultságkezelés; 50 fő felett a projektportfólió-kezelés és a részlegközi riportolás válik fontossá.
- Határozd meg a projekttípust. Ügyfélmunkánál (ügynökség, tanácsadás, kivitelezés) az időkövetés, a jóváhagyás és a számlázási kapcsolat a lényeg. Belső fejlesztésnél inkább az agilis projektmenedzsment támogatása, a sprintek és a backlog kezelése.
- Vedd számba a meglévő eszközparkot. Ha a cég Microsoft 365-öt vagy Google Workspace-t használ, nézd meg, mely eszköz kapcsolódik hozzá natívan. Ugyanez igaz a CRM-re és a számlázóra: az API-integráció hiánya később rengeteg kézi munkát jelent.
- Számold ki a teljes költséget. A havi felhasználónkénti díj csak egy tétel. Ide tartozik a bevezetésre fordított munkaidő, a betanítás és a későbbi bővítés ára is, három évre vetítve.
Bevezetés lépésről lépésre
Az alábbi sorrend azért működik, mert a folyamatból indul ki, nem a szoftverből. A legtöbb cég fordítva csinálja: előbb megveszi az eszközt, aztán próbálja ráhúzni a működésére.
- Folyamatfelmérés. Írd le egy tipikus projekt teljes útját az ügyfél igenjétől a számlázásig: ki mit csinál, hol akad el, ki hagy jóvá. Ez egy-két óra egy táblánál, de ez határozza meg az egész bevezetést.
- Minimális adatmodell kialakítása. Öt alapelemmel indulj: projekt, feladat, felelős, ügyfél, dokumentum. Minden további mező (címkék, egyedi státuszok, prioritási szintek) csak akkor kerüljön be, ha valaki konkrétan hiányolja.
- Pilotprojekt kiválasztása. Válassz egy 4-8 hetes, közepes bonyolultságú projektet egy nyitott hozzáállású csapattal. Ne a legkritikusabb ügyféllel kezdj, és ne is egy jelentéktelen belső feladattal.
- Jogosultsági szintek beállítása. Határozd meg, ki lát pénzügyi adatokat, ki hozhat létre projektet, és mit lát egy külső ügyfél vagy alvállalkozó. Ezt utólag módosítani mindig fájdalmasabb.
- Sablonok elkészítése. A pilot tapasztalatai alapján készíts projektsablont a visszatérő projekttípusokra, előre beállított feladatokkal, mérföldkövekkel és felelősi szerepkörökkel. Egy jó sablon a projektindítást órákról percekre rövidíti.
- Szelektív migráció. Csak a folyamatban lévő projektek kerüljenek át Excelből, a lezártak maradjanak archívumban. Az ügyféllista és az alapadatok importálhatók, de a régi feladatlisták átemelése általában több zajt hoz, mint hasznot, ezért ott érdemes nulláról indulni.
- Kiterjesztés a teljes csapatra. Ha a pilot után a csapat nem akar visszamenni a régi módszerhez, jöhet a többi projekt. Ha visszamenne, előbb derítsd ki, miért.
És most jön a legnehezebb rész.
Hogyan éred el, hogy a bevezetés után ne fusson párhuzamosan az Excel, az e-mail és a chat?
Az első feltétel a vezetői elköteleződés. Ha az ügyvezető továbbra is e-mailben ad ki feladatot, a csapat pontosan érti az üzenetet: a rendszer opcionális.
A vezetőnek kell elsőként és következetesen használnia.
A második az egyetlen igazságforrás szabálya. Ami nincs a rendszerben, az nem létezik: nincs feladat, nincs határidő, nincs jóváhagyás.
Kemény szabály, de két-három hét után megszűnik a vita arról, „melyik verzió az érvényes”.
A harmadik a kötelező belépési pont.
A heti státuszmegbeszélés a rendszer képernyőjéről menjen, ne egy külön összerakott prezentációból. Ha a meeting a rendszerben zajlik, a rendszer adatai naprakészek lesznek, mert senki nem akar a többiek előtt elavult feladattal szembesülni.
Mikor nem elég egy kész eszköz?
A kész SaaS-eszközök 70-80%-ban mindenkinek jók. A gond a maradék 20-30%-kal van, mert gyakran pont ott van a cég versenyelőnye.
Ha a működésed lényege nem fér bele egy általános sablonba, a kész eszköz előbb-utóbb a folyamatot kezdi formálni, nem fordítva.
Döntési keretrendszer: SaaS, integráció vagy egyedi fejlesztés
A döntés három szinten dől el, és érdemes alulról felfelé haladni.
Az első szint: a kész SaaS-eszköz elegendő. Ez a helyzet, ha a projektjeid szabványos lépésekből állnak, a jóváhagyás egy-két szereplős, és nincs szükség mély kapcsolatra más rendszerekkel.
A legtöbb 5-20 fős szolgáltató cég itt kezd, és sokan itt is maradnak.
A második szint: integráció szükséges. A kész eszköz jó, de a CRM-mel, a számlázóval vagy a munkaidő-nyilvántartással össze kell kötni.
Ilyenkor API-integráció vagy köztes automatizálási platform oldja meg a feladatot, viszonylag kis költséggel.
A harmadik szint: egyedi fejlesztés indokolt. Ez nem luxus, hanem racionális döntés, ha az alábbi jelek közül több is fennáll:
- Egyedi, többlépcsős jóváhagyási láncok, például műszaki, pénzügyi és ügyféloldali jóváhagyás feltételes elágazásokkal.
- Ügyfélportál igénye, ahol a megrendelő a saját arculatoddal látja a projekt állását, és ott hagy jóvá.
- Mobil- és webalapú belső használat egyszerre, például terepen dolgozó kollégák és irodai projektvezetők között.
- AI-alapú funkciók: megbeszélések összefoglalása, feladatkinyerés e-mailekből, kockázatjelzés a csúszások mintázata alapján, riport-előkészítés.
Egyedi rendszer a gyakorlatban
Az egyedi fejlesztéstől a kkv-k jellemzően két dolog miatt tartanak: elszálló költségek és véget nem érő projekt.
Jogos félelem.
Ezért számít, milyen konstrukcióban dolgozik a fejlesztő.
A CompletApp megközelítése jó példa arra, hogyan kezelhető ez a kockázat. Egyedi, mobil- és webalapú belső rendszereket fejlesztenek fix terjedelemmel és fix árral, így a megrendelő előre tudja, mit kap és mennyiért.
Az első működő verzió (MVP) 4 hetes ütemben készül el, ami a pilotprojekt logikáját a fejlesztésre is átülteti.
Két további elem csökkenti a függőséget.
A kiszállási garancia azt jelenti, hogy a megrendelő nincs bezárva egy előre nem látható, hosszú együttműködésbe. A 100%-os kódtulajdon pedig biztosítja, hogy a forráskód a cégé, vagyis a rendszer később más fejlesztővel is továbbvihető.
Az Apartmanom referencia jól mutatja, mit jelent ez a gyakorlatban. A rendszer a naptárat, a foglalást, a számlázást és az ügyfélkommunikációt kapcsolja össze egyetlen felületen.
Ugyanaz a logika, mint egy projektmenedzsment rétegnél: nem négy külön eszköz, hanem egy összefüggő folyamat.
Az AI szerepéről is érdemes józanul beszélni. Egy AI-alapú projektasszisztens ma reálisan adatelemzésre és javaslattételre alkalmas: összefoglalja a heti változásokat, kigyűjti a feladatokat egy megbeszélés jegyzetéből, jelzi, hogy egy projekt a korábbi minták alapján csúszásveszélyben van.
Ellenőrizetlen, automatikus projektvezetésre viszont nem való.
Az AI előkészít, a projektvezető dönt. Ez a munkamegosztás 2026-ban is az egyetlen felelős modell.
Az első lépés, amit érdemes ma megtenni
A döntés egyszerűbb, mint amilyennek látszik.
Ha a folyamatod szabványos, kezdj kész eszközzel, és csak akkor lépj tovább integrációra, ha a kézi adatmásolás már valódi időt visz el. Ha viszont egyedi jóváhagyás, ügyfélportál vagy AI-logika kell, kérj felmérést egyedi fejlesztésre, mielőtt hónapokat töltenél egy kész eszköz hajlítgatásával.
De ne a szoftverrel kezdd.
Ma, még mielőtt egyetlen demót megnéznél, vegyél elő egy papírt, és térképezd fel egy nemrég lezárult projekt teljes életútját: honnan jött az igény, ki mit csinált, hol várt a munka, hol veszett el információ.
Egy óra az egész.
Ez a vázlat lesz a legértékesebb dokumentum a teljes kiválasztási folyamatban. Megmutatja, mely funkciók kellenek ténylegesen, és melyek csak jól mutatnak a prezentációban.
És tartsd észben a legfontosabbat.
A szoftver nem old meg rendezetlen folyamatot… csak láthatóvá teszi. Ha a felelősségek tisztázatlanok, a rendszer ezt kíméletlenül megmutatja.
Pontosan ezért éri meg.
