A megállapítás mögött
legyen bizonyíték.

A Kyntrax működésdiagnosztikát, célállítást, kontrollált megvalósítást és folyamatvezérelt ERP-t kínáló márka.

A 12+ év, 3 500+ projekt és az ISO 9001 audittapasztalat az alapító korábbi vállalati működésére vonatkozó közlés, nem jelenlegi Kyntrax-mérés vagy tanúsítvány. — Korábbi tapasztalat; függetlenül nem ellenőrzött

A módszer leírása nem garantált eredmény. A konkrét vállalati hatást saját kiinduló adatokkal és mérési időszakkal kell igazolni.

A Kyntrax Mirror a vállalat tényleges működését tárja fel. Nem azt vizsgálja, hogyan kellene működnie a cégnek, hanem azt, mi történik valójában a folyamatokban, az információáramlásban, a felelősségekben és a döntési pontokon.

A módszer leírása nem garantált eredmény. A konkrét vállalati hatást saját kiinduló adatokkal és mérési időszakkal kell igazolni.

A Kyntrax Compass a vezetői jövőképet dokumentált, mérhető célállapottá alakítja. Nem egy általános „ideális vállalathoz” mérjük a céget: a célállapotot a tulajdonossal vagy ügyvezetővel közösen határozzuk meg, majd ehhez viszonyítjuk a Mirrorban feltárt jelenállapotot.

A módszer leírása nem garantált eredmény. A konkrét vállalati hatást saját kiinduló adatokkal és mérési időszakkal kell igazolni.

A Kyntrax Tunnel a Mirrorban feltárt jelenállapot és a Compassban meghatározott célállapot közötti utat tervezi meg és valósítja meg. A változás kontrollált, mérhető hullámokban történik: minden lépésnek van felelőse, feltétele, várt működési hatása és visszamérési pontja.

A módszer leírása nem garantált eredmény. A konkrét vállalati hatást saját kiinduló adatokkal és mérési időszakkal kell igazolni.

2008 óta folyamatosan fejlesztett process-driven vállalati architektúra, amely nemcsak rögzíti a működést, hanem szabályokkal, felelősségekkel és ellenőrzési pontokkal végig is vezeti azt.

A Kyntrax ERP leírása folyamatok, szerepkörök, feladatok, döntési pontok és jóváhagyások közös digitális struktúráját mutatja be. — Jelenlegi képességről szóló közlés; saját közlés

A Pandora történeti projektjei nem azonosak a jelenlegi Kyntrax ERP-verzió mérésével. A konkrét képességet és integrációt a kiválasztott konfigurációban kell ellenőrizni.

Governed enterprise AI runtime, amely a probabilisztikus modellképességet determinisztikus szabályokkal, jogosultságokkal, bizonyítékokkal, auditálással és emberi döntési határokkal fogja közre.

A Kyntrax AI OS a modellképességet és a végrehajtási jogosultságot külön kezeli. — Architekturális leírás; saját közlés

A közzétett termékleírás szerint több architekturális komponens implementált és automatizált tesztekkel lefedett; ez nem a teljes rendszer production igazolása. — Jelenlegi képességről szóló közlés; saját közlés

A teljes Kyntrax AI OS független production validációját ez a publikáció nem igazolja. — Éles üzemi igazolás; még nem igazolt

Az architektúra és az implementált komponensekről szóló közlés nem független production validáció. Nyilvánosan ellenőrizhető vállalati pilotmérési csomag itt nem áll rendelkezésre.

A formális vállalati rendszeren kívüli megoldás, amely tartósan a tényleges működéshez szükséges adatot, szabályt, számítást vagy munkafolyamatot kezel.

Az Excel árnyékrendszer jelenléte nem automatikusan felhasználói hiba vagy ERP-hiba: a hivatalos működés és a tényleges munkavégzés viszonyát és a helyi okot kell megvizsgálni. — methodological; saját közlés

Az árnyékrendszer önmagában nem bizonyít ERP-, folyamat- vagy felhasználói hibát. A helyi okot meg kell vizsgálni; a példák nem ügyféleredmények. — limitation; documented

Az árnyékrendszer önmagában nem bizonyít ERP-, folyamat- vagy felhasználói hibát. A helyi okot meg kell vizsgálni; a példák nem ügyféleredmények.

