GEGEVENSMANAGEMENT deel IV versie 1.0

  

 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. Jaagt in de bomen op Maki’s (halfapen)

Introductie deel IV het BGM

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. {Hij 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 een elders ontwikkeld systeem kan soms goed ingepast worden.

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 essentiele gegevens van het primaire proces van het bedrijf expliciet te maken. 

In Gegevensmanagement deel III, is de modellencyclus geïntroduceerd als een methode die de bedrijfsgegevensverzameling beschouwt als een communicatiemiddel tussen medewerkers van dat 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 werd de naam van de GM-afdeling B&IT-GM }

                                                                                                                       

In de vier hoeken staat steeds "LOKAAL RVE". Hierin staat RVE voor Resultaat Verantwoordelijke Eenheid. Daarmee 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. Meestal 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 bevatte 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 selectie zinvol is. De echte beschrijvende hoofdstukken bevatten slechts een aantal voorbeelden van een feitelijke inhoud. We concentreren hierbij op de handel; vooral verkoop en levering}

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 kunnen 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 typen. 

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 accu 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)  

- ACCU heeft een gewicht van K kilo

- ACCU levert een spanning van V volt

- ACCU heeft een capaciteit van C ampère-uur

Aanduidingstype

Type ACCU     :3A

Volgnummer   :6N

