Software-Optimierung

Abbildung des Umfelds ist das Maß der Dinge

23.01.1997

Software-Optimierung läuft darauf hinaus, alle beteiligten Ressourcen mit minimalem Einsatz und maximalem Ertrag einzusetzen. Um dieses Ziel zu erreichen, muß man den Weg von der Quelle bis zum Ziel untersuchen und alle störenden Einflußfaktoren aufdecken. Am Anfang allen Übels steht meist ein betriebswirtschaftliches Problem, das es zu lösen gilt. Deshalb muß zunächst einmal die Gesamtsituation des Unternehmens analysiert werden.

Bevor man ein betriebswirtschaftliches Problem angehen kann, ist es notwendig zu wissen, in welchem Zustand sich die Umwelt und damit das Unternehmensumfeld befindet. Diese Aufgabe stellt sich fortwährend, da das Umfeld ständigen Veränderungen unterworfen ist, die im Bereich der Informatik einer besonderen Dynamik unterliegen.

Prioritäten in einer Kette von Aufgaben

Das zu lösende Problem wird kein Mauerblümchendasein fristen, sondern je nach Priorität in einer Kette zu lösender Aufgaben eingegliedert sein. Die Länge dieser Kette (Auftragsvorlage Org./ DV) gibt Aufschluß darüber, wie weitreichend das Informationsdefizit des bisherigen DV-Systems ist. An diesem Punkt wird vereinfachend unterstellt, daß alle berücksichtigten Informationsbedürfnisse berechtigt sind (Eintrittsbarriere), das heißt, sie sind konform zu den Unternehmenszielen.

Die nächste Daueraufgabe ist die Beobachtung des gesamten Informationsbedarfs entlang der Zeitachse (Informatikstrategie), die ein permanentes Anwachsen des Bedarfs signalisieren kann. Bei der Analyse dieser Auftragsvorlage ist eine Strukturierung notwendig, die weitere Rückschlüsse auf die Ursachen von Defiziten zuläßt. So kann man diese beispielsweise nach technischen oder funktionalen Mängeln oder auch nach administrativen Erweiterungen etwa in Folge von Gesetzesänderungen gliedern.

Die Erkenntnisse, die sich aus dieser Vorgehensweise ableiten lassen, zeigen, ob das vorhandene Informationssystem technisch veraltet oder funktional rückständig ist. Wie schnell dieser Prozeß fortschreitet, ist ein weiterer wesentlicher Aspekt, der sich aus dieser Beobachtung gewinnen läßt.

Es kann Schwierigkeiten bereiten zu bestimmen, wie innovativ die Mitarbeiter eines Unternehmens im Verhältnis zu den Möglichkeiten der aktuellen Software-Entwicklung sind. Doch hier kann eine separate Untersuchung weitere Rückschlüsse bieten. Diese Analyse würde das Defizit des eigenen Informationssystems in bezug auf Funktionalität, Technik, Ergonomie etc. gegenüber dem Idealfall aufdecken.

Ein weiterer Blick sollte der jeweiligen Entwicklungsumgebung gelten. Man kann mit dem funktionalen Veränderungspotential aus der Vergangenheitsbeobachtung und aus den Zukunftserwartungen (Dynamik) eine Prognose ableiten, die als Entscheidungsgrundlage für einen möglichen Systemwechsel dient.

Wann läßt sich Altes nicht mehr ertragen?

Welche Schmerzgrenze ein Unternehmen ertragen kann, bis der Wechsel zu einem neuen Informationssystem erfolgen sollte, ist individuell anhand der jeweiligen Nutzenerwartung zu entscheiden. Dabei spielt es keine unerhebliche Rolle, ob ein Standardsoftwarepaket die eigenen Belange ab-deckt und welcher Funktionsabdeckungsgrad gegen die eigenen Anforderungen zu erwarten ist.

Der beschriebene Prozeß soll Unternehmen dafür sensibilisieren, den günstigsten Zeitpunkt für den Wechsel zu einem neuen Informationssystem nicht zu verschlafen. Dieses Vorgehen ist die Hauptstrategie, um einen langfristigen optimalen Einsatz der benutzten Software zu gewährleisten. Die meisten Unternehmen weisen in diesem Punkt eine gewaltige Lücke auf.

