Jedes Unternehmen hat während der Auswahlphase beispielsweise für ein Standard-PPS-System das Ziel, ein möglichst vollkommenes, komplettes, alle Bedürfnisse des Unternehmens abdeckendes System am Markt zu finden. Dabei kristallisieren sich bei den einen die Favoriten in relativ kurzer Zeit heraus. Bei anderen hingegen dauert diese Phase schon deshalb recht lange, weil sie sich bereits vorab Gedanken machen, welche Veränderungen sich mit dem Projekt gleichzeitig oder nacheinander umsetzen lassen. Aber noch so ausführliche Pflichtenhefte oder tiefgreifende Workshops können höchstens Erkenntnisse bringen über Anforderungen oder Vorstellungen, die für die zukünftige Entwicklung eines Unternehmens wichtig sind.

Bereits in dieser Phase eines Projekts beginnt der Entscheidungsprozeß für die Einsatzfähigkeit eines Standardpaketes ohne jegliche Erweiterungen oder mit Einbindungen in bereits vorhandene Anwendungssysteme oder aber auch Ergänzungen, die sich direkt in dem neuen Standardumfeld konzipieren lassen.

Der Gedanke "Standard um jeden Preis" kann und soll in der Auswahlphase nicht den Blick auf andere Möglichkeiten verstellen. So wie vieles dafür spricht, neue moderne Standard-Systeme in einem Unternehmen einzuführen, so gibt es im Unternehmen auch sehr gute Gründe, spezielle Abläufe oder Aufgaben sowohl in der Produktion als auch in administrativen Bereichen beizubehalten. Wenn das Ziel nicht darin besteht, "Standardunternehmen" zu schaffen, dann wird es auch richtig sein, für eine optimale und geeignete DV-technische Unterstützung rechts und links an einem Standardsystem vorbeischauen zu dürfen.

Erkennt das Projektteam in der Auswahlphase die eine oder andere "Abdeckungslücke", so wird an diesen Stellen eine konstruktive Diskussion beginnen, die die Frage zu klären hat: Wer oder was ist zu ändern oder anzupassen?

Dies sind im einzelnen

-die Unternehmensanforderungen,

-die Organisationsabläufe,

-die Informationsflüsse,

-die Aufgaben der Menschen im Unternehmen und nicht zuletzt

-das Denken der Menschen im Unternehmen.

Gerade in diesen Punkten sollten Kompromisse im Zusammenspiel zwischen Menschen, Aufgaben und Abläufen gefunden werden. Wie kompliziert dieses Miteinander sein kann, davon können viele Projektleiter, Berater ein Lied singen. Jedoch muß auch die Software ihren Anteil zur Kompromißlösung beitragen. Sie ist ein Hilfsmittel, sie soll Menschen bei ihrer Arbeit unterstützen, sie darf keinen Ärger herbeiführen. Um all diesen Anforderungen gerecht zu werden, haben die Anbieterfirmen immer flexiblere, aber auch zunehmend umfangreichere Standardsysteme entwickelt.

Versuche, Schnittstellen zu standardisieren

Zwischen Wunsch und Wirklichkeit klaffen jedoch oftmals Lücken. Die Entwicklung noch größerer und komplexerer Systeme läßt sich nur vermeiden, wenn sich der Kunde bei Spezialanforderungen entscheidet: entweder für unternehmensspezifische Erweiterungen oder Spezialpakete oder für Eigenentwicklungen. In einigen Fällen kann sogar eine manuelle Bearbeitung vorteilhafter, kostengünstiger oder sogar schneller sein.

Schon seit vielen Jahren laufen Versuche, Schnittstellen auf den verschiedensten Ebenen von Anwendungssystemen zu standardisieren. In einigen Branchen sind mit definierten Protokollen wie VDA, Odette oder Swift bereits Erfolge zu verzeichnen. Auch Edifact leistet dabei seinen Beitrag. Diese standardisierten Kommunikationsformen führten zu Vereinfachungen zwischen Kunden- und Lieferantenabläufen. In diesen Bereichen ist es schon möglich, daß unterschiedliche Softwaresysteme Aufträge, Rechnungen, Lieferscheine etc. austauschen. Noch vor zehn Jahren haben nur wenige Systeme diese Möglichkeiten geboten. Heute dagegen gehören die wichtigsten Protokolle zum Standardlieferumfang.