{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 natuurlijk wel objecttypen. Omdat een entiteittype ook een objecttype is, en dezelfde naam heeft als zijn objecttype heeft doen we daar in het BGM niet moeilijk over. 

Die tolerante opstelling maakt dat we objecttypen van gegevensverzamelingen van andere bedrijven kunnen vergelijken met die van 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 nog, dat er voor de aanduidingstypen van sommige 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. Vele entiteittypen hebben als rubriek de naam van het aanbevolen aanduidingstype. En in het BGM staat achter het katern met de beschrijving van de entiteittypen/objecttypen een katern met een beschrijving van de aanduidingstypen

Formele Specificatie

Dit is een enigszins abstract onderwerp dat te maken heeft met het ontstaan van objecttypen uit andere objecttypen. 

{je kan dit concept negeren, maar soms is het heel verhelderend}

In Post Geg.man.deel II hebben we de volgende algemene gedaante van een definitie geïntroduceerd: Een BLIE is een BLA die 'bliept'.

Hierin staat BLIE voor het objecttype dat gedefinieerd wordt; BLA is de generale verzameling waartoe BLIE behoort; en 'bliept' is het criterium waarmee BLIE geselecteerd wordt uit BLA.

(Bijvoorbeeld Een VRACHTAUTO is een AUTO die bedoeld is voor het vervoeren van vracht)

De formele specificatie is een typering van de structuur van het criterium  'bliept' dat dient om  BLIE te selecteren uit de generale verzameling BLA. 'bliebt' is een stukje tekst; maar interessant is vooral of er andere objecttypen in het criterium voorkomen. Als dat het geval is, dan wordt het objecttype BLIE gedefinieerd met behulp van die objecttypen; en dat maakt het BGM compact. 

In Post Geg.man. deel III ben je bij het gegevensmodel van de bibliotheek het objecttype "reservering" tegengekomen dat ontstaat uit de beide objecttypen "soort boek" en "klant". Deze constructie noemen we een aggregatie, en is een voorbeeld van een formele specificatie. "uitlening" is ook een aggregatie maar dan van "boek" en "klant". 

Er zijn vijf typen formele specificaties:

• ELEMENTAIR: Dit betekent dat er niet wordt verwezen naar andere objecttypen. De definitie volgt het gangbare spraakgebruik. Bijvoorbeeld Een NATUURLIJK-PERSOON is een mens of Een NATUURLIJK-PERSOON is een mens die handelingsbekwaam is. Als je echter bezig bent met een UOD over paleo-antropologie (afstamming van de mens) dan kun je er niet van uitgaan dat je gebruikers overeenstemming hebben over wat een 'mens' is. En zul je naar een objecttype met de naam van een mens(aap)achtige moeten verwijzen.
• SPECIALISATIE. Dit betekent dat het te definiëren objecttype wordt gekaraktiseerd door eigenschappen van het objecttype waarvan het een bijzonder geval is. Bijvoorbeeld een MEERDERJARIGE als specialisatie van NATUURLIJK-PERSOON. Het criterium is dan de eigenschap leeftijd is 18 jaar of ouder.
• ROL.  Verwant aan specialisatie is ook al behandeld bij het bibliotheekmodel. Het verschil is dat een specialisatie gaat om een intrinsieke eigenschap, en een rol om een wijze waarin het gedefinieerde zich soms voordoet. 
• GENERALISATIE. Het tegenovergestelde van Specialisatie. Een objecttype wordt gedefinieerd als een vereniging van twee of meer andere objecttypen. Bijvoorbeeld Een PERSOON is een NATUURLIJK-PERSOON of een RECHTSPERSOON.
• CLASSIFICATIE. Een classificatie verzamelt objecten van een objecttypen tot klassen (verzamelingen van objecten) waarbinnen de identiteit van de individuele objecten vanuit een bepaald gezichtspunt verloren gaat. Bijvoorbeeld Een SPECIALIST is een classificatie van MEDEWERKER op grond van vakspecifieke bekwaamheid.
• AGGREGATIE. Bij een aggregatie ontstaat een nieuw objecttype uit het verband tussen andere objecttypen. Deze zijn essentieel voor de identiteit van dat nieuwe objecttype. Bijvoorbeeld Een UITLENING is de tijdelijke overdracht van een BOEK aan een KLANT.  Een ander exemplaar van BOEK of een andere KLANT betekent een andere UITLENING. Een aggregatie is of een gebeurtenis of een concept.
• PARTITIE. Een partitie kan als bijzonderheid voorkomen binnen aggregaties. Dat komt voor als er een aantal objecten van  hetzelfde objecttype in een en dezelfde aggregatie voorkomen. Deze objecten onderscheiden zich slechts van hun type-genoten door deelname aan de betreffende aggregatie. Bijvoorbeeld UITLENING wordt in de bibliotheek verruimd tot een of meer BOEKen per KLANT. Een UITLENING is een tijdelijke overdracht van een of meer BOEKen aan een KLANT. Formele specificatie: aggregatie van {BOEK} aan KLANT. [dat deze aggregatie een partitie is blijkt uit { en } rond BOEK. Door deze verandering zou er ook het een en ander wijzigen aan de opzet   van onze bibliotheek; maar de partitie UITLENING verandert niet als er een BOEK terug gebracht wordt, terwijl anderen uitgeleend blijven. Immers de uitlening is een gebeurtenis, en die verandert niet.]

Bijna alle entiteittypen hebben een rubriek voor de formele specificatie.

Tot zover de recapitulatie van entiteittypen.

De selectie Handel uit het BGM bestaat uit een alfabetische lijst van de voorkomende entiteittypen,  een lijst met de daarbij behorende aanduidingstypen, en een lijst met overige opgenomen begrippen die een rol in de definities spelen.

 

We beginnen met een alfabetische index van alle opgenomen typen en begrippen.

Omdat de beschrijving van de entiteittypen zowel in de definitie als in de opgenomen beweringtypen vaak weer andere entiteittypen bevat kunnen we niet volledig zijn; noch met de gerelateerde entiteiten noch met de opgenomen beweringtypen. Omdat in het BGM alles indirect met elkaar verbonden is, zou de selectie Handel dan het volledige BGM omvatten; en dat is niet de bedoeling.

Het nut van het BGM is, dat bij twijfel of een bepaald object tot een bepaald objecttype hoort een definitie uitsluitsel geeft. In de dagelijkse praktijk hoort de naam van een objecttype voldoende te zijn voor de gebruikers. Een BGM is daarom alleen maar zinvol als de definities scherp zijn. Scherpe definities maken gegevens optelbaar. 

Hieronder worden een opsomming van de werkgebieden die door het BGM behandeld worden. De selectie Handel beperkt zich tot drie werkgebieden.

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 aan 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 
• 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. 

In deze selectie  beperk ik me tot drie werkgebieden die tezamen het leeuwendeel van het bedrijven van handel omvatten: Personen, Prestaties en Offerte-Overeenkomst-Klantorder-Nota.

{ Producten en Middelen laat ik er bewust buiten omdat ik de selectie niet telecommunicatie-specifiek wil maken }

Personen

De eerste gedachte hierbij is aan mensen. Die gedachte is te beperkt ook allerlei lichamen, niet van vlees en bloed, denk aan rechtspersonen kunnen zaken doen.

Het gaat om personen waarmee je overeenkomsten kan sluiten. Essentieel zijn echter de personen die door de overeenkomst gebonden worden. Als een bedrijfsdirecteur in een showroom een auto bestelt bij een verkoper; dan kan het heel goed zijn dat noch die directeur noch de verkoper persoonlijk door die overeenkomst gebonden zijn, maar de N.V. van directeur en de B.V. van de dealer waar de verkoper voor werkt. Ze kunnen natuurlijk wel door dat bedrijf en die dealer ter verantwoording worden geroepen omtrent de overeenkomst, maar niet door de rechter.

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. Samenwerkingsverbanden 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 of verkoper werkt op vaak 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#}

Bij prestaties maak je ook onderscheid of ze ingaand of uitgaand zijn, terwijl ze ook intern kunnen zijn: het ene bedrijfsonderdeel aan het andere.

Vrijwel alle leveringen betreffen standaardproducten dat wil zeggen dat de begunstigde geen voorkeur heeft voor een specifiek exemplaar van een product maar genoegen neemt met een identiek exemplaar. Ze zijn verwisselbaar voor de klant. {Tweedehands goederen en ook kunst kennen dus geen standaardleveringen}. 

Een artikel is een zaak met een zeker economisch nut. Bij een materieel artikel zit de waarde in de materie. Een immaterieel artikel heeft ook een waarde maar die zit niet in de materie bijvoorbeeld een computerprogramma of een advies.

Bij verrichtingen wordt er niets overgedragen aan de klant. De waarde verdwijnt naarmate de verrichting vordert. Bijvoorbeeld "de tuin wordt omgespit". Na afloop is de verrichting verdwenen maar de begunstigde heeft wel het resultaat.

Offerte, Overeenkomst, Klantorder en Nota

 

 

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 bevinden.

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"

{LEESWIJZER: Na de bovenstaande inleidingen op het BGM, is dit de meest logische plaats om de appendix met deze selectie uit het BGM te lezen. 

 

OMDAT de selectie "HANDEL uit het BGM" niet bedoeld is om in zijn geheel grondig gelezen te worden; maar om naar behoefte in te browsen. staat deze in een appendix aan het einde van de Post. 

ECHTER onmiddellijk hieronder staan de reacties die ik op het BGM kreeg. En wordt ook beschreven hoe het verder ging met het BGM en Gegevensmanagement bij Telecom. Daarvoor is het wenselijk om kennis gemaakt te hebben met het BGM.

ADVIES: Browse een beetje in de appendix, en keer daarna terug naar deze leeswijzer. De onderstaande paragrafen zijn interessant.  Ze eindigen bij de appendix en daarna kun je naar hartelust verder browsen.

Einde van de Leeswijzer}

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, en van de vraagsteller, dat voor hem bijna 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 zakelijke bezigheden van Telecom.  De bedoeling is natuurlijk dat ook de informatiesystemen die taal verstaan. Maar dat doen ze in eerste instantie nog niet, en ‘even’ aanpassen van de systemen is niet alleen onbetaalbaar maar het levert functioneel weinig op. Want deze legacy-systemen zoals ze zijn, vervullen hun taak immers in het algemeen naar behoren. De winst die aanpassen aan het BGM oplevert zit in de efficiëntie en de kwaliteit van de communicatie, bijvoorbeeld het elimineren van handmatige interfaces.

 

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.

Als aan deze voorwaarden voldaan is. Dan moet de informatie-inhoud van de essentiele gegevens uit een legacy-systeem afbeeldbaar zijn op de informatie-inhoud van gegevens volgens het BGM. Met andere woorden er zijn altijd interfaces mogelijk. 

Het is echter niet zo dat er altijd een 1-1-afbeelding mogelijk is; het zal vaak complexer zijn dan dat. 

De voordelen van het gebruik van het BGM: het efficiënter communiceren in de uitvoering van het bedrijf heeft weinig management-appeal: ze zijn veelal niet op de hoogte van de problemen in die communicatie. Het schetsen van het oplossen ervan met het BGM, kan een mooi verhaal zijn. Maar het klinkt onmiskenbaar als een lange termijn oplossing. 

Het bleek echter wel snel te kunnen!

In de post Gegevensmanagement Deel II wordt in de paragraaf "Een uitstapje in de tijd" het systeem KADO genoemd. De naam staat voor Klant Dossier, en was een applicatie op een PC waarop van alle klanten hun  installed base aan door Telecom geleverde producten werden getoond.

Dit systeem van de afdeling Kennis Centrum Informatica, maakte grote indruk. Op de PC werden alle klanten in begrijpelijke taal gepresenteerd met een overzicht van hun aansluitingen op de infrastructuur met de daarop geïnstalleerde voorzieningen en permanente producten.  

Hans K de manager van KCI hield de manier waarop KADO was gerealiseerd binnenskamers. Maar het gegevensmodel was gebaseerd op het BGM, en de klantgegevens werden bij elkaar gezocht met CKR. De vertaling naar het BGM gebeurde met complexe Match-en-Merge programma's in SQL.

Hoe het verder ging met gegevensmanagement

Ik ben in 1994 weggegaan bij GM, na mijn vertrek is in december van dat jaar de laatste versie van het BGM verschenen. Ik had daarna andere functies binnen B&IT, waarover in een volgende Post meer. 

B&IT kwam langzamerhand steeds meer onder druk en dat uitte zich in regelmatige reorganisaties; in mijn herinnering was dat ongeveer jaarlijks.   

De verdere geschiedenis van gm loopt langs drie sporen:

1. Een alternatief voor centraal gegevensmanagement,
2. Een alternatief voor het BGM
3. De OrderManager van ICT-Innovatie.

Er is geen duidelijke relatie tussen de drie sporen: ze spelen alle drie in ongeveer dezelfde periode.

1) Een alternatief voor centraal gegevensmanagement.

