Kaizen 2 go 032 : Agile Software-Beratung

 

Inhalt der Episode

  • Welche Herausforderungen haben Unternehmen oft bei der Beschaffung bzw. Auswahl von Software?
  • Was war zuerst da, Prozess oder Software?
  • Welche Rolle spielen agile Ansätze in der Software-Beratung?
  • Welche Vorteile bietet Open-Source für die Kunden?
  • Welche Vorbehalte ggü. Open-Source bestehen seitens der verschiedenen Stakeholder in den Unternehmen?

Notizen zur Episode

Ihnen hat der Inhalt gefallen? Dann bewerten Sie die Episode jetzt bitte bei Apple Podcasts.
Jetzt eintragen und Artikel/Denkanstöße zukünftig per eMail erhalten.

Artikel teilen auf ...

(Teil)automatisiertes Transkript

Eine KI-generierte Zusammenfassung finden Sie am Ende des Transkripts.

Episode 032 : Agile Software-Beratung

Herzlich willkommen zu dem Podcast für Lean Interessierte, die in ihren Organisationen die kontinuierliche Verbesserung der Geschäftsprozesse und Abläufe anstreben, um Nutzen zu steigern, Ressourcen-Verbrauch zu reduzieren und damit Freiräume für echte Wertschöpfung zu schaffen. Für mehr Erfolg durch Kunden- und Mitarbeiterzufriedenheit, höhere Produktivität durch mehr Effektivität und Effizienz. An den Maschinen, im Außendienst, in den Büros bis zur Chefetage.

Götz Müller: Im heutigen Gespräch mit Christian Dittrich geht es um agile Softwareberatung in der Praxis. Christian Dittrich ist der Geschäftsführer der Creatale GmbH in Ludwigsburg. Und ich begrüße Sie recht herzlich, Herr Dittrich, und möchte Ihnen einfach auch gleich das Wort geben, damit Sie sich selber kurz vorstellen.

Christian Dittrich: Ja, guten Abend. Vielen Dank, dass ich bei diesem Podcast dabei sein darf. Ich bin der Geschäftsführer der Firma Creatale. Wir sitzen in Ludwigsburg. Unser Thema ist agile Softwareberatung. Was verbirgt sich so ein bisschen dahinter? Ich denke, da werden wir dann später drauf eingehen. Für uns hat sich das Thema entwickelt quasi aus dem Studium heraus, aus dem Umgang mit agilen Softwareentwicklungsprozessen und auch einfach, weil wir gesehen haben, dass IT-Beratung, klassische IT-Beratung in der Praxis, den Kunden eher nicht hilft und wir eigentlich die Vorteile der agilen Entwicklungsprozesse in anderen Bereichen auch besser nutzen möchten. Das Studium habe ich hier in Stuttgart absolviert als Softwaretechniker. Das ist ein Informatikstudiengang mit Softwareengineering als Hauptschwerpunkt, um quasi Informatikern nicht nur das Programmieren beizubringen, sondern wie man Software, richtig gute Software auch entwickelt.

Ursprünglich, also ich bin extra fürs Studium nach Stuttgart gekommen, ursprünglich komme ich aus der Umgebung von Berlin. Also ich habe in meiner Ausbildung schon eine etwas weitere Reise hinter mir.

Götz Müller: Okay, prima. Dann werde ich mich, was mein Schwäbisch angeht, ein bisschen zurückhalten. Ich hoffe, das gelingt mir. Jetzt haben Sie gerade schon einen Punkt erwähnt in der Vorstellung, Dinge, die nicht funktionieren in der Softwareberatung. Wenn wir das noch ein bisschen mehr auf den Punkt bringen, was sind denn so die Hauptherausforderungen, die Ihre Kunden haben, bevor Sie die Leistung von Creatale in Anspruch nehmen?

