Kapitel 16Zusammenfassung und Ausblick

Ich liebe die alten Fragen.Schwungvoll:

Ah, die alten Fragen, die alten Antworten,da geht nichts drüber!

EndspielSamuel Beckett1

16.1 Sein und Wunsch

Wir haben gesehen, dass sich die Geschäftsprozesse eines Unternehmens aufGeschäftsobjekte stützen, vor allem zur Implementierung der Aktivitäten der Ge-schäftsprozesse. Die Geschäftsobjekte kapseln Geschäftsdaten. Die Geschäftspro-zesse umspannen heute meist mehrere Anwendungssysteme, welche wir in dieKategorien operative Systeme, analytische Systeme und Planungssysteme einteilenkönnen. Sie ergeben zusammen die Systemlandschaft eines Unternehmens undmüssen miteinander integriert werden. Auch zwischenbetriebliche Integration istfür Unternehmen wichtig. Integration ist auf den Ebenen der Geschäftsprozesse,-objekte und -daten möglich. Sie werden unterstützt von den Geschäftsschnitt-stellen, welche die Anwendungssysteme anbieten. Bei den Anwendungssystemenhandelt es sich um Standardsoftware, die an die Unternehmensbedürfnisse an-gepasst werden muss. In all diesen Bereichen haben sich spezifische Technikenherausgebildet.

Somit haben wir uns in diesem Buch vor allem den gegenwärtigen Stand derTechnologie von Unternehmenssoftware angesehen, also das „Sein“. Wir könnten

1 Beckett S (1974) Endspiel. Suhrkamp Taschenbuch 171, erste Auflage 1974, Frankfurt a. M.,S. 57.

331R. Weber, Technologie von Unternehmenssoftware, DOI 10.1007/978-3-642-24423-0_16,© Springer-Verlag Berlin Heidelberg 2012

332 16 Zusammenfassung und Ausblick

uns nun fragen, wie wir uns Unternehmenssoftware wünschten und dies mit demSein abgleichen. Aus meiner Sicht sieht es wie folgt aus:

16.1.1 Preisgünstig

Ein Anwenderunternehmen hätte gerne eine preisgünstige Software, was für Stan-dardsoftware spricht. Zum Tragen kommen die Gesamtkosten (Total Cost of Ow-nership, TCO), insbesondere die Einführungskosten, aber auch die Wartungskosten,welche bei Individualsoftware als höher eingeschätzt werden. Die Einführungs-kosten können hoch sein, ebenso das Projektrisiko. Beides lässt sich durch einfachmännisches Einführungsprojekt möglichst gering halten. Auch die Kosten desWechsels zu einem anderen Anbieter (s. u.) wären einzubeziehen.

16.1.2 Änderungen berücksichtigen

Die Unternehmenssoftware soll die aktuellen Geschäftsprozesse gut unterstützenund bei Bedarf verbessern lassen, z. B. wenn ein Produkt durch wirtschaftlichenDruck schneller auf den Markt gebracht werden muss (s. u.: unternehmensspezi-fische Prozesse). Zwangsläufige Änderungen, z. B. aufgrund gesetzlicher Ände-rungen, sollen automatisch integriert werden, was wiederum für Standardsoftwarespricht. Änderungen, z. B. die Fusion von Unternehmen, sollte sich schnell in derUnternehmenssoftware berücksichtigen lassen. Dies ist bei heutigen heterogenenSystemen nicht so einfach möglich (s. u.: Wechselmöglichkeit).

16.1.3 Standardprozesse ohne Aufwand

Standardprozesse, welche für viele Unternehmen, zumindest einer Branche, gleichablaufen, sollen unmittelbar in der Standardsoftware verwendbar sein. Anpassungs-aufwand sollte nur anfallen, wenn das Unternehmen von der Regel abweicht.

16.1.4 Unternehmensspezifische Prozesse

Das Unternehmen soll darüber hinaus die Möglichkeit haben, unternehmensspezifi-sche Prozesse dort individuell zu gestalten, wo ein Unterschied zu den Konkurren-ten besteht. Darin soll aber möglichst viel vorhandene Funktionalität integrierbar

