Stellenbeschreibung „Feuermelder“
- Professionelle Bezeichnung
- Kurze Zusammenfassung „Feuermelder“

SOA für den Hausgebrauch
- Grundstruktur der SOA
- Kommunikation – Rückgrat der SOA
- Ein paar Hinweise zur Realisierung
- Im Auge zu behalten
- Ein paar interessante Links zu diesem Thema
- Ein paar Begriffsbestimmungen

Dos and Don'ts für Software-Häuser oder: Wo bitte geht's zur Serviceorientierung?
- Bestandsaufnahme eines praktischen Falles
- Typische Aussagen und Beispielfälle
- Die betriebswirtschaftliche Prämisse und technische Produkte
- Fazit

1) Flickenteppich-Syndrom

Betriebswirtschaftliche Prämisse / Synergie

Betriebswirtschaftliche Prämisse:

Jedes Projekt darf nur im Rahmen des vom Kunden bezahlten Umfangs behandelt werden

Software ist ein technisches Produkt und unterliegt deshalb technischen Zwängen, sollte also nicht mit denselben Managementregeln „wie Toilettenpapier“ verwaltet werden, solange Zukunftsorientierung und komplexe Aufgabenstellungen als Ziel akzeptiert werden.

Die Fixierung auf Aufwandsminimierung und Auftragsumfang verhinderte im vorliegenden Praxisbeispiel mögliche Synergieeffekte mit anderen Projekten oder auch bestehenden Funktionalitäten: Die Software zerstückelte sich bei jeder Fortentwicklung weiter in Einzelfunktionen, die darüber hinaus noch kundenspezifisch waren und sich häufig als nicht wirklich allgemein nützlich erwiesen („Flickenteppich-Syndrom“). Weil sich diese Eigenschaft des „Standards“ jedoch in einträglichen Modifikationen niederschlug, hatte sich die betriebswirtschaftliche Prämisse selbst bestätigt.

2) Kostenbeschränktes Denken

Betriebswirtschaftliche Prämisse / Synergie

Schnelle Lösungen, günstige Angebote

Das Diktat der betriebswirtschaftlichen Prämisse erforderte die Projektbeschränkung auf den Umfang, den der Kunde bereit war zu bezahlen. Um attraktive Angebote erstellen zu können, wurde deshalb häufig mit der Untergrenze der geschätzten Projektdauer gearbeitet, da eine fundierte Konzeption als zu aufwändig angesehen wurde und somit Schwierigkeiten dazu neigten, übersehen zu werden. Auch Arbeiten wie Test, Dokumentation, Fehlersuche oder Fortentwicklung sollten innerhalb der bewilligten Zeitspanne erledigt werden. Also bemühten sich die Mitarbeiter nach Kräften, die Geschwindigkeit der Verarbeitung zu beschleunigen. Dies und die klare Anweisung, sich auf das Wesentliche zu beschränken, um keine unnützen Kosten zu erzeugen, führten zu einer Lösungsfindung ohne umfassende Bestandsaufnahme oder Überprüfung der intuitiv erfolgten Annahmen. Schien eine Lösung bekannt, wurde nicht nach weiteren gesucht außer im Falle, dass diese Lösung zu aufwändig war. Die Berücksichtigung von Konsequenzen, Querverbindungen oder über das Projekt hinausgehende Anwendungsmöglichkeiten (Stichwort Synergie, Wiederverwendbarkeit) galt vielmehr als Zeitverschwendung und musste vor der Geschäftsleitung so mühsam verargumentiert werden, dass es zumeist unterblieb.

3) Programmbaustein „Mensch“

Betriebswirtschaftliche Prämisse / Synergie Zukunftstauglichkeit / Wiederverwendbarkeit

Einfache Programme, übersichtliche Konzepte

Die Schnelligkeit der Angebotsfindung führte zu einer Vagheit der Aufgabenbeschreibung, die ohne weitere Präzisierung nicht in ausführbare Programme umgesetzt werden konnte. Da Dokumentation jedoch ähnlich wie Konzeption nicht von Kunden bezahlt wird, erfolgte die Klärung der Fragen und Beseitigung von Problemen während der Programmierung der bereits begonnenen Objekte mit der Folge, dass eine sachdienlichere Aufgabenteilung zwischen den bearbeiteten Programmen nicht mehr berücksichtigt werden konnte. Regelbasierte Systeme waren damit völlig ausgeschlossen, denn diese basieren auf Metadaten und ausführbaren Prozessen, die auf einer ausgeklügelten Arbeitsteilung zwischen den regelverarbeitenden und den „Endverbraucher“-Programmteilen beruhen. Solche Systeme benötigen eine klare Analyse aller existierenden Möglichkeiten, um sie zu modellieren und damit in Regeln und deren verarbeitenden Prozesse zu gießen.

Zeitaufwändige Problemanalyse, umfangreiche Modellierung ist jedoch das exakte Gegenteil von kostenbeschränktem Denken, das Lösungen fest in Code gießen muss, da dies die schnellste und bequemste Form der Programmierung ist. Neben der Tatsache, dass jede Variante der Lösung deshalb eigenen Code benötigt, hat diese Programmiertechnik freilich noch einen weiteren Nachteil:

den Programmbaustein „Mensch“, die Kopplung von Programmen in den Köpfen der Programmierer. Weil nämlich der Programmcode den Einzelfall der jeweiligen Lösung voll beinhaltet und nicht wie bei regelbasierter Programmierung für einen ganzen Typus von Aufgabenstellungen ausgelegt ist, können die Details der Einzelfälle nicht an einer zentralen Stellen überprüft werden. Dies steht in völligem Gegensatz zur regelbasierten Programmierung, deren Einzelfall der Ausführung erst durch die Kombination von allgemeinen Programmcode und individualisierenden Metadaten erzeugt wird:

Metadaten, die einem definierten Muster folgend an einer einzigen Stelle untergebracht sind.

Die Zusammenhänge einer Einzelfall-Programmierung sind im Gegensatz dazu nicht in einer zentralen, formalisierten Art beschrieben, sondern nur über den Sourcecode ersichtlich, was bei komplexeren Prozessen sehr viele Einzelfälle von Funktionalitäten betreffen kann und damit viele Programmobjekte zur Klärung bedarf. Dies ist genauso wenig formalisierbar und damit automatisierbar wie die Frage an die zuständigen Programmierer, wie denn die Zusammenhänge im Einzelnen aussehen würden.

Die Kopplung über die Gehirne der Programmierer hat demnach den großen Nachteil, weder mit technischen Mitteln verarbeitet noch geprüft werden zu können – die Grundvoraussetzung für SOA.

4) Fortbildung

Betriebswirtschaftliche Prämisse / Zukunftstauglichkeit

Modulare Entwicklungsumgebung, die die gleichzeitige Anwendung mehrerer Programmiersprachen ermöglicht

Im Gegensatz zu den technischen Möglichkeiten wurde nur eine einzige Sprache (ILE-RPG) verwendet, die konstruktionsgemäß eine Integration moderner Konzepte sehr erschwert. Der Lern- und Planungsaufwand für eine aktuellere Umgebung wurde zwar verbal unterstützt, jedoch unter betriebswirtschaftlichen Gesichtspunkten als ungerechtfertigt angesehen.

Wegen der signifikanten Zahl von Überstunden, die von fast jedem Mitarbeiter unabhängig von seinem Gehalt verlangt wurden, erwies sich indessen auch eine Freizeit-Fortbildung als nicht praktikabel.

5) Konservativität

Betriebswirtschaftliche Prämisse / Zukunftstauglichkeit

Verwendung kleiner, einfacher Module, die bequem zu konvertieren sind

Obwohl die Notwendigkeit der Konvertierung auf moderne Programmiersprachen erkannt war, wurden keinerlei Aktivitäten hinsichtlich zukunftsträchtiger Software-Konstruktion in Betracht gezogen, da auch hier der Lern- und Planungsaufwand keine Zustimmung von der Geschäftsleitung erhielt.

6) Catch 22

Betriebswirtschaftliche Prämisse / Zukunftstauglichkeit / Wiederverwendbarkeit

Dauerpflicht bei der Programmierung zur Separierung von wieder verwendbaren Bausteinen aus dem bestehenden Programmcode

Wieder verwendbare Bausteine sind per definitionem solche, die in mehreren Programmen ihren Dienst tun können. Dies wiederum bedeutet, dass mehrere Programme bearbeitet werden müssen im Falle eines Austauschs von individuellen mit wieder verwendbaren Funktionalitäten. Diese liegen aber, rein statistisch gesehen, in der Mehrzahl außerhalb der Objekte der bezahlten Projekte. Da die Prämisse der Betriebswirtschaftlichkeit im Falle des vorliegenden Praxisbeispiels absolut und unbedingt war, konnten solche Vorhaben faktisch nur im Zusammenhang mit Großprojekten wie Neuinstallationen durchgeführt werden. Dies geschah zwar selten, erforderte jedoch regelmäßig weitgehende Anpassung, da der projektbezogene Programmierstil kaum Kundenneutralität förderte (siehe Punkt 1, „Flickenteppich-Sydndrom“).

7) Fehlertoleranz

Betriebswirtschaftliche Prämisse / Qualitätssicherung

Dauerpflicht der Programmierung zur Beseitigung von Standardfehlern während bezahlter Projekte

Vorhandene Fehler zu beseitigen verlängert die Projektdauer. Nicht kundenauffällige Fehler zu beseitigen hat deshalb keine betriebswirtschaftliche Grundlage, zumal im Falle des vorliegenden Praxisbeispiels folgender Grundsatz galt:

Weil jede Software unvermeidlich Fehler hat, ist das Ziel einer fehlerfreien Software so unrealistisch, dass es nicht weiter zu berücksichtigen ist.

8) Qualitätslimits

Betriebswirtschaftliche Prämisse / Qualitätssicherung

Dauerpflicht der Programmierung zur Qualitätssicherung während bezahlter Projekte

Testen kostet Zeit, doch Fehler, die nicht kundenauffällig sind, kosten nichts. Darüber hinaus verbessert es die Meinung des Kunden über ein Softwarehaus, wenn es rasch und unbürokratisch Fehler beseitigt. So spricht neben der betriebswirtschaftlichen Prämisse auch die praktische Erfahrung mit Kunden dafür, die Qualitätssicherung nicht zu übertreiben.

9) Dokumentation

Betriebswirtschaftliche Prämisse

Dauerpflicht der Programmierung zur Dokumentation der Projekte, verwendeten Programmbestandteile und Texte

Schreiben kostet Zeit und Kunden, die sich eine Weile mit einer Software beschäftigt haben, greifen nur noch selten auf Dokumentation zurück. Darüber hinaus sind Kunden oft nicht willens, Bedienerhandbücher oder Fehlermeldungen zu lesen, sodass die praktische Erfahrung auch hier gegen eine aufwändige, kostenintensive Dokumentation spricht.

10) Qualifikation

Betriebswirtschaftliche Prämisse / Qualitätssicherung / Effizienz /Dokumentation

Junges Team, Trennung von Programmierung, Qualitätssicherung und Dokumentation

Die Wirtschaftskrise der IT hatte auch bei diesem Praxisbeispiel Spuren hinterlassen. Um die Personalkosten zu senken, war die Belegschaft vor einiger Zeit um fast ein Drittel verkürzt worden, wobei es vor allem Programmierer getroffen hatte, die einerseits nach der herrschenden Arbeitsteilung wenig Kundenkontakt hatten, andererseits jedoch die in der damaligen IT üblichen hohen Gehälter erhielten. Um die aus diesem Abgang fehlende Arbeitskraft zu kompensieren, wurden junge Leute eingestellt, die nach ihrer Ausbildung aufgrund der Wirtschaftslage wenig Ansprüche stellten und darüber hinaus noch aufgrund fehlender Erfahrung bereit waren, sich nach den Wünschen der Geschäftsleitung prägen zu lassen.