Dat was het idee dat de werkzaamheden van de afdeling GM beter zouden kunnen worden uitgevoerd binnen de afdeling B&IT-Operations; dat wil zeggen dichter bij de operationele processen en het functioneel beheer van systemen. 

Ik was toen al weg bij GM en vond het idee niet zo gek: misschien was dat wel een goede plek. Gerard F voelde er wel wat voor om het daar te gaan proberen. Hij had ervaring met het systematisch schonen van gegevens, in combinatie met het verbeteren van de processen om de oorzaak van de fouten te elimineren. Zie de post Gegevensmanagement deel III paragraaf Een stimuleringsbudget kwaliteitsborging van Gegevens.

Gerard F heeft het daar niet zo lang volgehouden. Hij heeft vooral wat rapporten geschreven die nooit uitgevoerd werden. Zonder een stimuleringsbudget lagen de prioriteiten elders. 

Ik denk dat binnen het Netwerkbedrijf gegevensmanagement wel langere tijd is blijven bestaan: er was nog in mijn tijd een goed gegevensmodel door Ronald en Chris voor de Netwerk-administratie gemaakt. En een betrouwbare administratie van het Net is voor Telecom essentieel.

2) Een alternatief voor het BGM

Volgens mij leefde binnen de automatiseringsafdeling I&AT het gevoel dat alles wat bij B&IT bedacht werd veel makkelijker kon. Een vooraanstaande functionaris bij I&AT slaagde erin een groepje van een man of vier op te richten onder leiding van ene Spijkervet, zij mocht proberen zaken die B&IT deed anders en beter te doen. Welke successen ze voor andere activiteiten van B&IT behaald hebben weet ik niet; maar ik heb wel enige betrokkenheid gehad bij hun werkzaamheden rond Gegevensmanagement en daar was ik niet van onder de indruk. 

