Office: (Office 2003) KANBAN DB aufbauen

Ist aber exakt Dein Datenmodell aus Access. *wink.gif* Ich habe es nur per Reverse Engineering da rauskopiert. *g*

Da siehste mal was einem alles so auffällt an dem eigenen Datenmodell wenn man es mal in übersichtlicher/anschlaulicher Form betrachtet.

Wie gesagt, ich habe daran nix gemacht, weder was eingegeben noch was geändert nur eben nach DeZign importiert und dann als Pdf ausgedruckt ... nicht mehr. Ein kleiner Vorteil wenn man solche Programme nutzt ... allerdings enorm groß wenn man mal andere DB's als die selbst erstellten überprüfen/checken muss.

Denk aber nicht nur über das und die Inventur (Warenretouren sind wohl ein ähnliches Thema) nach, sondern auch über die anderen Punkte die ich angesprochen habe. *wink.gif*

Gruß

Rainer

 

Hallo,

mit einem Punkt war ich zu oberflächlich! Ich benenne meine Primärschlüssel
"TabellenName_ID". Natürlich verwende ich auch Aliase für die Tabellennamen aber ich nehme sprechende und nicht T1, T2 usw.

Zur Frage nach Inventur und anderen Sonderfällen:
Dies wird über die Bewegungsart abgebildet. Hier hat die Inventuraufnahme (sofern sie in dieser DB überhaupt relevant ist) natürlich eine Sonderstellung.

Frage an Erich:
Ist diese DB die offizielle Bestandsführung Eurer Firma oder ist dies eine Art "Nebenrechnung". Ich denke, dass bei einer "offiziellen Bestandsführung" für die Bilanzierung noch ganz andere Aspekte berücksichtigt werden müssten. Ich sage nur "Bestandsbewertung, Niederstwerprinzip" usw. usw.

Wenn dies aber eine Art "Nebenrechnung" ist, stellt sich die Frage ob alle denkbaren Materialbewegungen berücksichtigt werden müssen. Ich denke, dies sollte die Komplexität senken.

Frohe Pfingsten aus Mannheim

 

Naja, egal ob Haupt- oder Nebenrechnung ... es müssen alle Materialbewegungen erfasst werden, ansonsten würde ja irgendwann der reale Bestand nicht mehr zu den Werten in der DB passen und dann gibt es ein Durcheinander beim Einkauf. Zumindest habe ich es so verstanden das die DB melden soll wenn ein Artikel unter Meldebestand sinkt damit der Einkauf dann den Artikel nachordern kann um zu vermeiden das es einen Versorgungsengpass gibt.

Aber natürlich ist die Frage wie detailliert muss das sein.

Ich denke selbst wenn die DB die offizielle Bestandsführung wäre, wäre das wahrscheinlich ein Thema für eine eigene Entität, bzw. eigene Erweiterung der DB.

Wobei das aber zu einer interessanten Frage führt:

In wie weit ist in der DB eigentlich eine wertmäßige Erfassung des Lagerbestandes sinnvoll/erwünscht?

Ich denke das das kein unwichtiges Thema ist. Die Firma wird ja wohl mit Sicherheit auch mal ab und an interessieren welchen Wert ihr Lagerbestand hat. Frei nach dem Motto: Artikel X, Bestand gesamt 10.000 Stück, durchschnittlicher Einkaufspreis: 1,2 € pro Stück oder auch im Lager XYZ befindet sich Lagerware im Gesamtwert von 240.000 € durchschnittlicher Einkaufspreis. Und mit Sicherheit wird es den ein oder anderen Controller nicht nur interessieren wieviel Stück für welche Maschine in welchem Zeitraum vom Artikel X entnommen wurden sondern auch wie der durchschnittliche Einkaufspreis/Wert des Artikels ist.

Wäre man aber bei der wertmäßigen Erfassung des Wareneinganges, sollte/müsste man auch eine wertmäßige Erfassung des Warenausganges vorsehen. Manche Artikel werden vllt verkauft oder ein Controller möchte den Verbrauch nach Kostenstellen erfassen und sieht daher für die Kostenstelle Lager- und Lagerverwaltung einen wertmäßigen Aufschlag bei Entnahme vor.

