Office: (Office 2000) Männlein oder Weiblein

Hallo,

ich denke, Saschas letzte Bemerkungen war die richtige Antwort auf die erste Antwort: Bis du jeck!? in diesem Thema

Gruß Peter

 

Hi,

ich halte die Anrede bzw. die "Kundengruppe" oder wie man es nennen mag für ein unabhängiges Faktum, das zu erfassen ist. Es korreliert lediglich mit dem Vornamen.

Warum? Weil Petra Müller nicht unbedingt eine Frau sein muss. "Sie" könnte eine Firma sein (Petra Müller e.K., Petra Müller OHG etc) oder eine sonstige juristische Person mit "natürlichem" Namen.

Meist interessiert ja gar nicht das biologische Geschlecht - und nur das wäre ja aus den Namen zu

 

Nur zur Klarstellung: Das war nicht auf Sinn des Vorhabens, sondern auf Aufwand für die Realisierung mit einer akzeptabelen Trefferquote bezogen. *wink.gif*

Daher wenn überhaupt, trifft nicht der letzte Beitrag von Sascha auf diese Aussage zu, sondern der Beitrag in dem er zeigt das es anscheinend doch nicht so irre aufwändig ist (vermute ich mal auf Grund der Schnelligkeit mit der die verbesserte Namens-DB gepostet wurde von ihm) eine passende Vornamens-DB zu erstellen ... zumindest wenn man das nötige Wissen dafür hat.

Gruß

Rainer

 

Hallo Martin,

ein Feld Geschlecht als Pflichtfeld zu deklarieren ist natürlich richtig.

Aber: Die Ermittlung eines Geschlechts aus dem Vornamen ist doch wichtig, wenn man eine bestimmte Datenmenge übernimmt, in der Name u. Vorname enthalten aber Geschlecht nicht enthalten ist, dieses jedoch für Selektionen benötigt wird.

Bei kleineren Datenmengen ist ja ein händisches Einsetzen möglich, bei größeren Datenmengen geht nur der Vergleich mit einer tblVornamen, die ich relativ oft benutze (da bei mir oft die Übername größerer Datenmengen nötig ist)

Gruß Peter

 

Jetzt gebe ich auch mal meinen Senf dazu:

Als Eingabehilfe halte ich eine Vornamen/Geschlechts/Anredetabelle für sinnvoll.
Als Ersatzeingabe, die bei fehlendem Feldinhalt z.B. für Serienbriefe herangezogen wird nicht! Da behelfe ich mir mit "Sehr geehrte(r) Frau/Herr ..."

Gerade hier im wunderschönen grünen Ruhrgebiet bräuchte ich sonst mindestens die KlickTel-CDs des gesammten süd- und osteuropäischen Raums um auf eine der genannten Trefferquoten zu kommen. *wink.gif*

Ein Mann mit italienischer Herrkunft und mit Namen 'Andrea' wird sich bedanken, wenn er als Frau angeschrieben wird.

 

Anrede als Pflichtfeld?
Da frage ich mich, ob ihr euren Anwendern schon mal über die Schulter geschaut habt?

Das ist es ja gerade: Die verhalten sich eben nicht so, wie der Entwickler sich das vorstellt. Und auch die Betriebsabläufe sind oft anders, als man sie sich am grünen Tisch vorstellte.

Ich habe einst auch allen möglichen Pflichtfelder und Plausibilitätsabfragen vorgesehen, die übrigens auch von den DB-Projektteams der Kunden oft so verlangt werden.
Und nachher durfte ich die jeweils zur Hälfte wieder rausschmeißen, weil dies an der Realität vorbei ging.

Es liegen nunmal bei Erstellung eines Datensatzes häufig noch nicht alle Informationen vor. Die Infos wurden noch nicht erhalten oder recherchiert, oder die Infos kommen über Mitarbeiter A und Mitarbeiter B zu Mitarbeiter C, der die Eingabe vornehmen soll.
Ich kann mich nun gerne als Unternehmensberater empfehlen und darauf drängen, dass man den Workflow überprüfen und die Struktur optimieren möge. Das wird tatsählich als Ratschlag durchaus angenommen ... indes, passieren tut nichts!