Christian Dittrich: Die Kunden, die stehen vor dem Punkt oder eher gesagt vor dem Problem, dass es dort draußen in der Welt ganz viele verschiedene Software-Systeme zum Kaufen gibt. Und wenn es nichts zum Kaufen gibt, dann kann man sich notfalls immer noch was entwickeln lassen. Und das ist einfach eine unübersichtliche Menge an Systemen, an Entscheidungsmöglichkeiten, die der Kunde hat und die man üblicherweise auch als Laie überhaupt nicht bewerten kann. Das heißt, ich kenne mich mit der Technik nicht aus. Ich bin auf die Produktwerbung der Hersteller angewiesen und welche Werbung ist da tatsächlich ehrlich, was die Produkte angeht? Und um hinter diese Aussagen der Werbung gucken zu können, braucht man ein tiefes technisches Verständnis.

Das heißt, die Kunden sind quasi mit der Entscheidung überfordert und die übliche Handlung, die dort daraus entsteht, ist, sich für die bekannte Marke zu entscheiden, ohne zu schauen, ist es genau das, was ich brauche. Bietet das die Funktionen, die ich haben möchte, kann ich damit auch die Zukunft meines Unternehmens entsprechend gestalten.

Und das ist, vor diesem Problem stehen die Kunden an der Stelle.

Götz Müller: Sie haben gerade das Stichwort gesagt, Laien. Was sind denn so ein paar Hauptkriterien oder Hauptcharakteristiken, was Ihre Kunden ausmachen? Das sind jetzt sicher selber keine Softwarehäuser. Was ist so das klassische Klientel, das Sie unterstützen?

Christian Dittrich: Unsere Beratung, die richtet sich an Geschäftsführer oder Entscheider im oberen Management in mittelständischen Unternehmen. Also Leute, die dann tatsächlich auch entscheiden dürfen, wird eine Software angeschafft oder nicht. Die sich mit ihren Geschäftsprozessen, die sich mit ihrem Geschäftsumfeld, mit ihren Konkurrenten wirklich gut auskennen. Die wissen, was sie, also meistens wissen, was sie wollen, wie ihre Prozesse auszusehen haben, die aber eher wenig, also keine technische Ausbildung haben, sprich keine Informatik studiert, die grundsätzlich nur als Anwender mit Software in Kontakt kommen und nicht auch als Entwickler beziehungsweise als jemand, der Softwarelandschaften konzipiert. Diese Leute, denen fehlt halt dieses technische Nachhol, was wir mit der Beratung in die Unternehmen reinbringen.

Götz Müller: Wenn wir das jetzt ein bisschen auf eine metaphorische Ebene heben, was ist denn so typisch zuerst, dass Ihre Kunden denken? Oder anders ausgedrückt, was war zuerst da, Henne oder Ei? Also denken die Kunden eher zuerst an eine Software oder innerhalb ihrer bestehenden IT-Landschaft oder denken sie eher an die Prozesse und die zugrunde liegenden Kundenbedürfnisse und wählen dann gezielt danach hoffentlich die passende Software aus?

Christian Dittrich: Üblicherweise kommen die Kunden an und sagen, ich brauche eine Software, weil ich entweder schon eine Software habe, die ich ersetzen muss, oder weil ich dieses Problem mit Software lösen möchte. Wie konkret dann diese Software aussieht, also auf das Thema Prozesse und Bedürfnisse, das ist dann immer erst zweitrangig. Also zuerst ist die Idee da, ich brauche eine Software und dann überlegt man sich, wie muss diese Software aussehen. Also dieser Prozess ist auch bei den Kunden, ich sag mal, üblich.

Götz Müller: Also letzten Endes doch eigentlich die falsche Reihenfolge.

Christian Dittrich: Ja… Also häufig ist der Instinkt, dass man eine Software braucht, gar nicht so falsch, aber man sollte dann tatsächlich trotzdem offen bleiben, auch zu sagen, vielleicht ist es sinnvoll, den Prozess nicht mit einer Software zu unterstützen oder vielleicht die Prozesse an eine bestehende Software anzupassen. Das ist das, was halt häufig dann in dem Zusammenhang fehlt, die Offenheit gegenüber anderen Lösungsansätzen.

