Office: (Office 2000) Männlein oder Weiblein

Merkwürdige Folgerungen. Einen Serienbrief, um beim Thema Adresse und Anrede zu bleiben, schreibe ich nicht mit dem Kopf.

Ich wollte nur darstellen - und da sehe ich mich in Übereinstimmung etlicher bereits geäußerter Meinungen - dass Informationsgewinnung wie auch das Lernen an sich nicht nur eine Aktion auf Knopfdruck, sondern meist eher ein Prozess ist. Das Ziel (= vollständige Daten in der DB) ist doch unbestritten.

 

\@ Atrus

Wir reden hier wohl von unterschiedlichen Situationen/Auftragslagen. Das eine - von dem Du redest - ist die Datenbank die sich die Führungsriege eines Großunternehmens wünscht und deren Bedingungen müssen erfüllt sein, völlig wurscht ob es dem kleinen Angestellten unten passt oder nicht er muss es so bedienen und wenn es im Extremfalle heissen sollte das er seine komplette Arbeitsweise umstellen muss. Das interessierte die Herren oben nicht und die Fragen auch nicht oder weniger nach Anwenderfreundlichkeit, da der Angestellte es so anzuwenden hat oder er ansonsten fliegt.

Ich sage mal salopp eine relativ komfortable Position für den Entwickler da man sich tatsächlich nur darum Gedanken machen muss das das Programm funktioniert und nicht das der Eingebende damit auch klar kommt und Freude bei seiner Arbeit hat. Und sind die Herren in den oberen Etagen zufrieden ist es völlig latte was der kleine Angestellte davon hält.

So läuft es in Großunternehmen wo der Datenbestand mehr zählt als der Anwender.

Anders sieht es aus wenn der Bezahlende selber der User/Eingebende ist oder engen Kontakt mit den Eingebenden hat.

Da zählt nur und in erster Linie Anwenderfreundlichkeit und Einsatz in der Praxis ohne die Arbeitsweise zu verändern. Funktionen und Features sind erstmal zweitrangig (die entscheiden "nur" ob das Programm überhaupt in die Auswahl kommt).

Deswegen sieht es in kleinst und mittleren Unternehmen ganz anders aus (und das sind ja wohl eindeutig unsere Hauptauftraggeber ... denke das wir Access-Entwickler sehr sehr selten mal in die Verlegegenheit kommen einen Entwicklungsauftrag von Siemens zu erhalten ^^), da entscheidet sehr oft der Eingebende ob die Software taugt oder nicht. Den kein Chef mag es wenn ihm seine Sachbearbeiter tagtäglich in den Ohren liegen was er da wieder für einen Krampf gekauft hat damit kann man ja gar nicht vernünftig arbeiten.

Software wurde bei meiner alten Firma in der Zentrale so gekauft: Chef suchte erstmal nach Features und Funktionen mögliche Software-Kandidaten aus. Chef startete die Demo-Version, sah sich den Bildschirm an und wenn der ihm nicht gefiel (im Sinnen von zu überladen, nicht sofort ersichtlich was zu tun ist) war die Thematik schon erledigt und das Programm weg vom Fenster. Gefiel ihm der Bildschirm hat er ein wenig rumgehakt, konnte er dabei Grundfunktionalitäten ohne Hilfe erfassen und nutzen war er zufrieden (Sein Lieblingsspruch dazu: "Das ist eine gute Software, die kann sogar ich bedienen") ... hat er aber erst die Hilfe lesen müssen um Grundfunktionalitäten zu beherrschen oder lange in irgendwelchen Menüs suchen müssen, war die Software schon gestorben (O-Zitat ... sehr wörtlich wiedergegeben da ich den öfters gehört habe: "Sind die zu blöde Software zu schreiben die man auch bedienen kann?").

Waren die zwei Tests beim Chef bestanden, ging die Demo-Version an die Aussendienstler oder Innendienstler (je nachdem für was die Software gedacht war) mit der Anweisung "Probiert es mal aus ob ihr damit zu Recht kommt".

Und erst wenn die zufrieden waren und begeistert genickt haben, wurde gekauft.

Bestes Beispiel war ein Browser-Programm zur Koordination und Steuerung von Terminen und Kontakten. Konnte alles was gefordert war, viel aber sang- und klanglos in der Praxis beim AD durch ... der AD hat sich schlicht geweigert das Programm zu nutzen und das nur wegen Kleinigkeiten in der Anwenderfreundlichkeit.