Und sag jetzt bitte nicht das Du das über die Tabelle Lieferinfo abbilden willst. *wink.gif* Das funzt nicht, Preise ändern sich im Laufe der Zeit und in Lieferinfo kann daher bestenfalls nur der aktuelle Preis stehen und wäre damit natürlich äußerst verfälschend wenn man mal eine Auswertung in der Vergangenheit vornimmt wo der Preis noch anders war.

Ist nur die Frage ob man das hier mit einbauen will oder ob das Werte sind die man aus der Buchführung ziehen will/sollte.

@ Erich

Ach ja, was mir noch auffällt:

LAGERPLATZ und LAGER

Zum Lagerplatz wählt man ja das Lager aus und dann den Lagerschrank und das Lagerfach ... woher kommen eigentlich Lagerschrank und Lagerfach? Saugt sich das der Eingebende aus den Finger oder würfelt das aus?

Woher und wie kommt die Information über den Lagerplatz rein, zumindest für den Eingang (beim Ausgang ergibt es sich ja aus dem MATBELEG)?

Gruß

Rainer

 

Hallo Bernd,

Nein, das wäre tatsächlich zu komplex. ich möchte 1x pro Jahr eine Bestandaufnahme (Ist) in Form einer Übersichtsliste habe also der Bestand soll geprüft werden eine kleine Art Inventur sollte durchführbar sein!
Denke ich.

so und nun wieder ein überarbeitetes Modell
1x PDF
1x mit der Dateiendung .dez für Rainer

wie hast du in dem Programm die zweite Spalte eingestellt?

wie sieht es denn jatzt aus? und aufgrund dem hin und her bin ich mir jetzt nicht mehr Sicher was nun richtig ist Alias Tabelle tblArtikel ? oder ARTIKEL

usw.

es müsste doch nun so langsam mal losgehen mit den Forms etc. mir ist es aber wichtig das es soweit passt oder ob noch wichtige Attribute her müssen.

 

Hallo Bernd, Hallo Rainer

schöne Pfingsten, nun das Access Modell!

ich mache nun erst mal eine Pause, um wieder einen klaren Kopf zu bekommen.
ich denke da sind noch Fehler drin aber ist und soll jetzt Basis sein.

 

\@ Erich

Menüpunkt 'Diagram' -> 'Data type display level' -> 'Names with physical data type'

Es gibt hier kein richtig oder falsch ... im besten Falle gibt es gebräuchlich/üblich. Du sollst das wählen mit dem Du am besten zu Recht kommst und optimalerweise etwas was ein fremder DB-Entwickler auch zügig lesen/interpretieren kann. In Sinne des Letzteren wäre das Präfix 'tbl' anzuraten, weil da weiss jeder sofort was gemeint ist. Das spielt im ERM keine Rolle, aber später im VBA-Code oder in der SQL-Ansicht von Abfragen spielt es schon für die Übersichtlichkeit eine wichtige Rolle.

Ich habe Dein Modell mal überarbeitet und die Benamsung einfach mal so gemacht wie ich sie sonst mache. Kannst ja mal gucken ob Du damit zu Recht kommst. *wink.gif*

Vorgenommene Änderungen in Deinem ERM ... gröberer Natur. *g*

Habe die Bestellanforderung über eine m:n Beziehung zum tblArtikel verbunden und in die m:n Beziehung die Beziehung zum tblLieferartinfos eingebaut, sowie die Menge für die Bestellanforderung. Zum tblBestellAnforderungen habe ich eine Beziehung zum tblLagerOrte hergestellt.

Somit wird es einfach zum Lagerbestand ergänzend auch noch die Bestellung zu einem Artikel auszuwerten. Also 100 Stück im Lager XYZ, 150 Stück im Lager TZU und 200 Stück in Bestellung ... ist ja nicht unwichtig die Info sonst wird wie blöd bestellt weil keiner wirklich genau weiss was in Bestellung ist. Eine Bestellanforderung gehört zu einem LagerORT und damit wäre die Bestellung noch weiter gehend nach Lagerorten auszuwerten. Und damit das Bild rund wird bekommt das tblBestellAnforderungen auch noch das tblBestellStatusse an die Seite gestellt mit einer Beziehung. So kann man dann auch noch auswerten in welchem Status die Bestellung sich befindet.