Götz Müller: Ich habe da vor kurzem so eine provozierende Aussage gelesen. Ich glaube, es war ein Geschäftsführer von einem großen deutschen Unternehmen, der meinte, was Digitalisierung angeht, wenn man einen, ich nenne es jetzt mal vornehm schlechten Prozess digitalisiert, dann hat man halt einen schlecht digitalisierten Prozess und nicht unbedingt durch die Digitalisierung was Besseres.

Christian Dittrich: Das ist eine sehr interessante Aussage, ja.

Götz Müller: Er hat da sehr viel deutliche Wörter, die mit SCH anzufangen, was den Prozess charakterisiert. Okay, jetzt haben wir ja in unserer Überschrift für das Gespräch das Thema Agil drin. Innerhalb klassischer Softwareentwicklung ist jetzt Agil so ziemlich Stand der Technik. Jetzt konzentrieren wir uns ja heute im Gespräch auf das Thema Softwareberatung. Was ist denn das Agile an der Softwareberatung bei Ihnen?

Christian Dittrich: Das unterscheidet sich von den Werten, die dahinter stehen, nicht von dem Agilen in der Softwareentwicklung.

Man hat in der Softwareentwicklung die agilen Ansätze eingeführt, weil man einfach die Risiken, die hinter einer Softwareentwicklung stehen, in den Griff bekommen muss oder wollte. Das heißt, ich habe Softwareprojekte, die über drei bis fünf Jahre entwickelt werden. Und man hat dann regelmäßig am Ende festgestellt, dass was dort rauskommt, das ist überhaupt nicht das, was man eigentlich braucht und was man wollte. Also dieser typische Chaos Report der Standish Group, wo dann wirklich im Jahr 95 15 Prozent aller Projektleiter oder Projektbeteiligten gesagt haben, dass ein Softwareprojekt tatsächlich erfolgreich verlaufen ist. Daher kommt dann auch so die Aussage, dass 80 Prozent aller Softwareprojekte scheitern. Und gerade für dieses Thema, um die Softwareprojekte dann auch erfolgreich zum Ende zu führen, haben sich dann die AG in Ansätze entwickelt. Das heißt, das Risiko zu managen, dass am Ende nicht das Richtige rauskommt. Sprich, durch schnelles Feedback, durch kurze Iterationen.

Einfach, dass man sich darauf vorbereitet, dass bestimmte Situationen einfach eintreten werden.

Wir sagen immer, folgende Situationen werden eintreten. Zum einen, der Kunde weiß nicht zu 100 Prozent, was er möchte. Das heißt, da werden immer noch Sachen kommen, ach und das hätte ich auch gerne noch und, Kunde wird seine Meinung auch ändern während des Projekts. Das ist dann so. Das hätte ich mir jetzt aber anders vorgestellt. Und das ist der Kern in den agilen Ansätzen oder in den agilen Methoden, die vorhanden, der dort quasi Risiko gemanagt wird.

Und einfach zu sagen, die gleichen Probleme, die existieren auch schon, bevor man eine Software entwickelt. Also ob ich jetzt eine Software kaufe oder sie entwickeln lasse, ich weiß am Anfang immer noch nicht zu 100 Prozent, was ich brauche. Und dann kommen die Unternehmen an und sagen, okay, machen wir mal ein Pflichtenheft. So, dann sitzen da Ingenieure sechs Monate, ein Jahr lang rum, schreiben alle Anforderungen plenibel auf und haben dann aber, wenn sie eine vernünftige Ausbildung haben und das verstanden haben, dann haben sie schon im Hinterkopf, das, was ich dort aufschreibe, ist erstens unvollständig und zweitens sowieso falsch. Das heißt, man steckt dort ein Jahr Arbeit rein in ein Thema, was eigentlich schon überholt ist, wenn es aufgeschrieben ist. An dieser Stelle setzen wir quasi mit dem Agile an, dass wir sagen, bei der Softwareauswahl kann man genauso vorgehen wie bei der Softwareentwicklung.

