Massive Konsequenzen für die Business-Anwendungen sieht man bei der SAP. „Wir haben in den vergangenen Jahren viel gelernt – ein System muss grundsätzlich für die Cloud entwickelt worden sein“, so artikuliert Christian Horak, Vice President Cloud Marketing bei der SAP AG, seine Erfahrungen.

„Ein Anwender will Anpassungen haben – eine hundertprozentige Standardisierung der SaaS-Software ist daher nicht machbar. Allerdings sind immer bestimmte Grenzen zu berücksichtigen.“ Dabei lautet seiner Meinung nach der geeignete Ansatz „Business Konfiguration“ – dabei tritt das Konfigurieren an die Stelle des Programmierens und „Customizings“.

Business Konfiguration löst Customizing ab

Als Beispiele für eine Standardisierung nennt Horak etwa das Festlegen der Accounting-Standards – ob die Bilanzierung nach US Gaap oder nach anderen Modellen erfolgen muss. Nicht nur die Software selbst, auch das Einführungskonzept sollte passen, so lautet die Überzeugung von Frank Siewert, Director Presales Consultat bei der Comarch Software und Beratung AG: „Wir haben beim Einführungsprozess von Business-Software neben dem klassischen einen weiteren Ansatz gefunden.  Bisher lautete die übliche Vorgehensweise, Lasten-/Pflichtenhefte beziehungsweise Einsatzanalysen zu definieren und dann
diese umfangreiche Liste komplett abzuarbeiten.“

SCRUM vereinfacht die ERP-Einführung

Doch mittlerweile setze man auch das aus der Software-Entwicklung her bekannte SCRUM-Vorgehensmodell in ERP-Realisierungsprojekten ein. Dieses Verfahren verspricht laut Siewert große Vorteile: „Es lässt sich durch die Attribute  empirisch, inkrementell und iterativ beschreiben – und führt dazu, dass durch die agile Einführungsmethode sich die ERP-Einführungsprojekte in aller Regel kostengünstiger realisieren lassen. Vor allem gelingt es uns mit dieser Methodik immer, die Projekte in den jeweils vorgegebenen Zeiträumen einzuführen.“

Der eigentliche Mehrwert in einem Unternehmen findet sich in den Geschäftsprozessen wieder – diese Meinung vertritt Sascha Köhler, Software Architekt bei PROFI Engineering: „In den bestehenden Systemen sind diese speziellen Ansätze bereits  implementiert – alles wird sich nicht mitnehmen lassen, auch wenn man die Software-Entwicklung für Cloud-Anwendungen ändert. Teilansätze werden funktionieren, aber es werden immer noch Altsysteme wie System z zum Einsatz kommen.“

Eher kritisch gegenüber den Best Practices beim Einsatz von Standardsoftware zeigt sich Ralf Adebar: „Wir haben in unseren Projekten aus den Best Practices den Schritt zu den ‚Best Suggestions‘ gemacht. Denn Anpassungen sind praktisch immer nötig – Unternehmen wollen ihre Besonderheiten abgebildet sehen. Dazu müssen wir auch beim Software-Bezug aus der Cloud beraten und Vorschläge für gute Umsetzung liefern. Hier empfiehlt sich zu zeigen, was andere gut gemacht haben.“

Automatisierung der Abläufe

Für Kurt Rindle, Cloud Portfolio Leader bei IBM, ist das dagegen nur ein erster Schritt: „IT ist das Rückgrat eines Unternehmens. Doch die Automatisierung der Abläufe ist dabei wichtig.  Das kann bei umfangreicher Business Software der Fall sein oder aber auch bei kleinen  Modulen, die ganz spezielle Aufgaben lösen.“ Daher sieht der IBM-Experte die Business Software aus der Cloud als einen Übergangsschritt. „Das Programmiermodell muss sich  extrem verändern, hin zum Dev-Ops Modell – also Development und Operations. Die Frage wird künftig lauten: ‚Wie entwickle ich die Software und wie bringe ich sie zum Anwender‘ – hier sind neuartige Ansätze gefragt.“

Daraus ergebe sich dann eine Änderung an die darunter liegenden Architekturen: So soll zum
Beispiel das Programmieren von extrem parallelen Applikationen eine sehr hohe Priorität  bekommen. „Das sind die größeren Herausforderungen; Unternehmen sollten sich besser auf diese Fragen einlassen“, empfiehlt Rindle.

Software muss für die Cloud entwickelt sein

Zustimmung für die Gedanken des SAP-Managers Horak gibt es von Michael Korbacher: „Software muss definitiv für die Cloud entwickelt werden – die ‚Google Software‘ ist förmlich in der Cloud geboren. Wer noch traditionelle Software aus dem ‚On Premise Einsatz‘ in die Cloud überführen will, der verlegt nur die heutigen Probleme in die Cloud. Dann gibt es am Wochenende wieder die Ausfallzeit aufgrund einer Systemaktualisierung. Dann sind nach wie Problem zu klären ,wie ‚passt das Frontend‘, ‚setzt der Anwender die richtige Office-Lösung ein‘ – all das sollte im Cloud-Modell nicht mehr nötig sein.

