- Přehledy IS
- APS (21)
- BPM - procesní řízení (23)
- Cloud computing (IaaS) (9)
- Cloud computing (SaaS) (29)
- CRM (49)
- DMS/ECM - správa dokumentů (19)
- EAM (16)
- Ekonomické systémy (68)
- ERP (87)
- HRM (27)
- ITSM (6)
- MES (32)
- Řízení výroby (47)
- WMS (28)
- Dodavatelé IT služeb a řešení
- Datová centra (25)
- Dodavatelé CAD/CAM/PLM/BIM... (40)
- Dodavatelé CRM (36)
- Dodavatelé DW-BI (50)
- Dodavatelé ERP (80)
- Informační bezpečnost (42)
- IT řešení pro logistiku (46)
- IT řešení pro stavebnictví (25)
- Řešení pro veřejný a státní sektor (26)
Tematické sekce
ERP systémy
CRM systémy
Plánování a řízení výroby
AI a Business Intelligence
DMS/ECM - Správa dokumentů
HRM/HCM - Řízení lidských zdrojů
EAM/CMMS - Správa majetku a údržby
Účetní a ekonomické systémy
ITSM (ITIL) - Řízení IT
Cloud a virtualizace IT
IT Security
Logistika, řízení skladů, WMS
IT právo
GIS - geografické informační systémy
Projektové řízení
Trendy ICT
E-commerce B2B/B2C
CAD/CAM/CAE/PLM/3D tisk
CRM systémy
Plánování a řízení výroby
AI a Business Intelligence
DMS/ECM - Správa dokumentů
HRM/HCM - Řízení lidských zdrojů
EAM/CMMS - Správa majetku a údržby
Účetní a ekonomické systémy
ITSM (ITIL) - Řízení IT
Cloud a virtualizace IT
IT Security
Logistika, řízení skladů, WMS
IT právo
GIS - geografické informační systémy
Projektové řízení
Trendy ICT
E-commerce B2B/B2C
CAD/CAM/CAE/PLM/3D tisk
Branžové sekce
Partneři webu
Performance management v praxi
-PR-
Snad v každém informačním systému je možné najít dva základní typy dat. Stavová a transakční data. Zatímco stavová data zachycují stav objektů k určitému momentu v čase, transakční data zachycují změny těchto stavů.
V řadě oblastí jsou transakční data nenahraditelná. Obsahují řadu informací, které ve stavových datech nenajdeme. Je jen těžko představitelné, že bychom například neznali podrobně jednotlivé transakce na našem účtu. Zatímco stav našeho účtu je sledován vždy ke konci určitého období, transakce zachycují zcela podrobně jednotlivé změny včetně informací o tom, komu nebo od koho peníze na účet přicházely, za jakým účelem transakce proběhla apod.
V primárních systémech je však zpravidla také celá řada entit, kde se podrobné informace o změnách jejich stavů nesledují. Pokud pak pro potřeby manažerského informačního systému tato data od primárních systémů požadujeme, primární systémy je zpravidla určitým způsobem zpětně vytvářejí. Tento postup potom často vede k nepřesnostem a výsledkem je nesoulad mezi zpracovávanými „transakcemi“ a jejich výsledným stavem a rostoucí nedůvěra k datům v datovém skladu a MIS vůbec.
Příkladem takovýchto transakcí jsou například transakce spojené se změnami zákaznických smluv. Každá smlouva prochází za svůj život celou řadou „stavů“. Na počátku je smlouva ve stavu návrhu, po podpisu vstoupí v platnost, za čas je navýšena nebo je na ní změněn nějaký tarif, pak se prodlouží a nakonec dojde k jejímu ukončení. Ačkoliv každá z těchto změn reflektuje určitou transakci – tedy operaci se smlouvou, tak v primárním systému jsou tyto změny zpravidla zachyceny změnou několika atributů, například: stav (aktivní, neaktivní), hodnota smlouvy (tarif smlouvy) a série dat – datum zaslání návrhu, datum účinnosti, datum platnosti do, datum ukončení, případně prodejní kanál, který provedl poslední změnu.
Pro MIS poskytující konzistentní informace nejen o stavu našich smluv, ale zejména o výkonnosti jednotlivých útvarů je pak nezbytně nutné vycházet z dobře historizovaných dat v datovém skladu. I v takovém případě je však reporting jednotlivých událostí (transakcí) často obtížný a nejednoznačný. GLOBTECH se svými partnery – společnostmi DNS a IBM – v takových případech úspěšně implementuje koncept tzv. tagování na základě business pravidel. Namísto vyžadování transakčních informací z primárních systémů se při implementaci MIS soustředíme na důsledné sledování stavu – důslednou historizaci všech stavových entit – a precizní popis business pravidel. Business pravidla jsou v rámci projektu popsána do podoby business slovníku (například v IBM InfoSphere Business Glossary) a odsouhlasena napříč společností.
Pro každou entitu jsou v business slovníku jednoznačně definovány business stavy (často více stavů než poskytuje primární systém) a dimenze (atributy entit), u kterých budou sledovány změny. Takto připravená pravidla jsou následně „materializována“ v datovém skladu – na základě pravidel jsou přímo v datovém skladu napočítány business stavy a následně jsou generovány transakční záznamy (tagy) reflektující změny ve stavech a na vybraných dimenzích. Tyto transakce jsou pak obohaceny o další atributy charakterizující daný záznam (transakci).
Ve výše uvedeném příkladu se pak dva stavy z primárního sytému například rozšíří na čtyři – smlouva ve stavu návrhu, aktivní a zrušená. Atributy hodnota smlouvy (tarif) a platnost smlouvy do se definují jako dimenze se sledováním změn. A atribut prodejní kanál se používá pro obohacení každé transakce. Z takto připravených dat jsou každodenně generovány jednoznačné transakce: počet zaslaných návrhů, počet uzavřených smluv, pročet ukončených smluv, počet prodloužených smluv, počet změn tarifů s jednoznačnou vazbou na prodejní kanál, který transakci provedl, a hodnotu smlouvy (tarif).
Napočtená data pak zaručují velice přesný a transparentní přehled o fungování společnosti – o výkonnosti jednotlivých složek – a současně zajišťují konzistenci stavových a transakčních dat a tím i důvěryhodnost celému manažerskému informačnímu systému. Současně je v případě rozšíření o další dimenze poměrně snadné systém doplnit o další ukazatele bez narušení vnitřní integrity dat.
Autor působí jako senior konzultant ve společnosti GLOBTECH, spol. s r.o.
GLOBTECH, spol. s r.o.
Karlovo nám. 17
Praha 120 00
Email: info@globtech.cz
V řadě oblastí jsou transakční data nenahraditelná. Obsahují řadu informací, které ve stavových datech nenajdeme. Je jen těžko představitelné, že bychom například neznali podrobně jednotlivé transakce na našem účtu. Zatímco stav našeho účtu je sledován vždy ke konci určitého období, transakce zachycují zcela podrobně jednotlivé změny včetně informací o tom, komu nebo od koho peníze na účet přicházely, za jakým účelem transakce proběhla apod.
V primárních systémech je však zpravidla také celá řada entit, kde se podrobné informace o změnách jejich stavů nesledují. Pokud pak pro potřeby manažerského informačního systému tato data od primárních systémů požadujeme, primární systémy je zpravidla určitým způsobem zpětně vytvářejí. Tento postup potom často vede k nepřesnostem a výsledkem je nesoulad mezi zpracovávanými „transakcemi“ a jejich výsledným stavem a rostoucí nedůvěra k datům v datovém skladu a MIS vůbec.
Příkladem takovýchto transakcí jsou například transakce spojené se změnami zákaznických smluv. Každá smlouva prochází za svůj život celou řadou „stavů“. Na počátku je smlouva ve stavu návrhu, po podpisu vstoupí v platnost, za čas je navýšena nebo je na ní změněn nějaký tarif, pak se prodlouží a nakonec dojde k jejímu ukončení. Ačkoliv každá z těchto změn reflektuje určitou transakci – tedy operaci se smlouvou, tak v primárním systému jsou tyto změny zpravidla zachyceny změnou několika atributů, například: stav (aktivní, neaktivní), hodnota smlouvy (tarif smlouvy) a série dat – datum zaslání návrhu, datum účinnosti, datum platnosti do, datum ukončení, případně prodejní kanál, který provedl poslední změnu.
Pro MIS poskytující konzistentní informace nejen o stavu našich smluv, ale zejména o výkonnosti jednotlivých útvarů je pak nezbytně nutné vycházet z dobře historizovaných dat v datovém skladu. I v takovém případě je však reporting jednotlivých událostí (transakcí) často obtížný a nejednoznačný. GLOBTECH se svými partnery – společnostmi DNS a IBM – v takových případech úspěšně implementuje koncept tzv. tagování na základě business pravidel. Namísto vyžadování transakčních informací z primárních systémů se při implementaci MIS soustředíme na důsledné sledování stavu – důslednou historizaci všech stavových entit – a precizní popis business pravidel. Business pravidla jsou v rámci projektu popsána do podoby business slovníku (například v IBM InfoSphere Business Glossary) a odsouhlasena napříč společností.
Pro každou entitu jsou v business slovníku jednoznačně definovány business stavy (často více stavů než poskytuje primární systém) a dimenze (atributy entit), u kterých budou sledovány změny. Takto připravená pravidla jsou následně „materializována“ v datovém skladu – na základě pravidel jsou přímo v datovém skladu napočítány business stavy a následně jsou generovány transakční záznamy (tagy) reflektující změny ve stavech a na vybraných dimenzích. Tyto transakce jsou pak obohaceny o další atributy charakterizující daný záznam (transakci).
Ve výše uvedeném příkladu se pak dva stavy z primárního sytému například rozšíří na čtyři – smlouva ve stavu návrhu, aktivní a zrušená. Atributy hodnota smlouvy (tarif) a platnost smlouvy do se definují jako dimenze se sledováním změn. A atribut prodejní kanál se používá pro obohacení každé transakce. Z takto připravených dat jsou každodenně generovány jednoznačné transakce: počet zaslaných návrhů, počet uzavřených smluv, pročet ukončených smluv, počet prodloužených smluv, počet změn tarifů s jednoznačnou vazbou na prodejní kanál, který transakci provedl, a hodnotu smlouvy (tarif).
Napočtená data pak zaručují velice přesný a transparentní přehled o fungování společnosti – o výkonnosti jednotlivých složek – a současně zajišťují konzistenci stavových a transakčních dat a tím i důvěryhodnost celému manažerskému informačnímu systému. Současně je v případě rozšíření o další dimenze poměrně snadné systém doplnit o další ukazatele bez narušení vnitřní integrity dat.
Autor působí jako senior konzultant ve společnosti GLOBTECH, spol. s r.o.
GLOBTECH, spol. s r.o.
Karlovo nám. 17
Praha 120 00
Email: info@globtech.cz
duben - 2024 | ||||||
Po | Út | St | Čt | Pá | So | Ne |
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 1 | 2 | 3 | 4 | 5 |
6 | 7 | 8 | 9 | 10 | 11 | 12 |
IT Systems podporuje
Formulář pro přidání akce
Další vybrané akce