Man schaut sich an, was sind die Anforderungen grob, was man zu diesem Zeitpunkt weiß, sucht eine Software aus, die diese Anforderungen erfüllt, beziehungsweise versucht, eine Software zu finden. Es gibt nicht immer unbedingt so viel Auswahl, dass man sagen kann, man findet immer eine Software für das Problem.

Setzt ein Testsystem auf, lässt es die Leute ausprobieren und dann kommt das Feedback. Und mit dem Feedback geht man in die nächste Situation. Das ist am Anfang natürlich auf dem Papier erstmal aufwendiger. Aber es zahlt sich am Ende aus, einfach.

Götz Müller: Ja, und in dem Augenblick, wo ja mal Geld über die Theke sprichwörtlich gegangen ist, sprich, wenn man was gekauft hat, dann wird es nochmal ein Stückchen schwieriger, was zu verändern. Meine Software kann man umentwickeln, aber eine Sache, die man gekauft hat, ein Auto, das in der Garage steht, kann man ja nicht einfach zurückgeben.

Christian Dittrich: Genau, und dann rennt man schon ins nächste Problem. man hat jetzt was gekauft in der Software, und jetzt muss die benutzt werden man steht dann zwar fest nach dem Kauf, okay das passt eigentlich hinten und vorne nicht so, aber wir haben es jetzt gekauft jetzt wird es benutzt und dann macht man sich die Probleme nur noch größer ja.

Götz Müller: Ja, jetzt haben Sie ja in Ihrem Beratungsmodell, Sie sind ja nicht nur reine Beratung, sondern Sie machen auch Prototypen, Implementierung und da habe ich auf Ihrer Seite auch das Stichwort Open Source gefunden. Wenn wir da jetzt mal rein die Beratung uns anschauen, was für Vorteile bietet da dann konkret die Open Source für Ihre Kunden?

Christian Dittrich: Im Beratungsprozess steckt da einfach dahinter, dass man da viele Abkürzungen nehmen kann. Also so ein Open-Source-System aufzusetzen, da muss man nicht erst den Hersteller einschalten, sondern das kann man einfach machen in der Regel. Ist zwar nicht unaufwendig, aber gerade wenn es große Systeme sind, aber üblicherweise geht das viel einfacher, wenn man dort ein Open-Source-System nimmt. Dann häufig Software entspricht nicht 100% den Bedürfnissen, so wie sie angeboten wird. Das heißt, da sind immer Anpassungen notwendig. Bei Open Source kann man einfach dort prototypisch die Anpassung einmal ausführen. Wenn das eine Software ist, die man von einem Hersteller sich ein Testsystem bereitstellen lässt, dann muss der Hersteller dort erstmal irgendwie einen Prototypen für die Anpassung machen. Und einfach dort ist der Roundtrip einfach viel länger, statt wenn man Open Source einsetzt.

Götz Müller: Ja, jetzt ist natürlich die Open Source sicher nicht das Allheilmittel. Was gibt es denn besonders zu beachten?

Christian Dittrich: Ja, natürlich. Open-Source ist nicht das Eierheilmittel. Was dort besonders zu machen ist, ist, wenn hinter dem Open-Source-Projekt kein großes Team steht, dann kann es durchaus sein, dass es in eine Sackgasse führt. Zwar nicht sofort, aber vielleicht in Zukunft. Sprich, wenn die Software irgendwann nicht mehr weiterentwickelt wird von der Community.