Dem kann sich Andre Kiehne, Vice President Cloud Business bei Fujitsu Technology Solutions, nicht anschließen. Nach seiner Einschätzung lässt sich die ‚Cloud-Fähigkeit‘ auch für die bestehende Software hinbekommen: „Dazu gibt es bei Fujitsu den ‚Cloud Store‘ und das zugehörige Software-Framework. Es erlaubt einem unabhängigen Software-Hersteller, sein
Software-Angebot Cloud-fähig zu machen.“ Das werde nur der erste Schritt sein, denn damit sei die Software noch nicht vollkommen skalierbar, dazu müsse man die Applikation selbst noch modifizieren – und das gehe bis hin zum Datenmodell.

Datenmodell wird geändert

„Irgendwann wird man seiner bestehenden Software noch sagen müssen, dass sie auf ein anderes Datenmodell zugreifen muss“, ist Kiehne überzeugt. „Für viele Unternehmen ist  allerdings auch ein ‚Mix and Match‘-Ansatz nötig – sprich nicht alles wird man aus der Cloud holen, es werden einige Bestandteile nach wie vor auf den bestehenden Systemen im eigenen Haus zum Einsatz kommen.“ Dabei gelte es Liefermodelle zu mischen – und dabei
werde ein eigener ‚Enterprise Appstore‘ wichtig. „So lässt sich die Frage beantworten, ‚wie bekomme ich alle Applikationen zum Endgerät – egal auf welcher Plattform‘.“

Künftig erwartet Kiehne eine Personal Cloud, also eine komplette Web-basierte Desktop-Umgebung, die jede Applikation – egal ob Altanwendung oder App – jedem Benutzer auf seinem Endgerät zur Verfügung stellt.

Aus der Sicht von Comarch setzt sich die ‚Cloud-Software‘ durch. „Software muss Cloud-fähig sein und für die Cloud geschrieben sein – lässt sich dann aber auch im traditionellen Modell ‚On Premise‘ einsetzen“, bringt es Siewert auf den Punkt. Als Vorteile nennt er vor allem die Skalierbarkeit, wie es etwa bei Zalando zu sehen ist.

Dynamische Konfigurierbarkeit ist gefragt

„Standardisierte Prozesse im SaaS-Bereich gibt es nicht, die Software muss in weiten Bereichen adaptierbar sein“, dieses Credo vertritt Ditmar Tybussek. „Unser Ansatz lautet: Programme stürzen mal ab, also machen wir keine üblichen Programme mehr. Bei uns gibt es sozusagen nur mehr einzelne Links, über die wir dann dynamisch konfigurieren, wenn klar ist, für welches Endgerät und für welche Umgebung die Software passen soll.
Aber auch Parameter wie die notwendige Sprachunterstützung, welche Formen die Masken haben sollen, welche Prozesse zu unterstützen sind – all das fließt hier zusammen. Erst dann wird die Anwendung ‚neu‘ erstellt. Jedes entstehende Modul hat dann auch gleich einen Customizing-Button, um die Felder selbst zu bestimmen. Mit einer traditionellen Client-Server-Technologie kommt man da nicht weit. Wenn etwas kompiliert ist, lässt sich das nicht dynamisch umbauen. Damit kann die Anwendungssoftware zum Beispiel an die Abrechnungsmodelle leicht angepasst werden.“ Eine Standardisierung sieht Tybussek nur für fest definierte Module, wie etwa einen Edifact-Konverter.

Die Konzentration auf die End-to-End-Geschäftsprozesse predigt Horak. „Der Dienstleister nimmt dem Anwender immer mehr Technikdetails ab. Er braucht sich nicht mehr um die Hardware kümmern, das Betriebssystem ist egal. Interessant wird dagegen die ‚Bezahlbarkeit‘ einer Lösung – brauche ich Berater oder kann ich das selbst leisten.“

Für  Horak geht die Wertschöpfung im Unternehmen klar in Richtung Prozess-Know-how. Doch diese Prozessorientierung sei immer im Kontext des Mitarbeiters zu sehen: „Ich benötige  nicht jeden Tag einen Quartalsabschluss, sondern nur alle drei Monate. Ich brauche aber jeden Tag die passenden Performance-Indikatoren über die kompletten Prozesse: Der Vertriebsmitarbeiter muss den Überblick über seine Pipeline und die Abschlussraten haben, im Herstellungsprozess geht es um die Qualität und die Ausfallraten – sprich jede Rolle benötigt andere Key Performance Indikatoren – und zwar tagesgenau.
Das muss die Software bieten – doch das geht nur, wenn die transaktionalen Systeme und die Entscheidungsunterstützungssysteme nicht mehr getrennt  agieren. Das ist heutzutage auch für Mittelständler machbar – so lautet das Versprechen einer Cloud-Lösung.“

Rainer Huttenloher