Für die einfachen Tätigkeiten aller Art rund um die Software-Erstellung (Datensicherung, Datenträgererstellung, Listenführungen) war jedoch auch dieser Personenkreis zu kostspielig, sodass kostengünstige Frauen aus dem fachfremden unteren Verwaltungsbereich von Banken oder Behörden eingestellt wurden, die sich die notwendigen Betriebskenntnisse über „Learning by doing“ erwerben mussten. Ihr Ansehen war deshalb auch nicht sehr hoch, ersichtlich besonders daran, dass die Frau der Geschäftsleitung, die wie im unteren Mittelstand recht üblich die Verwaltung leitete, noch großmütig die Bezahlung von Überstunden aufgrund des geringen Grundgehaltes duldete, obwohl sie sonst Zuwendungen an die Mitarbeiter generell als zu großzügig empfand.

Zu den Tätigkeiten dieser so genannten „Operator“-Abteilung wurde auch die Dokumentation der Software gezählt, da diese einerseits von Kunden zumeist nicht bezahlt wird, sondern als selbstverständlicher Bestandteil des Produkts angesehen wird, andererseits nicht von den Programmierern selbst beschrieben werden sollte, da deren technische Sichtweise selten für diese Aufgabenstellung geeignet ist. Eine Zentralisierung von Dokumentation hat darüber hinaus den unschätzbaren Vorteil, dass auch die Texte einfacher standardisiert werden können in Terminologie und Präsentation.

Ähnliche Verhältnisse wie bei der Dokumentation gelten auch für Qualitätssicherung (QS): auch QS wird von Kunden als selbstverständlicher Bestandteil des bezahlten Produkts betrachtet und auch QS sollte von anderen Personen als den Programmierern durchgeführt werden, da deren aufgabenspezifischer Umgang mit dem Programm nicht immer mit der „verbraucherspezifischen“ Art der Kunden übereinstimmt.

Wie Dokumentation stellt QS somit für viele Softwarehäuser auch nur ein Kostenträger ohne Gegenpart auf der Einnahmenseite dar. Deshalb war es nicht verwunderlich, dass die Operator-Abteilung in diesem Praxisbeispiel neben den Verwaltungstätigkeiten diese beiden ungeliebten Aufgabenbereiche zu übernehmen hatte.

Die durch eine eigenständige Abteilung für Qualitätssicherung erreichte Trennung von Programmierung und Test wurde freilich konterkariert durch die fehlende Kompetenz in Informationstechnologie und die untergeordnete hierarchische Position der „Damen“, wie sie gerne von der Geschäftsleitung genannt wurde. Ihre Erfolge reduzierten sich deshalb häufig auf die Beseitigung eher „untergeordneter“ Fehler wie fehlende Unterstreichungen oder Falschfarben, denn bei allen darüber hinaus gehenden Resultaten mussten sie sich auf das Urteil der Programmierer verlassen.

Und sie mussten wie alle anderen der betriebswirtschaftlichen Prämisse folgen und sich auf das Wesentliche beschränken, wobei Fehler, die nicht von Kunden bemängelten wurden, kaum als wesentlich galten. Dies hatte die interessante Folge, dass die Qualitätssicherung tatsächlich vor der Aufgabe stand, fehlerhafte Programme auf die Fehlerfreiheit „neu eingefügter“ Stellen zu prüfen, ohne dass „altes“ Fehlverhalten beanstandet werden durfte – mit der fast natürlichen Konsequenz, dass die Programmierer ihre Beanstandungen in solchen Fällen gerne mit der Begründung niederschmetterten, dass die eigentliche Grund des Fehlverhaltens Uraltfehler und nicht durch ihre aktuelle Programmierung verursacht seien.

11) Generationenkonflikt

Betriebswirtschaftliche Prämisse / Qualitätssicherung

Existenz eines Pflichtenheftes zur Vereinheitlichung der Programmierung, Existenz von Musterprogrammen

Die verwendete Programmiersprache (RPG) bietet keine Hilfen, Programmstrukturen zu optimieren. Eine Konsistenz der verwendeten Musterprogramme wird deshalb nicht von der Entwicklungsumgebung unterstützt, sodass bei einer Weiterentwicklung keine automatische Anpassung der bisherigen Verwendungen erfolgt. Da diese Musterprogramme durch manuelles Kopieren und Ergänzen in ihr individuelles Endergebnis überführt werden, liegen letztendlich bei solcher Programmierweise Objekte vor, die oft wenig Ähnlichkeit mit den aktuellen Musterprogrammen aufweisen, da diese im Lauf der Zeit verschiedene Versionen durchlaufen. Auch hier wurde der positive Ansatz durch die Begründung der Betriebswirtschaftlichkeit vereitelt, da eine Konsistenthaltung der Software zur Bewahrung der Einheitlichkeit der Programmierung in keinem Fall als betriebswirtschaftlich gerechtfertigt von der Geschäftsleitung akzeptiert wurde. („Flickenteppich-Syndrom“ hinsichtlich diverser Versionsstände derselben Basis).

12) Stiefkind „Datenstruktur“

Betriebswirtschaftliche Prämisse / Zukunftstauglichkeit / Wiederverwendbarkeit

einfache Datenbank-Architektur

Die verwendete Betriebssystem-Umgebung enthielt eine komfortable Datenbank-Organisation, die nicht nur eine einfache Verwaltung von Erweiterungen oder Reorganisationen einer Datei anbot, sondern auch die strukturelle Ergänzung durch ein sicheres und flexibles Kopierverfahren für Daten unterstützte. Felder zu ändern oder hinzuzufügen war somit keine Affäre.

Bequeme Programmierumgebungen haben jedoch häufig die Folge unüberdachter Programmierergebnisse, da die korrekten Ergebnisse genügend Erfolgserlebnisse sichern, um eine weitere Optimierung zu verhindern. Bei der Bearbeitung von Dateien äußert sich dies zumeist darin, dass sie als Nebenprodukt der Programmierung aufgefasst werden, nicht jedoch als eigenständiges Problemgebiet, das selbst genauer Analyse und Konzeption bedarf.

Doch noch ein weiterer Punkt wirkte sich auf die Konzeption der Datenstrukturen in diesem Praxisbeispiel aus: Obwohl die Software erst knapp 10 Jahre alt war, stammte das Konzept aus der Zeit der Programmiersprache (RPG) und war somit sehr viel archaischer.

Dateien in älteren Software-Produkten weisen freilich oft eine hohe Willkürlichkeit in Feldstruktur und Gruppierung auf, da sie nicht aufgrund eines objektorientierten Ansatzes geplant wurden, sondern als nichts weiter als ein Sammelsurium von Feldern angesehen wurden, das bestimmte Programme für ihre Verarbeitung benötigten. Objektorientierung als eine erfahrungsgestützte Anwendung des Prinzips „Information“ wirkte dieser früheren Einstellung entgegen und förderte durch eine problemorientierte Dateistruktur auch die Wiederverwendung der darin gespeicherten Daten in Data-Warehouses oder Business-Intelligence-Tools.

Zwar wiesen auch nicht-objektorientierte Softwareprodukte oft wohlstrukturierte Dateien auf, doch dies beruhte in der Regel auf der umfassenden Erfahrung der Entwickler sowie einer Firmenphilosophie, die auf Qualität achtete.

Beides lag im vorliegenden Praxisbeispiel nicht vor (siehe Punkt 1, Flickenteppich und Punkt 18, Legalität). Ganz im Gegenteil wurde die Beschäftigung mit Dateistrukturen als nicht gerechtfertigter Aufwand gesehen, weil auch hier Feldstrukturen als reines Hilfsmittel der Programmierung betrachtet wurden.

Die Philosophie der Geschäftsleitung, keine „Rucksackdateien“ zu verwenden, da diese eigenständige Verarbeitungen erfordern würden, führte vielmehr dazu, dass an bestehende Dateien bei Bedarf neue Felder hinzugefügt wurde, die man um einige „beliebige“ Felder ergänzte für späteren Bedarf. Deshalb richteten sich deren Namen nach dem Typus und der Länge des Feldes wie Alpa101, Alpha201, Num101, Dat01, Dat02, nicht jedoch nach ihrem Inhalt. Weder die Grundregel der Datenbankkonstruktion, Datensätze zu möglichst selbständigen Informationseinheiten zu machen (4fF-Methode), um sie in späteren Auswertungen nutzen zu können, noch der Ratschlag der Objektorientierung, sprechende Feldnamen zu verwenden, um die Lesbarkeit der Programme zu erhöhen, waren von Bedeutung.

Was zählte, war die Geschäftsleitung, nicht die Trennung von Daten- und Programmschicht, nicht die Wiederverwendbarkeit, nicht die Öffnung für zukünftige Funktionen, erst recht nicht die Effizienz der Programmpflege.

13) Spurensuche

Arbeitsorganisation / Effizienz / Dokumentation

Handhabung von Software-Versionen über Sperrung der bearbeiteten Sourcen und Beschränkung der Berechtigung der Programmierer auf ihre eigenen Testumgebungen, Dokumentation von Software-Bearbeitung

Da die Software nicht sehr umfangreich war, genügte der Standard keinem Kunden. Modifizierung war deshalb kein Luxus, sondern ein Erfordernis, das überwiegend allen übrigen Kunden als Standarderweiterung zur Verfügung gestellt wurde. Deshalb stand die Standardversion immer im Vordergrund, während Kundenversionen die Ausnahme waren, sodass es als ausreichend angesehen wurde, die verbale Dokumentierung der Versionierung der Software nur über Excel-Sheets in Kombination mit den Word-Dokumenten der Kundenordner zu handhaben. Die Gewährleistung der Einheitlichkeit des Standardcodes wurde durch Testumgebungen gesichert, in denen die Programmierer arbeiteten, während die Standardumgebung keine Änderungen erlaubte. Der Test durch die Qualitätssicherung erfolgte freilich erst nach Rückübertragung der veränderten Source in die Standardumgebung, wobei eine Kommentierung der geänderten Statements in der Source nicht üblich war. Dieser Aufwand galt als zu zeitaufwändig, obwohl bei dem Rücktransfer in die Standardumgebung genügend Zeit zur Verfügung stand, um die Umwandlungen zwar programmunterstützt durchzuführen, ihre Spezifikationen jedoch einzelfallspezifisch anzufordern, weshalb sie jedes Mal Eingriffe der Programmierer erforderten. Und auch die Übertragung der erstellten Objekte in die Standardumgebung musste manuell erfolgen.

Außerdem, so wurde zu Recht begründet, würden die genauen Änderungsdaten die Source zu unleserlich machen. Eine Verfolgung der einzelnen Änderungsschritte in der Source wurde denn auch nicht als nötig erachtet, weil die gesamte Modifizierungsaktion über die verbale Kommentierung der chronologischen Änderungsdaten der Programmsourcen ersichtlich war, die von den Versionsprogrammen zur Verfügung gestellt wurden. Doch da auch diese Kommentierung Zeit kostete, wurde sie in der Regeln nur stichwortweise ausgeführt. Die Dokumentierung des gesamten Änderungsvorgangs litt somit unter diversen Medienbrüchen und wies fehlerhafte Redundanzen auf. Auch eine bequeme Suche wurde verhindert. Letztendlich war eine verbindliche Korrelation des gesamten Projektverlaufs ausgehend von den umfangreichen Word-Dokumenten der Kundenordner über die Datenhaltung der Source-Versionsprogramme bis hin zu den Excel-Sheets der Qualitätssicherung nur über die Zeit der Mitarbeiter zu gewährleisten, doch wie im Falle „gewinnneutraler Ineffizienz“ (siehe Punkt 17) wurde dies häufig in Überstunden erledigt, die gelegentlich sogar nach dem Stechen der Uhr und somit nicht nur ohne Bezahlung, sondern gar ohne Nachweis abgeleistet wurden.

