Montag, 7. Februar 2011

Standard Software ist nicht gleich Standardisierung!

Liebe Leser!

Im Jänner besuchte ich ein Cloud Computing Event eines namhaften Beraters - eine durchaus interessante Mischung von Vorträgen zu diesem interessanten Hype-Thema. Ein Punkt hat mich dann aber doch sehr gestört. Ein Berater hat die Top 5 Punkte präsentiert, die in Zusammenhang mit einer Migration in die Cloud wichtig sind.

Der erste Punkt der Aufzählung war "Standardisierung". Und als Maßnahme, um diese zu erreichen, fand sich auf der Folie der Vorschlag, Standard Software einzusetzen, und der Berater riet ergo dazu, keine Eigenentwicklungen mehr durchzuführen.

"Schön!" denkt man sich nun reflexartig als IT Verantwortlicher - viele dieser Projekte sind ohnehin nicht reibungslos gelaufen, sparen wir uns das in Zukunft und geben Standardprodukten "aus der Schachtel" den Vorzug.

"Halt!" sage ich als Hersteller von Individualsoftware. Warum?

  1. Was bitte, hat Standard Software mit Standardisierung zu tun, außer vorerst einmal das gemeinsam benutzte Wort "Standard". Gerade große, monolithische Standard-Software-Produkte können es sich leisten, Standards eben nicht oder nicht sofort umzusetzen, und wenn, dann mit herstellerspezifischen, proprietären Ausnahmen, die der verbesserten Effizienz dienen sollen. Als Entwickler einer individuellen Lösung kann ich es mir oft gar nicht leisten, nicht konform zu den letzten Standards zu sein.
  2. Die Integration von Standardprodukten treibt vielen IT Verantwortlichen die Schweißperlen auf die Stirn - wo es bei vielen Eigenentwicklungen eine Sache von Stunden bzw. Tagen ist, eine neue Schnittstelle umzusetzen und in Produktion zu bringen, kann es bei einem Standardprodukt lauten "Kommt mit Release x.y Mitte nächsten Jahres".
  3. Wie kann ich mich, als Unternehmen, mit innovativen Prozessen und Produkten vom Markt unterscheiden, wenn ich nur Standardprodukte einsetze? Natürlich erlauben es moderne Prozesssteuerungs-Tools, individuelle Prozesse umzusetzen, jedoch liegt die Unterscheidung zum Mitbewerb immer auch in innovativer fachlicher Logik. Diese Innovation bedingt aber zu einem gewissen Grad, Business Logik in Technologie zu gießen - und zwar als "Eigenentwicklung".
Diese Punkte führe ich im Kampf um das Alleinstellungsmerkmal "Eigenentwicklung" an (und habe noch mehr in der Hinterhand). 

Scheinbar entbrennt ein Kampf Standardisierung versus Flexibilität. Am vorjährigen Oracle Day hat ein Top Berater eines anderen großen Beratungsunternehmens den anwesenden Entscheidern in selber Manier geraten, nur mehr Srandardprodukte einzusetzen und diese nicht einmal mehr zu groß anzupassen. Warum? Damit man Versionsupgrades reibungsfrei durchführen kann. Viele Kunden zahlen nämlich jährlich hohe Supportkosten, können dann aber nicht auf die neueste Produktversion umsteigen, weil die vielen individuellen Anpassungen genau das verhindern.

Standard Software ist ohne Zweifel Bestandteil jeder funktionierenden und kosteneffizienten IT. Aber Standardisierung bedeutet meines Erachtens, die Voraussetzungen für Integration und Flexibilität zu schaffen, um die innovativsten und produktivsten Prozesse unterstützen zu können, die zum Wohl des Unternehmens umsetzbar sind. Und in diesem Kontinuum hat Eigenentwicklung aus meiner Sicht nach wie vor seinen Platz.

Ob der - von anderer Seite vorgeschlagene - Verzicht auf jegliche Eigenentwicklung uns den entscheidenden Schritt in Richtung Service Orientierung und Prozessketten Chaining, Cloud, IT als Commodity und IT Industrialisierung voranschreiten lässt, überlasse ich, geschätzte Leser, Eurer werten Einschätzung. 

Ich habe meinen Standpunkt klar gemacht.

Euer 
JWR@coopXarch.