16.1 Sein und Wunsch 333

sein – also keine Individualentwicklung, sondern eher eine Individualkonfigurati-on. Das Problem erscheint mir heute noch nicht gut gelöst. Workflow-Systeme undSOA versprechen hier zu helfen, aber zumindest ist der Aufwand heute noch höherals gewünscht.

16.1.5 Verschiedene Anwendungssysteme und damit Integration

Dass die Geschäftsobjekte, -daten und -prozesse verschiedene Anwendungssystemeinvolvieren und damit Integrationsaufwand entsteht, ist in erster Linie kein Interessedes Anwenderunternehmens. Das Unternehmen interessiert, dass die Funktiona-lität erbracht wird, wie die Aufteilung funktional geschieht, kann ihm egal sein.Oder weniger als egal, wenn man Aufwand und Reibungsverluste durch Integrationberücksichtigt. In ähnlicher Weise ist die Aufteilung in operative und analytischeSysteme zu sehen, welche organisatorisch (es gibt im „Sein“ viele Datenquellen)und technisch (Performanz) motiviert ist. Der Kauf verschiedener Systeme kannaber sehr wohl durch Kosten motiviert sein – wenn zwei kleine Systeme günsti-ger als ein größeres sind. Der heutige Stand sind allerdings mehrere Systeme ineiner Systemlandschaft, mit entsprechendem Integrationsaufwand. Verbunden da-mit ist, dass meist konzeptuelle Geschäftsobjekte zerstückelt sind, z. B. Teile derKundendaten im ERP-System, andere im CRM-System. Wünscht man einheitliche,systemübergreifende Methoden, wären diese mit Aufwand zu erstellen.

16.1.6 Wechselmöglichkeit

Für ein Unternehmen wäre es vorteilhaft, wenn es den Wechsel auf ein anderesProdukt ohne großen Aufwand vollziehen könnte. Ähnlich wie man den Telefonan-bieter dauerhaft oder sogar von Anruf zu Anruf wechseln kann, was bei einemdermaßen standardisierten Dienst natürlich einfacher ist. Hierfür sind „Standards“erforderlich. Der Begriff „Standardsoftware“ erklärt sich dagegen als Unterschiedzur Individualsoftware. Standardisiert sind nur kleinere Teilmengen der Funktiona-lität, z. B. gewissen Schnittstellenformate. Für den Umzug wäre also zumindest einStandardformat für den Abzug von Geschäftsdaten erforderlich, und die Geschäfts-objekte in Quell- und Zielsystem dürften sich auf Typebene nicht unterscheiden.Zudem müssten implizite und explizite Geschäftsprozesse kompatibel sein. VomWunschzustand sind wir hier also weit entfernt.

334 16 Zusammenfassung und Ausblick

16.1.7 Qualität

Selten in der Literatur oder in Produktbroschüren angesprochen, wo hauptsächlichüber die Funktionalität geschrieben wird: Die Software sollte eine gute Qualitäthaben. Nicht die Reichhaltigkeit der Funktionalität sollte alleinbestimmend sein,sondern die Güte, mit der sie erbracht wird. Dies betrifft nicht nur die Software,sondern auch die damit verbundenen Dienstleistungen. Bei vielen Gütern, insbe-sondere Konsumgütern, erleben wir, dass die Qualität im Zeitablauf nachlässt. Soft-ware erreicht große Technologie- und Funktionalitätssprünge, aber die Qualität hältnach meiner Einschätzung nicht mit. Bessere Qualität wäre durch sorgfältigere Ent-wicklung, insbesondere umfangreichere Tests möglich, aber mit höherem Aufwandund damit Kosten verbunden. Die Beobachtung zeigt, dass sich die vorhandenePreis-Qualitätskombination am Markt behauptet. Aus meiner Sicht könnte eine Ge-samtkostenbetrachtung hier ein anderes Bild ergeben, beim Softwareanbieter wiebeim Anwenderunternehmen. Beim Softwareanbieter entsteht durch geringere Qua-lität Aufwand beim Service (s. Abschn. 15.3). Aus dem Software-Engineering istbekannt, dass spät entdeckte Fehler besonders teuer sind. Bei Standardsoftwarebetrifft dies Korrekturen in verschiedenen Softwareversionen. Beim Anwenderun-ternehmen fällt Problembearbeitungsaufwand natürlich ebenso an. Eine besondereDimension bekommen Qualitätsmängel, wenn zwei Produkte interagieren sollen,die Produkte natürlich wenig für die vielfältigen Kombinationsmöglichkeiten inte-grationsgetestet sind, und die Verantwortlichkeit für das Problem nicht klar demeinen oder anderen Produkt zuordenbar ist. Oder wenn durch die Integration eindrittes Produkt betroffen ist, was sich aber erst aus einer langen Analyse ergibt.Mit anderen Worten: Gerade bei der sowieso schon aufwändigen Integration sindQualitätsmängel noch zusätzlich erschwerend.