14) Zentralismus

Führungsstil

Existenz eines Organisationshandbuches, das Selbstverantwortung der Mitarbeiter und Respekt seitens der Führung verlangt, kollegiales Verhalten der Führung

Der Zwiespalt der Mitarbeiter zwischen den Dauerpflichten zur Produktverbesserung und der unbedingten betriebswirtschaftlichen Prämisse, sich auf das Wesentliche zu beschränken, führte regelmäßig zu Differenzen hinsichtlich der Interpretation dieses Konflikts mit der genauso regelmäßigen Konsequenz, dass Klärungsbedarf zwischen Führung und Mitarbeitern bestand. Dies erweckte einerseits bei der Führung den Eindruck von völliger Unselbstständigkeit der Mitarbeiter, was bei jeder Gelegenheit und gegenüber vielfältigen Gesprächspartner beklagt wurde, und andererseits eine Art von Lethargie derselben, die nicht mehr wagten, Probleme von Bedeutung ohne den Segen der Geschäftsleitung zu lösen, zumal Kritik heftige Reaktionen auslöste.

15) Allverwendbarkeit

Führungsstil / Arbeitsorganisation

kurze Befehlsketten, flexible Aufgabenverteilung

Gerade der untere Mittelstand mit seiner überschaubaren Belegschaft hat den Vorteil, auf effizienzfressende Hierarchien verzichten zu können. Die andere Seite der Medaille ist jedoch, dass die Mitarbeiter zumeist in vielen Aufgabengebieten bewandert sein müssen und somit kaum in einem zum echten Experten werden können. Das Problem wird üblicherweise durch Software-Unterstützung gelöst oder auch nur durch eine Art von Bibliothek, in der notwendige Informationen für diejenigen gesammelt vorliegen, die eine bestimmte Aufgabe nicht täglich tun.

Beides war im vorliegenden Praxisbeispiel als nicht erforderlich angesehen worden, sodass den Bedürfnissen der verwaltenden Geschäftsleitung und ihrer Frauen gemäß die Organisation der Arbeiten durchgeführt wurde. Waren diese Personen nicht anwesend, mussten untergeordnete Kräfte einspringen, die nicht nur die Art der Arbeit zu kennen hatten, sondern auch deren Differenzierung. Wer nicht über einfache Gedächtnisleistung das passende Formular auf dem passenden Computer im passenden Zimmer auffinden konnte, war nicht imstande, die ihm ganz selbstverständlich auferlegten Pflichten zu erfüllen und hatte deshalb mit den üblichen öffentlichen Sanktionen zu rechnen.

Und diese konnten sehr persönlich ausfallen in dem kleinen Haus, in dem zumeist alle Türen offen standen und jeder jeden genau kannte. Die persönliche Atmosphäre wurde denn auch methodisch eingesetzt, einerseits für das Werben der Geschäftsführung für Verständnis, dass sie nicht die allen übrigen auferlegten Pflichten erledigen könne, weil sie zuviel zu tun hätte, und andererseits für erzieherische Maßnahmen in familiärer Form, um Wohlverhalten der einzelnen Mitarbeiter zu erreichen. Dazu gehörten sowohl die gezielte Ausnutzung von Gruppendruck als auch die moralische Ansprache, wobei das Recht auf Kritik immer auf der Seite der Geschäftsführung lag. Dies wurde mit dem fehlenden Überblick der Mitarbeiter begründet, was aufgrund fehlender Ausbildung oder Erfahrung teilweise richtig war, jedoch auch auf der in dem vorliegenden Praxisbeispiel üblichen Arbeitsteilung beruhte, unbeaufsichtigte Kundenkontakte für normale Mitarbeiter auf das geringste Maß zu reduzieren. Damit wurde den Mitarbeitern schließlich nicht nur die Möglichkeit zur freien Entscheidung über ihre Tätigkeit genommen, sondern auch die Gelegenheit, Erfahrung zu erwerben, was umgekehrt der Geschäftsleitung, die die resultierende Entschlusslosigkeit ihrer Mitarbeiter sehr offen beklagte, wieder die Bestätigung für die bisherige Verfahrensweise lieferte.

Dass dies zu Überlastung der wenigen Projektleiter hinsichtlich Kundenkontakten führte, war somit fast zwangsläufig, zumal die Arbeitsorganisation der Geschäftsführung sich in der Arbeitsorganisation der Firma niederschlug. Doch während die resultierenden Überstunden der Geschäftsleitung sich über Gewinne egalisieren konnten, wurden die sich aus der Übertragung von Kleinarbeiten und den ständig wachsenden Ansprüchen der Geschäftsführung ergebenden Überstunden der Mitarbeiter in der Regel nicht bezahlt und dementsprechend nicht wahrgenommen. Diese fehlende Wahrnehmung führte denn auch nicht nur zu Verständnislosigkeit gegenüber der Arbeitsbelastung der einzelnen Untergebenen seitens der Geschäftsleitung, sondern darüber hinaus zu einer ungebremsten Anspruchsmentalität gegenüber den Mitarbeitern.

Dass darüber hinaus Kritik an der Chefetage mit harschen Gegenmaßnahmen geahndet wurde, förderte zwar die Selbsteinschätzung der Geschäftsführung, jedoch nicht die Kreativität und Leistungsfähigkeit der Firma, sodass die alte Weisheit der IT ständig bestätigt wurde:

„Vorher ein bisschen nachdenken, erspart meist viel Zeit und Ärger. Wenn das Kind in den Brunnen gefallen ist, ist es zu spät.“

16) Bananensoftware

Arbeitsorganisation / Effizienz

Schnelle Release-Wechsel

Der geringe Leistungsumfang der Software machte es erforderlich, den bestehenden Kunden so rasch als möglich die realisierten Erweiterungen zur Verfügung zu stellen, unabhängig davon, wie allgemein verwendbar diese Funktionalitäten waren (siehe Punkt 1, Flickenteppich-Syndrom). Dies führte zu einem schnellen Release-Wechsel-Rhythmus mit dem an sich positiven Effekt des Angebots erweiterter Funktionalität. Doch da die Qualitätssicherung in der Standardumgebung testete, um die Bedingungen des Kunden nachzuvollziehen, kam es häufig zu Problemen mit mehreren Kunden, die nicht ausgetestete Standardsoftware erhielten (siehe Punkt 8, Qualitätslimits, und Punkt 10, Qualifikation), was wiederum zu den üblichen, recht öffentlich gehaltenen Sanktionen für die einzelnen Mitarbeiter führen konnte.

Eine Testsoftware wurde jedoch aus Kostengründen nicht in Betracht gezogen. Die Geschwindigkeit der Release-Wechsel führte somit zusammen mit der strengen Auflage der betriebswirtschaftlichen Prämisse sowohl für Qualitätssicherung als auch für die Programmierung und der praktizierten Software-Versionierung zu einem Standardprodukt, das selbst in der Demonstrationsumgebung nur in den gängigen Funktionalitäten aufrufbar war und zu gravierenden Fehlern neigte bei umfangreicheren Änderungen. Dies ist freilich so selbstverständlich in der Branche, dass es dafür sogar einen Spitznamen gibt: „Bananensoftware, denn sie reift beim Kunden“.

17) Gewinnneutrale Ineffizienz

Betriebswirtschaftliche Prämisse / Führungsstil / Arbeitsorganisation / Effizienz

Dokumentation von Projektaufwänden (Tagesaufstellung)

Aufgrund des Kostenfaktors wurden Tagesaufstellungen über die geleisteten Tätigkeiten und Projekte mithilfe eines selbst erstellten Programmkomplexes bearbeitet, der nach einem ersten lauffähigen Stadium nicht mehr gepflegt wurde. Die Umständlichkeiten und Fehler mussten durch die Mitarbeiter aufgefangen werden, die gezwungen waren, parallele Excel-Sheets zu führen, um Übersicht und Konsistenz zu sichern, weil bezahlte Arbeitszeit ein heikles Thema war, bei dem mit wenig subtilen Mitteln um jede Minute gekämpft wurde. So wurden mit der in dem kleinen Haus üblichen Öffentlichkeit Überschreitungen der Tagesaufstellung durch die Stechuhr-Angaben mit einer solchen öffentlichen Inbrunst geahndet, dass die Mitarbeiter mit der üblichen Fügsamkeit die an sie gestellten Anforderungen zur vollen Zufriedenheit der Geschäftsführung erledigten. Diese Informationen wurden wie andernorts auch sowohl für die Rechnungsschreibung als auch für interne Auswertungen benötigte, waren jedoch trotz der Umständlichkeit und ständigen Neuauflage von Anforderungen erstaunlich wenig differenziert strukturiert und aufgearbeitet. So mündete diese aufwändige Pflege der Tagesberichte zwar in kaum aussagefähige Daten, dafür zumeist in Überstunden. Da diese freilich überwiegend nicht bezahlt wurden, bestand kein betriebswirtschaftlicher Bedarf zur Modernisierung der Programme.

18) Legalität

Betriebswirtschaftliche Prämisse / Führungsstil / Arbeitsorganisation

Flexibilität

In der deutschen Software-Industrie sind juristische Kenntnisse oft nicht sehr weit verbreitet. Selbst bei Finanzbuchhaltungs-Software kennt sich keineswegs jeder in den grundlegenden deutschen Gesetzesbüchern aus, die eine der fundamentalen Säulen von Buchhaltungssystemen bilden. Das vorliegende Praxisbeispiel stellte keine Ausnahme dar. Das geltende Recht wurde dem Firmenmotto gemäß über Kundenwunsch definiert, was umgekehrt hieß, dass ohne erklärte Kundenforderung kein Wissen über die rechtlichen Grundlagen vorhanden war.

1) Flickenteppich-Syndrom

„Bill Gates wurde zum reichsten Mann der Welt nicht dadurch, dass er besser war als seine Konkurrenten, sondern dadurch, dass er schneller war als sie. Hätte er seine Produkte jedes Mal austesten lassen, hätte er das nie geschafft.“

2) Kostenbeschränktes Denken

„Man kann wegen eines Angebots doch nicht die ganze Software durchforsten. Wissen Sie, wie viele Sourcen das sind?“

„Das brauchen die Kunden nicht.“

„Standardfehler?
- Das kannst du in deiner Freizeit machen.
- Das kannst du im Sommerloch immer noch erledigen, wenn es keine Arbeit mehr gibt.“

„Andere Anwendungsfälle?
- Das wird nicht bezahlt.
- Das kostet jetzt aber zuviel Zeit.
- Da kann ich jetzt wirklich nicht noch drüber nachdenken.“

3) Programmbaustein „Mensch“

„Kunden müssen sich eben dran halten, was man ihnen sagt.“

„Das muss man eben wissen.“

„Das war schon immer so.“

„Wenn es sich um xyz handelt und in der Tabelle abc der Wert 123 vorliegt, dann steht doch immer Schwachsinn in diesem Feld drin! Also das weiß man aber!“

„Frag mich eben, wenn du an meinen Dateien herumspielst.“

„Wie willst du dich sonst als Programmierer unentbehrlich machen?“

7) Fehlertoleranz

„Software ohne Fehler gibt es nicht.“

„Standardfehler? Hat die ein Kunde schon bemerkt?“

„Ach dieses Programm? Das ist eine Katastrophe!“

„Das wissen wir doch längst, aber das ist ein Uraltprogramm.“

„Das haben unsere Kunden noch nie wirklich verwendet.“

„Jede Software hat Fehler. Schaut euch doch Bill Gates an! Nicht die beste Software gewinnt, sondern die schnellste.“

„Der Fehler ist nicht neu. Das sieht nur so aus.“