Eltérés a hivatalosan előírt működéstől egy feladat elvégzése vagy egy konkrét cél teljesítése érdekében.

Az árnyékrendszer önmagában nem bizonyít ERP-, folyamat- vagy felhasználói hibát. A helyi okot meg kell vizsgálni; a példák nem ügyféleredmények.

Az adott üzleti kérdésben hitelesnek tekintett információ forrása; nem feltétlenül ugyanaz minden kérdésben.

Az árnyékrendszer önmagában nem bizonyít ERP-, folyamat- vagy felhasználói hibát. A helyi okot meg kell vizsgálni; a példák nem ügyféleredmények.

Kézi beavatkozás a rendszerben vagy a mellette vezetett nyilvántartásban; célját és helyi okát meg kell vizsgálni.

Az árnyékrendszer önmagában nem bizonyít ERP-, folyamat- vagy felhasználói hibát. A helyi okot meg kell vizsgálni; a példák nem ügyféleredmények.

Vizsgálandó eltérés a formális rendszerben leírt működés és a tényleges munkavégzés között.

Az árnyékrendszer önmagában nem bizonyít ERP-, folyamat- vagy felhasználói hibát. A helyi okot meg kell vizsgálni; a példák nem ügyféleredmények.

A teljes folyamat teljesítményéhez, szabályaihoz, kapcsolódásaihoz és változtatásaihoz tartozó felelősség rendezése.

A részfeladatok felelőssége nem azonos a teljes folyamat end-to-end tulajdonlásával. Átadásoknál döntési, információs vagy felelősségi rés alakulhat ki. — methodological; saját közlés

A részfeladat felelőse nem feltétlenül a teljes folyamat tulajdonosa. A szervezeti megoldás vállalatfüggő; a folyamattulajdon nem korlátlan döntési jog. — limitation; documented

A részfeladat felelőse nem feltétlenül a teljes folyamat tulajdonosa. A szervezeti megoldás vállalatfüggő; a folyamattulajdon nem korlátlan döntési jog.

Szerepkör, amely biztosítja, hogy a teljes folyamat eredménye, szabályai és problémái ne váljanak gazdátlanná.

A részfeladat felelőse nem feltétlenül a teljes folyamat tulajdonosa. A szervezeti megoldás vállalatfüggő; a folyamattulajdon nem korlátlan döntési jog.

Annak tisztázása, hogy az adott ponton ki végzi a munkát, ki dönt és ki felel az eredményért.

A részfeladat felelőse nem feltétlenül a teljes folyamat tulajdonosa. A szervezeti megoldás vállalatfüggő; a folyamattulajdon nem korlátlan döntési jog.

A szerepkör lehetősége szabályok, változtatások, átadások vagy eszkalációk kezelésére a kijelölt hatáskörben.

A részfeladat felelőse nem feltétlenül a teljes folyamat tulajdonosa. A szervezeti megoldás vállalatfüggő; a folyamattulajdon nem korlátlan döntési jog.

A folyamat résztvevői közötti átadás, ahol az információ vagy a felelősség elveszhet, késhet vagy bizonytalanná válhat.

A részfeladat felelőse nem feltétlenül a teljes folyamat tulajdonosa. A szervezeti megoldás vállalatfüggő; a folyamattulajdon nem korlátlan döntési jog.

A kiváltó eseménytől az eredményig tartó teljes folyamat, amely több szervezeti egységen is áthaladhat.

A részfeladat felelőse nem feltétlenül a teljes folyamat tulajdonosa. A szervezeti megoldás vállalatfüggő; a folyamattulajdon nem korlátlan döntési jog.

Annak meghatározása, hogy a normáltól eltérő helyzetben ki dönt, ki hagy jóvá és ki felel az eredményért.

A részfeladat felelőse nem feltétlenül a teljes folyamat tulajdonosa. A szervezeti megoldás vállalatfüggő; a folyamattulajdon nem korlátlan döntési jog.

Az ERP-változtatás előtti működés meghatározott módon mért kiindulási állapota a későbbi összehasonlításhoz.

Az ERP baseline és a bevezetés előtti mérés nélkül a működési megtérülési állítás nem ellenőrizhető megbízhatóan. A mérési pontokat, definíciókat és időszakot a változtatás előtt kell kialakítani. — methodological; saját közlés

