Wie fachlich klare Konzepte technische Probleme lösen

Nachdem ich im vorherigen Beitrag Beispiele zur Abgrenzung des fachlichen Konzepts Kunde gegeben habe, möchte ich in dem folgenden Video erklären, wie die Fachabteilung zu guter Software beitragen kann. Denn wenn fachliche Konzept klar abgegrenzt werden, fallen viele technische Probleme automatisch weg.

Der Klick aufs Bild führt zu dem Video in meinem YouTube Channel. Unten auf dem Zahnrad könnt ihr die Auflösung hochsetzen.

Video mit der Erklärung für die Fachabteilung woher die technischen Probleme bei der Vermengungen von fachlichen Konzepten kommen.

Werbung

Das Konzept Kunde gibt es nicht

Die Entwickler müssen genau hinhören, was mit manchen Begriffen gemeint ist. (Quelle: Fotolia)

Im vorherigen Artikel habe ich erläutert, wie der Domänenbegriff Kunde in unterschiedlichen Bedeutungen verwendet wird. In diesem Post mache ich einige Vorschläge, welche zeigen, wie es sich besser machen lässt.

Der Kunde im Verkauf ist die Person, die meine Produkte kauft. Er ist also der Käufer.

Im Support ist der Kunde derjenige, der meine Produkte bedient und sich bei Fragen zur Bedienung an den Support wendet. Da könnten vielleicht Anwender oder Nutzer als Begriffe in Frage kommen.

Im Rechnungswesen ist der Kunde derjenige, der mir Geld für meine Produkte schuldet und die Schuld dann hoffentlich begleicht. Schuld => Debit => Debitor. Oder alternativ Kontoinhaber. Das wiederum könnte aber zur Verwechslung mit den Lieferanten führen, die natürlich auch Kontoinhaber sind. Also nehmen wir besser Debitor.

Im Versand oder im Lager geht es darum die Produkte an einen Empfänger auszuliefern. Wir benötigen die Adresse, um das Paket, das die Ware erhält, zu adressieren. Also Empfänger, Adressat, Warenempfänger – man hat die freie Auswahl.

Das Marketing hat unter anderem die Ziele, die Neukundenakquise mit Werbemaßnahmen anzukurbeln, gleichzeitig aber die Kundenbindung zu festigen. Also wie wäre es mit Neukunde und Bestandskunde. Alternativ potentieller Kunde oder – für manche Branchen denkbar – Kandidat.

Fazit

Es muss nicht immer schwer sein gute Domänenbegriffe zu finden, die klar ausdrücken, worum es sich bei dem Konzept handelt. Oftmals genügt es sich die Domäne, in der der Begriff verwendet wird, anzuschauen und zu umschreiben, was der Begriff ausdrücken soll. Mit der Erfahrung wird das für den Fachexperten ganz selbstverständlich und ihm springen förmlich schlechte Benennungen ins Gesicht (schon mal über das Konzept der ‚Benutzer‘ nachgedacht?).

In meinem nächsten Artikel kommen wir zu der spannenden Frage, woher die technischen Probleme bei Vermengungen von Bedeutungen kommen.

Was meint die Fachabteilung eigentlich, wenn Sie von Kunden spricht?

Jede Fachabteilung spricht von dem sogenannten Kunden (Quelle: Fotolia)

Heute war ein Meeting mit dem Rechnungswesen. Sie wollen eine Änderung, um einfacher die Kontodaten unserer Kunden ändern zu können. Letzte Woche sollte unser Kampagnen-Tool fürs Marketing dahingehend erweitert werden, dass sich detaillierter Informationen zu den Kunden sammeln lassen. Und nächste Woche, so wurde mir gesagt, soll ich mit dem Verkauf sprechen, um in den Gutschriften für Kunden einen Passus zu ergänzen.

Ups, was ist da los? Alle Welt spricht von dem ‚Kunde‘. Aber ist dabei immer der gleiche Kunde gemeint? Also natürlich ist es dieselbe Firma bzw. Person, aber ist auch das gleiche Konzept gemeint? Oder anders gefragt: Würde das Rechnungswesen Informationen über die Kundenbeziehungen ändern oder würde der Versand Änderungen an Gutschriften durchführen? Wohl eher nicht. Benötigt denn der Kundenservice in seiner Oberfläche Informationen wie die Bankverbindung oder muss das Rechnungswesen die abonnierten Mailinglisten des Kunden sehen können? Ups, da war es wieder: Der Kunde.

Mit diesem Artikel soll der Einstieg in eine kleine Serie gemacht werden, in der ich erkläre, warum sich viele Probleme mit der Anwendung bereits dadurch vermeiden lassen, dass die Fachabteilung bei Domänenbegriffen respektive -konzepten genauer abgrenzt und explizit macht, was sie meint.

Beispielsweise wirkt sich das, auch wenn es der Anwender nicht glauben mag, stark auf die Geschwindigkeit und die Skalierbarkeit des Programms aus. Gleichfalls ist die Erweiterbarkeit und die Entwicklungsgeschwindigkeit davon betroffen. Oder die Usability. Genauso die Sicherheit und die Fehleranfälligkeit. Ganz schön viel, was die nicht differenzierte Betrachtung eines Kunden ausmachen kann oder?

Im nächsten Teil erläutere ich Beispiele, die zeigen: Hey, das ist gar nicht so schwer eine klare Unterscheidung zu machen.