Der zunehmend stärkere Zeit-, Kosten- und Termindruck erfordert in immer mehr Bereichen schnelle und moderne Informa- tionsaufbereitung.

Da hierzu auch das Zusammentragen notwendiger Daten und Informationen gehört, werden die bisher noch oft "stand alone" betriebenen Auswertungssysteme wie Excel oder Lotus immer mehr über Schnittstellen von den integrierten Standardsystemen versorgt.

Diese Front-end-Erweiterungen haben auf den gesamten Datenfluß in dem integrierten System keinen Einfluß. Aus diesem Grund ist es jederzeit möglich, bei fehlenden oder zusätzlich gewünschten Informationsaufbereitungen auf die von den Herstellern angebotenen Standardschnittstellen zurückzugreifen. Die Einbeziehung der Desktop-Anwendungen von Microsoft ist bei den meisten Standardsystemen über die OLE-Technik möglich.

Nicht immer können Unternehmen ihre Erweiterung auf so einfache Weise lösen. Verschiedene Möglichkeiten bieten sich an:

-die Anbindung von Fremdpaketen,

-die Anbindung von Eigenentwicklungen,

-die Ergänzung von Funktionen und Algorithmen sowie

-die Erweiterung und Ergänzung von Daten und Strukturen.

Die Anbindung eines separaten kompletten Fremdsystems führt häufig zu Problemen, wenn funktionale Überlappungen mit dem Standardsystem bestehen. In diesen Fällen gestaltet sich der Datenaustausch recht komplex. Beispielhaft dafür ist die häufige Anbindung von Werkstattsteuerungssystemen an Standardsysteme wie R/3 oder Baan.

Das R/3-System bietet für den Datenaustausch die umfangreich ausgestatteten Remote-Function-Calls. Im Baan-IV-System steht für den kontrollierten Datentransfer das Exchange-Modul zur Verfügung. Mit Hilfe dieser Tools können Datenbestände aus den jeweiligen Standardsystemen in die Fremdpakete übernommen beziehungsweise umgekehrt Daten verschickt werden.

Daß derartige Anbindungen mit dem Datentransfer noch nicht reibungslos funktionieren, machen bereits solche Kleinigkeiten wie geänderte Arbeitspläne im Werkstattbereich deutlich. So nutzt zum Beispiel das Baan-System einen Arbeitsgangkatalog, der als Erstellungshilfe für die Arbeitsplanung dient.

In einem fremden Werkstattsteuerungssystem muß dies nicht unbedingt der Fall sein. Jedoch ist es möglich, separate Arbeitsgänge hinzuzufügen. Erfolgt schließlich ein Rücktransport der Daten in das Baan-System ohne einen entsprechenden Eintrag im Katalog, kann das bereits zu Konsistenzproblemen führen.

Dieses einfache Beispiel zeigt, daß die von den Standardanbietern bereitgestellten Kommunikationswerkzeuge trotzdem noch eine detaillierte, funktionale und organisatorische Absprache und Einbindung erforderlich machen.

Werden zwei Fremdsysteme miteinander verbunden, ist außerdem zu berücksichtigen, daß jedes System einer gesonderten Release-Pflege unterliegt. Dann kann es für ein Unternehmen mitunter schwierig sein, die passenden Release-Stände zur richtigen Zeit zu erhalten oder mit den vorhandenen Schnittstellen aufeinander abzugleichen. Der Einsatz von separaten Paketen, die im Normalfall über eigene Stammdaten, Entwicklungsumgebungen etc. verfügen, ist deshalb nur in Spezialbereichen, in denen spezifische Softwareanforderungen bestehen, sinnvoll.

In der Anbindung ähnlich, aber in der Realisierbarkeit der Schnittstellen und der Integration zu einem Standardsystem anders, ist firmeneigene Software. Es kann sich dabei bereits um sehr modern gestaltete Eigenentwicklungen handeln, daneben gibt es aber auch Altsysteme, die noch aus den achtziger oder gar siebziger Jahren stammen. Keine Frage: Schnittstellen zu moderner Individualsoftware, die zum Beispiel auf Basis von Oracle oder Ingres oder Sybes entwickelt wurden, sind einfacher zuhandhaben.