A baseline önmagában nem bizonyít okságot és nem garantál pozitív ROI-t. A párhuzamos változásokat és a mérési időszakot figyelembe kell venni; a számítási példák szemléltetőek. — limitation; documented

A baseline önmagában nem bizonyít okságot és nem garantál pozitív ROI-t. A párhuzamos változásokat és a mérési időszakot figyelembe kell venni; a számítási példák szemléltetőek.

A tervezett ROI előretekintő becslés; a tényleges üzleti eredmény utólagos mérést és a változás értelmezését igényli.

A baseline önmagában nem bizonyít okságot és nem garantál pozitív ROI-t. A párhuzamos változásokat és a mérési időszakot figyelembe kell venni; a számítási példák szemléltetőek.

A változtatás előtti állapot meghatározott mutatóval, adatforrással, időszakkal, gyakorisággal, definícióval és mérési felelőssel.

A baseline önmagában nem bizonyít okságot és nem garantál pozitív ROI-t. A párhuzamos változásokat és a mérési időszakot figyelembe kell venni; a számítási példák szemléltetőek.

Működésben felhasznált idő vagy erőforrás, amely nem feltétlenül jelenik meg külön költségsoron, például kézi összevetés vagy hibajavítás.

A baseline önmagában nem bizonyít okságot és nem garantál pozitív ROI-t. A párhuzamos változásokat és a mérési időszakot figyelembe kell venni; a számítási példák szemléltetőek.

A munka ismételt elvégzése vagy javítása, amelynek ideje és erőforrásigénye a baseline részeként vizsgálható.

A baseline önmagában nem bizonyít okságot és nem garantál pozitív ROI-t. A párhuzamos változásokat és a mérési időszakot figyelembe kell venni; a számítási példák szemléltetőek.

A meghatározott kezdő- és végpont között mért idő, a várakozás és a kivételek kezelésének explicit szabályaival.

A baseline önmagában nem bizonyít okságot és nem garantál pozitív ROI-t. A párhuzamos változásokat és a mérési időszakot figyelembe kell venni; a számítási példák szemléltetőek.

A manuális lépésekre, adatbevitelre, ellenőrzésre vagy beavatkozásra fordított munka.

A baseline önmagában nem bizonyít okságot és nem garantál pozitív ROI-t. A párhuzamos változásokat és a mérési időszakot figyelembe kell venni; a számítási példák szemléltetőek.

Előre meghatározott, visszaellenőrizhető működési mutató az elvárt változás megítéléséhez.

A baseline önmagában nem bizonyít okságot és nem garantál pozitív ROI-t. A párhuzamos változásokat és a mérési időszakot figyelembe kell venni; a számítási példák szemléltetőek.

A tervezett előnyök tényleges megvalósulásának mérése és ellenőrzése a bevezetés után is.

A baseline önmagában nem bizonyít okságot és nem garantál pozitív ROI-t. A párhuzamos változásokat és a mérési időszakot figyelembe kell venni; a számítási példák szemléltetőek.

A vállalati célállapot a vezetés által elfogadott leírás arról, hogy egy meghatározott időtávon milyen eredményeket, képességeket és működést szeretne elérni a cég, milyen feltételek mellett. A célműködési modell azt mutatja meg, hogyan kapcsolódnak össze ehhez az emberek, a folyamatok, a döntések, az adatok és a támogató rendszerek.

A jövőképtől a célműködési modellig „Három év múlva több rendelést szeretnénk teljesíteni úgy, hogy kevesebb napi ügyben legyen szükség a tulajdonosra.” Ez már érthető vezetői szándék. A megvalósítás előkészítéséhez azonban tudnunk kell, milyen rendelésekről beszélünk, mit ígérünk a vevőknek, és milyen döntéseket tud majd önállóan meghozni a szervezet. Négy fogalom segít rendet tenni: - A jövőkép megadja az irányt és a tulajdonosi szándékot: milyen vállalatot szeretnénk vezetni. - A célállapot rögzíti az elérni kívánt helyzetet, annak időtávját, feltételeit és ellenőrizhető elvárásait. - A célműködési modell a kívánt működés összefüggő leírása. Angol elnevezése Target Operating Model, röviden TOM. - A megvalósítási terv a szükséges változtatásokat rendezi feladatokká, felelősökhöz, erőforrásokhoz és határidőkhöz. A vállalati célállapot tágabb a belső működésnél: tartalmazhat piaci pozícióra, eredményességre és a tulajdonos szerepére vonatkozó elvárásokat is. A célműködési modell ezek működési következményeit kapcsolja össze. Leírja például, mire támaszkodik az értékesítő, amikor határidőt vállal, és ki dönthet, ha egy új rendelés veszélyezteti a korábbi ígéreteket. — methodological; documented