„Wer soll’s denn machen? Der das programmiert hat, ist längst nicht mehr in der Firma.“

9) Dokumentation

„Dokumentation? Die meisten Programme haben doch schon Bedienerhilfe.“

„Die Kunden verstehen das sowieso nicht.“

„Die Kunden sollen anrufen, wenn sie etwas wollen.“

„Dafür gibt es Schulungen.“

10) Qualifikation

„Den Kunden haben wir im Griff, der macht keinen Ärger“.

„Das ist kein Fehler, hat mir der Programmierer gesagt.“

„Der Programmierer hat gesagt, der Kunde will es genauso haben. Und wenn er es will, kriegt er es auch, ob das nun richtig oder falsch ist. Ich hab’ das nicht zu entscheiden.“

„Das Alte will ich nicht sehen - ich will nur sehen, was Sie selbst gemacht haben.“ (QM an Programmierer)

13) Spurensuche

„Falls es dem QM nicht ausreicht, wird nachdokumentiert“.

14) Zentralismus

„Wir brauchen hier jemanden mit Entscheidungsbefugnis“ (Problem blieb ungelöst)

„Dieses ganze Für und Wider ufert jetzt aus, wir haben doch etwas Besseres zu tun.“ (Problem blieb ungelöst)

„Die Regeln mache immer noch ich.“ (Geschäftsführung als Reaktion auf eine kritische Stellungnahme).

1) Flickenteppich-Syndrom:
Betriebswirtschaftliche Prämisse

Schein und Sein:

Die Betriebswirtschaft ist naturgemäß die Basis einer betriebswirtschaftlichen Software, doch schien der Überblick über angrenzende Fachgebiete und Konkurrenzprodukte im vorliegenden Praxisbeispiel nicht sehr ausgeprägt zu sein. So wurden im Hauptmenü die Rechnungsschreibung mit offenen Posten und der Möglichkeit, Mahnungen zu erstellen, bereits unter „Buchhaltung“ eingestuft und der Fertigungsauftrag, dessen Umfang sich auf ein einziges Window mit einigen dahinter stehenden Tabellen und Dateien beschränkte, galt schon als Fertigung.

Zwar ist es in der betriebswirtschaftlichen Software recht verbreitet, ein Fremdprodukt für die Finanzbuchhaltung zu verwenden, es ist in der Regel jedoch das Bestreben vorhanden, die beiden Produkte weitgehend ineinander zu verzahnen. Da dies augenscheinlich bisher noch nicht von Kunden angefordert worden war, genauso wenig wie eine etwas üppigere Fertigungsverwaltung, blieb es also bei den großen Bezeichnungen für einfache Funktionen.

2) Kostenbeschränktes Denken:
günstige Angebote

Neuinstallation:

Ein Kunde, der die gesamte Software kauft, ist in einem kleinen Software-Haus eine seltene Sache, die nur alle ein bis zwei Jahre auftritt, dann aber aufgrund der vorherrschenden Struktur der Software monatelange Modifikationen und noch längerfristige Betreuungsprojekte verspricht. Genau deshalb ist natürlich das Bestreben groß, solche Kunden zu gewinnen und dies geschieht sehr oft durch großzügige Angebote. Im vorliegenden Beispielfall erstellte die Geschäftsführung solche Angebote selbst aufgrund ihrer langjährigen Erfahrung mit der Software, unabhängig davon, wie viele längst verschwundene Mitarbeiter daran gearbeitet hatten. Und da eine genaue Analyse zu aufwändig war, wurde diese Schätzung intuitiv erstellt mit der Folge, dass die letzte Installation ihr Budget bereits nach weniger als der Hälfte aller installierten Module verschlungen hatte. Der Kunde drohte bereits mit dem Rechtsanwalt und die Geschäftsführung, deren Fehler dieser eklatante Missgriff war, reagierte bereits mit Aggression gegenüber den Untergebenen, die nicht fähig waren, ihre professionellen Vorgaben zu erfüllen. Der weitere Verlauf dieses Projekts reichte über den Beobachtungszeitraum hinaus, es besteht jedoch die Vermutung, dass die Fehlleistung der Führung durch unbezahlte Überstunden der Mitarbeiter wenigstens teilweise aufgefangen werden wird, sodass das Projekt für die Bilanz gerettet werden kann.

2) Kostenbeschränktes Denken:
schnelle Lösungen

Fertigungsauftrag:

Im Fertigungsauftrag funktionierten sogar in der Demo-Umgebung, die für Vorführungen gegenüber Interessenten genutzt wurde, wesentliche Suchfunktionalitäten nicht. Im Fertigungsauftrag ist das Fehler geeigneter Suchmöglichkeiten besonders schmerzhaft für Anwender, da ein Fertigungsauftrag ein komplexes Objekt ist, dessen Komponenten selbst geübte Sachbearbeiter nicht immer aus dem Kopf aufsagen können.

2) Kostenbeschränktes Denken:
schnelle Lösungen

Layout-Änderungen:

Eine generelle Änderung im Layout, die die besondere Natur von Feldern berücksichtigte, die Eingaben zwingend erforderten, führte zu permanenten Fehlermeldungen sogar in der Demo-Umgebung.

2) Kostenbeschränktes Denken:
schnelle Lösungen

Sperrung:

Ein Auswerteprogramm, das offene Positionen als Druckergebnis lieferte, sollte erstmalig programmiert werden. Als Kopiervorlage diente ein anderes Programm, dessen Konzept und Verarbeitung ähnlich genug war, um die von der Auftragsschätzung vorgegebene Projektdauer einzuhalten. Die Konstruktion nutzte dabei zwei temporäre Dateien: eine zur Bestimmung und Berechnung der Werte und eine Datei, in der diese Werte für die Ausgabe aufbereitet wurden. Die erste Datei wurde gesperrt, um Konkurrenzproblemen mit weiteren Benutzern zuvorzukommen, die zweite Datei jedoch blieb unberücksichtigt. Und da die Vorlage diese zweite Datei nicht sperrte, durfte auch bei dem neuen Programm nichts gesperrt werden, denn, so folgerten die gehorsamen Mitarbeiter, dies sei bisher nicht nötig gewesen und wäre damit schlicht zuviel Aufwand, sprich: zu teuer.

Der Auftrag seitens „des Chefs“ hieß nurl, die Kopiervorlage zu verwenden und so rasch als möglich umzuschreiben: Von zusätzlichen Features war nicht die Rede gewesen.

Das Problem dabei war, dass die nicht gesperrte Datei somit von anderen Stellen gesperrt werden konnte wie beispielsweise von einem SQL-Zugriff. Also führte die Befolgung dieses Befehls zu ständigem Ärger in der Testphase und oft längerwierigen Diskussionen, ohne dass die einfache Dateisperrung durchgeführt wurde.

Dieses Programm freilich lag der Geschäftsführung sehr am Herzen, da sie es alleine schon deshalb ausliefern musste, weil es längst „zum Stand der Technik“ gehörte und folglich längst schon hätte vorhanden sein müssen. Als es deshalb dem Kunden vorgeführt werden sollte, stieg der Adrenalinspiegel gewaltig and und setzte damit die übliche Panik im Haus in Gang, wenn jemand, vor allem die Geschäftsleitung, beim Kunden war (siehe auch Beispiel „Angst“). Denn sie hasste wie jedermann Peinlichkeiten.

Diese Panik nun hatte die natürliche Folge, dass alle Beteiligten im Haus in Habacht-Stellung standen, um Probleme zu bereinigen und da die einfachste Bereinigung das Ersparen ist, wurden die entsprechenden Aktivitäten über Leitung verfolgt, nicht zuletzt durch SQL-Zugriffe. Genau dies aber führte zur Sperrung der ungesperrten Datei und, ganz wie bei der Kopiervorlage, zum Programmabsturz. Und genau dies führte zu den üblichen Anschuldigungen und am Ende zu der einfachen, mit Sicherheitsabfragen nur wenige Statements langen Sperrung der Datei.

Fazit: 5 Minuten freies Denken, 2 Minuten „unnützes Programmieren“ hätten den gesamten Ärger, die vielen Diskussionen, die Peinlichkeit vor Ort und die emotionalen Reaktionen des gedemütigten Chefs verhindert. (siehe auch Beispiel „Layout“)

2) Kostenbeschränktes Denken:
schnelle Lösungen

Layout:

Es ging um ein Excel-Layout als Ausdruck des Auswertungsprogramms über die Positionen aus Beispiel „Sperrung“, das nicht „schön genug“ war. Mit mehreren Mitarbeitern war es diskutiert worden, die jedoch der obersten Doktrin des Hauses gehorchend zeitsparend mit der Fragestellung umgingen und sie rasch als „unlösbar“ verwarfen.

Diesmal stimmt „der Chef“ jedoch nicht zu, denn er braucht das neue Programm beim Kunden zu dringend, und Layout ist nun einmal eine sichtbare Angelegenheit, auf die Kunden oft mehr Wert als auf Funktionalität legen. Also fragte er die bei einer späteren Diskussion anwesende Mitarbeitern, ob sie glaube, dieses Ergebnis würde von der BASF® akzeptiert und fuhr daraufhin fort, dass ihr dieses Layout wohl um die Ohren geschlagen würde.

Den Punkt, dass das neue Programm eine in den meisten ERP-Lösungen selbstverständliche Funktionalität zu erfüllen hatte, dass der Kunde somit für etwas bezahlte, was er eigentlich hätte erwarten können, dass das ganze Software-Produkt solchermaßen aus den Einzelbedürfnissen unterschiedlichster Kunden aus unterschiedlichen Branchen und unterschiedlichen Zeiten zusammengesetzt war, dass die meisten Programme mit versteckten Fehlern aufwarteten, die von fehlender Dokumentation über Programmabstürze bis zu inkonsistenten Daten führen konnte, übersah „der Chef“ dabei geflissentlich, genauso wie die Architektur des von ihm konzipierten Programms, das Auswertungen hardcoded wie in alten Zeiten realisierte, nicht jedoch über ein modernes Reporting-Tool.

Oder mit anderen Worten: die BASF hätte sein Produkt nie in Betracht gezogen, die verstörte Mitarbeiterin wäre somit niemals in diese Zwangslage gekommen. Ihre Loyalität, ihr Gehorsam gegenüber seinem strikten Gebot, schnell zu arbeiten und sich nur auf das Wesentliche zu konzentrieren, hätte sie also niemals in diese peinliche Lage gebracht.

Der zweite hochinteressante Punkt dabei war, dass die Mitarbeitern nach der Maßregelung plötzlich doch einen Ausweg wusste.

Schnelligkeit und Selbstbeschränkung hatten hier somit zwar zu kurzen Diskussionen geführt, diese jedoch verteilt über mehrere Mitarbeiter bis hin zum abschließenden Bericht an den projektleitenden Geschäftsführer, den sie liebevoll-respektvoll „Gott“ nannten und der dann in diesem emotional schmerzhaften Tadel für die Mitarbeiterin seinen unangenehmen Höhepunkt fand - nur um ein Ergebnis zu liefern, das sie mit ein wenig mehr Zeit zu Beginn der Problemlösungssuche auch hätte finden können.

Fazit: Offensichtlich brauchte sie tatsächlich die „Erlaubnis zum freien Denken“ durch den Chef persönlich. (siehe auch Beispiel „Sperrung“)

2) Kostenbeschränktes Denken:
schnelle Lösungen

Anzeigemodus:

Wie in vielen Anwendungen wurden dieselben Fensterobjekte verwendet für Anzeige und Verwaltung der Daten. In diesem Fall jedoch reagierte die Anzeige regelmäßig noch, bot bei normierten Feldwerten die Tabellenwerte zur Auswahl an und nahm gelegentlich sogar veränderte Werte entgegen. Diese Werte wurden zwar nicht in die Datensätze übernommen, jedoch in manchen Fällen beim Verlassen des Fensters mit dem Hinweis beantwortet, dass die durchgeführten Änderungen nicht gespeichert würden und ob man dies tatsächlich wünsche. Eine Speicherung wurde dann natürlich nicht geduldet.