Das das tblLieferartInfos nicht mehr direkt mit dem tblArtikel verbunden ist sondern nur indirekt als 3tes Argument zu der m:n Beziehung tblBestellAnforderungen_tblArtikel hat den Grund das sich LieferartInfos ändern können mit der Zeit. Wenn man nun für jede Änderung eine neue LieferartInfo anlegt, hat man den Vorteil das man nun genau nachvollziehen kann wann man welchen Artikel zu welchen Bedingungen bestellt und geliefert bekommen hat. Was die Urpsrungsauswertung doch etwas einfacher/sinnvoller gestalten dürfte. Da in LieferartInfo auch der Preis festgehalten ist zu dem die Bestellanforderung aufgegeben wurde ist so auch langfristig die Preisentwicklung nachzuvollziehen, bzw. für die Controller ein durchschnittlicher Einkaufswert im Zeitraum X einfacher auszuwerten.

Mit der Verknüpfung zum LagerOrt über das tblBestellAnforderungen kann dieses Auswertung sogar pro Lager bezogen durchgeführt werden.

Man könnte natürlich auch die Verknüpfung zum tblLagerOrte direkt in die m:n Beziehung zwischen tblArtikel und tblBestellAnforderungen einbauen. Wobei man eben überlegen muss/sollte ob die BestellAnforderung immer nur für einen Lagerort gelten soll oder ob die BestellAnforderung zentral gemacht wird und daher durchaus für mehrere Lagerorte gelten kann (dann müsste die Beziehung zum tblLagerOrte in die m:n Beziehung eingebaut werden).

Durch die neu Gestaltung der Beziehung sind einige Argumente rausgeflogen da sie sich nun aus den Beziehungen ableiten lassen.

Als nächsten Punkt habe ich eine Beziehung vom tblBestellAnforderungen zum tblMaterialBelege hergestellt. Damit können nun direkt aus der BestellAnforderung wenn die Lieferung da ist "positive" Materialbelege erstellt werden.

Durch die Beziehung vom tblMaterialBelege zum tblLagerBestaende soll nun eigentlich dargestellt werden, dass es keine Lagerbestandveränderung ohne Materialbeleg geben darf ... und damit sind sowohl Zugänge wie auch Abgänge gemeint.

Damit erhalten die Materialbelege eine zusätzliche Bedeutung ... sie dokumentieren nun jede einzelne Bewegung im Lagerbestand eines Artikels. Durch das neue tblBelegArten können die Materialbelege nun auch unterschiedliche Bedeutung annehmen ... z.B. BelegArt Inventudifferenz buchen, Wareneingang, Warenretoure etc., etc. .

Das sicherte die 100%ige Nachvollziehbarkeit jeder einzelnen Bewegung im Lagerbestand. Wie schonmal gesagt ist es zwar wichtig zu wissen das 100 Stück dazu gekommen sind, aber es ist eben mindestens genauso wichtig zu wissen wieso weshalb warum und woher. *wink.gif*

Durch die Beziehung ist nun die Erfassung von LagerPlatz im tblMaterialBelege unnötig geworden, da sich der LagerPlatz aus der Beziehung zum tblLagerBestaende ableiten lässt.

Die Beziehungen sind jetzt erstmal nur in Hinblick auf Richtigkeit 1:n gesetzt worden. Überprüfungen bezüglich Identifying-Relationship Yes or No, Cascade on Delete/Update Yes or No, Mandantory Yes or No u.ä. habe ich noch nicht gemacht. Das mache ich immer gerne erst am Schluß in dem ich jede einzelne Beziehung nochmal durchgehe und hier ausführlich drüber nachdenke und dann die Eigenschaften der Beziehung einstelle.

Das wären jetzt erstmal so meine wichtigsten Punkte ... Argumente habe ich auch noch nicht bis auf's Detail geprüft. Sowas macht man ja eh erst wenn die Entitäten und Ihre Beziehungen zueinander stehen.

Im Anhang eine *.DEZ Datei (als *.zip gepackt) zum weiter dran arbeiten und eine PDF-Datei für diejenigen die kein DeZign zum ansehen haben. *wink.gif*

Wie Du siehst ... noch lange nicht. *wink.gif*

Gruß

Rainer

 

Hallo Rainer,

man merkt und erkennt auf einen Blick wer Profi ist

tblMatBelegArten, finde ich gut