Weitere Strategien, die großen Einfluß auf die Produktivität haben, stellen den Faktor Mensch in den Vordergrund. Software läßt sich nur optimal entwickeln und gestalten, wenn alle beteiligten Organisationseinheiten möglichst reibungslos zusammenarbeiten. Das setzt voraus, daß alle organisatorischen Rahmenbedingungen stimmen.

Eine Fachabteilung läßt sich nur optimal unterstützen, wenn die Org./DV-Abteilung diese organisatorisch widerspiegelt. Daraus läßt sich ableiten, daß die Zahl der Mitarbeiter in Org./DV nicht höher ist als in der Organisationseinheit beziehungsweise Fachabteilung.

Ist das Verhältnis umgekehrt, läßt sich eine optimale Hilfestellung für die Fachabteilung nur schwer vorstellen. In diesem Fall wäre über eine Restrukturierung des IT-Konzepts nachzudenken. Natürlich wird es trotzdem weitere Spezialisten geben, die teils die eigene Org./DV vertikal unterstützen (Netze, Datenbanken, Betriebssysteme), und solche, die horizontal ein breites Fachwissen in spezieller PC-Software (Word, Excel etc.) für Ad-hoc-Probleme aufweisen.

Um eine kontinuierliche optimale Unterstützung zu erzielen, muß die Organisationsabteilung Änderungen in den Fachabteilungen mit möglichst geringem Zeitverzug nachvollziehen. Daß jeder DV-Mitarbeiter, und zwar nicht nur während der Einarbeitungsphase, die Fachabteilung durchläuft, sollte sich, bei den sich ständig ändernden Anforderungen, nach kürzester Zeit amortisieren. Auch die Schulung der Fachabteilungsmitarbeiter in bezug auf eine einheitliche Spezifikationssprache zwischen beiden Bereichen müssen bedarfsgerecht gesteuert werden.

Das Problem vieler Mitarbeiter ist die fehlende Vorstellung davon, was sich alles mit Softwaresystemen abbilden läßt. So ist es immer noch keine Seltenheit, daß Beschäftigte Listen manuell mit viel Aufwand sortieren, die sich systemtechnisch mit minimalem Aufwand elektronisch bearbeiten ließen. Um die Software optimal zu nutzen, könnte eine Untersuchung über alle manuellen Nachbereitungen am Rande der Informationsverarbeitung Licht ins Dunkel bringen.

Ähnlich liegt die Problematik beim Ausdruck größerer Listen. Nicht selten wird wegen der Summenbildung nur die letzte Seite benötigt. Der Aufwand, um Listprogramme besser auf die Anforderungen der Endanwender abzustimmen, also für den gewünschten Ausdruck besser zu skalieren, ist in der Regel nicht übermäßig. Das kann man von den direkten und indirekten Papierkosten (Entsorgung, Handhabung) nicht unbedingt behaupten.

Da das Zusammenspiel an den Nahtstellen zwischen Fachabteilung und Org./DV-Abteilung wesentlich von der Kontinuität der beteiligten Stellen abhängt, wird sich eine hohe Fluktuation immer negativ auf die Produktivität der Software-Erstellung und -Wartung auswirken. Zu beantworten ist auch die Frage, wie leicht sich ein Mitarbeiter der Org./DV ersetzen läßt. Wenn das nicht so einfach möglich ist, befindet sich das Unternehmen in keiner beneidenswerten Position. Eine personelle Abhängigkeit wiegt dabei bei kleineren Unternehmen noch wesentlich schwerer. Hinzu kommt das Problem, daß gute Leute für eine veraltete proprietäre Systemumgebung nur schwer zu gewinnen sind.

Viele Bausteine mit vielfältigen Beziehungen

Software ist nicht nur als Ansammlung von Programmen, sondern als komplexes System zu verstehen. Innerhalb dieser Lösung gibt es die unterschiedlichsten Bausteine, die in vielfältigen Beziehungen zueinander stehen. Sie hat den Zweck, bestimmte betriebswirtschaftliche Probleme zu lösen.