Das Ziel ist also nicht in erster Linie 100% vollständige und korrekte und nicht redunante Datensätze zu haben, sondern den Anwender dazu zu bewegen erstmal überhaupt damit gerne zu arbeiten. Denn dann kommen überhaupt erstmal Datensätze in die DB und dann kann man sukzessive auf die Vollständigkeit der DS hinarbeiten ... will er Serienbriefe/-Emails und es fehlen Anreden ... na gut, aussortieren, anzeigen und bitten zu ergänzen.

Der Anwender wird erst die Notwendigkeit von vollständigen DS erkennen und auch verstehen, wenn er in eine Situation kommt wo er das Ergebnis gerne hätte und das nun nicht vollständig bekommt weil er Eingaben vergessen hat. Jetzt leuchtet ihm der Sinn der Anrede ein und jetzt wird er ihn auch gerne eingeben da er ja das Ergebnis gerne möchte.

Wäre es ein Pflichtfeld das schon bei Anlage des Kontaktes gefordert wäre, wäre der User im besten Falle nur genervt da er den Sinn und Zweck noch gar nicht einsieht, bzw. die Anrede noch gar nicht braucht ... also wofür was eingeben wenn ich es noch gar nicht brauche?

Natürlich ist es das Endziel vollständige DS zu haben ... aber es ist kein Ziel mit erster Priorität. Das Ziel der ersten Priorität ist dem User die tägliche Arbeit zu ermöglichen damit er überhaupt DS eingibt und das er Deine Anwendung so sehr mag das er sie auch käuflich erwerben möchte.

Deswegen meinte ich vorhin komfortabele Position wenn die Anwendungs-/Kaufentscheidung von denen getroffen wird die nie damit arbeiten müssen. Für die zählt nur ob hinten die Auswertung rauskommt die sie gerne möchten, aber nicht wie die Daten reinkommen und wie sich die tägliche Arbeit damit gestaltet. *wink.gif*

Gruß

Rainer

 

Hallo zusammen,
zum Thema Pflichtfelder: Meiner Meinung nach sollten so wenige wie möglich vorhanden sein. Allein aus der Erfahrung, dass genervte Anwender das reinschreiben, was am schnellsten geht und nicht unbedingt was sinnvolles. Wenn dann alle Anreden nur aus "x" bestehen oder alle auf "Herr" gesetzt sind, weil das die erste Auswahl ist, hilft das auch nicht weiter. Ich schließe mich da Rainer an: Der Anwender gibt die Daten vernünftig ein, die er einsieht.
Bei allem anderen wird Murks herauskommen, dem ist auch nicht mit Pflichtfeldern beizukommen.

Gruß
Vincenz

 

\@raist:

So ein Sklaventreiber bin ich ja nun auch nicht. *wink.gif*

Die meisten Kunden, die ich bisher hatte, waren dankbar für die (z.T. fast schon unternehmensberaterähnlichen) Überlegungen, die ich bei den Vorbesprechungen eingebracht habe. "Hätte ich nie dran gedacht", hieß es oft.

Es ist ja nicht so, dass ich in meinen Plausis und Pflichtfeldern was verlange, was völlig weltfremd ist. Ich mache schon fast alles, was die von mir verlangen. Aber ich mache die Auftraggeber gerne auf Dinge aufmerksam, die ich für suboptimal halte. Ja, das mag besserwisserisch klingen. Aber oft sind Betriebsfremde (und das bin ich fast überall) bessere Indikatoren für Optimierungspotential als Betriebsblinde, die "das schon immer so gemacht haben". Und dann wollen sie meistens auch, was ich vorschlage: "ist ja prima, dann brauchen wir nicht mehr xyz zu machen": Ja, eben. *Smilie

Mir ist immer wichtig, den Workflow dahinter zu erkennen und zu durchdringen. Das zeigt mir, worum es eigentlich geht. Und dann kann ich (und viele andere) auch erkennen, was nötig ist, anstatt im Nachhinein zu erkennen, was hätte gemacht werden müssen.