Doch auch auf niedrigerer Ebene wurde diese Form von Arbeitsersparnis fortgeführt. Im Bemühen um Standardisierung wurden Felder, die irgendwann und irgendwo einmal editierbar waren, immer als editierbar behandelt. Dass sie in manchen Fällen nur zur Anzeige diente, wurde durch einfaches Sperren der Felder berücksichtigt, was jedoch weder den Anschein von Editierbarkeit beeinflusste noch die Eingabe von Werten behinderte. Nur die Übernahme der Werte war damit vereitelt worden.

Da ein solches Verhalten von erfahrenen Anwendern jedoch toleriert wird, schien eine Bereinigung überflüssig, bei GUI-Programmierern, deren Anwendungen häufig von ungeübten Benutzern verwendet werden, wird eine solche irreführende Layoutgestaltung indessen selten als „Standardisierung“ bezeichnet.

2) Kostenbeschränktes Denken:
schnelle Lösungen

Preisfindung:

Ein Musterbeispiel des „kostenbeschränkten Denkens“ zur schnellen Erledigung anfallender Projekte war die Modifikation einer Preisfindung.

Sie konnte einige Stammdaten-Konditionen bewältigen und auch manuelle Preisveränderungen akzeptieren bis auf eine vernachlässigbare Kleinigkeit: Die dahinter stehende Datei speicherte keine Währung. Aufgrund der komfortablen Datenbank, die verwendet wurde, gehörte es zu den Selbstverständlichkeiten des Lebens, dass Felder jederzeit ergänzt werden können, zu viel Aufhebens machte deshalb niemand um Felder. Dies hatte zur Folge, dass auf Feldstrukturen kein besonderes Augenmerk geworfen wurde und die Arbeit, die ein Feld erfordert an Pflege und Prüfung, nur an den Kosten gemessen wurde. Der Umfang der zu konservierenden Information, die in einem Datensatz fernab der Anwendung dauerhaft untergebracht wurde, war dagegen nicht nur kein Thema, dass ein Datensatz tatsächlich Information repräsentierte, war schlicht keine wesentliche Vorstellung.

Das Fehlen der Währung dieser Datei manueller Preisänderungen war schließlich zur Zeit ihrer Erstellung nicht erforderlich gewesen, da alle hinterlegten Preise in der Firmenwährung vorzuliegen hatten. Mit der Zeit verwendeten jedoch mehrere Kunden mehr als nur eine Währung, sodass das Problem der Rundungsdifferenzen aufkam. Gemäß der betriebswirtschaftlichen Prämisse wurden zur Behebung dieses Problems ausschließlich die Programme behandelt, bei denen diese Rundungsdifferenzen auffällig geworden waren. Dies geschah dadurch, dass diesen Programmen mitgeteilt wurde, welche der beiden Währungen vom Kunden als „führend“ betrachtet wurden, sodass diese als Basis der Umrechnungen fungieren konnte.

Dies geriet in Konflikt mit der fehlenden Währung in der Datei manueller Preisänderungen, jedoch erst, nachdem die veränderten Programme bereits beim Kunden waren. (siehe Punkt 12, Stiefkind „Datenstruktur“ und Punkt 16, ...denn sie reift beim Kunden)

Eine weitere interessante Eigenschaft der Preisfindung waren negative Preise in beliebiger Höhe. Auch hier war die Begründung „Benutzerfreundlichkeit“, da die Anwender jede Freiheit hätten, durch Rabatte den Endpreis zu erzeugen und sei er noch so tiefrot. Und obwohl Gutschriften im System verarbeitet werden konnte, wurde ein negativer Preis nicht in diesem Zusammenhang gesehen, zumal augenscheinlich noch kein Kunde sich beklagt hatte. Sie schienen Margenprüfungen wohl auf anderem Weg durchzuführen.

2) Kostenbeschränktes Denken:
schnelle Lösungen

Textkonserven:

Ein kleines Programm für Textkonserven, das allgemein genug ausgelegt worden war, um von beliebigen Kontexten verwendet zu werden, ging dieser völligen Wiederverwendbarkeit verlustig, als es für die Personendaten der Standardsoftware benutzt wurde. Dies hatte zwangsweise Wechselwirkungen zwischen den beiden Programmteilen zur Folge, doch der Zwang zur schnellen Erledigung führt wie des Öfteren dazu, die erstbeste Lösung zu implementieren. Diese äußerte sich darin, dass das zentrale Textkonservenprogramm Funktionalität ausführte, die eigentlich spezifisch für den neuen Kontext war: Das Programm hatte einen weiteren Text anzuzeigen, also ermittelte es diesen neuen Text, anstatt ihn wie zuvor nur über eine Platzhalterfunktion zu offerieren, deren Inhalt von dem rufenden Programm geliefert wurde. Im Falle von RPG hieß dies, eine Datei zu implementieren, die mit der eigentlichen Textkonserve nichts mehr zu tun hatte. Innerhalb der Standardsoftware war dies auch unschädlich, weil diese Datei ständig zur Verfügung stand. Eine mögliche Verwendung außerhalb des Standards, möglicherweise in einer mobilen, abgespeckten Umgebung, war damit jedoch sehr erschwert worden. Da freilich keine solche Standard-Ergänzung geplant war, fiel das Problem auch nicht auf.

Die „schnelle ökonomische“ Lösung jedoch hatte zur Folge, dass das Textprogramm nunmehr bedingt und das Blackbox-Prinzip gebrochen war. Jeder neue Kontext, der diese Textkonserven verwenden sollte, musste nun auch dieses Textprogramm anpassen.

Einige ersparte Minuten im ersten Fall hatten somit zur Folge, dass für den nächsten Kontext, der diese Textkonserve nutzen sollte, nicht nur die Integration der Blackbox „Textkonserve“ durchzuführen war, sondern darüber hinaus eine Klärung benötigt wurde, wo und warum die zugesagte Wiederverwendbarkeit nicht völlig erfüllt war. Zuletzt wurde Zeit für die Suche nach einer Lösung erzwungen, die die bereits implementierten Kontexte nicht störend beeinflusste.

Ein weiteres Problem dieser ökonomischen Form der Programmierung bestand darin, dass die fehlende Beschäftigung mit Zusammenhängen dazu führte, dass die zugehörigen Daten deaktiviert wurden, ohne die Textkonserve mit zu berücksichtigen. Da die Anzeige- und Verarbeitungsprogramme der Textkonserven nicht benutzt würden und da es sich außerdem nur um Texte handelte, schien eine Berücksichtigung dieses Falles jedoch nicht gerechtfertigt zu sein.

2) Kostenbeschränktes Denken:
schnelle Lösungen

Benutzerverwaltung:

Jede Anwendung, die mehrere Benutzer verwalten kann, kennt Benutzerprofile. Jedes Betriebssystem ebenso. Deshalb wird oft eine Verbindung zwischen beiden Benutzersystemen geschaffen, um den Anwendern mehrfache Anmeldungen zu ersparen. In modernen Umgebungen geschieht dies häufig über ein eigenes Software-Modul, das nicht viel anderes tut als einheitliche Benutzer in die diversen Hierarchien des Computers zu integrieren (Stichwort „Single Sign On“).

In älteren Anwendungen erfolgt dies zumeist durch einfaches Zuordnen zwischen beiden Systemen, da in der Regel die Menschen dazu neigen, ihre Benutzerprofile unter dem gleichen Namen anzulegen. Wie des Öfteren in kleineren Softwarehäusern geschah diese Kopplung über die Gehirne der Mitarbeiter. Das ersparte Programmierung, damit Konzeption, Implementierung und Test und den Kunden wurde es in den Schulungen beigebracht, für die zumeist noch Rechnungen erstellt werden konnten.

Die Kopplung über die Gehirne der Programmierer hat jedoch einen großen Nachteil: Sie ist weder mit technischen Mitteln zu verarbeiten noch zu prüfen. (siehe Punkt 3, Programmbaustein „Mensch“). So geschah es, dass der Vertrieb bei einem Neukunden, der Nummern statt Namen als Identitäten für Benutzer verwendete, mit dem Kopf nickte, der Neukunde daraufhin seine Benutzer in die Software einpflegte und diese dann Probleme bereitete. Was war geschehen? Die inhärente Kopplung von Anwendungs- und Betriebssystembenutzern hatte es ermöglicht, sich nicht darum kümmern zu müssen, welcher Typ von Benutzer gerade im Spiel war. So wurden Bestellungen beispielsweise mit dem Betriebssystembenutzer gesucht und mit dem Anwendungsbenutzer sortiert.

Rasch wurde deshalb die Betriebssystematik zum führenden System bestimmt, weil es als zuverlässiger galt und der Zugriff dazu einfach über die Betriebssystembefehle gestellt wurde. Berechtigungsprobleme wurden nicht diskutiert, weil es als Vorteil angesehen wurde, wenn ein Benutzer die Arbeit der anderen weitermachen konnte. Wie bei anderen bekannten Standardfehlern wurde jedoch nicht nach jedem einzelnen Vorkommen gesucht, sondern nur diejenigen Probleme beseitigt, die vom Kunden bemängelt worden waren oder diejenigen, die in einem aktuellen Projekt mit erledigt werden konnten. (siehe Punkt 7, Fehlertoleranz)

6) Catch 22:
Separierung von wieder verwendbaren Bausteinen

Zugriffsprogramm:

Wiederverwendbarkeit wurde hoch angesehen in den meisten kleinen Softwarehäusern. Auch die Software in diesem Praxisbeispiel zeigte deutliche Anzeichen des Versuchs, Wiederverwendbarkeit zu realisieren. So existierte ein allgemeines Zugriffs-Programm mit dem wieder verwendbar klingenden Kommentar, es sei zum Aufruf mit „mehreren Schlüsseln“ gedacht. Als Wrapper für ältere Programme mit unterschiedlichen Parametern war es prächtig geeignet, gleichartige Eingaben in moderneren Programmen zu empfangen, um sie dann auf die älteren Bedingungen umzustellen – als Blackbox, sodass die historisch bedingten Mängel der Uneinheitlichkeit der älteren Programme vor den Augen der modernen Programmierer verborgen bleiben könnten.

Der Zwang zur Schnelligkeit hatte diesen wohlgemeinten Ansatz freilich zunichte gemacht. Zwar konnten mehrere Objekt-Arten, sprich Dateien, damit für diverse Such- und Zugriffs-Verfahren angesprochen werden, jedoch musste bei der Verwendung des Wrappers nicht nur die Art des Objektes bestimmt werden, sondern auch die spezifischen Eingabebedürfnisse derselben befriedigt und die Ergebnisse je nach Objektart differenziert werden. Den Programmierern wurde also lediglich der Programmname für den Zugriff vereinheitlicht. Ob und wie Sachbearbeiter oder Disponenten gesucht wurden, mussten sie immer noch genau wissen und unterscheiden und zwar nicht nur nach Parameteranzahl und –inhalt, sondern sogar nach Formatierung und Feldlänge.

Das genügte wohl offensichtlich, um das Bedürfnis nach Wiederverwendbarkeit zu stillen und hatte dabei möglicherweise noch den günstigen Nebeneffekt, die Vorzüge der Wiederverwendbarkeit in Grenzen zu halten – als Argument gegenüber der Profit verheißenden betriebswirtschaftlichen Prämisse verlor Wiederverwendbarkeit an Boden und wurde nur mehr als eine abstrakte Zielsetzung angesehen, nicht als etwas, das sich im täglichen Leben immer und immer wieder bewährt. (siehe auch Beispiel „Prozesssteuerung“, „Statistik“)