Egy gyártócég példája Képzeljünk el egy kisebb gyártóvállalatot, amely visszatérő sorozatokat és egyedi termékeket is készít. A tulajdonos három éven belül több visszatérő rendelést szeretne, megbízható teljesítéssel és kevesebb személyes beavatkozással. Az egyedi munkákat is megtartaná, de csak külön egyeztetett feltételekkel. A jelenlegi működés feltárásakor kiderülhet, hogy az értékesítés telefonon kérdez rá a szabad kapacitásra, a beszerzési dátumok több helyen szerepelnek, a sürgős rendelések sorrendjéről pedig többnyire a tulajdonos dönt. A példa szemléltető helyzet, nem ügyféleset. Az alábbi elvárások azt mutatják meg, hogyan lehet ebből célműködést leírni; a tényleges célokat mindig a saját vállalat adataiból és vezetői döntéseiből kell kialakítani. — example; documented

A célműködési modell hét tartalmi eleme Az alábbi hét terület jól használható gyakorlati felosztás. A modell részletességét a vállalat összetettségéhez és a meghozandó döntésekhez igazítjuk. — methodological; documented

1 Ügyfélkör és kiszolgálási vállalások Először azt tisztázzuk, kiket és milyen feltételekkel akarunk kiszolgálni. Az általános „legyünk gyorsabbak” helyett érdemes külön leírni az ajánlatadás, a visszaigazolás és a teljesítés elvárt működését. A gyors válasz és a gyors szállítás eltérő képességeket igényelhet. A példabeli gyártónál a visszatérő termékek rendelései meghatározott adatok alapján vállalhatók. Az egyedi terméknél a műszaki tisztázás megelőzi a végleges határidő visszaigazolását. A sürgős igényekre külön döntési rend vonatkozik. Így a rugalmasság költsége és következménye is látható marad. — methodological; documented

2 Folyamatok és átadások A modell végigköveti, hogyan jut el a munka az igénytől a teljesítésig, majd az elszámolásig és a visszajelzésig. Különösen fontos, milyen feltételekkel adható át egy ügy a következő területnek, és honnan tudható, hogy az átvétel megtörtént. A gyártócég célműködésében a termeléshez csak olyan rendelés kerülhet, amelynek ismert a jóváhagyott műszaki tartalma, mennyisége, vállalt határideje és anyagellátási helyzete. Ha valami hiányzik, az ügynek van látható állapota és felelőse. A következő kollégának így nem kell újra kiderítenie, miben állapodtak meg a vevővel. — methodological; documented

3 Szerepek és döntési jogok Rögzíteni kell, ki felel egy folyamat eredményéért, ki végez egy feladatot, és ki milyen keretek között dönthet. A felelősséghez hozzá kell rendelni a szükséges információt és felhatalmazást is. A példában az értékesítő az elfogadott vállalási szabályok szerint önállóan igazolhat vissza rendelést. A már vállalt határidőket érintő átsorolásról a kijelölt vezető dönt, az érintett területek adatai alapján. A tulajdonoshoz a meghatározott üzleti vagy kockázati határt meghaladó ügyek kerülnek. A modellnek a helyettesítést is rendeznie kell. Egy szerep önállósága akkor használható, ha szabadság vagy távollét idején is világos, ki és milyen jogkörrel veszi át a nyitott ügyeket. — methodological; documented