Beispiel: kleine Baufirma, Baustellenverwaltung. Man "will" nicht angeben, ob der Kunde ein Privatmann oder eine Firma ist. Mein Einwand: von dieser Kundenart hängt der korrekte MwSt-Ausweis ab [1]. Es muss also sein. Wussten sie zwar, haben sie aber nicht bedacht. Was ist nun das bessere Programm: eins, das das "lästigerweise" erzwingt, oder eins, das Angebote auch ohne diese Angabe schreibt (und das dann nur falsch machen kann).

Ich bin aber auch noch nie davon abhängig gewesen, meine Programme zu verkaufen. Meist waren es nicht nur Programmierungs- sondern auch Optimierungsaufgaben. Ich wurde also nicht verflucht. Oder wenn, dann auftragsgemäß und gegen Entgelt *wink.gif*

[1]Ohne ins Detail gehen zu wollen: Stichwort Schuldung der MwSt durch den Auftraggeber, wenn der eine Firma im Bauhauptgewerbe ist.

 

Einfaches Gegenbeispiel: Versicherungssoftware.

Nicht wenige Anwender hassen es, wenn man, um mal schnell eine Variante rechnen zu können, erst einen kompletten Kunden anlegen muss ...
Die Berechnung könnte zeigen, dass dieses Ergebnis nicht geeignet ist, die Person als Kunden zu gewinnen.

Eine Verstärkung des Problems wird dann eintreten, wenn der Dienstleister Angebote mehrerer Unternehmen mit jeweils deren Software rechnet, um sich und dem Kunden einen Vergleich zu ermöglichen.

 

Dafür kann es ja "Präsentations-"/Dummykunden geben. Auch der Kunde an der Imbissbude ist immer der gleiche: "Barzahler". Der isst ziemlich häufig da *wink.gif*

Im übrigen wird bei der Versicherung die "Variante" von einigen Parametern abhängen, aber sicher nicht vom Namen.... Das, was nötig ist, um eine qualifizierte Versicherungsberatung abzugeben, muss sein. Sonst ist die Ausgabe nicht verlässlich.

 

Darf ich zusammenfassen?

Die Mehrheit ist der Auffassung, dass Pflichtfelder nur dort vorgeschrieben werden sollen, wo die wirklich nötig ist, um die Hemmschwelle der Anwender zu senken.
Zusätzlich ist "Intelligenz" im Programm sinnvoll, die einerseits dem Anwender bei der Eingabe Arbeit abnimmt und weiter an Stellen, wo Inkonsistenzen im Datenbestand auftreten, die zu beheben sind. Also nachträgliche Plausibilitätsmechanismen.
Weiter ist jedoch darauf zu achten, dass je nach gestellter Anforderung und Weiterverarbeitung der Daten, nicht zuviel Freiheit geboten wird. Die Ust.-Geschichte von Atrus war ein gutes Beispiel dafür.
Und auch das würde ich unterstreichen: Die Einführung oder Optimierung einer Datenverarbeitung bringt im Zweifel auch immer Umstrukturierungen mit sich. Es ist auch für mich ganz normal, mich da als Ratgeber zu betätigen. Gerade im Workflow gibt es praktisch immer Optimierungsbedarf, zumal so ein Unternehmen ja kein statisches Gebilde ist, sondern sich dauernd neuen Herausforderungen stellen muss, denen es gerne mal hinterher hinkt.

Ich fand diesen Thread außerordentlich fruchtbar!
Das sind Themen, die mir besonders am Herzen liegen, wie vielleicht auch der eine oder andere weiß, der sich zufällig mein Buch zu Gemüte führte.
Neben all der Technik darf nie aus dem Fokus, wofür man überhaupt entwickelt!

1+ für diesen Thead!

Ciao, Sascha

 

Keine Diskussion, ohne diese Kenntnisse kann man nur "Mist" programmieren.

Das sehe ich ein wenig anders als Du. *wink.gif*

In meinen Augen sind beide Programmarten die Du beschreibst suboptimal, das eine mehr das andere weniger.

Wann wird der MWSt-Ausweis benötigt? Bei der Angebotsserstellung. Dann reicht es völlig den User an dieser Stelle zu den Angaben zu zwingen wenn er das Angebot erstellen will. Hier sieht er es auch ein und empfindet es nicht als lästig/nervend.