De enige remedie tegen de slechte kwaliteit van gegevens die ik van hen gehoord heb was: "220 volt op de toetsen als ze het fout doen". Dat was natuurlijk een grapje; maar als gegevensmanager kom je daar niet mee weg. Je moet het voor een medewerker die een rubriek invult aantrekkelijker maken om het goed dan fout te doen. En dat is verre van triviaal.

Men meende een veel beknopter BGM te kunnen maken door zich te richten op objecten die over de grenzen van systemen en/of afdelingen werden uitgewisseld. Ze wilden een Bedrijfs Uitwisselings Gegevens  Model (BUGM) maken. En dat zou veel beknopter zijn dan het BGM. 

Het BUGM zou ook veel instabieler zijn dan het BGM want vooral de grenzen tussen afdelingen wijzigen bij elke reorganisatie. Bovendien als de uitwisselingsgegevens van belang zijn, en dus doelstellingen ondersteunen dan staan ze al in het BGM. En als een bepaald gegevenstype na een reorganisatie niet langer uitgewisseld wordt; verwijder je het dan met alle informatie die erop gebaseerd is?

Men wilde kennelijk graag opnieuw beginnen want ze organiseerden voor hun groep een cursus gegevens-management door Panfox, de voortzetting van Brainforce waar OIT-GM, de cursus bij gevolgd heeft. Zie de Post Geg.man deel III onder het kopje De modellencyclus voor het maken van een gegevensmodel.