Dann sitzt man mit der Software man kann sie zwar weiterentwickeln, aber üblicherweise sprengt das dann auch den Kostenrahmen für die Kunden. Da hat man den Vorteil, wenn man einen Hersteller hat, der kann natürlich auch pleite gehen, dann sitzt man, dann steht man noch schlimmer da, als wenn man die Open Source Variante hat, aber üblicherweise, wenn man sich dort an große Hersteller wendet, dann ist dort die Gefahr sehr gering, dass das System irgendwann nicht mehr gepflegt wird. Und dann bei Open Source häufig ein Problem sind die Lizenzen. Sprich, gerade wenn ich aus verschiedenen Komponenten ein System zusammenbaue, was für eine Gesamtlizenz ergibt sich daraus, was muss ich beachten für Änderungen, die ich an dem System vornehme. Das ist weniger schlimm, wenn man das System nur Inhouse einsetzt. Es ist schlimmer, wenn man tatsächlich das System aufbaut und dann, auch für seine Kunden verkauft bzw.

zur Verfügung stellt.

Götz Müller: Ja, weil die unter Umständen ja gar nicht damit rechnen, dass es Open Source ist und vielleicht auch nicht mal das Verständnis oder die Folgen, die man ja dann hat. Da kann ich jetzt aus meiner eigenen Erfahrung berichten, schon viele Jahre her, so im Embedded-Umfeld, wo man sich schon, ich würde mal sagen, locker 20 Jahre Open Source verwendet, Da gab es durchaus Vorbehalte gegen das Thema Open Source von ganz unterschiedlichen Stakeholder-Gruppen innerhalb der Entwicklung, zum Teil auch in Einbeziehung des Produktmanagements, die ja irgend so etwas wie eine Stimme des Kunden darstellen. Was begegnet Ihnen da für Vorbehalte gegenüber Open Source in unterschiedlichen Szenarien von Ihren Kunden?

Christian Dittrich: Da muss ich sagen, haben wir bisher wenig Probleme gehabt. Wenn wir sagen, also wenn wir offen kommunizieren, wir würden das gerne mit Open-Source-Komponenten machen und dann auch im Gegenzug dafür, dass wir die verwenden Anpassungen wieder auch in die Community zurückgeben, hat bisher immer auch im Zusammenspiel mit den Kunden sehr gut funktioniert. Also wir haben zum Beispiel, das sieht man auf unserer Webseite, im Rahmen eines Projekts eine Komponente entwickelt, die für das Node.js Ökosystem OCR-Bibliotheken bereitstellt. Die wird mittlerweile auch von vielen anderen Projekten verwendet. Und da hat der Kunde gesagt, solange dort keine Betriebsinterne rausgehen, ist das alles kein Problem.

Götz Müller: Ja, jetzt kommt mir auch gerade in den Sinn, wir haben ja einen gemeinsamen Bekannten, fast einen Namensvetter von Ihnen, der ja in seinem Umfeld Document Management auch sehr stark auf das Thema Open Source setzt.

Christian Dittrich: Ja, also zum Thema Open Source kann ich halt einfach nur sagen, das, was wir machen und auch viele andere Unternehmen, die IT einsetzen, die könnten ihre IT wahrscheinlich ohne Open Source überhaupt nicht betreiben. Das erste Thema ist, wir haben Linux, wir haben Apache, beziehungsweise Nginx, das heißt, alle Webseiten, die im Internet ausgeliefert werden, gehen höchstwahrscheinlich über ein Open-Source-Projekt. Und auf der anderen Seite, gerade wenn ich jetzt an Node.js denke, aber auch viele andere Ökosysteme, Ich kann einfach nach einer Komponente suchen, die ich gerade brauche und so innerhalb kürzester Zeit auch komplexere Systeme zusammenstecken. Und da kommt man, also wenn man das irgendwie über Closed Source machen würde, wo man dann erst jede Komponente einzeln einkaufen muss und ich dann aber heutzutage in modernen Systemen 20 Komponenten zusammenstecke, da wird man wahnsinnig.

