GEGEVENSMANAGEMENT deel IV
Een Fossa dit is het grootste roofdier van Madagascar. Het lijkt een beetje op een kleine poema met een spitse snuit; maar het is een Civitkat.
Introductie
In 1980 ben ik in dienst getreden bij KPN. Tot 1987 heb ik in allerlei projecten meegewerkt aan het mega-project Integraal Telecom Informatie Systeem (ITCIS). Zie Een Integraal Systeem deel I en II.
ITCIS was zoals de meeste integrale systemen een heel zware bevalling, waar we het nog relatief goed van afgebracht hebben. Mijn conclusies van dit moeizame traject waren:
1) Systeemontwikkeling moet veel meer al prototypend gebeuren.
Om een systeem te kunnen laten bouwen heb je gedetailleerde specificaties nodig. Het is voor de opdrachtgever lastig om die te beoordelen. De beoordeling gaat veel makkelijker als dat gaat via een aantal prototypes, die evolueren totdat de opdrachtgever zegt: dit wil ik. {die moet dan nog wel even wachten; want een prototype is nog lang geen operationeel systeem!}
2) Bedrijfsbreed GegevensManagement leek me veelbelovend.
Dit zou een mogelijkheid bieden om systemen die met elkaar moeten samenwerken onafhankelijker van elkaar te ontwikkelen. Ook het kopen van een deelsysteem is soms mogelijk.
In 1987 ben ik overgestapt van de automatiseringsafdeling naar het onderdeel GegevensManagement van het InformatieManagement van KPN. In 1988 werd ik hoofd van de GM-afdeling, ongeveer 6 personen.
De afdeling GM bestond al een paar jaar, had vooral onderzoek naar bepaalde systemen en het financiële werkveld gedaan. Ook was er een methode voor gegevensmodellering gekozen: de zogenaamde modellencyclus. Zie hiervoor Gegevensmanagement deel I, II en III. In het onderstaande wordt een globale bekendheid met de terminologie van deze methode bekend verondersteld.
BedrijfsGegevensModel (BGM)
Het bleek al gauw dat we bezig waren met de vierde poging om bij Telecom tot succesvol gegevensmanagement te komen, en dat de verwachting was dat we toch wel binnen een jaar met een aanzet tot een bedrijfsbreed gegevensmodel moesten komen.
Wat in het BGM staat is conform de modellencyclus maar dient een speciaal doel. Een 'gewoon' gegevensmodel wordt ontwikkeld om te leiden tot een database voor een bepaalde toepassing. Het BGM dient om de samenhang tussen de gegevens van het primaire proces van het bedrijf expliciet te maken.
In Gegevensmanagement deel III, is de methode geïntroduceerd als een communicatiemiddel tussen medewerkers van het bedrijf. De methode is gebaseerd op verzamelingenleer en de formele logica; maar de communicatie gebeurt in de vorm van een soort gestructureerd Nederlands. Dit heeft het voordeel dat het laagdrempelig is, terwijl je door zorgvuldig te structureren de dubbelzinnigheid die in natuurlijke talen altijd op de loer ligt, kunt vermijden.
Het BGM vervult de rol van een woordenboek van dat gestructureerde taalgebruik waarmee de gegevens die een rol spelen in het primaire bedrijfsproces kunnen worden beschreven.
De hoofdrol hierbij worden gespeeld door de entiteittypen, die in deze analogie fungeren als de woorden van dat taalgebruik.
Het BGM is nooit klaar; bij nieuwe ontwikkelingen zullen vaak nieuwe entiteittypen geïntroduceerd worden, die als ze van systeemoverschrijdend belang zijn in het BGM opgenomen moeten worden.
Samenwerking rond gegevensmanagement bij Telecom
Een discipline als gegevensmanagement die dient om de informatievoorziening voor het primaire bedrijfsproces efficiënt te maken moet daartoe samenwerking zoeken met alle partijen die deze informatievoorziening gebruiken en beïnvloeden.
Hieronder staat het werkveld schematisch beschreven.
Centraal staan OIT-GM, de naam van de Gevensmanagement-afdeling en I&AT-DBA, de Database-Administrator onderdeel van automatiseringsafdeling van Telecom. { na een reorganisatie was de naam van de GM-afdeling B&IT-GM }
In de vier hoeken staat steeds "LOKAAL RVE". Hierin staat RVE voor Resultaat Verantwoordelijke Eenheid. Daar mee verwijzen we naar de grote onderdelen waaruit Telecom bestaat. Zoals de dertien Telecomdistricten, dit zijn vooral uitvoerende organisaties. En de BusinessUnits zoals het Netwerkbedrijf en het Mobiele Bedrijf, die de telecommunicatie-diensten leveren. Daarnaast zijn er de BusinessUnits Zakelijke Markt en Consumenten Markt: deze zijn verantwoordelijk voor de marketing en verkoop. {Ik pretendeer niet volledig te zijn. Ook de boekhouding en personeelzaken zijn RVE-en}.
De BusinessUnits zijn verantwoordelijk voor de grote landelijke systemen en hebben daar eigen informatiekundigen voor. Het technisch onderhoud gebeurt bij I&AT.
De ontwikkeling van nieuwe systemen gebeurt gewoonlijk op initiatief van een BU, in samenwerking met één of meer districten.
Alle grotere ontwikkelingen worden opgenomen in een jaarplan waarover de directie van Telecom beslist.
De afdeling GM nam bij nieuwe systeemontwikkelingen bij voorkeur met 1 of 2 personen deel in het project. Altijd met de bedoeling dat het project een goed gegevensmodel zou krijgen. Vaak konden we het BGM, of de aanzet daartoe, gebruiken. Vaak leerden we nieuwe entiteittypen voor het BGM, of ontdekten dat hetgeen we al hadden, nog aanpassing behoefte.
Er zijn tussen 1987 en 1994 vijf versies van het BGM uitgebracht. Versie 1 bevatte 107 entiteittypen, versie 5 bevat er 184.
Lokaal gegevensmanagement
De meest RVE-en hebben eigen informatiedeskundigen, die zich bezighouden met het functioneel beheer van de systemen waarvoor de RVE verantwoordelijk is, dat kunnen grote, landelijk gebruikte, systemen zijn, maar ze ontwikkelen ook wel systemen voor eigen gebruik.
Met name Telecomdistricten hebben wel eigen systemen ontwikkeld als aanvulling op de te kortschietende of te trage ontwikkeling van landelijke systemen.
De afdeling GM stimuleerde de kennis over gegevensmanagement op lokaal niveau:
- We gaven zelf cursussen Gegevensmanagement.
- We hadden een Handboek Gegevensmanagement, waarin de aanpak van deze discipline binnen Telecom beschreven stond. En het hele traject van de ontwikkeling van een database volgens de Modellencyclus stond.
- Ook hebben we een folder "Coderen hoe doe je dat" uitgebracht waarin bijvoorbeeld stond onder welke omstandigheden het handig was om een code betekenisvol te maken, en wanneer je dat juist niet moest doen.
Beslissingen over het wijzigen van het BGM
Het BGM werd geproduceerd door de de afdeling GM, onder verantwoordelijkheid van het InformatieManagement.
De voorstellen voor opname en wijzigingen werden opgesteld door de medewerkers van GM. Maar soms ook wel door het lokale gegevensmanagement. Ook de Database-Adminstrator gedroeg zich wel eens als lokaal gegevensmanagement en kwam met wijzigingsvoorstellen.
Voor de beslissingen over de ingediende wijzigingsvoorstellen werd eens in de paar maanden een vergadering belegd met vertegenwoordigers van het lokale gegevensmanagement.
Hun inbreng was belangrijk, en vaak doorslaggevend: met kennis van gm kan je een formeel onberispelijke definitie opschrijven. Maar iemand met praktijkkennis uit het betreffende werkveld kan beter beoordelen of deze de bedrijfswerkelijkheid juist beschrijft. {zo herinner ik me dat we het entiteittype Kabelverdeelkast hadden opgenomen, daarmee wordt verwezen naar de kasten die in de wijken staan als verdeelpunten voor het aansluitnet. Tot we er door iemand uit de praktijk op gewezen werden, dat dergelijke verdeelpunten ook wel eens in een KPN-gebouw staan; maar dan zonder kast. Dat vereiste de introductie van het entiteittype Verdeler; waarbij de Kabelverdeelkast degradeerde tot een kast ter bescherming daarvan. Een definitie heeft geen uitzonderingen!}
Een selectie uit de inhoud van het BGM
{Ik volg in grote lijnen de inhoud van een versie van het BGM. De meer inleidende hoofdstukken pas ik aan bij wat voor deze proeve zinvol is. De echte beschrijvende hoofdstukken bevatten slechts een aantal voorbeelden van een feitelijke inhoud}
Inleidende onderwerpen BGM
Recapitulatie Entiteittypen
Het begint met het universe of discourse. Het universum waarover een zakelijke discussie wordt gehouden door een groep betrokkenen die daarbij geleid worden door bepaalde doelstellingen. In ons geval is dat een projectgroep met medewerkers van Telecom en een of meer gegevensmanagers. Het Universe kan alles omvatten wat met Telecom te maken heeft, en de doelstellingen kan alles zijn wat nodig is om telecommunicatie te kunnen leveren.
Om praktische redenen zal men steeds focussen op een deelgebied van het universum en op de doelstellingen die daarbij een rol spelen.
Alles wat onderscheidbaar is van zijn omgeving in dat deelgebied kan als een object beschouwd worden. De doelstellingen helpen om de relevante objecten te selecteren en in te delen in types.
De doelstelling is bijvoorbeeld het leveren van electrische spanning en stroom, en het objecttype is accu. Nu volgt onze methode de conventie om alle objecten die opgenomen worden in onze gegevensregistratie aan te duiden als entiteit. Elke geregistreerde exemplaar van een batterij is nog steeds een object van het type accu . Maar we kennen iedere accu individueel bijvoorbeeld met een code die bestaat uit drie letters voor het type accu gevolgd door een serienummer van 6 cijfers binnen dat accu-type. In de registratie zal allicht een verzameling accu's voorkomen. Deze verzameling geven we ook de naam van het objecttype. En daarmee hebben we
Entiteittype accu.
Definitie: Een ACCU is een oplaadbaar APPARAAT voor het leveren van spanning en stroom.
Voorbeelden van beweringtypen
- ACCU heeft afmetingen van (L cm, B cm, H cm)
{de categorie aanduidingstype speelt een belangrijke rol in databases. Stel
dat in het Logisch Datamodel staat 'APPARAAT wordt gevoed door ACCU' dan zal het primaire entiteittype APPARAAT in het LDM een kolom hebben voor ACCU, met als kopje bijvoorbeeld "aangesloten-op-ACCU".
De regels in die kolom bevatten dan een waarde conform het aanduidingstype, die de identiteit=sleutel van de betreffende accu bevat . En het apparaat zelf waar de accu op wordt aangesloten wordt ook geïdentificeerd door de eigen aanduiding.
De inhoud van een operationele database is een verzameling tabellen die waarden van aanduidingstypen bevatten}
Het BGM beschrijft de details van de belangrijkste entiteittypen. Maar het kan ook wenselijk zijn om objecttypen op te nemen waarvan geen objecten in de database zitten, denk aan gegevens van een nieuwe dienst die nog niet operationeel is, of een uitgefaseerde dienst. Formeel zijn dat geen entiteittypen, maar objecttypen. Omdat een entiteittype ook een objecttype is, en dezelfde naam heeft als zijn objecttype heeft doen we daar niet moeilijk over.
Die tolerante opstelling maakt dat gegevensverzamelingen van andere bedrijven ook betekenis kunnen hebben in het BGM. Er zijn immers veel gegevens die vaak ook bij andere bedrijven voorkomen: personen, adressen, bankrekeningen, coordinaten, datums, ... . Als we alles beschouwen als objecttypen kunnen we de overeenkomsten zien.
Belangrijk is, dat er voor de aanduidingstypen van dergelijke veel gebruikte objecttypen standaarden zijn. Vaak zijn dat internationale standaarden waarvan Nederland een eigen zogenaamde NEN-norm heeft afgeleid. Het gebruik hiervan wordt conform het beleid van KPN-Telecom in het BGM toegepast.
Werkgebieden
{In het BGM wordt een aantal werkgebieden onderkend. Een werkgebied is een onderscheidbaar onderdeel van het bedrijf of dat ontstaat door een bepaald aspect van de bedrijfsvoering in ogenschouw te nemen. We beschrijven de werkgebieden in termen van de objecten van het BGM.}
- Personen: met personen duiden we alle natuurlijke personen en organisaties die betrokken zijn bij het zakelijk en maatschappelijk verkeer van Telecom
- Produkten&Middelen: Dit omvat alle dingen die onderwerp zijn van het zakendoen. Ze worden door Telecom verhandeld, aangekocht, gebruikt, ect.
- Prestaties: dit gaat over het geven en doen van dingen. De overdracht van producten en middelen dus
- Offerte, Overeenkomst, Klantorder en Nota: dit is de basis van het zakendoen; de wilsovereenstemming. Het juridische jasje van het zakendoen
- Infrastructuur: typisch voor Telecom is de telecommunicatie-infrastructuur. De netten waarlangs het telecommunicatie-verkeer wordt afgehandeld. Zeer gecompliceerd en vereist veel samenwerking ook internationaal.
- Personeel: alles wat zich afspeelt rond de productiefactor arbeid.
- Voorraad: alles rond logistiek, zowel de materiaalbehoefte als de arbeidscapaciteitsbehoefte om de bedrijfsprocessen draaiende te houden.
- Financiële Administratie: van oudsher het instrument voor de besturing van het bedrijf of onderdelen daarvan.
Links staat afgebeeld wat voor soorten personen er gewoonlijk in overeenkomsten gebonden kunnen worden. Bij rechtspersonen is dat wettelijk geregeld. Bij natuurlijke-personen ook, die worden geacht handelingsbekwaam te zijn. Samenwerkingsverband onderscheiden zich van de rechts- en natuurlijke personen doordat ze geen of geen zelfstandig vermogen hebben. Bij informele verenigingen treedt vaak één van de leden als aansprakelijke op.
Rechts staan de rollen waarin personen deel nemen in het zakelijke verkeer.
Prestaties
Dit werkgebied gaat over wat er bij het zaken doen zoal rondom het bedrijf gebeurt. Dus de handelingen van een bedrijf bij het nakomen van overeenkomsten. Die kun je gemakkelijk splitsen in "iets geven" en "iets doen". Bij "iets geven" maak je onderscheid in "het geven van artikelen" en "het geven van geld". Aldus onderscheiden we drie soorten van prestaties: artikel-leveringen, verrichtingen en betalingen.
In de prestaties zouden we een groot aantal detaileringsniveau's kunnen aanbrengen. Een manager zal vaak behoefte hebben aan een heel globaal niveau, en een monteur werkt op detailniveau.
We onderkennen daarvoor in het BGM geen aparte categorieën, maar lossen dat detailverschil op met beweringen:
- LEVERING bevat {Levering#}
- LEVERING is onderdeel van {LEVERING#}
- BETALING bevat {BETALING#}
Leveringen, verrichtingen en betalingen zijn gebeurtenissen die veelal in groepsverband voorkomen. Bijvoorbeeld omdat ze voor dezelfde klant zijn, dat ze op hetzelfde tijdstip betrekking hebben, maar ook omdat ze zich in hetzelfde stadium bevingen.
De objecten die onderwerp zijn van dit werkgebied ontlenen hun naam aan het stadium waarin de leveringen, verrichtingen en betalingen zich bevinden.
OFFERTE
In het offerte stadium maakt Telecom bekend welke leveringen of verrichtingen ze aan een klant aanbiedt en wat ze daar aan betalingen tegenovergesteld wil zien.
OVEREENKOMST
Als een klant zich akkoord verklaart met het geoffreerde dan ontstaan één of meer overeenkomsten. Juridisch gezien worden de leveringen of verrichtingen uit de offerte voor Telecom dan "plichten", terwijl de betalingen "rechten" worden.
KLANTORDER
Als leveringen en verrichtingen in het stadium "overeengekomen" verkeren, dus verplichtingen zijn, dan is een eenvoudige order van de klant voldoende om de leveringen/dienstverleningsmachine van Telecom in beweging te brengen. De betreffende gebeurtenissen gaan dan over in het uitvoeringingsstadium. De klantorder is de trigger voor die processen.
Met het uitvoeringsstadium is het laatste stadium van levering of verrichting ingetreden. Als er sprake is van nacalculatie dan worden van de daaronder vallende leveringen of verplichtingen de juiste omvang gemeten.
NOTA
Met het verzoek aan de klant om betalingen te doen wordt de gebeurtenis-cyclus afgesloten. Telecom claimt haar verworven rechten. Bij nacalculatie kan dat pas na de levering. Voor andere soorten is de omvang al voor de uitvoering bekend. Bij grote projecten kan zelfs voor de start van de uitvoering een vooruitbetaling worden gevraagd
De selectie HANDEL uit het BGM
Reacties op het BGM
De belangrijkste reacties op het BGM, kwamen wat mij betreft uit de telecomdistricten; daar zitten de mensen die werken in de praktijk die in het BGM beschreven wordt. Ik behandel twee belangrijke geheel verschillende reacties;
Wat voor nieuws staat er in het BGM?
De vraagsteller bedoelde daarmee dat zaken als: rechtspersoon, debiteur, aanbiedingsvorm en offerte juist en uitgebreid beschreven stonden in het BGM, maar dat er niets echts nieuws aan toegevoegd werd.
Na enige reflectie vond hij wel dat dit nu eenmaal hoort bij het BGM als woordenboek van de gegevens. Als je een taal grondig kent dan kom je in een woordenboek niet gauw iets nieuws tegen. Misschien was het wel een verdienste van het BGM dat voor de vraagsteller alles bekend was.
Is het budget beschikbaar om de informatievoorziening aan te passen aan het BGM.
Een goede maar ongemakkelijke vraag. Het BGM is het woordenboek van de taal waarmee de medewerkers met elkaar praten over de objecten van Telecom. De bedoeling is natuurlijk dat ook de informatiesysteem die taal moeten verstaan. Maar dat doen ze in eerste instantie natuurlijk nog niet, en ‘even’ aanpassen van de systemen is niet alleen onbetaalbaar maar het levert ook niets op. Want deze legacy-systemen zoals ze zijn, vervullen hun taak immers in het algemeen naar behoren.
Een makkelijk antwoord op deze ongemakkelijke vraag luidt dat het de bedoeling is dat bij nieuwe ontwikkelingen het BGM wordt gevolgd; zodat de informatievoorziening kan evolueren richting BGM.
Er is ook een fundamenteler antwoord: We gaan ervan uit dat we bij het maken van het BGM ons werk goed hebben gedaan:
- We hebben bij het Universe of Discourse medewerkers betrokken die de bedrijfswerkelijkheid op de besproken punten goed kenden.
- We hebben bijdragende doelstellingen geformuleerd die nodig en noodzakelijk zijn om de doelstelling van het bedrijf na te streven.
- Bij iedere doelstelling zijn functies gedefinieerd waarmee de gegevens worden geproduceerd nodig en noodzakelijk om de doelstelling na te streven.
Comments