4 Adatok és információkapcsolatok A „mindenki ugyanazt lássa” elvárás pontosításra szorul. Meg kell nevezni, mely adatnak mi a hiteles forrása, ki felel a frissítéséért, mikor kell rendelkezésre állnia, és kik használhatják. A gyártónál külön állapotot jelenthet a beszállítótól várt, a beérkezett, az ellenőrzött és a már más rendeléshez lefoglalt anyag. Ezekből más következtetés adódik a vállalható határidőre. A célműködésben az értékesítés és a termelés ugyanazokat az állapotokat ugyanúgy értelmezi, a változás pedig eljut azokhoz, akiknek emiatt dönteniük kell. — methodological; documented

5 Kapacitás és szakértelem A kívánt működést meghatározott terhelésre kell leírni. A rendelési mennyiség mellett számít a termékösszetétel, a szezonalitás, az átállások és az egyedi igények aránya is. A példában hiába van szabad gépidő, ha a műszaki előkészítést csak egyetlen túlterhelt munkatárs tudja elvégezni. A célmodell ezért a szükséges szaktudást, a helyettesíthetőséget és a kritikus munkaszakaszok terhelhetőségét is tartalmazza. Ebből később levezethető a képzés vagy a kapacitásbővítés igénye; a konkrét személyügyi döntések a vezetésre tartoznak. — methodological; documented

A gyártócég és a 95 százalékos célérték szemléltető példa, nem ügyféleset, általános ajánlás vagy Kyntrax-eredményígéret. Az elfogadott célállapot szándékot rögzít; teljesülését későbbi működési adatokkal kell igazolni.

A fejlesztési célok rangsorolása az üzleti célokat, a függőségeket, a szervezet tényleges teherbírását és a várakozás árát együtt kezeli.

Döntési keret az üzleti érték, az előfeltételek, az erőforrások és a halasztás következményeinek mérlegeléséhez. — methodological; documented

Egy vállalatban szinte mindig több jó fejlesztési ötlet létezik, mint amennyit ugyanabban az időszakban biztonságosan végre lehet hajtani. Az ajánlatadás gyorsítása, a készletek csökkentése, az ERP-folyamatok rendezése vagy a beszerzés automatizálása külön-külön is indokolt cél lehet. A döntő kérdés mégsem az, melyik hangzik a legígéretesebben, hanem hogy melyik visz legbiztosabban a kívánt működés felé. A fejlesztési célok rangsorolása ezért nem egyszerű kívánságlista, és nem is kizárólag megtérülési verseny. A sorrendnek az üzleti célokat, a függőségeket, a szervezet tényleges teherbírását és a várakozás árát együtt kell kezelnie. — methodological; documented

Négy kérdés, amely nélkül a sorrend könnyen félrevezető — methodological; documented

1. Milyen üzleti eredményhez járul hozzá? A fejlesztés neve helyett először az elvárt működési változást rögzítsük. Nem az a cél, hogy „legyen automatikus rendelés”, hanem például az, hogy az utánpótlási igény időben felismerhető legyen, a készlethiányok száma csökkenjen, miközben a lekötött készlettőke ellenőrzés alatt marad. A célhoz megfigyelhető teljesülési feltétel és kiindulási mérés is kell. Ha az eredményt nem tudjuk meghatározni, a fejlesztés prioritása sem értékelhető megbízhatóan. — methodological; documented

2. Mely előfeltételeknek kell előbb teljesülniük? Egy automatizált beszerzési folyamat például csak akkor hozhat megbízható eredményt, ha a cikktörzs, a készletadatok, a beszállítói átfutási idők és az engedélyezési szabályok megfelelőek. Ha ezek hiányoznak, a fejlesztés elindítása nem gyorsítás, hanem kockázatnövelés lehet. Az előfeltétel nem alacsonyabb prioritású mellékfeladat: gyakran maga az első, szükséges fejlesztés. — methodological; documented

3. Van hozzá tényleges szervezeti kapacitás? A pénzügyi fedezet nem azonos a megvalósítási kapacitással. Ugyanazokra a kulcsemberekre több projekt is épülhet: a raktárvezetőre, az értékesítési vezetőre, a beszerzőre és az informatikai felelősre. Mérlegelni kell a felszabadítható idejüket, a szükséges szakértelmet, a vezetői döntési kapacitást, valamint azt, hogy a napi működés közben is fenntartható-e a változás. — methodological; documented