16.1.8 Verlässliche Beziehung zum Softwareanbieter

Gerade weil ein Wechsel zu einem anderen Softwareanbieter eben doch nicht soeinfach ist, ist eine verlässliche Beziehung wünschenswert. Dies beinhaltet, dassdie Preise, z. B. für Wartung oder Folgeversionen, im Rahmen bleiben, dass sich dieQualität der Software nicht verschlechtert, dass die Software langfristigen Bestandhat.

Die Wünsche und Ziele von Softwareanbietern und Beratungsunternehmen da-gegen decken sich natürlich nur zum Teil mit den Anwenderwünschen. Softwa-reanbietern liegt an einem großen Marktanteil. Bei Großunternehmen teilen sichdie großen Anbieter SAP und Oracle den Markt weitgehend, bei mittelgroßen undkleineren Unternehmen gibt es eine viel größere Anzahl von Softwareanbietern. Dadas Wachstum für die großen Anbieter bei Großunternehmen beschränkt ist, wer-den Wachstumsmöglichkeiten im Mittelstand gesehen. Ein Beispiel ist das Produkt

16.2 Konzepte 335

SAP Business ByDesign. Und wie in allen Branchen besteht das Interesse, Kundenzu halten.

16.2 Konzepte

Es geht die Rede, dass die Beschäftigung mit abstrakten Dingen das Denken schu-le, unabhängig vom konkreten Untersuchungsgegenstand. In diesem Buch ist eseher der gegenläufige Ansatz: es spricht über konkrete Dinge, und uns interes-sieren daraus abgeleitete abstrakte Konzepte. In der Informatik, genauer in derSoftwaretechnik, wird das Thema unter dem Begriff Muster (Pattern) behandelt:Entwurfsmuster, Architekturmuster. Mein Ziel ist nicht eine Formalisierung derKonzepte/Muster. Ich denke, es ist bereits hilfreich, die Muster am Beispiel zu ver-deutlichen. In diesem Sinne werden im Buch angesprochene Konzepte aufgelistet,mit einem Verweis, bei welchem Thema und Kapitel sie angesprochen wurden. DieHoffnung ist, dass das beispielhafte Lernen eines Konzepts einen nachhaltigen Ef-fekt hat.

Konzept Inhalt/Zweck Thema Kapitel

Asynchrone vs.synchrone Kommu-nikation

Engere oder losereKopplung zwischenKommunikationspart-nern

NachrichtenorientierteIntegration

11

Bring-Schuld (Push)vs. Hol-Schuld(Pull)

Steuerung der Informa-tionsübermittlung

Workflow-Management,SCM-Datenaustausch

12, 5, 9

Datentransformation Abbildung von einemQuell- auf ein Zielfor-mat

XML, XSLT, ETL,Nachrichten-Broker, Alt-datenübernahme

9, 4, 11,13

Datenübertragungzum Datenabgleich