Ik had er als ex-hoofd GM geen behoefte aan om de opdrachtgever van de groep Spijkervet te gaan uitleggen, dat hij zijn budget beter kon besteden. Dat was ook niet nodig; want na enige tijd werd de groep collectief ontslagen. Naar verluidt vonden ze dat niet zo erg: ze zaten allen tegen hun pensioen aan; en hadden leuk aan deze klus verdiend. 

3) De OrderManager van ICT-Innovatie.

Vanwege het succes van KADO werd de afdeling afdeling KennisCentrumICT uitgebouwd tot ICT-Innovatie. Hans K had het BGM een steuntje in de rug kunnen geven, maar hield zijn kaarten tegen de borst. 

Hij had alle kennis erover in huis: want zijn medewerkster Liesbeth had altijd deelgenomen aan de vergaderingen  over de ingebrachte wijzigingsvoorstellen op het BGM met de vertegenwoordigers van het lokale gegevensmanagement. Zie de bovenstaande paragraaf Samenwerking rond Gegevensmanagement bij Telecom. En hij had medewerkers die de, inmiddels gepatenteerde, SQL-processen Match and Merge hadden ontwikkeld om bestaande systemen op het BGM af te beelden. 

Bij de opheffing van B&IT heeft hij mij als enige medewerker daarvan overgenomen. Zoals in de paragraaf Een uitstapje in de tijd in post Geg.man. deel II staat werkte ik al gauw aan een concept voor de door Hans K bedachte OrderManager. Deze werd op het BGM en de bijbehorende methode gebaseerd; terwijl de wijze waarop de klantgegevens werden getoond was afgeleid van KADO. De combinatie van KADO met een Ordermanager maakte de installed base van KADO muteerbaar. En dat alles in de taal van het BGM.

==================================================

SELECTIE HANDEL BGM 

    Algemene Index

    Gebruikte afkortingen in de index  

•      e entiteittype
•      a aanduidingtype
•      o overige begrippen   