6) Catch 22:
Separierung von wieder verwendbaren Bausteinen

Prozesssteuerung:

Ein ähnlich gelagerter Fall wie in Beispiel „Zugriffsprogramm“ war die Prozesssteuerung, die mit einer wirklich flexiblen API den Aufruf von Programmen steuerte. Doch wie im Falle des Beispiels „Zugriffsprogramm“ wurde auch hier der Ansatz zunichte gemacht durch die einzelfall-spezifische Parametrisierung. Das hatte wohl erlaubt, die Prozesssteuerung so einfach auszulegen (siehe Punkt 3, Programmbaustein Mensch), dass eine schnelle und funktionierende Lösung zustande kam: Jedes Programm wurde in der API hardcoded aufgerufen. Ohne Metadaten musste denn auch kein generalisierter Zugriffsmechanismus geplant und berücksichtigt werden.

Wie im Beispiel „Zugriffsprogramm“ wurde durch die Teil-Anonymisierung eine gewisse Wiederverwendbarkeit erreicht, die Tatsache freilich, dass in jedem Fall, in dem das API verwendet wurde, trotzdem der Einzelfall in fast all seinen spezifischen Einzelheiten zu berücksichtigen war, raubte dem Versuch jeden Anschein, eine „black box“ zu sein.

Dass guter Wille allein nicht ausreicht, mag die „standardisierte Parameterliste“ der API verdeutlichen. Sie war tatsächlich ellenlang, enthielt auch jeden (bisher) notwendigen Parameter, doch welche Parameter wie zu bestücken war, blieb eben doch Sache des Einzelfalls.

Eine regelbasierte, typkonforme Lösung, die über Metadaten steuerbar und damit ohne Programmierung beliebig erweiterbar wäre, hätte dagegen einen Weg finden müssen, sich ihre Parameter selbst zu bestimmen. Viele mächtigere ERP-Systeme verwenden in dem Fall Identifikatoren für die betroffenen Fälle, nicht einzelne Attribute, sodass die API sich über diese Identifikatoren die betreffenden Datensätze zusammensuchen kann und sich die notwendigen Werte somit selbst beschafft. Auch die Lösung, einen generalisierten Parameter zu übergeben, lässt noch eine Metadatensteuerung zu. Da auch hier der generalisierte Parameter immer noch einzelfallspezifisch mit Werten versorgt werden muss, ist die Verbindung der beiden Programmbausteine jedoch immer noch zu intensiv, weil jede Änderung des maßgeblichen API-Elementes noch im rufenden Baustein programmiert werden muss. Letzterer Fall ist damit noch nicht SOA-fähig. (siehe auch Beispiel „Statistik“)

6) Catch 22:
Separierung von wieder verwendbaren Bausteinen

Statistik:

Ein weiterer Fall demonstriert, dass im vorliegenden Beispielfall noch keine Kompetenz hinsichtlich echter Wiederverwendbarkeit aufgebaut worden war, denn wie in den Beispielen „Zugriffsprogramm“ und „Prozesssteuerung“ war die Statistik sehr wohl als vielfältige Sammlung recht gleichartiger Einzelfälle erkannt worden, zumal ERP-Systeme praktisch das gesamte Geschäftsleben einer Firma enthalten und ihre Daten wie kein zweiter Informationslieferant für Auswertungen geeignet sind, um den aktuellen „Zustand“ einer Firma klarzulegen. Deshalb entwickelt fast jede Firma einen großen Appetit auf Auswertungen und entdeckt immer neue Möglichkeiten, interessante Zusammenhänge aus den ERP-Daten zu gewinnen.

Um diesem Punkt Rechnung zu tragen, war die Statistik als recht flexibles Konzept zur Programmsteuerung entworfen, doch wie in den zuvor erwähnten Beispielen verhinderten festgelegte Parametrisierung und hardcoded fixierte Programmnamen die umfassende Wiederverwendbarkeit. Waren neue Programme nötig gewesen, wurden sie nicht als generalisierte Reporting-Tools konzipiert, sondern wie üblich in der früheren Programmierung als Einzelfall programmiert und mussten Stück für Stück in die Statistik einprogrammiert werden:

„Für jedes Fällchen ein Ställchen.“

7) Fehlertoleranz:
Beseitigung von Standardfehlern

Währungsumrechnung:

Aufgrund von Fehlern in der Währungsumrechnung war Ende der 90er Jahre bereits eine Unterroutine erstellt worden, die das Problem behob. Das Diktat der betriebswirtschaftlichen Prämisse gebot freilich, dass nur im Rahmen bezahlter Projekte – oder auf direktes Geheiß der Geschäftsführung – Fehler bereinigt werden durften, weshalb diese Unterroutine noch nicht in allen betroffenen Programmen verwendet wurde.

Bei einem Programm zur Belegverwaltung war diese Problematik wohl bisher noch nicht aufgetreten, denn die moderne Unterroutine wurde hier noch nicht verwendet. Es besaß jedoch die Möglichkeit, die Basiswährung des Belegpreises festzulegen, um bei Umrechnungen Rundungsfehler zwischen der Finanzbuchhaltungs- und der Kundenwährung zu vermeiden. Diese Möglichkeit schien freilich kaum genutzt zu werden, denn die Benutzung dieser Funktionalität führte dazu, dass die Währungen vertauscht wurden, dass also Preise in US-Dollar plötzlich zu Preise in Yen oder Euro wurden.

Im Zuge einer Modifikation des Programms rund um diese Basiswährungs-Bestimmung fiel dieses Problem im Test auf, ein Problem, das der Qualitätssicherung (siehe Punkt 10, Qualifikation) seit langem bekannt war, und es fiel auf, dass das Programm tatsächlich die moderne Unterroutine längst im Code enthielt – sie wurde nur nie verwendet. Fast fünfzig dokumentierte Programmänderungen waren seit der Zeit erfolgt, ohne dass das Code-Segment gestört hätte. Die bisherigen Kunden hatten den entsprechenden Fehler wohl auch noch nicht festgestellt, da sie ohne Fremdwährungen auskamen: Also war es kein Fall, dessen Beseitigung von der betriebswirtschaftlichen Prämisse geduldet worden wäre.

Da im Jahr des Beobachtungszeitraums jedoch Fremdwährungen immer selbstverständlicher wurden und ein Neukunde auf dieser Funktionalität beharrte, musste das Problem nun angefasst werden.

Dabei stellte sich dann heraus, dass die maßgebliche Preisdatei keine Währungsfelder enthielt, weil es bisher noch nicht nötig gewesen war, zumal alle Preise bisher in einer definierten Währung vorzuliegen hatten.

10) Qualifikation:
Junges Team

Angst:

Die fehlende Erfahrung, besonders mit Kundenkontakten, führte zu einer Unsicherheit, die von der Geschäftsführung zu ihren Gunsten verwendet wurde. Obwohl Motivationsanreize über die Bedeutung von Kunden an den Wänden hingen, war „der Kunde“ ein Fremdkörper, der nicht wirklich etwas mit der Arbeit zu tun hatte. Ganz im Gegenteil stellte er einen Gefahrenherd dar, denn „der Kunde“ konnte jederzeit Gegenstand des Unwillens der Geschäftsführung werden, die ihren Ärger in solchen Fällen deutlich kundtat. Weil in kleinen Häusern so etwas nirgendwo zu überhören ist, blieb das selten vor den Kollegen verborgen.

Zeigte sich gar aufgrund der praktizierten, zeitsparenden Produktion der Software ein Fehler, während die Geschäftsführung „dem Kunden“ Auge in Auge gegenüberstand, so wurde dies als höchst peinlich empfunden, besonders dann, wenn dieser Fehler von einem Mitarbeiter stammte. Die Klagen der Geschäftsführung über die unzureichende Arbeitsweise der Untergebenen und die klare Aussage, dass dies Konsequenzen haben würde, versöhnten die aus dem Mittelstand stammenden Kunden zwar zumeist, die Peinlichkeit der Situation führte aber regelmäßig zu ebenso peinlichen Situationen für die Verursacher.

Dies hatte die Konsequenz, dass alle Mitarbeiter im Büro auf Abruf stehen mussten, wenn die Geschäftsführung beim Kunden war, um bei Missständen sofort Unterstützung leisten zu können. Ging etwas schief, „so verdunkelte sich das ganze das Haus“ (Zitat).

Dennoch genügte dieser Schmerzpegel nicht, die Qualität der Software in den Vordergrund der Aufmerksamkeit zu stellen oder den unselbständigen Mitarbeiter genügend Vertrauen entgegenzubringen, um sie ihre eigenen Projekte vor Ort vorstellen zu lassen.

Es genügte jedoch, eine Konfrontationshaltung der Mitarbeiter gegenüber „dem Kunden“ aufzubauen, als seien die Mitarbeiter Dompteure, die mit wilden Tieren umzugehen hätten mit der unschönen Nebenwirkung, dass gerade kooperative Kunden mit einer gewissen Verachtung gestraft wurden und im Zweifelsfall sogar zurückstehen mussten.

11) Generationenkonflikt:
Vereinheitlichung der Programmierung

Funktionstasten:

Standardisierung heißt aus der Sicht der Anwender „Gleichverhalten“, sie müssen also bei standardisierten Programmen nicht für jedes einzelne lernen, wie es zu bedienen ist und wie es reagiert.

Eine solche benutzerfreundliche Oberfläche wurde auch im vorliegenden Praxisbeispiel angegangen, indem wie üblich, Menüpunkte, Feldverhalten und Funktionstasten soweit als möglich vereinheitlicht wurden bis hin zu der Gleichschaltung von Editierfeldern (siehe Beispiel „Anzeigemodus“). Das Problem dabei war jedoch, dass Software sich ändert und gerade die Software kleiner Software-Häuser muss dies aufgrund ihres geringen Funktionsumfangs so rasch als möglich tun, sodass es immer wieder zu Konkurrenzproblemen zu bisherigen Lösungen kommen kann.

Da die betriebswirtschaftliche Prämisse eine Bearbeitung der älteren Programme verbot, existierten somit verschiedene „Standards“ parallel nebeneinander. Besonders unschön wirkte sich dies im Fall der Funktionstaste aus, die für die Bestätigung der Arbeit ausgewählt worden war („OK“-Button). Eine solche universelle Bedienung prägt sich Anwendern sehr rasch ein und jeder Bruch im Verhalten löst zwangsweise Verwirrung aus, denn je selbstverständlicher etwas ist, umso eher wird der Ausnahmefall als Fehler verstanden. Genau dies geschah mit einem recht wichtigen Programm, das die neuere Variante der Bestätigung der Arbeit über Funktionstasten noch nicht integriert hatte und deshalb sogar bei der eigenen Qualitätssicherung regelmäßig eine Schrecksekunde auslöste.

12) Stiefkind „Datenstruktur“:
einfache Datenbank-Architektur

Repository:

Eine Dateibeschreibung zu erstellen, ist am schnellsten und einfachsten dadurch zu bewältigen, dass die Felder aufgeführt und definiert werden. Danach lässt sich sofort mit dieser Datei arbeiten und sie für die weitere Programmierung nutzen.

Eine Referenzdatei, die möglicherweise nicht nur Feldname und –Art beinhaltet, sondern auch beschreibende und Hilfetexte oder gar ausführbare Funktionalitäten wie Prüfroutinen enthält, hat dagegen augenscheinlich den Nachteil, dass sie bei jedem einzelnen neu benötigten Feld nach Übereinstimmungen zu durchleuchten ist, was bei umfangreichen Dateien einige Zeit dauern kann. Dies hatte zur Folge, dass in dem vorliegenden Praxisbeispiel eine der gängigsten Standardisierungen moderner ERP – die der Dateifelder – nicht verwendet wurde mit der unausweichlichen Konsequenz, dass weder eine Vereinheitlichung von Form noch von Inhalt der Dateifelder zwingend war.