Trennung in Initial-übertragung undÄnderungsübertragungzur Aufwandsreduktion

ETL, Planungssysteme 4, 5

Datenverdichtung Konzentration auf dasWesentliche

DWH 4

Definitions- vs.Laufzeit

Auswirkung derFestlegungen zur De-finitionszeit auf dieLaufzeit kennen; Abwä-gung, welche Schrittezu welcher Zeit stattfin-den sollen

Web-Services, ge-schäftsprozessorientierteIntegration

10, 12

336 16 Zusammenfassung und Ausblick

Konzept Inhalt/Zweck Thema Kapitel

Dynamischer Funk-tionsaufruf

Generisch Funktionenbereitstellen

BAdI, SAP Records Ma-nagement, Web-Service

14, 10

Flaschenhals Performanzengpass Client-Server-Systeme 3

Indirektion Änderungsfreundlich-keit

Systemlandschaft, ab-strakter Bearbeiter

6, 2

Hierarchiebildung Strukturierung, zurÜbersichtlichkeit undeinfachen Verarbeitung

XML, DWH 9, 4

Kapselung Zusammenfassung zueinem „Ding“

Geschäftsobjekte 2

Kopieren vs. Refe-renzieren

Änderungsfreundlich-keit

ID eines Geschäftsobjekts,Referenzdaten

2

Namensraum Namen eindeutig ma-chen

Namensraum in XML,Eigenentwicklung

9, 14

Parallelisierung Leistungssteigerungdurch kürzere Durch-laufzeit

Geschäftsprozesse, DWH(Partitionierung, Domä-nen), Client/Server

2, 4, 3

Veröffentlichen undAbonnieren

Flexibles Koppeln vonSendern und Empfän-gern

NachrichtenorientierteIntegration

11

Replikation Ausfallsicherheit Client-Server-Systeme 3

Schichtenbildung Beherrschung der Kom-plexität

Dreistufige Client-Server-Architektur

3

Schnittstellenbil-dung

Funktionale Dekom-position, Flexibilität,Änderungsfreundlich-keit

Geschäftsobjekte, WSDL 2, 10

Single Point ofFailure

Kritische Stelle bzgl.Ausfallsicherheit

Client-Server-Systeme 3

Skalierung Performanzsteigerung Client-Server-Systeme 3

Speicher- vs. Re-chenperformanz

Abgeleitete Informationspeichern oder jedesmal neu berechnen

Data Warehouse Systeme 4

Speicherhierarchie Kosten und Zugriffs-geschwindigkeitverbessern

DWH, persistenteObjekte, Haupt-speicherdatenbank,Tabellenpufferung, Ar-chivierung

4, 2, 15

Standardisierung Vereinfachung des Zu-sammenwirkens vonKomponenten

XML, Web-Service 9, 10

Typ vs. Instanz Schematische Be-schreibung undSyntaxprüfung (Feh-lervermeidung zurLaufzeit)

XML Schema, Geschäfts-objekte

9, 2

16.2 Konzepte 337

Konzept Inhalt/Zweck Thema Kapitel

Vor die Klammerziehen

In Analogie zum Dis-tributivgesetz in derMathematik: (a * b) +(a * c) = a * (b + c). ZurRedundanzfreiheit undÜbersichtlichkeit

Client-Server-Systeme,Kopf- und Positionen

3, 2

Virtualisierung U. a. leichtere Hand-habung, ähnlichSchnittstellenbildung

Client-Server-Systeme,Geschäftsobjekte, Cloud-Computing, DWH

3, 2, 6, 4

Ende, es ist zu Ende,es geht zu Ende,

es geht vielleicht zu Ende.Pause.

Ein Körnchen kommt zum anderen,eins nach dem anderen,

und eines Tages, plötzlich, ist es ein Haufen,ein kleiner Haufen,

der unmögliche Haufen.Endspiel

Samuel Beckett2

2 Beckett S (1974) Endspiel. Suhrkamp Taschenbuch 171, erste Auflage 1974, Frankfurt a. M.,S. 11.