Hallo Willy,
diese Beschreibung hätte viel früher kommen müssen.
ja…
Der Kunde wählt natürlich erstmal aus, was er kaufen möchte.
Dann kommen extra Wünsche, die wir dann erfassen.
Du sollst dir das so vorstellen, wie ein Kunde, der ein
Rennrad kauft und dann einen anderen Sattel haben möchte. Oder
einen hohen Sitz, usw…
Der Verkäufer kann nicht vorhersehen, was für Änderungswünsche
ein Kunde haben könnte.
Verstehst du?
Klar doch… 
Also momentan ist es so dass:
- Ein Kunde möchte irgendetwas kaufen (Produkt).
- Dieses Produkt setzt sich auf mehrere Komponente zusammen,
die wir anbieten.
Unter anderem aus der Elektronik-Abteilung,
Informatik-Abteilung, usw …
- Der Kunde äußert wünsche, wie das sein soll.
- Wir erfassen sie und bewerten die Wünsche.
d. h. er kann ein EndProdukt aus Einzelprodukten selber zusammenstellen. Wenn es ein Einzelprodukt noch nicht gibt (das beinhaltet auch ein solche, die es schon gibt, aber geändert werden müssen), dann tritt Euere „Entwicklung“ in Aktion und setzt ein neues Einzelprodukt zusammen.
- Falls diese Wünsche Möglich sind, bekommt er ein Angebot,
das er unterschreiben wird.
Geschieht das, bevor das neue Einzelprodukt bearbeitet wird?
(Natürlich mit wünschen, Risiken
und alle Mögliche Sachen von jeder Abteilung gelistet)
- Diese Unterlagen bekommt er in Word.
Es ist zunächst egal, auf welchem „Datenträger“ die Daten ausgegeben werden. Hier ist erst mal der Workflow (Abfolge der Änderunge/Erzeugung von Daten in Abhängigigkeit der Geschäftsprozesse) zu klären: Wer macht mit welchen Daten was, wann und wo…
Momentan für die Erfassung der Daten sieht es so aus:
- Der Kunde hat eine Liste in 3 Excel-Dateien von den ganzen
(Komponenten und es sind sehr sehr viele mit Beschreibung und
so).
Die Anzahl der Daten ist unerheblich (bis zu gewissen Grenzen). Wesentlich ist die genaue Definiton und Kennzeichnung der Komponeneten(Artikel?)
- Wenn er ausgewählt hat. wird seine Auswahl in verschiedenen
Word-Dateien kopiert. Er äußert auch seine finale Bedingungen
und Kommentaren dazu.
Word-Dateien können hier vergessen werden. Aber versteh ich es richtig, dass das Angebeot an den Kunden mehrere Alternativen zu seinen Wünschen enthält? Wenn ja, muss das während der Datenanalyse, die nach der Festlegung/Klärung des Geschäftsablaufes (der Geschäftsprozesse) berücksichtigt werden.
Informatik Abteilung bekommt seine Word-Datei, Elektronik
Abteilung auch, usw…
Hier ist zu fragen, ob zu/für diesen Zeitpunkt die DB verwendet werden soll (wenn ja, für was?) oder diese Abteilungen lediglich ein „Projekt“ abarbeiten, das als Ergebnis lediglich zu erzeugende, bzw. zu ändernde Komponenten abwirft.
- Die Informatiker je nach dem Produkt schreiben, was für
Risiken, wie Teuer, wann Auslieferung erfolgen kann usw …
Gleich für die Elektrotechniker …
OK, so en Produkt kann ja als „Neue Komponente“ in die DB eingepflegt werden. Ob das nun die Entwickler selber tun müssen, oder ein „Arbeitsvorbereiter“ besser dafür zuständig wäre, liegt an Eueren Geschäftsmodell.
Die einzelnen Auswertungen von den Abteilungen werden als
Word-Datei zusammengefasst und zu dem Kundenbetreuer (Bei uns)
zugeschickt (könnte mehr als 10 Dicke Word Dateien werden) und
der muss darein rumsuchen und zum Beispiel für die
Auslieferung das spätere Datum von allen die vorgeschlagenen
auswählen.
Das hat m. E. nichts mit der DB zu tun, sondern unterliegt Eueren geschäftlichen Tätigkeiten. Wenn es darum geht, die in der Db erfassten Daten zu kombinieren, wären allerdings Word-Doc hier fehl ab Platz.
Gesamter Preis berechnen, Risiko abschätzen, weil wenn die
Informatiker sagen das Risiko ist auf Level 1 und die
Elektrotechniker auf Level 2, dann hat das fertige Produkt
Level 2 Risiko.
Diese Auswertung kann natürlich von der Db erledigt werden, wenn Die Daten aus den o . g. Word-Docs
Wenn das alles fertig ist. muss das ganze als eine Light
Version (Word-Datei) zusammengefasst werden und zu dem Kunde
zugeschickt werden.
Wie o. g. es ist letztendlich egal, wie die von der DB (und den Usern) verarbeitetetn DB-Daten ausgegeben werden. Ich sehe in dieser Kladde ein „Kundenangebot“
Wenn er unterschrieben hat, schickt er das zurück und die
Produktion kann anfangen.
Gut, das hoffen wir dann mal…
Warum wollen wir eine Datenbank:
- weil für jede Komponente, kennt schon jede Abteilung
Risiken, Preis, usw.
ok
- Mit dem Formular ( Access-Formular) könnte der
Kundenbetreuer eine Komponente auswählen und per VBA würde die
Risiken und so automatisch generiert werden. (Dafür werden
Produkte mit Eigenschaften in einer Datenbank gespeichert)
Risiken automatisch generieren: Wenn es für die Berechnung des Risikos einen Algorithmus gibt… ja.
Wie stellt sich mein Chef das vor.
Der Kunde wählt die Komponente
aus der Excel-Liste
aus, die er braucht und schickt
uns das.
Der Kundenbetreuer öffnet das
(Datenbank-)Formular
und wählt die
Komponente aus einer Liste aus. Dann für jede Auswahl
erscheint automatisch Sachen wie Risiken und so in dafür
vorgesehene Textfelder.
ok, wenn diese Daten (Artikel, Komponenten) schon existieren
Momentan habe ich eine Datenbank mit den Komponenten. Im
Formular werden diese Komponenten über eine Combobox
ausgewählt und mit einem „>“ Knopf in die Liste hinzugefügt.
(d.h beliebig viele Produkte können in die Liste)
ok, aber nur als Liste eher zu sehr „unterdimenssioniert“. Diese Liste sollte als Tabelle „KundenAngebot“ einschliesslich aller dazugehörenden verknüpften Daten aus anderen Tabellen erscheinen.
Das ist übrigens eine Seite des Formular.
Vergiss erst mal Formulare… Die kommen erst zum Zuge, bzw. werden erstellt, wenn die (unverzichtbare!) Basis einer DB gebaut ist, nämlich die normaliesierte Tabellenstruktur und die Verknüpfugen (Beziehungen).
Eine andere Seite hat das Auslieferungsdatum. Für jede Produkt
wird dieses Datum in der Datenbank auch eingetragen und draus
automatisch gelesen.
Mit VBA wird das „größte“ Datum ausgewählt und als gesamte
Auslieferungsdatum angezeigt.
Wie auch immer, solche Sachen sind erst nach dem Erstellen der gesamten(!) Tabellen zu erledigen (—> Formulare /Berichte erst NACH dem Tabellenaufbau angehen.)
Also ich weiß nicht, ob ich ein gutes Bild von der Situation
malen konnte.
Momentan habe ich ungefähr 10 Seiten vom Formular mit den
verschiedenen Daten die erfasst oder erzeugt werden.
Vergiss das Ding, siehe oben. Du hast noch nicht den Hauch eines Tabellenkonzeptes.
Mein einziges Problem ist bei dieser Seite, wo die Wünsche der
Kunde für das gesamte Produkt erfasst werden muss (NB: mehrere
Komponente aber ein einziges Produkt).
Hier spielt schon wieder der Tabelleaufbau hinein: Es sind weitere Tabellen in bestimmter Beziehung zueinander nötig.
Zusammengefasst:
Es ist so als ob, der Kunde sagt. Ich möchte eine fliegende
Auto.
wir produzieren Flügeln, Rädern usw.
wir wissen mit Flügeln wird das Risiko zum Unfall größer.
Für das fliegende Auto muss der Kunde sagen können:
Ich hätte dazu MP3 Player, Schiebedach, usw … das muss
erfasst sein.
Tut mir leid, wenn alles wieder so lang ist. Ich habe mich so
kurz gefasst wie ich konnte. 
Na, wie Du siehst, ist das Ganze immer noch nicht detailliert genug. Ich würde Dir raten, zunächst GANZ GENAU den „Datenverkehr“ im Einzelnen in Euerem Geschäft zu untersuchen, die Geschäftsprozesse klar zu legen, am Besten auf Papier, und die Daten nach Zusammengehörigkeit zu ordnen . Das geschieht am Besten auf einem Stück Papier, ohne Gedanken an eine DB…
Aber das gesamte DB-Projekt ist auch nicht ohne und hoffentlich weißt Du, was Du Dir da vorgenommen hast… Ich bezweifle ob alle Fragen und Probleme (d. H. Systemanalyse, Datenanalyse, Datenbeziehungen, Tabellenaufbau, Normalisierung, etc… hier im Forum beantwortet bzw. gelöst werden können…
Viele Grüße vom Bodensee
Franz, DF6GL
