Gerade eben habe ich in der Computer Woche einen Artikel mit dem Thema „Sind ERP-Systeme für das Business zu langsam?“ gelesen und dort einen interessanten Begriff entdeckt: Agile Enterprise. Immerhin formuliert von einem Partner und Leiter der Management Beratung bei Ernst & Young.
Da wir uns starkt mit agiler Software Entwicklung beschäftigen, habe ich mich gefragt, was ein „Agiles Unternehmen“ ausmacht. Also habe ich mal Google befragt und ein wenig nachgelesen. Eine gute Zusammenfassung findet man bei Business Dictionary:
Fast moving, flexible and robust firm capable of rapid response to unexpected challenges, events, and opportunities. Built on policies and processes that facilitate speed and change, it aims to achieve continuous competitive advantage in serving its customers. Agile enterprises use diffused authority and flat organizational structure to speed up information flows among different departments, and develop close, trust-based relationships with their customers and suppliers.
Grundsätzlich zusammengefasst sind „Agile Unternehmen“ also die Unternehmen, die besonders schnell und flexibel auf sich ändernde Marktbedingungen reagieren können. In den meisten Artikeln, die ich gefunden habe werden Selbstorganisation und Interaktion zwischen Mitarbeitern und Abteilungen als Basis für agile Unternehmen gesehen. Aber was bedeutet das jetzt für die IT?
Aber zurück zum Artikel. Es geht um große ERP Systeme und das die meisten Unternehmen Schwierigkeiten haben auf die steigende Flexibilität und Geschwindigkeit des Business zu reagieren. Grund sind die hohe Komplexität der Systeme, teilweise schlechte Produktqualität, ein hohes Maß an Customizing an des Systemen und teilweise auch das Alter dieser Monolithen. Bleibt die Aussage: „ERP bremst Business!„.
Soweit so gut, viele der Aussagen sind bis dahing für mich durchaus nachvollziehbar und sehen wir auch täglich in unseren Projekten. Nicht nur bei ERP Systemen, sondern bei vielen Standardsoftware „Monstern“ – beispielsweise auch im Bereich der Versicherungskernsysteme. Ich habe mich immer gefragt, warum man zunächst viele Millionen in Lizenzkosten investiert, dann merkt, dass der „Standard“ eigentlich nicht zu den eigenen Prozessen passt und man nur 20% der Funktionen benötigt. Deshalb führt man auch erst mal ein mehrjähriges Customizing Projekt durch. Meistens hat man die Software danach soweit angepasst, das sie nicht mehr Release fähig ist oder jedes Upgrade wieder mit hohen Anpassungsaufwänden verbunden ist. Aber das beste kommt noch: ca. 20% muss man jedes Jahr für die Wartung der Standard Software zahlen – sprich: Alle 5 Jahre hat man die Software noch mal gekauft.
Leider liefert der Artikel nicht wirklich interessante Lösungsszenarien. Zunächst wird bemängelt, dass die Strategien der ERP Hersteller die großen Versprechen von SOA nicht gehalten haben – insbesondere, weil die SOA von den Herstellern fast ausschließlich technisch betrachtet wurden.
Eine mögliche Lösung wird in der Cloud und in Software as a Service gesehen – da hat mich der Artikel dann auch entgültig abgehangen. Wenn ich also mein „Monster“ nicht mehr selber betreibe, sondern in der „Wolke“, dann sind meine Business Probleme weg und ich bin auf einmal flexibel und schnell!? Da scheinen einige der der Experten doch eher im „Nebel“ zu stehen.
Da ich mich seit einigen Wochen damit beschäftige das „Why“ für unsere Agile Software Factory zu finden, hat mir dieser Artikel wirklich sehr geholfen.
Aus meiner Sicht liegt die Lösung für das Problem doch klar auf der Hand:
Wenn Agile Enterprise heißt, dass mann innovativ sein (First Mover ) und schnell reagieren (Fast Follower) muss, dann kann die Lösung doch nicht in „Standard“ und „Monolithen“ liegen. Standard ist definitiv nicht innovativ und Monolithen sind in der Regel komplex und wenig flexibel anzupassen.
Aus meiner Sicht muss man bei der Umsetzung der Geschäftsprozesse auf individuelle Software setzen. Die genutzten Komponenten können aber sehr wohl Standard sein. Was ich damit meine ist, dass ich niemandem empfehlen würde eine Buchhaltungssoftware inidividuell selber zu bauen – hier ist durch gesetzliche Vorgaben etc. wenig Innovation und Individualität zu erwarten. Allerdings können sich die Prozesse rund um die Buchhaltung sehr wohl stark unterscheiden und zu einem Wettbewerbsvortei werden. Kunden können über Web und Mobile direkt eingebunden werden, Geschäftsvorfälle können automatisiert werden und andere, eigene Systeme können sich direkt integrieren. Insbesondere kann man „Insellösungen“ vermeiden und dem Benutzer eine einheitliche Oberfläche und schnelle Bearbeitung in einem System anbieten.
Um schnell und flexibel zu sein, mit unbekannten Anforderungen umgehen zu können und das Risiko von inidividueller Entwicklung zu reduzieren, muss man auf agile Vorgehensweisen setzen. Mit schwerfälligen Wasserfallmethoden und Projekten mit Laufzeiten von mehreren Monaten oder Jahren bis man dem Business etwas Lauffähiges anbieten kann, wird man heute nicht mehr konkurrenzfähig sein.
Genau das ist unsere Agile Software Factory: Ein etablierters Vorgehensmodell auf Basis von Scrum und XP mit vielen Best Practices („Agile“) und dem Einsatz von standardisierten Komponenten und Frameworks („Factory“).
Bei den Komponeten setzen wir meistens auf Open Source, da die verwendeten Standards und offene Quellen zu einer verbesserten Integrierbarkeit und schnelleren Entwicklung führen – zudem ist man weniger von der „Politik“ einzelner Hersteller abhängig. Alfresco im Bereich ECM, Pentaho für Business Intelligence, Liferay als Portal Lösung, OpenCms als CMS oder Compiere im Bereich ERP und CRM sind nur Beispiele für Open Source Komponenten, die wir in die Anwendungen unserer Kunden integrieren. Die individuellen Prozesse und Anwendungen werden dabei auch auf Basis von etablierten Best Practices mit Open Source Frameworks wie Spring , Hibernate , Drools , jBpm oder Mule entwickelt. Immer auf Basis leichtgewichtiger, evolutionärer Architekturen!
Die agile Vorgehensweise sorgt dafür, dass das Business alle 2-4 Wochen neue und benötigte Funktionen zur Verfügung gestellt bekommt – und das in hoher Qualität durch automatisierte Unit-, Regressions- und Systemtest, sowie kontinuierlicher Integration, Pair-Programming und automatisierter Code- und Designüberprüfungen.
Mein Fazit: Wenn wir als IT auf sich schneller ändernde Business Anforderungen reagieren wollen („Agile Enterprise“), dann müssen wir uns von großen „Standardsoftware Mostern“ und langlaufenden Projekten trennen. Die Lösung für mich sind agile Projekte – allerdings auf Basis von standardisierten Anwendungsbausteinen und Frameworks.
War dieser Beitrag hilfreich?
Weitere Beiträge
von Mirko Novakovic
21.2.2014 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Weitere Artikel in diesem Themenbereich
Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Mirko Novakovic
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.