___________________________________________________

 

    e  AANBIEDINGSVORM

    a  AANTAL

    a  ADRES

    a  AFDELINGSNAAM-VERKORT

    a  AFDELINGS OMSCHRIJVING

    e  ARTIKEL

    e  ARTIKEL-LEVERING

    e  BEDRIJFSONDERDEEL

    e  BEDRIJFSORGAAN

    e  BETALING

    e  DEBITEUR

    a  DEBITEURENNUMMER

    o  ‘dubieuze debiteur’

    a  EENHEID

    o  ‘hoofdvestiging’

    e  IMMATERIEEL-ARTIKEL

    e  KLANT

    e  KLANTORDER

    e  LEVERANCIER

    e  LEVERING

    e  MATERIEEL-ARTIKEL

    e  NATUURLIJK-PERSOON

    a  NATUURLIJK-PERSOONSNAAM

    o  ‘nevenvestiging’

    e  NIET-NATUURLIJK-PERSOON

    a  NIET-NATUURLIJK-PERSOONSNAAM

    e  NORM-VERRICHTING

    e  NOTA

    e  OFFERTE

    e  OMVANG

    o  ‘omzet’

    o  ‘onderneming’

    e  OVEREENKOMST

    e  PERSOON

    a  PERSOONSNAAM

    e  PROJECTACTIVITEIT

    e  PROJECTGROEP

    e  RECHTSPERSOON

    e  RECHTSSUBJECT

    o  ‘resultaat-verantwoordelijk’

    e   SAMENWERKINGSVERBAND

    e   SOORT-APPARAAT

    e   SOORT-ARTIKEL

    e   SOORT-VOORZIENING

    e   STANDAARD-LEVERING

    e   STANDAARD-PRODUKT

    e   VERKOOPNOTA

    o   ‘verkoopprijs’

    e    VERRICHTING

    e    VOORZIENING

---------------------------------------------------------    

Overzicht Entiteitypen

                                                                           

                                                                              

                               

       

                  ______________________________________________________________

                 entiteittype          NOTA           (zie VERKOOPNOTA)

            

          

        

                   

                        

---------------------------------------------------------

Overzicht Aanduidingtypen

       

              

                   

                  

        

                         

          

                

           

                               

             

 

-----------------------------------------------------------------------------

Overzicht overige begrippen

 'dubieuze debiteur"                                                                              

 Een debiteur wordt als dubieus gekwalificeerd indien Telecom aanneemt  dat één of meer vorderingen op de betreffende debiteur niet of slechts gedeeltelijk te innen zijn.

'hoofdvestiging'

De vestiging waar het rechtssubject resideert. 'hoofdvestiging' wordt door de KVK aangegeven met 'hoofdzaak'.

'nevenvestiging'

De vestiging waar het rechtssubject zich manifesteert, maar niet resideert.

‘omzet’

Het totaal van de verkopen van een onderneming of een bedrijfsonderdeel in een bepaalde periode

'onderneming'

Een samenstel van activiteiten die onder een naam worden uitgevoerd met als doel winst te maken.

'organisatorische-relatie'

De wijze waarop een persoon zich, vanuit organisatorisch oogpunt beschouwd, zich verhoudt tot een ander persoon

'resultaat-veranwoordelijk'

Er is sprake van resultaat-verantwoordelijkheid zodra een bedrijfsonderdeel zich over het behaalde resultaat moet verantwoorden bij een "hoger" bedrijfsonderdeel. Het resultaat wort altijd uitgedrukt in geld maar kan betrekking hebben op zaken als "bruto-omzet", "netto-omzet", "winst", "kosten", "rendement", etc. Vooral moet een doel in termen van het verwachtte resultaat gesteld zijn. Het bedrijfsonderdeel heeft een grote mate van vrijheid om dit doel te realiseren.

'verkoopprijs'

Het bedrag waarvoor klanten, volgens het dan geldende tarief, één artikel van de betreffende soort kunnen kopen. Het bedrag is verminderd met kortingen die in het algemeen of aan een bepaalde klant door Telecom worden verleend.