- damit hat sich die Frage von Bernd, meine Anmerkung dazu geklärt
- denn dort, sind ja nun die MatBelege definiert
- Inventur ...Beleg
- Buchungs...Beleg
- Wareneingangs ...Beleg
- KanBan ....Beleg könnte man dort ja auch definieren??
dazu hatte ich in tblMaterialBelege das Feld Barcode eingebunden
damit darüber die Lagerbestände geregelt werden können

mir fällt am Modell auf, das es kaum Datums Angaben gibt
ach was sagt die tblBestellStatusse aus?
- storniert
- Bestellung eingetroffen

oder erledigt, offen (das verstehe ich unter Status)

 

Genau Informationen dieser Art.

Genauso und im Prinzip ja, man könnte dort auch einen Beleg als KanBan-Beleg markieren.

Ich hatte doch gesagt ... Argumente kümmern mich zu diesem Stadium erstmal nur sekundär. Fällt mir was ein was dringend rein muss füge ich es zwar schon ein, aber ohne Anspruch auf Vollständigkeit. Das kommt erst wenn die Entitäten und die Beziehungen wirklich so gut wie fertig sind.

Immer schön auf den Wesentliche konzentrieren sonst verliert man schnell den Überblick. Deswegen die von mir favorisierte Reihenfolge:

1. Entitäten und Beziehungen
2. Argumente
3. Beziehungs-Eigenschaften

Und zum Thema Entitäten/Beziehungen ... mal eine Überlegung über die Du nachdenken solltest:

Wann und in welcher Form entstehen eigentlich Materialbelege?

Der Grund der Frage ist man könnte im Prinzip ja schon bei Wareneingang die Belege ausdrucken und an jede VE (Verpackungseinheit) einen Beleg dran pappen. Dann müsste der entnehmende Mitarbeiter nur noch sein Kürzel drauf setzen und den Beleg in den Sammelbehälter am Lagerausgang einwerfen.

Das führt dann aber wiederum zu der Frage ... wie werden Materialbelege für die ENTNAHME gedruckt und mit welchen Angaben?

Z.B. 1 Materialbeleg = 1 Verpackungseinheit?

Das führt schlicht zu der Überlegung eine Art doppelte Buchführung für den Lagerbestand aufzubauen. Was durchaus aus dem Gedanken des Controllings Sinn machen würde.

Also im Prinzip Ihr bekommt eine Lieferung mit 50 Verpackungseinheiten à 10 Stück vom Artikel A. Jetzt kannst Du unkontrolliert und blind einfach mal 50 Entnahme-Belege drucken und die an die Kisten pappen. That's it ... aber ist das so sinnvoll?

Wäre es nicht auch eine Überlegung die gedruckten Entnahme-Belege in eine Tabelle abzuspeichern? Und den Ausdruck mit der ID des Tabelleneintrages als Kontrollnummer versehen.

Somit wäre überprüfbar ob der gebuchte Entnahmebeleg nicht vllt gerade doppelt gebucht wird, bzw. ob es den Entnahmebeleg überhaupt geben darf.

Dadurch könnte allerdings auch noch eine Rückverfolgung entstehen ... z.B. bei einer bestimmten Lieferung weisst der Artikel XYZ eine hohe Felerquote aus. Jetzt könnte man sofort noch alle offenen Entnahmebelege zu der Lieferung auswerten und die Restmengen der Lieferung aus dem Lager entfernen.

Verstehst Du worauf ich hinaus will?

Gruß

Rainer

 

Hallo Rainer,

Guter Anstoss

ich hatte mir da ja folgenden Ablauf gedacht, da meine Jungs (Instandhalter) sich im wesentlichen um die Maschine kümmern sollen, haben die keine Zeit sich mit der Datenpflege zu beschäftigen sollen also bei Bedarf sich aus dem Lagerbestand mittels "KanBan" ein entsprechendes Ersatzteil für die Maschine entnehmen, so geschieht es heute ja auch allerdings ohne saubere Datenpflege was ich ja nun vorhabe umzusetzen (ordentliche Lagerverwaltung) nicht so komplex aber Sinnvoll.

auf der Karte die jeder Lagerplatz bekommt stehen dann folgende Informationen:

- Bezeichnung
- Artikelnummer
- Lieferant
- Lagerort & Lagerplatz
- Min
- Max
- Bestand & Einheit (in Stückangabe, auch wenn Päcken als Einheit angegeben wird
und der Inhalt 10 Stück ist)
- Barcode (Inhalt ArtikelNr, Bestand (1), Maschinennr)
so muss nicht an jedem Artikel xyz ein Zettel (Beleg gepappt werden)


diese Karte geht dann in eine Kiste, wie du schon beschrieben hast
ich sammel die dann täglich ein (prüfe also das Lager täglich) und mittels Scanneranbindung geht die Karte in die Erfassung DB und zurück ins Lager des Artikels.

oder habe ich da einen möglichen Ablauffehler, der Instandhalter soll eine Art Personenbezogene Nummer auf den Beleg stempeln um die in der DB zu verwenden wegen der Rückverfolgung Ersatzteil wurde von entnommen

 

\@ Erich

Okay ... wie Du es beschreibst ist es die simpelste Methode aber auch die Methode die Schwund Tür und Tor öffnet und keinerlei Kontrolle ermöglicht.

Mitarbeiter entnimmt Ware, schmeisst Beleg in Kiste und gut ist ... wer hat die Ware entnommen, wann wurde Sie entnommen und durfte/konnte er überhaupt die Ware entnehmen wird nicht geprüft.

Also spazierst jeder Dieb bei Dir ins Lager schmeisst brav den Beleg in die Kiste und Du/Deine Firma merkt davon überhaupt nix weil es noch nicht mal eine Inventurdifferenz gibt da ihr/Du ja brav die Belege in der Kiste scannt und bucht und dann den Beleg wieder zurück ins Lager tragt ... wo natürlich der Dieb schon auf den Beleg wartet um sich noch eine weitere Kiste mit nach Hause zu nehmen.

Sehe ich das so richtig? ^^

Oder kurz: Das was Du vor hast ist absolut tödlich. *wink.gif*

Part 1: Ein Entnahmebeleg kann nur EIN EINZIGES MAL genutzt werden und MUSS vom Mitarbeiter mit seiner Personalnummer, dem Datum, der Uhrzeit und mit seiner Unterschrift versehen sein ... optimalerweise noch irgendeinen Hinweis auf die Verwendung und wenn es mit Kästchen zum ankreuzen ist.

Damit wäre zumindest mal zügig nachzuvollziehen ob der Mitarbeiter der gerade mit einer Kiste unterm Arm deren Inhalt vllt ein paar tausend Euro Wert ist das auch korrekt entnommen hat. Könnte sehr hilfreich sein um Inventurdifferenzen niedrig zu halten.

Part 2:

Falsch ... nicht der Lagerplatz bekommt den Entnahmebeleg sondern die Ware, bzw. die Entnahmekiste.

Part 3: Je mehr ich drüber nachdenke desto sinnvoller finde ich es die Entnahmebelege pro Kiste/VE bei Eingang der Lieferung zu drucken und auch explizit abzuspeichern. Die gedruckten Belege natürlich in der DB abzuspeichern mit einer Unique-ID (Autowert optimalerweise) und die ID natürlich mit auf den Entnahmebeleg zu drucken. Der Entnahmebeleg kommt dann sofort auf die Kiste drauf.

Somit ist sofort bei Eingabe der Entnahme durch einscannen des Beleges nach zu vollziehen ob die Entnahme korrekt oder getürkt war ... jeden Beleg gibt es ja nur einmal. *wink.gif*

Durch die Einmaligkeit ist dann natürlich auch nachzuvollziehen aus welcher Lieferung von welchem Lieferanten der entnommene oder der noch gelagerte Artikel stammt. Und es wäre damit auch zumindest in etwa nachzuvollziehen wenn zu hohe Störzeiten bei den Maschinen auftreten aus welcher Lieferung die verarbeiteten Materialien stammen. Treten bei mehreren Maschinen zu hohe Störzeiten für die allesamt kurz zuvor ein Artikel eines bestimmten Lieferanten zu Produktion aus dem Lager entnommen wurde wäre es ein einigermaßen deutlicher Hinweis darauf das möglicherweise der Artikel des Lieferanten an den Störzeiten Schuld ist ... wäre doch nicht ganz uninteressant zu wissen, oder? *wink.gif*

Denke mal ganz ernsthaft darüber nach ob man das so machen sollte, wenn ja müsste natürlich das ERM darauf angepasst werden. *wink.gif*

Gruß