Bevor ich den schlichten Anwender nun mit Pflichtangaben quäle und ihn zwinge, sich erst alle benötigten Unterlagen zu beschaffen - und der Erste bin, dessen Unmut ich dann abbekomme -, lasse ich eher die Möglichkeit offen, zunächst einen rudimentären Datensatz anzulegen, der dann später (hoffentlich) vervollständigt wird. Wenn nicht, so ist es deren Bier und die Nacharbeit steht z.B. beim Serienbriefexport an.

Um beim komkreten Beispiel zu bleiben:
Für die Eingabe der Daten, aus der die Vornamen der tbl_Personen meiner Demo stammen, ist eine Mitarbeiterin zuständig, die die Infos schriftlich auf Formularen bekommt, die keineswegs vollständig ausgefüllt sind. Diese Formulare sind Folge von Telefonaten mit Behördenmitarbeitern. Die Daten müssen schnell in die Datenbank eingegeben werden, weil daran weitere Vorgänge geknüpft sind, die keinen Aufschub dulden.
Also weiß die Mitarbeitern sowenig, wie die Fuzzy-Logic der Demo, wie die korrekte Anrede für Klaus-Bärbel lautet. Die wird sie erst auf gesonderte Nachfrage des zuständigen Projektmitarbeiters erfahren. Solange kann sie aber nicht auf das Anlegen des Datensatzes warten...

Genau das ist doch mein Thema: Datenbanken sind im Prinzip extrem strukturiert aufgebaut und dulden keine noch so kleine Abweichung. Das bildet das wirkliche Leben aber nur unzureichend ab, denn so strukturiert ist kein Unternehmen- weder kleine, noch große. Das Maß an Improvisation ist erheblich größer, als ich früher jemals annahm.
Ergo versucht man, die Anwendung so zu entwickeln, dass sie mit einer bestimmten Unschärfe zurecht kommt.

Ciao, Sascha

 

Also ich habe das kürzlich auch umgesetzt.
Habe im Internet 40.000 Vornamen mit M/w (Quelle CT-Magazin) gefunden.

Habe das in einer Tabelle eingebaut wo es eine Spalte Mänlich (J/N) und Weiblich (J/n) gibt. Somit kann man auch die Vornamen abfangen die nicht eindeutig m/w zugeordnet werden kann.

Und ich muss sagen es funz prima, weil nicht nur das m/W unterschieden wird, sondern der Vorname kann gleich erkannt werden, somit habe ich eine automatisch Trennung errreicht zwischen Vor- und Nachname.

 

Das kann ich so wie es da steht nur unterschreiben.

War lange Jahre selber im Vertrieb und habe da auch versucht eine Ordnung in Kontakte/Termine u.ä. per Software zu erzielen. Die ersten Programme die ich als untauglich rausgeschmissen habe waren die die mich andauernd genervt haben mit dem Hinweis das noch Angaben für die Speicherung fehlen.

Heute werkel ich selber an einer DB für den Vertriebs-Aussendienst und da meine Kollegen keinen Deut anders sind als ich es damals war, lasse ich z.B. die Anlage eines Kontaktes nur mit Vornamen ODER nur mit Nachnamen und sonst keinen weiteren Angaben zu. Damit der Aussendienstler auch Termine für einen neuen Kontakt schnell erfassen kann, nämlich nur dann tut er es auch.

Richtig, es fördert die Akzeptanz draussen beim Anwender. Allerdings muss man als Programmierer dafür dann einen Haufen Zeit und Arbeit investieren um diese Unschärfe dann wieder auszubügeln oder die DB dazu zu bringen damit zu Recht zu kommen.

Aber das Thema geht noch unendlich weiter als nur Pflichtfelder zu minimieren. Ich habe es früher als Anwender gehasst wenn Programme zur Erfassung von Kundenangaben mich zu genauen Datumseingaben zwingen wollte, wenn ich doch nur Aussagen vom Kunden ala "Irgendwann gegen Mitte 1998" hatte. Dabei rauskommen tut natürlich immer der 01.06. ... was dann im Zweifel schlechter war als hätte ich die Aussage Mitte 1998 so direkt notiert (Thema Baufi und Angaben zum Beruf).

Oder Programm die bei Gehaltsangaben nur eine Zahl zu liessen. Was macht man mit Aussagen ala "es sind immer so zwischen 3.000 und 4.500 €" oder "mehr als 2.000 €"? Man bekommt halt draussen gewisse Infos erst nach und nach konkret und da sind Programm die Detailangaben wollen/verlangen tierisch nervend.