Der Verkäufer der den Kunden angelegt hat, der empfindet es aber mit Sicherheit als nervend wenn er schon Daten eingeben muss die noch gar nicht zu dem Zeitpunkt benötigt werden. Den nicht bei jedem Kunden der neu angelegt wird, kommt man auch zu einer Angebotsabgabe.

Ich sehe das unter dem Motto alles an Eingaben ermöglichen, nichts erzwingen. Nur wenn Eingaben für eine Aktion nötig sind, dann erst werden sie erzwungen.

Keine Angebotsausdruck/-versand ohne Angabe der Kundenart wäre hierbei das Mittel meiner Wahl. Das versteht jeder, aber auch wirklich jeder der mit der Materie zu tun hat und das hat die Firma bis Sie dich kennen gelernt hat auch nicht anders gemacht.

Aus welcher Sicht? Aus der Sicht des DB-Entwicklers vom grünen Tisch aus? *wink.gif*

Oder aus der Sicht des Anwenders der tagtäglich damit umgehen muss?

Ersters wird es sein, weil Du letzteres nicht bist.

Da gebe ich Dir auch wieder Recht.

Aber dann ist es nicht die Aufgabe des Programmieres die Abläufe zu ändern. Das macht nur Ärger und führt zu unsinnigen Diskussionen die manchmal dazu führen können einen Auftrag zu verlieren.

Sondern die Aufgabe des Programmieres ist es die Möglichkeit zu bieten mit den alten Abläufen zu arbeiten aber als Alternative dazu eine Möglichkeit zu schaffen neue Abläufe zu integrieren und diese im Einsatz paralell zu den alten Abläufen einzusetzen.

Denn eines sei Dir gewiss, Du kannst bei der Workflow-Beratung noch so richtig liegen mit Deinen Ideen und Vorschlägen und am Tisch wird Dir zugestimmt. Aber jmd der seit 10 oder 20 oder mehr Jahren so (mehr oder weniger) erfolgreich arbeitet wirst Du nicht umstellen/ändern, sondern der wird so weiter arbeiten wie zuvor. Und wenn es die Mehrheit der Eingebenden ist, dann wird es problematisch oder Junior-Chef stimmt Dir zu und Senior-Chef lehnt ab.

Das sind keine Aussage von einem Programmieren, sondern die habe ich aus Sicht eines Vertrieblers der rd. 20 Jahren seines Leben nur verkauft hat geschrieben. *wink.gif*

Und um was geht es bei Aufträgen? Richtig, nicht der beste Programmierer bekommt den Auftrag (das kann der Kunde nämlich nicht erkennen), sondern derjenige der die (vermeintlich) beste Lösung bietet. Und beste Lösung bezieht sich i.d.R. auf einfaches Handling, schnelle und problemlose Integration in den laufenden Betrieb und das die Angestellten auch gut damit zu Recht kommen.

Diskutiere nie mit einem Kunden darüber das er seinen Betriebsablauf an Dein Programm anpassen muss/sollte. Das kannst Du mal in zweiter oder dritter Linie tun. Nämlich dann wenn Du den Auftrag hast, das Programm bereits läuft und alle zufrieden sind. Dann wirst Du Gehör finden. Machst Du es vorher baust Du eine unnötige Diskussion auf die Dich mit guter Wahrscheinlichkeit vielleicht den Auftrag kosten könnte, spätestens dann wenn ein zweiter Programmierer um den gleichen Auftrag kämpft und dem Auftraggeber alles mögliche verspricht/verschweigt um den Auftrag zu bekommen steigt die Wahrscheinlichkeit den Auftrag zu verlieren nochmals an.

Immer der erste 100%ige Ansatz einen Auftrag zu verlieren/nicht zu bekommen. *wink.gif*

Wenn ich als EX-Vertriebler Vertriebssoftware verkaufe, weiss ich wovon ich rede, wie das Tagesgeschäft aussieht und wo die Probleme liegen und kann mit meinen Kunden auf gleicher Kenntnis- und Erfahrungsebene reden. Mir würden zwar jeder aus der Branche zu hören, da ich die gleiche Sprache spreche, durch branchentypische Merkmale nicht darüber reden muss ob ich erfolgreich war oder nicht und weil mich einige aus Seminaren die ich gehalten habe kennen.