Da sehr viele PPS-Projekte aufgrund der Jahrtausend- oder der Euro-Umstellung gestartet werden, ist auch über die Lebensdauer älterer Softwaresysteme zu entscheiden. Davon abhängig ist die Einbindung in das Standardsystem zu konzipieren, entweder komfortabel oder nur für den temporären Gebrauch.

Gerade in diesem Zusammenhang kann sich eine zweite Erweiterungsmethode zu einem Standardsystem vorteilhaft erweisen. Die in einem Altsystem vorhandenen Spezialfunktionen werden in der Entwicklungsumgebung des Standardpakets neu abgebildet. Dies können zum einen separate Zusatzfunktionen sein, die über Menüstrukturen für den Anwender bereitgestellt werden. Handelt es sich jedoch um Verbesserungen von Algorithmen oder um Optimierungsfunktionen, so eignen sich zur Anbindung an den Standard die bereits häufig vorgesehenen sogenannten User-Exits.

Wie auch immer die Änderung einer Standardfunktion aussieht, wichtig ist, das im Unternehmen vorhandene Fach-Know-how in die angebotene Standardsoftware einzubinden. Das läßt sich in vielen Fällen auf eine sehr Release-freundliche Art und Weise erreichen. Werden dabei die Entwicklungs-Tools der jeweiligen Standardanbieter genutzt, so hat das zum einen den Vorteil, daß die Entwicklungswerkzeuge der Eigenentwicklung stets den gleichen Release-Stand aufweisen wie das zugehörige Standardpaket. Auch die Aufwendungen der Ausbildung lassen sich dann auf eine begrenzte Anzahl von Tools festlegen.

Wurde ein Datenbanksystem vom Unternehmen als Entwicklungsplattform gewählt, so sind heute die großen Standardsysteme auf fast allen gängigen Systemen einsetzbar. Demzufolge können Eigenentwicklungen auch auf die Daten der Standardsysteme in bekannter Form zurückgreifen. Vorsicht ist natürlich immer dann geboten, wenn unternehmensspezifische Funktionalitäten in schreibender Form in die Standarddatenbestände eingreifen. Hier wäre der Einsatz der angebotenen Call-Funktionen der Standardpakete vorteilhafter, da in diesen Fällen alle notwendigen Prüfungen korrekt mit vorgenommen werden.

Inwieweit das eine oder andere Standardpaket die Anbindung fremder Software oder die Einfügung zusätzlicher Funktionen und Daten unterstützt, ist sehr unterschiedlich.

Dabei sind nicht allein die angebotenen Tools, Calls oder User-Exits entscheidend. Auch die Offenlegung und Dokumentation der internen Zusammenhänge ist für die Vermeidung von Fehlern bei der Erweiterung von Standardsoftware notwendig. Bei den großen Anbietern, etwa SAP, Baan, Oracle oder People-Soft lohnt deshalb für jedes Projektteam ein Blick in diese Dokumente, um besser einschätzen zu können, wie einfach oder kompliziert zukünftige Erweiterungen und Änderungen realisierbar sind.

Sehr häufig war in der Vergangenheit bei den Eigenentwicklungen der Unternehmen die Dokumentation der Programme, Funktionen und Abläufe ein Stiefkind der Entwicklung. Aus Zeit- oder Kostengründen wurde an diesen Stellen gespart. Bei Standardsystemen, die in viel größerer Anzahl verkauft und eingesetzt werden, ist sowohl der Anwender als auch der Programmierer mit aussagekräftigen Dokumentationen zu unterstützen. Neue oder schnell wachsende Standardsysteme haben aber gerade hier einen Nachholbedarf. R/3 bietet vergleichsweise recht gute Anwender- und Programmiererdokumentationen in Buch-, CD- oder Online-Form an.