Götz Müller: Bis hin, dass es wahrscheinlich einfach unterm Strich überhaupt nicht mehr kommerziell vertretbar wäre, das alles selber zu entwickeln. Die Preise würden letztendlich explodieren, die da alles auf der Entwicklung nach sich zieht. Gut, zum Abschluss, wenn Sie unseren Zuhörern einen Tipp geben wollen, so der typische Mittelständler, der vor der Neugestaltung, vor einer Veränderung in der IT-Landschaft steht, weil er veränderte Prozesse hat, weil alte Werkzeuge, Softwarewerkzeuge nicht mehr so verfügbar sind. Was sind denn so ein paar zentrale Tipps, die Sie da den Menschen geben können?

Christian Dittrich: Ganz klar Tipp Nummer eins, ausprobieren. Ich sehe das viel zu oft, dass Leute sich über ein Software-System, was sie gekauft haben, beschweren und dann aber auf Nachfrage sagen, nee, ausprobiert haben wir es nicht. Also Testsystem hingestellt und mal zwei Leute dran sitzen oder sowas. Und das andere, flexibel sein. Also wie gesagt, es stellt sich immer heraus, dass Sachen nicht so funktionieren, wie man es sich vorstellt, dass man Sachen anders haben möchte, dass man neue Ideen hat. Und das funktioniert nur, wenn man nicht irgendwie starr in einem Schema denkt. Ich würde sogar so weit gehen, dass ich vielen Unternehmen oder dass ich in vielen Unternehmen in Zukunft das so sehe, dass quasi die IT nicht einfach nur eine Stelle ist, der man einem Budget und Anforderungen gibt, sondern einen Bereich im Unternehmen, der das Geschäftsmodell aktiv im Unternehmen verändert. Und darauf muss man sich einlassen.

Und wenn man das macht, dann kann man auch von den ganzen Entwicklungen, die heutzutage im IT-Bereich passieren, auch extrem gut profitieren.

Götz Müller: Und das ist ja dann auch die Chance, eben über Prototypen wirklich gemeinsam zu lernen, was denn die Bedürfnisse der Nutzer sind. Und letzten Endes kommt es auf die ja in dem konkreten Fall an.

Christian Dittrich: Genau, genau. Das wird viel zu wenig gemacht, ja. Also dass man auch mit der IT einfach mal Sachen ausprobiert. Da heißt es immer nur, das Projekt muss so und so viel kosten und das muss alles können. Und dann heißt es an der IT-Abteilung so, jetzt seht mal bitte zu, dass das passiert. Aber einfach, dass man dort Spielraum gibt, zu sagen, wir haben jetzt diese Idee, kann man das machen, funktioniert das? Und dann auch den Rückkanal zu haben, die IT sagt, guck mal, da gibt es gerade diese Entwicklung. Wir können uns das hier und hier vorstellen. Das passiert viel zu wenig.

Götz Müller: Ja, und das ist ja dann auch wieder die Chance, die Open Source eben anbietet, wenn man schnell irgendwo in die Werkzeugkiste greifen kann und dann da was dabei hat. Und dann eben auch so dieser lapidare Spruch eben, wenn man da nicht nur einen Hammer drin hat und dann auch nicht jedes Problem nur ein Nagel sein kann.

Christian Dittrich: Ja.

Götz Müller: Gut, prima. Ich finde diese Kombination Prototyping, Agile und Open Source, das ist ein spannendes Thema, wo man viele Dinge rausholen kann. Da danke ich Ihnen jetzt für die Zeit, für unser Gespräch. Und ich denke, man kann den Nutzer, den Kunden nur ins Herz legen, sich genau zu überlegen, wie sie ihre Probleme lösen wollen und nicht alles schon von Anfang an auch nur auf ein Stück Papier schreiben und dann glauben, das, was da auf dem Papier steht, ist die allheilige Wahrheit und wird nie verändert werden.

Christian Dittrich: Ja, wenn der Zuhörer jetzt ja eins mitnimmt, dann ist es, nichts ist beständiger als die Veränderung und darauf muss man sich einstellen.