Es müssen dazu Prozesse ablaufen, die Funktionen und Daten benutzen, Informationen erzeugen und Organisationseinheiten einbinden. Alle Zustände innerhalb des Prozeßdurchlaufs müssen gut definiert und die Zeit bis zum Erreichen des Endzustandes muß minimal sein. Ungewollte Systemzustände, besser bekannt als Fehlersituationen, können bei kontinuierlicher Betrachtung auch zur Analyse herangezogen werden. Eine Fehlerstrukturanalyse kann Auskunft über die Fehlerursache und die Häufigkeitsverteilung geben. Je nach Lage der Dinge lassen sich wiederum gezielte Gegenmaßnahmen treffen.

Eine zentrale Bedeutung kommt der Dokumentation des gesamten Informationssystems zu. Auch wenn die verschiedensten Softwarepakete Verwendung finden, wachsen sie häufig im Laufe der Zeit immer mehr zusammen. Gerade die stärkere Prozeßorientierung der Unternehmen in letzter Zeit hat diese Entwicklung vorangetrieben. Je prozeßorientierter ein Unternehmen ausgerichtet ist, desto wichtiger ist die Schaffung von Transparenz als komplexitätsreduzierende Maßnahme.

Das Festlegen von Qualitätsstandards und Verfahrensrichtlinien stellt eine der wesentlichen Pflichten dar, die es hier zu erfüllen gilt. In diesem Bereich muß eine homogene Verquickung zwischen Unternehmensrichtlinien, Stellenbeschreibungen und Softwaredokumentationen erreicht werden. Einem zeitlichen Auseinanderfallen zwischen Dokumentation und Entwicklung der Software müssen organisatorische Maßnahmen vorbauen.

Das System Software mit all seinen Objekten ist dabei vollständig zu erfassen, und die Beziehungen der Objekte sind untereinander abzubilden. Den unterschiedlichen Sichten (betriebswirtschaftliche, technische etc.) und Detaillierungsstufen (grob bis detailliert) ist Rechnung zu tragen. Grundsätzlich ist bei Standardsystemen darauf zu achten, daß das Dokumentationssystem genauso offen ist wie andere wichtige Komponenten.

Langfristig werden Modellierungswerkzeuge, Dokumentations- und Workflow-Systeme durch die aktive Integration innerhalb der Informationssysteme zusammenwachsen. Diese Erkenntnis ist von essentieller Bedeutung, da nur von transparenten Systemen ein hoher Ausnutzungsgrad zu erwarten ist. An schwer überschaubaren Systemen werden Veränderungen nur mit großer Zurückhaltung vorgenommen werden.

Viele Anwender erwarten von neuer, moderner Software Wunderkräfte und vergessen dabei, daß ein zielgerichteter Programmgebrauch entscheidend ist. Ein gut eingesetztes und optimal an die Firmenbelange angelehntes altes Softwaresystem ist für ein Unternehmen möglicherweise wesentlich vorteilhafter als eine schlecht genutzte neue Applikation.

Mangelnde Transparenz kann erheblich die Flexibilität konterkarieren, die man gerade bei neueren Anwendungen erwarten darf. Software wird durch aktive Ausprägung beim Kunden zu einem lebendigen Produkt. Je stärker es an die Firmenorganisation angelehnt ist, desto höher ist der individuelle Wert für das Unternehmen.

Angeklickt

Spötter behaupten, nur in verschwindend wenig Fällen sei überhaupt jemals ein fehlerfreies Programm geschrieben worden. Gegen derartige Lästerzungen werden sich jede Menge DV-Profis mit Belegen aus dem eigenen Schaffen zur Wehr setzen. Trotzdem sind sie damit nicht aus dem Schneider. Das beste Programm kann ein einziger Fehler sein - auch ohne daß die Auftraggeber durch ständige neue Einfälle das schönste Konzept vermurksen. Der Kardinalfehler liegt allzu häufig in der Mißachtung des Umfelds, in dem Software-Entwicklung stattfindet.

*Peter Klukas ist bei der AEG Lichttechnik (Phillips) in der Organisation und Informationsverarbeitung, Springe beschäftigt