Bei der Suche nach der geeigneten IT-Unterstützung für das Unternehmen mit dem Ziel, nicht alles in eigener Regie gestalten oder festlegen zu wollen, bildet ein Standardsystem eine gute Basis für weitere Software-Anwendungen. Wichtig ist, daß dessen Offenheit gewährleistet ist und sich alle Daten in verschiedenen Bereichen möglichst einfach nutzen lassen. Funktionsabläufe für bestimmte Unternehmensstrukturen müssen unterschiedlich gestaltbar sein. Nur so läßt sich das Ziel erreichen, bei Bedarf mit geeigneten, gut konzipierten Standardergänzungen das eigene Unternehmen und seine Anwender noch effizienter und flexibler unterstützen zu können.

Die immer größer werdende Modularität der Standardsysteme ermöglicht einerseits eine flexible Anpaßbarkeit an Unternehmensänderungen (zum Beispiel die Baan-Philosophie des Dynamic-Enterprise-Modeler). Andererseits aber erfordert sie eine noch viel größere Sorgfalt bei der Einbindung von Fremdsystemen oder Funktionen, die nicht auf der gleichen Plattform basieren. Es werden dann Verwaltungssysteme benötigt, die unabhängig von den verschiedensten Entwicklungswerkzeugen kleine "Softwarestückchen" hinsichtlich ihrer Abhängigkeit, Release-Fähigkeit etc. überprüfen.

Es ist fraglich, ob jedes Unternehmen diese Aufgaben übernehmen wird. Vielmehr wird der bisher eingeschlagene Trend, einen Standard möglichst vorgefertigt, das heißt, auch mit vorgeschlagenen Abläufen einfach zu implementieren, weiterverfolgt, manchmal auch zu Lasten der Effizienz in Abläufen und Funktionen. Doch unterscheiden sich hier große, mittlere und kleinere Firmen; die Marktvielfalt ermöglicht eine entsprechende Auswahl.

Im Zusammenhang mit der Erweiterbarkeit von Standardsystemen, die an weit mehr Stellen gegeben ist als oft angenommen wird, darf auf Hinweise zur Release-Pflege und -Umstellung nicht verzichtet werden. Bei geeigneter Konzeption und unter Berücksichtigung der Systemstrukturen des Standards ist heute in allen großen marktgängigen Systemen eine Release-freundliche Anpassung möglich. Beispielsweise kann die von Baan angebotene VRC-Technologie (Version Release Control) von Vorteil sein. Bei der falschen Erweiterungsmethode schützt diese Möglichkeit jedoch auch nicht vor den Problemen beim nächsten Wechsel.

Schnellebigkeit zeigt sich auch in der raschen Abfolge der Release-Wechsel bei den Standardanbietern. Es vergeht kaum ein Jahr ohne größere Release-Sprünge auf seiten der Hersteller. So geraten Unternehmen immer weiter unter Druck, diese Wechsel mit nicht zu großen Zeitabständen vorzunehmen, um so in die schnelle Fehlerbehebung als auch komplette Anrechenbarkeit ihrer einmal bezahlten Lizenzkosten zu gelangen. Da alles, auch der kleinste Release-Wechsel, stets mit Kosten und Zeit verbunden ist, wird sehr häufig auf eine vorteilhafte Erweiterung des Standards verzichtet. Das Weiterleben von Eigenentwicklungen läßt sich ebenfalls mit diesem Kostenargument rechtfertigen.

Um die Standardsysteme in Zukunft nicht weiter zu überfrachten, sollten die Anbieter noch mehr Möglichkeiten schaffen, über standardisierte, sich nicht bei jedem Release-Wechsel ändernde Anbindungspunkte individuelle Softwareteile einzubeziehen. Beispiele dafür sind die erwähnten User-Exits im R/3-System. An diesen Stellen garantiert SAP fast immer gleichbleibende Daten- und Ablaufstrukturen.

Aus den oben erwähnten Möglichkeiten und Methoden soll jedes Unternehmen seine eigene Wahl treffen. Das beginnt bereits bei der Diskussion der Änderungswünsche der eigenen Organisation und des Denkens der Mitarbeiter. Die Flexiblität beginnt am Schreibtisch jedes einzelnen. Erwarten wir nicht von Software Änderungsmöglichkeiten, die wir selbst nicht bereit sind, im eigenen Arbeitsablauf umzusetzen.

*Beate Arnold ist Geschäftsfühererin deer Pico Consultant mit Sitz in Schwarzenbruck, Ostfildingen und Münsingen.