Götz Müller: Genau, das war ein prima Schlusswort. Vielen Dank für Ihre Zeit und tschüss bis zum nächsten Treffen.

Christian Dittrich: Sehr gerne, vielen Dank.

Götz Müller: Das war die heutige Episode im Gespräch mit Christian Dittrich zum Thema agile Softwareberatung.

Wenn Ihnen die Folge gefallen hat, freue ich mich über Ihre Bewertung bei Apple Podcasts. Sie geben damit auch anderen Lean-Interessierten die Chance, den Podcast zu entdecken.

Ich bin Götz Müller und das war Kaizen to go. Vielen Dank fürs Zuhören und Ihr Interesse. Ich wünsche Ihnen eine gute Zeit bis zur nächsten Episode. Und denken Sie immer daran, bei allem was Sie tun oder lassen, das Leben ist viel zu kurz, um es mit Verschwendung zu verbringen.

KI-generierte Zusammenfassung

In dieser Episode spricht Götz Müller mit Christian Dittrich über agile Softwareberatung in der Praxis und darüber, wie Unternehmen bessere Entscheidungen bei der Auswahl und Einführung von Software treffen können. Christian Dittrich ist Geschäftsführer der Creatale GmbH in Ludwigsburg und erläutert, wie sich sein Beratungsansatz aus dem Studium des Softwareengineerings und der praktischen Erfahrung mit agilen Methoden entwickelt hat. Ausgangspunkt war die Beobachtung, dass klassische IT-Beratung Kunden häufig nicht wirklich weiterbringt, weil sie zu stark produkt- oder herstellergetrieben ist und zu wenig die tatsächlichen Bedürfnisse berücksichtigt.

Ein zentrales Problem vieler Unternehmen beschreibt Christian Dittrich als Überforderung durch die Vielzahl an verfügbaren Softwarelösungen. Der Markt bietet unzählige Systeme, die jeweils mit umfangreichen Funktionsversprechen werben. Für Entscheider ohne tiefgehendes technisches Verständnis ist es kaum möglich, diese Angebote realistisch zu bewerten. Die Folge ist häufig eine Entscheidung für bekannte Marken oder etablierte Anbieter, ohne systematisch zu prüfen, ob die Lösung wirklich zu den eigenen Prozessen und strategischen Zielen passt.

Die Zielgruppe von Christian Dittrich sind Geschäftsführer und Führungskräfte im oberen Management mittelständischer Unternehmen. Diese kennen ihre Geschäftsprozesse und Märkte sehr gut, verfügen jedoch meist nicht über eine fundierte Ausbildung im Bereich Informatik oder Softwarearchitektur. Genau hier setzt die Beratung an: Sie bringt technisches Know-how in die Organisation und unterstützt dabei, fundierte Entscheidungen zu treffen.

Typischerweise beginnt der Entscheidungsprozess mit der Annahme, dass eine neue Software benötigt wird. Erst danach wird überlegt, wie diese aussehen soll. Götz Müller hinterfragt diese Reihenfolge kritisch und weist darauf hin, dass häufig nicht zuerst Prozesse und Kundenbedürfnisse analysiert werden, sondern direkt nach einem IT-Werkzeug gesucht wird. Christian Dittrich bestätigt, dass dieser Reflex weit verbreitet ist. Zwar sei die Annahme, eine Software zu benötigen, nicht grundsätzlich falsch, doch fehle oft die Offenheit für alternative Lösungsansätze, etwa die Anpassung von Prozessen oder die Nutzung bestehender Systeme.