4. Milyen ára van a halasztásnak? Nem minden későbbre sorolt fejlesztés jelent ugyanolyan veszteséget. Egy kisebb adminisztratív kényelmetlenség elviselhető lehet néhány hónapig; a rendszeres téves kiszállítás, a súlyos információhiány vagy egy megfelelési kockázat viszont sürgős beavatkozást követelhet. A halasztás költségét a várható üzleti veszteség, az ügyfélhatás, a kockázat és az elszalasztott lehetőség alapján kell megítélni — amennyire lehetséges, bizonyítékokkal. — methodological; documented

Hogyan lesz a szempontokból vezetői döntés? Egy egyszerű, újrahasználható döntési eljárás öt lépésből állhat: Határozzuk meg a célállapotot. Mit akarunk másképp működtetni, és hogyan igazoljuk a javulást? Jelöljük a nem halasztható beavatkozásokat. Súlyos működési, biztonsági vagy megfelelési kockázatot ne rejtsünk el egy összpontszám mögé. Rajzoljuk fel a függőségeket. Mi az, amit előbb kell rendezni, és mi az, amit önállóan vagy párhuzamosan is meg lehet valósítani? Vizsgáljuk a vállalhatóságot. Milyen kapacitást köt le, és melyik másik kezdeményezést szorítaná háttérbe? Rögzítsük a döntést és a felülvizsgálat feltételét. Indul, előkészíthető, feltétellel halasztott vagy elvetett — mindegyikhez indok tartozzon. A szempontokhoz használhatunk például 1–5 közötti értékelést, de a pontszám nem írhat felül kritikus előfeltételt vagy kötelező beavatkozást. Az ilyen számsor a megbeszélést támogatja, nem objektívnek látszó automataként dönt a vezetés helyett. — methodological; documented

A nagykereskedelmi helyzet szemléltető példa, nem ügyféleredmény. A tényleges sorrendet a vállalat bizonyított jelenállapota határozza meg. Az 1–5 közötti értékelés nem írhat felül kritikus előfeltételt vagy kötelező beavatkozást.

Egy működési cél teljesülését akkor lehet felelősen elfogadni, ha előre tisztáztuk, milyen változást várunk, hol és milyen időszakban vizsgáljuk, valamint miből igazoljuk az eredményt.

Egy működési cél teljesülését akkor lehet felelősen elfogadni, ha előre tisztáztuk, milyen változást várunk, hol és milyen időszakban vizsgáljuk, valamint miből igazoljuk az eredményt. Elkészült az új rendszer. Megtörtént az oktatás. Az első rendelések átmentek az új folyamaton, a projekt feladatai mellett zöld jelzések sorakoznak. Egy ilyen helyzetben jogos a vezetői kérdés: elértük, amit szerettünk volna? A válaszhoz vissza kell térni a működési célhoz. Az átadás igazolhatja, hogy egy megoldás használható. Azt viszont külön kell megvizsgálni, hogy a vállalat a napi működésben is képes-e tartósan teljesíteni az elfogadott elvárást. — methodological; documented

Mi számít pontosan teljesülésnek? A „jobb ügyfélkiszolgálás” túl tág ahhoz, hogy egyértelműen eldönthessük, megvalósult-e. Érdemes megnevezni, mely vevőket, rendeléseket és kiszolgálási jellemzőket érinti a cél. Például egy kiválasztott termékkörben azt várjuk, hogy a rendelések a vállalt határidőre, megfelelő mennyiségben és hibátlanul érkezzenek meg. Ehhez rögzíteni kell a mérés szabályát is. A rendelés egészét vagy az egyes sorokat értékeljük? Melyik vállalt határidőhöz viszonyítunk? Hogyan számoljuk a részszállítást és a vevő által kért módosítást? Ezek a részletek meghatározzák a mutató jelentését. Ha minden terület másként számol, a közösnek gondolt célszám mögött valójában több eltérő elvárás áll. A számszerű cél mellett megfigyelhető működési feltételek is szükségesek lehetnek. Látható-e minden érintett számára a rendelés állapota? Van-e kijelölt felelőse az eltérésnek? Visszakövethető-e a rendkívüli kedvezmény jóváhagyása? Ezek teljesülését megfelelő esetek áttekintésével és a munkafolyamat ellenőrzésével lehet vizsgálni. — methodological; documented