Rainer

 

Hallo Rainer,

das ist ja schon der Supergau deine Anmerkungen und Überlegungen.

ich denke da gibt es nichts zu überlegen, macht wirklich Sinn auch Bspw. den Controller mal zu erklären warum ich von Lieferant B keinen Artikel (Ersatzteil möchte auch weil er evtl. einige € billiger ist)

wie kann das ERM dann aussehen?

ich versuche gerade, mir dein Modell auf Papier zu malen und

1. Entitäten und Beziehungen
2. Argumente
3. Beziehungs-Eigenschaften

mir da mal Gedanken drüber zu machen
um noch besser zu verstehen.

wäre ja Super wenn ich das Anfang Sept.10 weitesgehend fertig hätte

 

OK, was wenn der Mitarbeiter das nicht gemacht hat in dem Trudel der Aufregung und im Grunde nur den Kopf bei der Maschine hat das sie wieder läuft

Und was wenn er sich versehen hat, das falsche Ersatzteil erwischt bzw. genommen hat >> dann müsste er das Teil mit dem vorher ausgefüllten Beleg wieder zurücklegen

Bsp. spezielle Leitungen sind auch Artikel

es kann passieren das man ein Teil entnimmt und dies ist bereits defekt geliefert, er holt die zweite Leitung wieder über Beleg
was soll dann mit dem ersten beleg passieren? und woher weiß ich dann warum er zwei Leitungen entnommen hat

Da einen gesunden Ablauf zu erhalten ohne großen Aufwand....

 

Rainers Gedanken sind ja durchaus richtig, jedoch wird Dir auch die beste Datenbank keine Diebe verscheuchen.
Wenn also kein Lagerverwalter da ist, der die Ausgabe dokumentiert und jeder Mitarbeiter da selber verantwortlich ist, solltest Du den Verwaltungsaufwand so klein wie möglich halten. Wahrscheinlich ist es tatsächlich die beste Idee an jedes Teil einen Zettel zu kleben, der dann mit Name und Datum versehen in eine Kiste gelegt wird; und selbst bei dieser Simpelverwaltung wird viel gutes zureden nötig sein, um das zuverlässig zu erledigen.
Außerdem sollte man den Preis der Teile berücksichtigen. Ein M3-Schräubchen ist billiger als der Zettel, der dranhängt. Für die Übergabe eines Kilobarrens Gold könnte man sogar einen Notar und zwei Sicherheitsleute aufwenden.

 

Hallo Thomas,

du betätigst was ich ebenfalls befürchte.
es muss ein notwendiger Ablauf festgelegt werden, wenn die Inventurdifferenz
große Abweichungen hat, dann ist klar das der Ablauf nicht eingehalten wurde
wir nennen das AAW Arbeitsanweisung, aber wie macht aldi das ?
jeder Artikel ist mit einem Barcode (Beleg)versehen, die Kasse ist die Ausgabe
oder der Entnahmebeleg

auf die DB projeziert heißt das doch
- Artikel (Ware) hat Beleg in Kiste
- Artikel entnehmen (evtl. Scanner) um Zeit zu sparen
- Artikel Entnahme dokumentiert

viel mehr sollte es doch nicht sein

 

Es ist sicher eine gute Idee, sich die Modelle und Organisationen anderer Betriebe anzuschauen.
Nützt nur alles nix, wenn Du nicht die Kompetenz hast, eine Idee durchzusetzen. Geh nochmal einen Schritt zurück und plane so, wie Du es auch tatsächlich umsetzen kannst.
Kannst Du die Kollegen tatsächlich dazu bringen, die Lagerverwaltung mitzutragen? Findest Du Unterstützung für Deine Pläne bei der Geschäftsleitung? Ist es sinnvoll, die Einkaufspreise zu beachten: es gibt doch mit Sicherheit eine Finanzbuchhaltung bei Euch, woher bekommen die Ihre Zahlen? Hast Du Einfluß auf die Einkaufsentscheidungen?
Damit wären wir wieder beim Pflichtenheft. Was soll die DB leisten? Leg' das fest und fang dann mit dem Datenmodell an. Wenn im Pflichtenheft nix von Einkaufspreisen steht, dann gehören die eben nicht dazu.
Ein sorgfältig normalisiertes und dokumentiertes Modell läßt sich immer nachträglich erweitern.