Im weiteren Verlauf erläutert Christian Dittrich, was den agilen Charakter seiner Beratung ausmacht. Agile Methoden entstanden ursprünglich in der Softwareentwicklung, um das Risiko langfristiger Projekte zu reduzieren. Klassische Projekte mit mehrjähriger Laufzeit führten häufig zu Ergebnissen, die nicht den tatsächlichen Bedarf trafen. Agile Ansätze setzen dagegen auf kurze Iterationen, frühes Feedback und kontinuierliche Anpassung. Ein Grundgedanke lautet: Der Kunde weiß zu Beginn nicht exakt, was er braucht, und seine Anforderungen ändern sich im Projektverlauf.

Diesen Gedanken überträgt Christian Dittrich auf die Softwareauswahl. Anstatt monatelang detaillierte Lasten- und Pflichtenhefte zu erstellen, empfiehlt er, mit groben Anforderungen zu starten, geeignete Systeme zu identifizieren und diese in Testumgebungen praktisch auszuprobieren. Nutzer sollen frühzeitig mit der Software arbeiten und Rückmeldungen geben. Auf dieser Basis wird schrittweise weiterentwickelt oder neu entschieden. Dieser iterative Ansatz mag zu Beginn aufwendiger erscheinen, reduziert aber langfristig das Risiko teurer Fehlentscheidungen.

Ein weiterer Schwerpunkt des Gesprächs ist der Einsatz von Open-Source-Software. Christian Dittrich erläutert, dass Open Source im Beratungsprozess erhebliche Vorteile bietet. Testsysteme lassen sich häufig schneller und unabhängiger aufsetzen, da kein Hersteller eingebunden werden muss. Anpassungen können prototypisch umgesetzt werden, ohne lange Abstimmungsprozesse. Dadurch verkürzen sich Feedbackzyklen erheblich.

Gleichzeitig betont Christian Dittrich, dass Open Source kein Allheilmittel ist. Risiken bestehen insbesondere dann, wenn hinter einem Projekt keine aktive und stabile Community steht. Wird eine Software nicht weiterentwickelt, kann dies zu erheblichen Problemen führen. Auch Lizenzfragen spielen eine wichtige Rolle, vor allem wenn Komponenten kombiniert oder an Kunden weitergegeben werden. Dennoch weist Christian Dittrich darauf hin, dass ein Großteil moderner IT-Infrastrukturen auf Open-Source-Komponenten basiert, oft ohne dass dies den Anwendern bewusst ist.

Vorbehalte gegenüber Open Source begegnen ihm in der Praxis zunehmend seltener. Entscheidend sei Transparenz im Umgang mit dem Thema und die klare Regelung, dass keine sensiblen internen Informationen in die Öffentlichkeit gelangen. Wenn Anpassungen wieder in die Community zurückgespielt werden, profitieren langfristig alle Beteiligten.

Zum Abschluss formuliert Christian Dittrich zwei zentrale Empfehlungen für Unternehmen, die vor Veränderungen in ihrer IT-Landschaft stehen. Erstens: ausprobieren. Viele Unternehmen beschweren sich über Systeme, die sie nie real getestet haben. Ein einfaches Testsystem mit ausgewählten Nutzern kann wertvolle Erkenntnisse liefern. Zweitens: flexibel bleiben. Anforderungen ändern sich, neue Ideen entstehen, und technologische Entwicklungen eröffnen neue Möglichkeiten. IT sollte nicht nur als Kostenstelle verstanden werden, sondern als aktiver Gestalter des Geschäftsmodells.

Götz Müller greift diesen Gedanken auf und betont die Bedeutung von Prototypen als Lerninstrument. Beide sind sich einig, dass starre Planung und die Vorstellung, ein einmal definiertes Konzept bleibe unverändert gültig, der Realität nicht gerecht werden. Veränderung ist unvermeidlich. Wer sie aktiv gestaltet und iterativ vorgeht, kann die Chancen moderner IT deutlich besser nutzen.

Jetzt eintragen und Artikel/Denkanstöße zukünftig per eMail erhalten.

Artikel teilen auf ...

Hinweis: Ich behalte mir vor, Kommentare zu löschen, die beleidigend sind oder nicht zum Thema gehören.