Dies führte zwar nicht zu einer völligen Willkürlichkeit bei der Definition und Bearbeitung der Dateifelder, da der Programmbaustein „Mensch“ (siehe Punkt 3) die Zusammenhänge kennt und gleiche Inhalte ganz intuitiv mit denselben Namen und Eigenschaften ausstattet, der Störfaktor „Neuling“ oder „weniger bekannter Feldinhalt“ versah die Anwendung all dieser nicht fixierten, zu wissenden Regeln jedoch zwangsweise mit einem Zufallselement. Dieses Zufallselement, sprich die Abweichung von der Norm für ein spezielles Feld, war notwendig am stärksten ausgeprägt in der Behandlung der funktionalen Abhängigkeiten des Feldes. Dies lag nicht nur am fehlenden Repository, sondern auch an dem in den meisten kleinen Software-Häusern intuitiven Umgang mit der Objektarchitektur. Bis auf den heutigen Tag werden auch in Java und C++ die meisten Funktionalitäten intuitiv programmiert und wenn auch Objekte benutzt und sogar wieder verwendet werden, so wird sich doch wenig Gedanken über die Minimierung von Verknüpfung zwischen den Objekten gemacht, sodass die Zusammenhänge wie selbstverständlich in den übergeordneten Programmcode einfließen.

Da gerade Geschäftsregeln vor allem Verknüpfung sind, finden sich die meisten somit als impliziter Teil des Codes verteilt über manchmal mehrere Programme und sind in ihren Bestandteilen kaum einzelnen Objekten, erst recht nicht einzelnen Feldern zuzuordnen. Damit fehlt auch jede Möglichkeit, Standardisierungspotential zu erkennen.

Was im vorliegenden Praxisbeispiel jedoch erstaunlich war, blieb die Tatsache, dass diese Standardisierung von Dateifeldern auch für Texte nicht in Anspruch genommen wurde, denn der Arbeitsaufwand, den eine Referenzdatei allein mit der einfachen Möglichkeit der Texthinterlegung verhindert hätte, war enorm – und dauerhaft. Jedes Text verwendende Programm erforderte deshalb die höchst umständliche, langweilige und zeitaufwändige Anlage von neuen, immer ähnlich lautenden Texten in den erforderlichen Sprachen mit all den Problemen redundanter Datenhaltung, auch wenn diese bei Texten nicht so sehr ins Gewicht fallen mögen. Der reine Tipp-Aufwand für diese Texte konnte darüber hinaus im Gegensatz zu Programmcode kaum durch das Kopieren umfangreicher Elemente ersetzt werden, da die Meldungssystematik des Betriebssystems verwendet wurde und deren datentechnische Handhabung nicht bekannt war. Also lagen auch keine Programmhilfen vor, mit denen eine bequeme Textbearbeitung für solche Dateifeld-Präsentationen in Programmen bearbeitet werden konnte. Im Klartext hieß dies, dass tatsächlich für jedes Feld in einem Layout, ob Druck oder Bildschirm, die notwendigen Texte angelegt werden musste, wobei die größtmögliche Arbeitserleichterung noch das Copy&Paste-Verfahren war. Diese extrem aufwändige Lösung führte denn auch dazu, dass nur eine beschreibende Nachrichten-Ebene in dieser Software verwendet wurde. Die Möglichkeit des Betriebssystems, einen darüber hinaus gehenden, umfangreicheren Text als Hilfestellung für die Anwender zu offerieren, blieb ungenutzt.

Da dieser Aufwand von jedem Programmierer, also auch von der mitarbeitenden Geschäftsleitung, erledigt werden musste, wäre wohl zu erwarten gewesen, dass die erhebliche, aber einmalige Investition für ein Repository in Betracht gezogen würde. Dies war nicht der Fall.

Ganz im Gegenteil wurde diese Behandlung von Texten als ein positives „Feature“ gesehen, da es den Anwendern völlige Freiheit bei der Formulierung ihrer Layouts bieten würde. Eine Lösung aus Unterlassungstexten, die nach Belieben überschrieben werden konnte, wurde nicht diskutiert. Weil die mitarbeitende Geschäftsleitung ihre Zeit natürlich weitaus nützlicher mit Akquisition als mit solchen langwierigen und langweiligen Tätigkeiten verbringen konnte, wurden diese von „den Damen“ der Qualitätssicherung und Dokumentation mit übernommen wurden und fielen damit nicht mehr ins Gewicht. Da andererseits die aufwändige Textbearbeitung für die übrigen Programmierer einen nicht unerheblichen Bestandteil an den unbezahlten Überstunden ausmachte, die bei 2,3 Stunden am Tag noch als völlig „normal“ galten, berührte es freilich auch kaum die betriebswirtschaftliche Prämisse und verlor somit erheblich an Motivationskraft.

12) Stiefkind „Datenstruktur“:
einfache Datenbank-Architektur

Berechnungen:

Nicht nur die fehlende Referenzdatei war ein Hinweis darauf, dass Datenbankstrukturen nur von untergeordneter Priorität waren, auch die Auftrags- und Bestellpositionen führten die Willkürlichkeit der Dateikonstruktion vor, wobei letztere, wie des Öfteren in älteren ERP-Softwarehäusern geschehen, eine recht weitgehende Kopie der ersteren war.

Während „Rucksackdateien“ in neuerer Zeit nicht gern gesehen wurden und durch Anpflanzen von Dateifeldern an bestehende Dateien ersetzt wurden, was dem Artikelstamm-Datensatz zu enormen Ausmaßen verholfen hatte, waren diese beiden Datenbereiche sehr wohl in mehrere Dateien strukturiert. Dabei wurden in den Datensätzen en jedoch keine aufgelaufenen Werte oder auch Einheiten berücksichtigt. Dies führte zu Problemen, als ein Kunde Preise und Mengen in verschiedenen Einheiten zu verwalten wünschte und es hatte darüber hinaus den unschönen Nachteil, dass die Positionen nicht nur keine Gesamtpreise auf Dateiebene anboten, sondern es sogar in den Verwaltungsprogrammen den Kunden überließen, die Berechnung des endgültigen Positionspreises aus hinterlegten und manuellen Konditionen durchzuführen. Auch die Übersichtsprogramme über den Stand der Aufträge oder Bestellungen lieferten nur die Inhalte der Dateien, sodass der gesamte Preis einer Position erst bei der gedruckten Bestätigung ersichtlich wurde. Freilich war auch dort der Gesamtpreis nur „über den Kontext“ ersichtlich, denn die Werte der Positionskonditionen wurden zwar bei der zugehörigen Position angedruckt, jedoch nicht berechnet und nur in einer abschließenden Summe berücksichtigt.

12) Stiefkind „Datenstruktur“:
einfache Datenbank-Architektur

Data-Warehousing und Business Intelligence:

Je mehr Information in den Daten steckt, umso umfassenderen Nutzen können Auswertesysteme liefern. Information findet sich aber aufgrund ihrer Natur gerade nicht in den einzelnen Daten, sondern nur in ihrer Verknüpfung, eine Tatsache, der die 4fF-Methode Rechnung trägt. Data Warehouses und Business Intelligence benötigen deshalb Daten, die nicht nur fehlerfrei sind, sondern auch konsistent. Der lockere Umgang mit Datenstrukturen verhindert freilich zumeist eine weitergehende Aussagekraft, wie folgendes Beispiel deutlich macht:

In Preis bezogenen Positionsdatensätzen waren Felder enthalten, die sowohl Beträge als auch Prozentwerte aufnahmen. Wie üblich in solchen Fällen wurde die jeweilige Ausprägung über eine Tabelle gesteuert, wobei zumeist der Steuerwert in den Datensätzen mit abgespeichert wird. Mit einem einfachen SQL-Befehl lässt sich somit der korrekte Betrag abhängig von diesem Schalterwert errechnen, was die Voraussetzung dafür ist, automatische Auswertungen über die Daten zu erstellen.

In dem vorliegenden Praxisbeispiel wurde die Speicherung dieses Schalterwertes jedoch unterlassen. Dies erhöhte die Aktualität des Datensatzes enorm und wurde deshalb als Vorzug angesehen, denn bei jedem Zugriff auf den Datensatz, unabhängig vom Erfassungs- oder Änderungsdatum, musste die aktuelle Ausführung der Steuerungstabelle neu bestimmt werden, um zu ermitteln, welcher Natur der Zahlenwert des betroffenen Dateifeldes war. Dass das Fehlen des Steuerwertes freilich selbst den eigenen Programmen Problemen bereitete, zeigte die Währungsumrechnung, die auch für die Prozent-Werte durchgeführt wurde, doch da die Programmierer des kleinen Hauses dies wussten und es noch niemand gestört hatte, wurden dieses Manko nie bereinigt.

Dass jedes Auswerteprogramm deshalb dieses Wissen integrieren musste und somit jedes allgemeine Reporting-Tool seinen Nutzen verlor, war aufgrund der vorhandenen Software-Architektur dagegen nicht von Bedeutung.

12) Stiefkind „Datenstruktur“:
einfache Datenbank-Architektur

Log-Datei:

Protokolldateien haben die Aufgabe, bestimmte Arbeitsschritte zu dokumentieren, um sie notfalls kontrollieren oder gar korrigieren zu können. Deshalb werden sie häufig bei Migrationsprogrammen verwendet, die einmalige, dafür aber umfassende Datenänderungen vornehmen müssen. Wie jede Datei sollten sie also „sprechend“ sein, denn „Anwendungen vergehen, Daten bestehen“.

Für ein solches Migrationsprogramm musste nun auch eine neue Log-Datei erstellt werden, da keine generelle Protokollmöglichkeit bestand. Die Datei durfte jedoch so ausgelegt werden, dass sie für ähnlich gelagerte Migrationsprogramme, die als Kopien aus einer „passenden Vorlage“ erstellt wurden, auch unverändert verwendet werden konnte. Was sie jedoch nicht werden durfte, war „sprechend“. So erlaubte die Projektleitung keine Felder für die Identifikation und maßgeblichen Feldinhalte des behandelten Datensatzes, da diese Identifikation im erklärenden Textfeld längst enthalten sei, dessen Inhalt wie üblich hardcoded im Programm verankert und mit den jeweiligen anzugebenden Daten verknüpft wurde. Mehrsprachigkeit war deshalb zwar nicht möglich, aufgrund der Einmaligkeit der Migration und der Tatsache, dass kaum mit mehrsprachigen Kunden und noch weitaus weniger mit mehrsprachigen Kollegen zu rechnen war, jedoch auch kein Thema. Eine spätere mögliche Verwendungen der Datei zu berücksichtigen, kam ebenfalls nicht in Betracht wegen der betriebswirtschaftlichen Prämisse. Somit gab es keine Ursache, die zusätzlichen Datenbankfelder bei der Neuanlage der Log-Datei mit aufzunehmen und die notwendigen Statements zu ihrer Bestückung im Programmcode aufzunehmen, sodass die Log-Datei fast nur aus einem einzigen, riesigen Textfeld bestand, dessen Inhalt dem Programm-Einzelfall entsprechend aus diversen Elementen zusammengesetzt worden war.

13) Spurensuche:
Dokumentation von Software-Bearbeitung

Die Wiedererfindung des Rades:

Ein häufig auftretender Fehler ließ sich bis auf das verwendete Musterprogramm zurückführen. Da die betriebswirtschaftliche Prämisse eine Überprüfung derjenigen Nachkommen des fehlerhaften Programmes verbot, die nicht im aktuellen Projekt inbegriffen waren, wurde in dem Excel-Sheet, das Programmfehler der Software auflistete, über Layout-Mittel die Universalität des Fehlers und seiner Lösung festgehalten, um bei späterem Auftreten des Problems als Hilfestellung zu dienen.

