07 Jul CONSALTENT – Tausendsassa im IT-Business
Kennen Sie das auch? Als SAP-Anwender stehen Sie oft vor der Aufgabe Geschäftsprozesse sowohl optimieren als auch neue etablieren zu müssen. Bestenfalls wird dabei auf das Know How eines kompetenten Beraters zurückgegriffen, um gemeinsam die Anforderungen auszuarbeiten. Der Berater überlegt sich eine technische Lösung; dabei versucht er so viele Anforderungen wie möglich durch Customizing des Systems zu erfüllen. Sobald die technischen Möglichkeiten des Beraters ausgeschöpft sind, werden Aufgabenpakete für Entwickler erstellt. Der Entwickler gießt die Gedanken des Beraters möglichst genau so in Code. Nur noch implementieren und die Anwendung produktiv nehmen. Schön wär´s, wenn damit alles schon inhaltlich, technisch und wirtschaftlich zufriedenstellend gelöst ist.
Nicht selten aber ist der Ablauf von längeren Entwicklungszeiten durch Verwaltungs- und Kommunikations-Schleifen sowie zahlreichen Workarounds gekennzeichnet. Auch ist das Phänomen erheblicher Abweichungen zwischen Funktionsumfang der gelieferten Lösung und tatsächlichem Bedarf hinlänglich bekannt. Ob dem Anwender durch diese Vorgehensweise wirklich geholfen ist und – ob es dafür keine Alternative gibt – haben wir hinterfragt. Auch Kundennutzen lässt sich deutlich steigern.
Die Aufrechterhaltung eines hauseigenen Teams aus Fachbereichsanwendern und das Outsourcing an SAP-Berater sowie Programmierer kostet in der Regel mehr als das Hinzuziehen spezialisierter CONSALTENTS.
Jedes Modell hat seine Vor- und Nachteile, und für kein Unternehmen gibt es die absolut perfekte Lösung. Wenn man jedoch die Faktoren kennt, auf die es hier ankommt, und entscheidet dann auf dieser Basis, kann dies signifikant Kosten reduzieren. Und das, ohne Kompromisse bei der Qualität eingehen zu müssen. Wir beleuchten hier einmal die Fallstricke der einzelnen Lösungsvarianten durch den Fachbereich selbst, durch einen internen oder externen Berater und durch Outsourcing an einen reinen SAP-Entwickler.
Fachbereich (Endanwender bzw. ein Repräsentant)
Endanwender verfügen oft über viel Wissen in der fachlichen Domäne, dagegen in den meisten Fällen kaum über das technisch erforderliche Verständnis oder haben eine geringe Vorstellung vom technisch Machbaren.
Interner Berater
Als „Interner“ verfügt man im Allgemeinen über ein besseres Verständnis für das Unternehmen und für seine individuellen Business-Prozesse, einschließlich seiner Fachsprache. Oft entstammt man selbst einem Fachbereich, hat aber keine programmiertechnische Ausbildung genossen. Dennoch entscheidet der interne Berater, wie die technische Lösung im Detail aussehen soll; der Entwickler wird dabei entweder zu spät in die Problemstellung einbezogen oder nur mit der programmiertechnischen Umsetzung beauftragt. Erschwerend kommt für den internen Berater hinzu, dass für ihn viele andere Aufgaben bestehen bleiben, während wenig Zeit bleibt die Umsetzung angemessen begleiten zu können.
Externer Berater
Das Unternehmen profitiert beim externen Consultant von dessen SAP-Know How, weil er bei den neuesten Technologien stets auf dem aktuellen Stand ist – schon allein deswegen, weil er Kunden gewinnen und behalten möchte. Sein Interesse ist also primär darauf ausgerichtet generell Lösungen zu verkaufen unabhängig davon, ob sie für den Kunden langfristig sinnvoll und wirtschaftlich sind. Zudem verfassen Berater ohne entsprechend langjährige und fundierte Erfahrung einfach nur technische Konzepte, ohne jenen Hintergrund zu kennen, wie etwas im Detail technisch umgesetzt werden soll. Auch gelten Konzepte oftmals als fix und sind dann schwer zu ändern, wenn sich herausstellt, dass sie Lücken letztendlich aufweisen.
SAP-Entwickler
Beim Entwickler verlässt sich der CIO auf das sowohl hohe analytische Denkvermögen als auch auf das tief gehende technische Verständnis dieses Spezialisten. Die Zielrichtung ist klar auf Programmierperformance ausgerichtet. Doch im Allgemeinen ist ein SAP-Entwickler nicht nahe genug am fachlichen Problem, so dass er kaum eine Chance hat zu prüfen, ob es für das Problem auch alternative Lösungen oder versteckte Möglichkeiten -z.B. innerhalb der Standard-Lösungen- gibt. Erfahrungsgemäß wird der Entwickler ohnehin sehr spät eingebunden. Der Beratungslogik folgend, setzt der Entwickler diejenige Lösung um, wie es vom Consultant beauftragt wurde und weniger danach, wie es für den Endanwender tatsächlich am Besten ist. Der SAP-Entwickler bleibt also auf das Wissen beschränkt, das er besitzt, und hat umgekehrt nicht hinreichend das Know-how, um die Business-Bedürfnisse der Nutzer zu erfüllen.
Der Ablauf von längeren Entwicklungszeiten ist durch Verwaltungs- und Kommunikations-Schleifen und zahlreichen Workarounds gekennzeichnet. zudem entstehen doppelte Personalkosten. Auch ist das Phänomen erheblicher Abweichungen zwischen Funktionsumfang der gelieferten Lösung und tatsächlichem Bedarf hinlänglich bekannt.
Identifizierte Problemfelder:
Technisches Wissen des Entwicklers wird bei der Suche nach der Lösung nicht berücksichtigt, d.h. technisch innovative Lösungen werden so von vornerein ausgeschlossen.
Umgekehrt werden vom Berater oft Lösungen konzipiert, die technisch problematisch umzusetzen sind, viel Support von Dritten erfordern bzw. schlecht wartungsfähig oder kaum erweiterbar sind, ganz zu schweigen, wenn sie kaum den Qualitätsmerkmalen nach ISO 9126 entsprechen dürften (https://de.wikipedia.org/wiki/Softwarequalität).
Es entsteht ein langer Kommunikationsweg, da die Kommunikation immer über den Berater läuft. Iterative Entwicklung mit regelmäßigen Feedback vom Fachbereich und eine Nachjustierung der Anforderung sind unter diesen Umständen nur sehr schwer möglich. Es hilft auch nicht mit Scrum, Agiler Softwareentwicklung oder ähnlichen Vorgehensmodellen auf diese Konstellation zu reagieren.
Oft wird bei der Umsetzung eine logische Inkonsistenz in der fachlichen Domäne festgestellt. Statt diese im Gespräch mit dem Fachbereich zu beheben und so gegebenenfalls Geschäftsprozesse konsistent zu machen bzw. zu optimieren, werden komplexe technische Workarounds erzeugt (technische Schulden), um die Inkonsistenzen einigermaßen in den Griff zu bekommen.
Ein implizites Aufräumen bzw. Zurückbauen von obsoleten Funktionalitäten ist kaum möglich, da nur der Fachbereich weiß welche Funktionen obsolet sind und nur der Entwickler, welche technischen Schulden existieren.
Consaltents sparen Zeit, Kosten und Nerven. Denn sie bündeln die Aufgaben des Beraters und Entwicklers in einer Rolle.
Vorteile:
Der CONSALTENT kennt die Domäne des Fachbereichs.
Der CONSALTENT verfügt sowohl über tiefes technisches als auch fachliches Wissen; somit ist es möglich die optimale Lösung für beide Seiten zu finden.
Der CONSALTENT setzt das Projekt von der Anforderungsanalyse bis zur Produktivsetzung um. Als Gesamtverantwortlicher ist es möglich eine insgesamt qualitative und integrierte Lösung zu entwickeln, die sehr nah an den wirklichen Bedürfnissen des Endanwenders liegt.
Der CONSALTENT kann schnell und gezielt auf Änderungswünsche reagieren, da keine Abstimmung über mehrere Ebenen der Entwicklung nötig ist.
Der CONSALTENT kann effizienter sowohl das Abbauen technischer Schulden, als auch das Zurückbauen obsoleter Funktionalitäten in den Entwicklungsprozess integrieren.
CONSALTUM setzt auf genau diese Eigenschaften. Und immer mehr Kunden wissen das zu schätzen.
Die Schwierigkeit besteht darin Personen zu finden, die dieser Rolle gewachsen sind, die sich sowohl in die fachliche Domäne des Endanwenders hineinversetzen können, als auch technisch so versiert sind, dass sie die Gesamtlösung entwickeln können. Neben fachlicher und methodischer Kompetenz sind vor allem entsprechende soziale Kompetenzen ein Must Have! Dies ist vor allem bei den klassischen Programmierern (noch) ein seltenes Gut.