Mihez és milyen adatokkal hasonlítunk? A kiinduló állapotnak és az elért eredménynek összehasonlíthatónak kell lennie. Ugyanazt a rendelési kört, azonos fogalmakat és következetes adatgyűjtést érdemes használni. Ha a fejlesztés előtt minden késő rendelést számoltunk, utána pedig csak a készletről teljesíthetőket, a javulás egy része a mérés változásából is adódhat. Ugyanez történhet, ha a nehezebb esetek csendben kikerülnek a vizsgált körből. Az adatforrást, a számítás módját és az esetleges kizárásokat ezért előre célszerű rögzíteni. A kizárt esetek maradjanak láthatók, indokkal együtt. Így a vezetés azt is érti, mire nem vonatkozik az eredmény. Ha a korábbi adatok nem megbízhatók, ezt nem lehet egy utólag választott becsléssel eltüntetni. Ilyenkor először a mérés alapját kell rendezni, és pontosan jelezni, milyen összehasonlításra van már lehetőség, illetve mire még nincs. — methodological; documented

Egy jó nap vagy stabil működés? Egy sikeres bemutató vagy rövid próba fontos eredmény, de csak a ténylegesen vizsgált helyzetekről ad bizonyítékot. A teljes működési cél elfogadásához a vállalat szempontjából érdemi terhelést és eseteket kell látni. Képzeljünk el egy nagykereskedőt, amely az új rendeléskezelést egy telephelyen, néhány egyszerű termékkel próbálja ki. A próba hibátlan. Ebből még nem következik, hogy több telephely, készlethiány, részszállítás és sürgős rendelés mellett is ugyanilyen eredmény várható. A megfigyelési időszakot a működés ritmusához kell igazítani. Számíthat a heti rendelési ciklus, a csúcsidőszak vagy egy ritkábban előforduló, de jelentős kockázatú kivétel. Nincs minden vállalatra érvényes, önmagában elegendő nap- vagy esetszám. A próba elfogadható a saját határain belül. A szélesebb körű teljesüléshez szükséges további megfigyelést külön kell megnevezni. Így egy részleges eredmény is hasznos marad, túlzó következtetések nélkül. — methodological; documented

Milyen áron javult az eredmény? A célhoz tartozó feltételeket együtt érdemes értékelni. Gyorsabb lett a kiszolgálás, de jelentősen nőtt a sürgős fuvarok költsége? Csökkent az adminisztráció, miközben a raktár több utólagos javítást végez? Kevesebb lett a készlet, de több vevő vár hiányzó termékre? Az elfogadási feltételekben szerepeljen, milyen minőséget, költséget, terhelést vagy ellenőrizhetőséget kell megőrizni. Ezekhez ugyanúgy szükséges bizonyíték, mint a javítani kívánt mutatóhoz. A környezet változását is figyelembe kell venni. A kisebb forgalom például önmagában rövidítheti az átfutási időt. A javulás mérhető ténye és annak bizonyítása, hogy kizárólag a fejlesztés okozta, két külön kérdés. A következtetés legyen olyan erős, amennyit az adatok valóban alátámasztanak. — methodological; documented

Ki mondja ki, hogy elértük? A döntéshez legyen meg az elfogadott cél, a mérési eredmény, a vizsgált időszak és terület, valamint a fennmaradó eltérések leírása. Az erre felhatalmazott vezető vagy folyamatgazda ezek alapján fogadja el a teljesülést, vagy jelölje meg, mi hiányzik még. A Kyntrax Compassban kialakított célállapot és mérési elvárások ehhez teremtenek közös alapot. A Tunnel részletes megvalósítása és visszamérése később ehhez kapcsolódik. A teljesülés elfogadása után is szükség lehet rendszeres követésre, hogy az elért működés fennmaradjon. A következő projektzáráskor ezért érdemes feltenni a kérdést: Milyen bizonyítékot tudunk megmutatni arra, hogy a kívánt működés a mindennapokban is létrejött, az elfogadott feltételekkel együtt? Kyntrax Compass – Közös célok. Világos prioritások. Mérhető haladás. — methodological; documented

A nagykereskedő szemléltető példa, nem ügyféleredmény. Nincs minden vállalatra elegendő általános nap- vagy esetszám. A mérhető javulás nem önmagában oksági bizonyíték; a saját módszertani közlés nem független igazolás.