Genauso schlimm waren Programme bei denen man sich zu einer oft benötigten Funktion erst umständlich von Menü über Untermenü zu Untermenü und dann zum 6ten von 15 möglichen Punkten hangeln musste. Manchmal habe ich mich ehrlich gefragt ob der Programmierer schonmal versucht hat den Mauszeiger mittels Touchpad so genau zu steuern wenn man den Laptop auf den Schoss hat ... da trifft man alles bloss nicht den benötigten Eintrag.

Genauso idiotisch fand ich Programm die nicht in der Lage waren trotz eingegeben Geburtsdatums das Alter des Kunden selber zu errechnen/anzuzeigen oder obwohl man Brutto-Monatsgehalt und Anzahl Monatsgehälter eingegeben hatte das Programm nicht automatisch das Jahresbruttogehalt einfügen konnte. Natürlich kann das nur ein Vorschlagswert sein, da ja durchaus Sonderzahlungen auch noch das Gehalt verändern können ... aber so ein Vorschlag hat durchaus seinen vorteil wenn der Kunde dann angibt es kommen noch so ca. 10 bis 20.000 € an Tantiemen dazu, man braucht keinen Taschenrechner mehr. ^^

Und auch schlimm fand ich Programm die zwar jede Menge Eingabefelder hatten, bloss bei Sonderfällen versagten weil man diese nirgendwo erfassen konnte oder Programme die nur 1 Adresse oder nur maximal 4 Kinder oder nur 1 oder 2 Email-Adressen zu liessen. Oder Programme mit detaillierten aber nicht verständlichen Hilfeanweisungen (zumindest aus Laiensicht hilft die Aussage: Prüfen Sie die COM-Schnittstelle" oder "Registrieren sie die fehlende DLL im System erneut" nicht wirklich was).

Die Litanei liesse sich noch um einige Punkte erweitern ... was wahrscheinlich die mögliche Zeichenanzahl für diesen Beitrag sprengen würde.

Fazit ist aber schlicht: Vertriebssoftware und CRM-Tooles werden genug angeboten, aber extrem selten genutzt schlicht wegen Inakzeptanz bei den Vertrieblern. Meistens wird sie nur genutzt wenn der Vertriebsleiter ordentlich und mächtig Rabatz gemacht hat und schon mit Kündigung droht. Zumindest so in meiner ehemaligen Branche.

Gruß

Rainer

 

Ist zwar inzwischen OT, aber eins vergaß ich noch zu erwähnen:
Es ist nicht nur die Featureitis, die zu Anwendungen mit mangelhafter Schnittstelle führt.
Es ist auch die Tatsache, dass einem die Entwicklungs-Tools-Hersteller ständig was neues unterschieben.
Dadurch hat man andauernd damit zu tun, die imgrunde gleiche Anwendung lediglich auf ein anderes System zu hieven.
Hier für Access: Man migriere eine A2003er-DB nach A2007 und schon hat man ordentlich damit zu tun, die Oberfläche neu zu programmieren, ohne dass für den Anwender auch nur der kleinste Zugewinn raus kommt.

Oder manche sind der Meinung, dass Access eh keine Zukunft mehr habe, und man nun rechtzeitig auf den Visual Studio-Zug aufspringen müsse.
Ja, super, ich kenne solche Leute, die seit nunmehr einem halben Jahr ihr Access-Frontend auf VB.NET migrieren und noch immer nicht die gleiche Funktionalität haben. Und wenn sie dann fertig sind, ist das System bereits veraltet, weil es viel bessere Möglichkeiten mit LINQ gibt - ach nein, inzwischen auch nicht mehr LINQ, sondern Silverlight und NET 4.0... VS2010 kommt ja gerade raus.

Viel Spaß auch mit Access 2010, das in den nächsten Wochen das Licht der Beta-Öffentlchkeit erblickt! Damit könnt ihr euch die Weihnachtszeit versüßen und zu erforschen versuchen, wie man eine normale Access-DB ins Web bekommt. *wink.gif*

Manchmal hat man den Eindruck, dass die ganze Programmierergilde sich nur noch um sich selbst dreht und den Kontakt zur Außenwelt verloren hat.
Ein bisschen Entschleunigung täte den Produkten wahrscheinlich gut.

Ok, nun ist aber gut mit dem OT!

Ciao, Sascha

 

Hi,

nennt mich einen Ketzer, wenn ich sage: unvollständige Daten sind schlimmer als keine Daten. Denn das Nacherheben findet erfahrungsgemäß nicht statt. Ich halte es für naiv, sich "irgendwann mal die Datenqualität vorzunehmen" und in einem Rutsch z.B. die Anrede/geschlecht nachzupflegen (und sei es autoamtisiert). Das passiert doch eh nie! Type and forget, so kenn ich meine Erfasser. Und dann wird auf halbfertige Daten ein Serienbrief gesetzt. Panik kommt da nicht auf, weil der Serienbrief sehr geduldig ist....

Es ist zwar richtig, wie Rainer sagt, dass übermäßig streng ausgestaltete Plausis/Pflichtfelder und begrenzte Möglichkeiten für z.B. telefonnummern die Eingabe hemmen. Dem unbedarften Anwender ist es aber völlig egal, welche Qualität die Daten haben. Wenn er könnte, würde er Kunden ohne Vor- und Nachname anlegen. Dann ist er nämlich schneller fertig. Sind ja nur sch... Daten. *frown.gif* Was schert es ihn.

Meine Programme jedenfalls erzwingen daher die nötigen Angaben. No way out! Aber was nötig ist, wird mit dem Auftraggeber besprochen. Und das, was er als nötig ansieht, wird gnadenlos durchgesetzt. Eine Anrede oder Geschlechtsangabe halte ich für meine Aufgaben z.B. für nicht zwingend, da ich meist eher eine Kundengruppe einrichte (und Menschen, egal ob m oder w, sind da eine Gruppe: natürliche Person; die Anrede ist im Briefkopf dann allgemein gehalten und entfällt im Adressfeld). Das Geschlecht "darf" sowieso in immer weniger Zusammehängen eine Rolle spielen (AGG und so). Selbst "Ausfall" wegen Elternzeit ist ja inzwischen für m und w möglich.

Es ist m.E. absolut nötig, dass der Auftraggeber des Programms sich klar macht, was unverzichtbar ist und was er nur aus Gewohnheit für nötig hält. Der Programmierer kann das nicht sicher entscheiden.

Übergenauigkeit ist meist nicht so schlimm wie Rainer es schildert. Wo ist das Problem, z.B. beim Auto-TÜV (der ja nur Monat und Jahr angibt), Monat und Jahr einzugeben und die implizit auf dem Monatsersten zu setzen?

Andererseits: wozu die Gehaltsangabe in Euro und Cent, wenn das schwankt? Bei meiner Gehaltsabrechnung z.B. werden private Telefongespräche (if any) als letzter Posten vor der Auszahlung abgezogen. Da sind doch Gruppen/Bereiche/Größenordnungen viel besser. Unzulässige Vereinfachung, da "ein Gehalt" einzutragen. Außerdem sagt das gehalt auch wenig aus, wenn der Aufhebungsvetrag schon unterschrieben ist oder die Pleite des Arbeitsgebers absehbar ist.

Wisset, was ist wissen wollt. Aber deutet es richtig.

Edit: Papier ist geduldig. Natürlich kann ein Kunde unsinnige/unvollständige Daten liefern. Aber wenn wir von Außendienstlern reden, kann man denen schon zutrauen, dass die bei einem Kunden alle relevanten Daten erheben. Bei den meisten Kunden erkennt man ja, ob es m oder w ist *wink.gif* Und wenn es um verschickte Papierformulare geht: da fasst man halt nach oder richtet eine Webseite mit (sparsamen) Pflichtfeldern ein.

 

Ich misch mich jetzt auch noch mal ein.
Frei nach dem Motto: Es ist zwar schon alles gesagt aber noch nicht von allen.

Grundsätzlich möchte ich Sascha beipflichten: so wenig Daten wie möglich als Pflichtfelder um einen Datensatz erst mal abzuspeichern, der an anderer Stelle benötigt wird. Zum Beispiel: um eine Bestellung eines Kunden aufzunehmen, brauche ich doch bei der Neuanlage des Kundendatensatzes nicht seine Kommunikationsdaten oder sein Geburtsdatum etc. ... da reicht es doch, den Datensatz mit Name und ggf. Vorname anzulegen.

An anderer Stelle, wenn es darum geht, die Rechnung (oder Auftragsbestätigung) auszudrucken, dann sollte das Programm so 'intelligent' sein, die fehlenden Daten anzumahnen und die Verarbeitung ggf. zu unterbrechen.

Ich entwickle vorzugsweise in direkter Zusammenarbeit mit den künftigen Anwendern. Das macht zwar etwas mehr Gespräche notwendig und kostet den Auftraggeber die Zeit, die er diese Leute freistellen muss abgesehen davon, dass die Anwender auf diese Weise eine Maßanfertigung erhalten, spielen sie auch gleichzeitig Alpha- und Beta Tester (denn: wer kann sich schon eine eigene Testabteilung leisten).

 

Ein wenig sollte man schon differenzieren zwischen "Eingabesklaven" und denjenigen, die ein Programm auch nutzen.

Bei der von mir betreuten, jeweils lokal betriebenen Anwendung ist der Eingebende jeweils auch der Nutzer, und die Daten sind die Daten seiner Kunden, und er würde schon aus rein egoistischen Motiven möglichst komplett erfassen wollen, wenn er könnte. Immerhin will er auch die aufbauenden Auswertungen nutzen.
Unter diesem Aspekt funktioniert auch eine extrem niedrige Pflichtfeldquote.

Was der einzelne Anwender an Auswertungen nutzt und damit, welche Daten dafür notwendig wären, ist dann individuell recht unterschiedlich. Insofern lassen sich "Auftraggeberanforderungen" schwer fassen.

 

Hi,

auch interessierte "Endnutzer"/Auswerter erkennen aber oft nicht, dass es z.B. oft mehrere Leute gleichen namens (Vorname, Nachname) in der gleichen Stadt (Ort) gibt.

Diese Felder als Pflichtfelder mögen genügen, um die einzelnen Bestellung zu erfassen. Aber: sie genügen nicht, um den Kunden in der mglw. schon vorhandenen Datenmenge wiederzufinden.

Zu fragen "Ist es einer von denen?" ist aus dem Namen und Ort alleine nicht zu klären. Willi Müllers in Wiesbaden gibts viele. Da ist jede Antwort falsch.

Und im Zweifelsfall wird der Kunde also neu angelegt. *rolleyes.gif* "Eh man es dem falschen in Rechnung stellt..." Dem Anwender ist das egal; "Hauptsache die Bestellung geht raus". Dem "Datenqualitätsbeauftragten" nicht, denn alle Auswertungen nach Kundenrentabilität etc. sind falsch.

Und solche Karteileichen werden faktisch nie aufgeräumt. Wie auch, wenn man sie nicht unterscheiden kann. Wie unterscheidet man 50 Willi Müllers in Wiesbaden? Selbst das Geburtsdatum könnte mehrfach auftreten (auch wenn es ziemlich signifikant ist und die Trennschärfe erhöht).

Das ist m.E. das Hauptproblem: Identifikation. Im Extremfall genügt die Kundennummer. Aber die meisten Kunden wissen die nicht oder sind neu (sagen das aber nicht). Alle anderen müssen anhand geeigneter Suchkriterien gesucht werden. Mangels Pflichtfeldern kommen dafür aber nur wenige Felder in Frage.

 

Vielleicht sollte man auch bei der Aufgabenstellung an eine Datenbank etwas offener sein. Nicht immer werden nur Geschäftsvorfälle dokumentiert, manchmal baut man auch erst Beziehungen und Vertrauen zum (bis dahin potentiellen) Kunden auf, um zu Geschäften kommen zu können. Dort ist es naheliegend, dass nicht alle benötigten Informationen auf einen Schlag vorliegen.

Und nebenbei: Für manche sind Kunden keine Karteikarten, sondern Menschen - der (dann auch qualifizierte) Kontakt zu diesen ist von einem Betreuer/Verkäufer ausdrücklich gewünscht. Und man darf es glauben: Wenn man sich ab und an mit seiner Kundenliste auseinandersetzt, kann man durchaus 3 - 7000 Personen einordnen.

 

\@ebs:
Naja, dann brauch ich auch keine Datenbank mehr. Wenn ich alles "im Kopf haben muss" bzw. kennen/wissen soll...

Es geht ja i.d.R. gerade um die Unabhängigkeit vom Wissen Einzelner. Kein Chef/Guru, ohne den nichts geht, sondern zentrale Ablage relevanter Daten.