Aber trotzdem werde ich auch da wo ich Erfolglosigtkeit auf Grund falscher Arbeitsweise erkenne, bestimmt nicht mit dem Kunden/User darüber diskutieren das er eine andere Arbeitsweise braucht/umsetzen muss um mehr/besseren Erfolg zu haben.

Sondern ich mache ihm einfach klar das er meine Software so wie sein Tagesablauf ist und seine Gewohnheiten sind einsetzen kann. Dazu zeige ich ihm alternative Möglichkeiten mit der Software umzugehen, bzw. anders als bisher zu arbeiten ... aber was er dann letztendlich tut, ist mir völlig latte. Hauptsache er ist zufrieden, erzielt die Ergebnisse die er sich erwartet und bezahlt zufrieden den Preis der Software.

Und bei Branchen in denen ich nicht 20 Jahre gearbeitet hat, würde ich tunlichst die Klappe zum Thema Arbeitsablauf Veränderung halten. Wofür diskutieren und den Auftrag in Gefahr bringen?

Erkenne ich alternative bessere Wege, baue ich die mit ein oder sehe sie zumindest vor und biete diese in einem Nachgang an.

Bitte, wie alles ist das nicht 100% in allen Fällen richtig. Es wird auch durchaus Wege geben, wo der Entscheider weiss das er eine Software braucht aber nicht wirklich weiss was die können soll/muss damit es gut für ihn ist. Da sind dann natürlich Diskussionen um das Thema Tagesablauf und Integration der Software notwendig und auch erwünscht.

Aber aus Erfahrung kann ich hier sagen, zu erst immer zeigen das man alles machen kann was der Anwender will und wie er es will ... aber der Weg B wäre doch auf Grund XYZ am geeignesten für Ihren Betrieb, oder meinen Sie nicht? *wink.gif*

Just my 5 Cents. ^^

Gruß

Rainer

P.S.: Immer frei nach dem Motto .... ich will schließlich Software verkaufen und nicht Weltenverbesserer spielen (was eh sowas von undankbar ist, ich kenne zumindest keinen materiell erfolgreichen Weltenverbesserer .... zumindest nicht zu Lebzeiten ^^).

 

Hallo!

So, ich aber auch, weil mich das Thema Pflichtfelder auch schon mehr oder weniger beschäftigt hat.

Wäre das nicht ein Thema für Access im Unternehmen? Weniger die technische Abwicklung für die Programmierung von Pflichtfeldern (gab es ja schon), sondern eher die grundlegenden Gedanken und die möglichen Eingabehilfen (Warnungen bei Dublettenverdächtigen, Straße falsch geschrieben, Straße gibt es im Ort gar nicht usw).
Mich würde als Thema diese "Fuzzy-Logik" und deren Einsatzmöglichkeiten in Access interessieren.

Grüße
Ingo

 

Hallo,

auch 1+ für dieses Thema!

Zusammenfassung von Sascha ist eigentlich die Zusammenfassung:

Alle haben Recht, es kommt immer auf die Situation, das Programm und den Kunden an

Meine Erfahrung: Weniger auf Auftragssicherung bedacht sein und mehr Weltverbesserer sein!

aber eben nicht immer*biggrin.gif* *biggrin.gif*

Gruß Peter

 

Du hast vergessen anzufügen: ... wenn man sich es finanziell leisten kann. *wink.gif*

Gruß

Rainer

 

Hallo an alle,
auch von mir herzlichen Dank für diesen Thread!

Mal "ganz einfach" gedacht:
Wenn Pflichtfelder sein müssen, kann es ja für jedes Pflichtfeld eine "eigene" Eingangsmöglichkeit geben.
Bisipielsweise
Kunde weiblich: Schaltfläche "Neuer Auftrag Frau"
Kunde männlich: Schaltfläche "Neuer Auftrag Herr"
Kunde weiblich Kind: Schaltfläche ...usw.
Naja, möglicherweise ist das aber auch wieder "das Problem von hinten angepackt"... :-)
Gruß, Dirk

 

vor lauter Herrs und Fraus findet man dann nicht mehr das, was man eigentlich klicken will... auch keine gute Idee.

Insgesamt eine fruchtbare Diskussion, aufgrund derer ich selbst sicherlich auch nochmal über das eine oder andere nachdenken werde bei meiner nächsten Entwicklung :-)