13) Spurensuche:
Handhabung von Software-Versionen

Umwandlungsprogramm:

Im vorliegenden Praxisbeispiel war die Erstellung von Objekten aus Sourcen über ein Umwandlungsprogramm geregelt, das die erforderlichen Verbindungen zwischen den einzelnen Objektbestandteilen regelte. Gemäß der betriebswirtschaftlichen Prämisse war es jedoch auf den Umfang beschränkt, der als üblich galt, sodass jedes erlaubte Statement, das nicht zu diesem Umfang gehörte, zu einem Programmabsturz führte. Das Problem dabei war, dass dieser Umfang auf die am einfachsten zu bearbeitenden Statement-Formen beschränkt war, die in der Regel den Nachteil haben, weniger flexibel zu sein als solche, die sich über Parser-Programme ein wenig schwerer ermitteln lassen.

15) Allverwendbarkeit:
flexible Aufgabenverteilung

„Wir kaufen nix“:

Um keine ungerechtfertigten Forderungen von Außenstehenden zu provozieren, war die Annahme jeglicher Waren oder Dienstleistungen grundsätzlich untersagt. Ausnahme mussten natürlich die „gerechtfertigten Forderungen“ sein. War also etwas bestellt, sollte es auch angenommen werden. Eine Übersicht solcher Vorgänge war auf einem Computer zu finden, der von der Frau der Geschäftsleitung, die für die Verwaltung zuständig war, verwendet wurde. Da sie damit auch heiklere Themen wie die Zeiterfassung bearbeitete, wurde dieser Rechner isoliert betrieben.

Mitarbeiter, die nun aufgrund der Abwesenheit von Verwaltungspersonen gezwungen waren, eine Bestellung entgegenzunehmen, mussten also sowohl Kennwort des fremden Computernutzers als auch den Namen der Textdatei kennen, die dafür verwendet wurde, wobei generelle Ausnahmen, die nicht in dieser Datei vorlagen, ebenfalls zu wissen waren.

In einem kleinen Software-Haus gelten solche Details jedoch oft als so geringfügig, dass einerseits keine Organisationshilfen geboten werden, andererseits eine Nichtbeachtung zu Tadeln führen kann, die in der familiären Umgebung solcher Firmen regelmäßig persönlich werden.

18) Legalität:
Flexibilität

Produkthaftung - Dokumentation und Gewährleistung:

„* Minimal-Dokumentation nach § 4 Abs. 2 Ziffer 3 GPSG Gebrauchs- und Bedienungsanleitung
* Montageanweisung
* Beschreibung des Produkts
* Sicherheitshinweise
* Informationen zum Hersteller
* Serviceadressen und Lieferanten von Zubehör- und Ersatzteilen
* Garantie- bzw. Gewährleistungshinweise
* Informationen zur Außerbetriebnahme
* Hinweise zur Entsorgung
* Hinweise zur Reinigung
* technische Daten“ (Quelle 20.01.2005)

„Die von der Rechtsprechung für Benutzeranleitungen im Rahmen der Produkthaftung entwickelten Grundsätze sind auf Softwareanleitungen entsprechend anzuwenden“: Saarbrücker Standard 1999 (Quelle 19.01.2005 bzw. Google-Cache vom 19.01.2005)

(siehe dazu auch „Richtlinie für die Softwaredokumentation“, Quelle 20.01.2005, PDF, 326 KB)

Der Versuch ist verbreitet in der Software-Industrie, die eigene Software über Dienst-, nicht Werkvertrag zu verkaufen, doch nicht nur die deutschen Richter sehen diese Behandlung ein wenig skeptisch. Die moderne Entwicklung der IT hin zur Service-Orientierung (zu deutsch auch: „Produktorientierung“) zeigt ebenfalls klar auf, dass das „Werk“ im Vordergrund steht, nicht die Stundenleistung von Programmierern. Eine solche „Werkssicht“ führt jedoch zur Frage der Dokumentation, die auch in der IT den Kunden als wesentliches Element der Lieferung mitzugeben ist, um die wunsch- und bestimmungsgemäße Verwendung des „Werks“ zu gewährleisten.

Dokumentation wird freilich nicht bezahlt, und solange die Kunden nicht aufhören, Rechnungen für Software ohne Dokumentation zu begleichen, solange sie nicht eine klare Beschreibung ihres gekauften Produktes einfordern, solange ist Dokumentation nur ein Kostenfaktor, der mit letzter Priorität gehandhabt und lieber durch bezahlte Schulungen ersetzt wird. Dies hatte im Falle des vorliegenden Praxisbeispiels zur Folge, dass Programmbauteile, die Interessenten bei Demonstrationsveranstaltungen vorgeführt wurden, mit Bedienerhilfe aufwarten konnte, viele „abwegige“ Funktionalitäten jedoch nur mit der Telefonnummer der Firma als Dokumentation versehen waren.

Von der Operator-Abteilung der Firma, die für die Software-Dokumentation zuständig war (siehe Punkt 10, Qualifikation), wurde geschätzt, dass „schon 80%“ der benötigten Beschreibungen erledigt seien: eine Aussage, die aufgrund der Einarbeitungsmethode der Abteilungsangehörigen mit einer gewissen Distanz zu bewerten ist, da weder Ausbildung noch Learning by doing den umfassenden Überblick unter den gegebenen Beschränkungen der betriebswirtschaftlichen Prämisse hätte gewähren können.

Auch die Konsequenz aus einer fehlenden oder unzureichenden Dokumentation für ISO-Normen wie die ISO 9241 (Ergonomic requirements for office work with visual display terminals) wurde nicht in Erwägung gezogen. Anforderungen, die Benutzer mit Online-Hilfen soweit als möglich zu unterstützen und ihnen so wenig als möglich (bezahlten) Support von der Softwarefirma abzuverlangen, stehen eher im Gegensatz zu den erklärten Zielen der Software-Lieferanten und fördern deshalb nicht automatisch eine kompetente und durchdachte Dokumentationserstellung.

Solange die Kundschaft einer Firma solche fehlenden Elemente kaum verlangt, ist dieses Vorgehen letztendlich sogar gerechtfertigt, da es Kosten vermeidet, die nur gesetzlich zum Umfang des Produkts gehören, nicht jedoch faktisch erforderlich sind.

18) Legalität:
Flexibilität

Arbeitsrecht:

„Nur ganz ausnahmsweise dürfen die 10 Stunden täglich überschritten werden…Der Arbeitgeber ist nach dem Arbeitszeitgesetz verpflichtet, die werktägliche Arbeitszeit der Arbeitnehmer, die über 8 Stunden hinausgeht, aufzuzeichnen.“ (Quelle 20.01.2005)

Die Neigung vieler kleiner Software-Häuser, die Loyalität ihrer Mitarbeiter betriebswirtschaftlich zu verwenden, führt oft zu bereitwillig ausgeführten Überstunden, die weit über das arbeitsrechtliche Maß hinausgehen. In einem Fall wurde es beispielsweise als völlig selbstverständlich angesehen, Mitarbeitern noch Tätigkeiten nach Stechen der Uhr auferlegen zu können so wie es im Lauf der Zeit als selbstverständlich betrachtet wurde, mindestens zwei Überstunden pro Tag abzuliefern, was neben den arbeitsrechtlichen Bedenken jedoch auch Effizienzbetrachtungen hätte herausfordern sollen.

Denn da diese Überstunden überwiegend nicht bezahlt wurden, wiesen sie einen klaren Nachteil auf: Die betriebswirtschaftliche Prämisse entfiel als Effizienzmotor. Ganz im Gegenteil wurden Investitionen behindert durch diese Strategie, da jegliche Effizienzsteigerung mit Änderungen verbunden ist, die zumeist Kosten verursachen, während loyale Mitarbeiter Fehler in Arbeitsorganisation und Planung immer zu vermeiden suchen, notfalls sogar durch unbezahlte Überstunden – ein Mehraufwand, der sich freilich Schritt für Schritt steigert, je länger ineffiziente Mechanismen Redundanzen und Fehlerquellen verschleiern oder gar selbst hervorrufen, ganz abgesehen von dadurch verhinderten Verbesserungseffekten, die aus nicht erschöpften Mitarbeitern resultieren könnten. Loyale Mitarbeiter mit Freizeit können sich fortbilden, können sich Gedanken über Verbesserungen machen, können kreativ sein, ein Punkt, der jedoch in Firmen zumeist nicht als überzeugendes Argument gilt. Kreativität wird in Unternehmen und Behörden meist nur dem zugestanden, der Führungspositionen innehat, wobei der übliche restriktive Umgang mit Mitarbeitern als Self fulfilling Prophecy wirkt: Wer nicht anerkannt wird, wer überarbeitet ist und/oder sich vor Sanktionen fürchtet, neigt tatsächlich wenig zu der nötigen Offenheit und dem nötigen Selbstbewusstsein, das Kreativität und auch deren Vermarktung erfordert.

Darüber hinaus hat eine solche Mitarbeiterführung jedoch noch einen weiteren Effizienz hemmenden Nachteil, den „Spiegelsaal“-Effekt. Diejenigen, die für Kreativität bezahlt werden, sind in solchen Hierarchiestrukturen oft nicht mehr diejenigen, die diese Kreativität in die Realität umsetzen müssen. Das heißt einfach, dass ihnen Fehler ihrer Konstrukte nicht mehr direkt zugänglich sind und das wiederum führt allzumenschlich dazu, dass diese Fehler den ausführenden Organen angelastet werden, was wiederum nichts anderes heißt, als dass solche Hierarchien kaum lernfähig sind.

Lernen ist aber in veränderlichen Umgebungen die einzige Methode, mit Information umzugehen, denn „fertige Lösungen“ kann es nur für recht stabile Problembereiche geben. Lernen bedeutet desweiteren häufig die Akzeptanz fremden Wissens und genau das fällt Führungskräften erwiesenermaßen sehr schwer und es fällt schwerer, je mehr es die eigene Position gefährdet, völlig unabhängig von sachlichen Anforderungen.

Dabei vergessen Führungskräfte oft, dass ihre Macht ihnen die Mittel gibt, ihre Umgebung zu prägen und dass viele Fehler, die sie an ihren Untergebenen sehen, deshalb wenigstens teilweise auf die Art und Weise zurückzuführen sind, wie sie ihre Machtstellung nutzen.

Wie in dem kleinen Software-Haus, in dem der Chef alle verantwortlichen Tätigkeiten wie Kundenkontakte und Programmkonzepte selbst durchführte und es nur einem einzigen Mann erlaubte, solche Tätigkeiten mit zu übernehmen: ein Mann, der sich eine solche Vorzugsbehandlung verdient hatte durch jahrelange Bereitwilligkeit, seine Familie zugunsten der Firma zurückzustecken und durch jahrelange Dienstbarkeit, jegliche erforderliche Arbeit auszuführen, als sei er selbst der Unternehmer, dabei jedoch recht bescheiden in seinen Ansprüchen war, sich solchen Unternehmerfleiß auch auszahlen zu lassen – ein Traum-Untergebener, wie ihn jeder deutsche Unternehmer sich ersehnt.

Und der dabei noch so still und unauffällig wirkte, dass er die Chefetage nicht herausforderte und sie bei Erfolg nicht um das Ansehen beraubte.

Dennoch schützte ihn dies nicht davor, genauso öffentlich gemaßregelt zu werden wie alle übrigen, wenn der Geschäftsleitung nicht passte, was er tat. Genau dieser Geschäftsleitung, die sich ausgiebig über die Lethargie ihrer Untergebenen beklagte und die nie das alte deutsche Sprichwort gehört zu haben schien:

„Wie der Herr, so’s Gescherr.“