In CIO Podcast Folge 35 geht es um die Softwareauswahl. Welche Software ist die richtige für die jeweilige fachliche Anforderung? Sollte man Standardsoftware oder Individualsoftware einsetzten? Um diese und weitere Fragen geht es in dieser Episode.
Podcast: Play in new window | Download (Duration: 17:39 — 15.0MB)
CIO Podcast abonnieren: Apple Podcasts | Google Podcasts | Spotify | Amazon Music | Android | RSS
Folgende Aspekte werden in der Podcast-Folge besprochen:
- Worauf kommt es bei der Softwareauswahl an? [00:00:30]
- 3 Handlungsoptionen bei der Softwareauswahl [00:03:30]
- Mit den Fachbereichen die Tool-Nutzung verhandeln (Option 1) [00:07:20]
- Standardsoftware vs. Individualsoftware einführen (Option 2) [00:09:00]
- Parallelbetrieb mit anschließender Tool-Konsolidierung (Option 3) [00:14:30]
- Use Cases für die Softwareauswahl erstellen [00:15:30]
Viel Spaß beim Hören des Podcasts. Ich freue mich, wenn Sie ein kurzes Feedback hinterlassen, wie Ihnen die Folge gefallen hat und Sie mit diskutieren.
Worauf kommt es bei der Softwareauswahl an?
In der heutigen Folge geht es um das Thema der Software-Auswahl und zwar der Software-Auswahl für die jeweilige fachliche Anforderung. Ebenfalls werden wir darüber sprechen, ob es denn immer Standardsoftware sein muss oder ob es auch Fälle gibt, in denen Individualsoftware ihren Platz hat und auch tatsächlich sehr viel Sinn macht.
Worauf kommt es an, wenn Sie Software auswählen? Klick um zu TweetenFachliche Anforderungen identifizieren
Zunächst mal sollten Sie an der Stelle auf die fachlichen Anforderungen schauen und diese fixieren zusammen mit Ihren Fachbereichen. Das ist ganz, ganz wichtig, also die fachlichen Rahmenparameter, was eigentlich gefordert ist, was wirklich angefragt ist, das ist ganz wichtig zunächst einmal zu erheben, bevor man überhaupt auf die Software schaut und auf die Software-Auswahl schaut, sollte man die fachlichen Anforderungen kennen, man sollte die Prozesse kennen, um die es geht. Das heißt, all das sollte man zunächst einmal erst einmal erheben und mit dem Fachbereich diskutieren, bevor man sich auf die Suche macht ein Tool zu finden.
Leider sieht das in der Praxis häufig anders aus. Da sind die Tools schon eingekauft, ehe denn überhaupt klar ist, was man damit machen soll. Also ich kenne ganz viele Unternehmen, wo dann einfach schon mal das Tool da steht und man sich dann da fragt:
„Was machen wir denn jetzt eigentlich genau damit?“
Leitlinien und Rahmenparameter für das Architekturmanagement anwenden
Und damit ihnen das nicht passiert oder sie das ein bisschen eindämmen können, wenn das bei Ihnen der Fall ist, erst mal die Anforderung klären, bevor Software eingekauft wird und vor allen Dingen auch ein ganz wichtiger Parameter, die technischen Rahmenparameter und Leitlinien klären für das Architekturmanagement, die Sie ja im besten Falle aus der Strategie aus Ihrer Strategie heraus schon haben. #00:02:14-0#
Was heißt das genau? Also zum Beispiel bestimmte Programmier-Richtlinien, bestimmte architektonische Komponenten, ob jetzt Sie monolithische Systeme befürworten, ob Sie jetzt modulare Systeme haben wollen. Diese Fragestellungen zu klären oder zu sagen, ich habe bestimmte Voraussetzungen, die ich erfüllen möchte, was das Betriebssystem angeht, was Datenbank-Technologien angeht usw.
Das heißt, solche technischen Parameter, die kann man ja schon zumindest mal in Architekturdesignprinzipien festlegen und da schon mal eine klare Leitlinie setzen, wonach man dann auch bei der Software-Auswahl gehen kann. Das macht das Ganze deutlich leichter und dann passt Ihre IT Architektur hinterher auch zusammen. #00:02:58-7#
Also nicht ein Stückwerk aus verschiedenen Tools und verschiedenen Software-Modulen, die völlig unterschiedlich sind und gar nicht miteinander kommunizieren können. Denn es kommt ja in der vernetzten Welt auch darauf an, dass Sie nachher all diese kleinen Einzelteile und diese Bausteine verknüpfen können, damit Sie dann nachher auch eine Gesamt-IT-Steuerung ermöglichen können. Also das zunächst mal vorweg.
3 Handlungsoptionen bei der Softwareauswahl
Bevor Sie die eigentliche Software auswählen und aus meiner Sicht ergeben sich 3 Möglichkeiten, wenn Sie die fachlichen Anforderungen kennen und die technischen Rahmenparameter geklärt sind, wie Sie jetzt da vorgehen können. Es gibt 3 Handlungsalternativen sozusagen.
1. Option: Ein bestehendes Tool nutzen
Die 1. Option ist, Sie nutzen ein bestehendes Tool. Wenn Ihre Anforderungen das hergeben und Sie haben bereits ein Tool identifiziert, das die Anforderungen abdeckt und das haben sie bereits im Einsatz, dann können Sie das durchaus einsetzen. Vielleicht ist es auch möglich ein Tool, was Sie heute schon im Einsatz haben, dahin zu entwickeln, dass es diese Anforderungen letztendlich abdeckt. #00:04:00-0#
Wichtig ist dabei das nicht komplett zu verbiegen, weil dann würden es auch nicht mehr sinnvoll sein das einzusetzen, sondern dass wirklich mit einem überschaubaren Aufwand auch diese Anforderungen abdeckbar sind. Das wäre die 1. Option.
2. Option: Neuartiges Tool wird notwendig
Die 2. Option ist, Sie benötigen ein neues Tool, also neue Softwarelösung. Die können Sie jetzt zum einen beschaffen, also quasi einkaufen via Standardsoftware. Oder Sie erstellen sie oder lassen sich für sich erstellen als Individualsoftware. Beide Möglichkeiten gibt’s da unter dieser Option 2. Also Sie haben noch kein Tool, was diese fachlich geforderten Anforderungen abdeckt.
Dann können Sie wie ich das gerade gesagt habe sich natürlich erst einmal am Markt orientieren und schauen welche Lösungen Sie da angeboten bekommen. Oder sie schauen nach einer Individuallösung und programmieren die. Da gehe ich gleich nochmal darauf ein, wie Sie denn am besten vorgehen. Also wann sollten Sie denn jetzt nach Standardsoftware gucken und wann sollten Sie nach Individualsoftware gucken? #00:05:01-3#
Ich habe das schon mal in einer der Podcast-Folgen erwähnt, dass ich der Meinung bin, dass Sie Ihre IT auch danach durchforsten sollen, wo Sie differenzierende Merkmale haben. Also wo können Sie sich strategisch vom Wettbewerb abheben. Und was ist wirklich für Ihr Geschäftsmodell des Unternehmens, was ist da wirklich geschäftskritisch, wo haben Sie Wettbewerbsvorteile? Und da kann es durchaus Sinn machen genau für diese Bereiche individuelle Softwarelösungen zu programmieren. Ich gebe Ihnen da nachher nochmal ein Beispiel dazu. Aber an der Stelle kann es durchaus Sinn machen, individuelle Lösungen zu programmieren.
Wenn Sie jetzt irgendwas haben, also ich sage mal in Anführungsstrichen dieser Begriff „Commodities“ ist, also täglich Brot sozusagen, der muss abgearbeitet werden, differenziert sie aber nicht. Dann ist es schon eher wahrscheinlich, dass sich eine Standardsoftware anbietet, weil das einfach vom Preisleistungsverhältnis in einem anderen Rahmen steht als alles selber zu programmieren und dann letztendlich auch warten zu müssen. #00:05:59-2#
3. Option: Parallelbetrieb und anschließende Konsolidierung
Die 3. Option ist eigentlich das, was dann noch übrig bleibt, der Parallelbetrieb von zwei Tools, die Ihre Anforderungen abdecken. Eigentlich würden beide Tools in Frage kommen und der Parallelbetrieb ist aus meiner Sicht erst einmal grundsätzlich nicht zu empfehlen. Es kann durchaus im Einzelfall Sinn machen, aber hier sollte tatsächlich genau abgewogen werden. Besser ist es bei der Option 3, wenn Sie sagen: Na ja wir haben da zwar ein Tool, das wäre auch einsetzbar, aber es gibt am Markt was viel, viel Besseres.
Dann kann das durchaus Sinn machen, erstmal die Lösung, die Sie jetzt quasi neu identifiziert haben, einzuführen für den Teilbereich, der jetzt gerade diese Anforderung angefragt hat, also der Fachbereich, der da jetzt mit Ihnen ins Gespräch geht. Aber da könnten Sie nachher sagen, okay, dieses neue Tool, das wollen wir nicht parallel betreiben, sondern da wollen wir letztendlich dafür sorgen, dass die andere Lösung, die wir schon im Einsatz haben, auch tatsächlich abgeschaltet wird. #00:07:00-0#
Also, dass Sie da grundsätzlich auch ein bisschen Ihre IT-Architektur steuern und nicht einen Wildwuchs zulassen in alle Richtungen, weil da werden Sie nachher nicht mehr Herr dieser Sache.
Mit den Fachbereichen die Tool-Nutzung verhandeln (Option 1)
Gehen wir mal auf die einzelnen Optionen etwas genauer ein. Die Option 1, bestehendes Tool nutzen. Also, wenn Sie das Tool identifiziert haben, können Sie das bestehende Tool nutzen. Der Fachbereich muss dann vielleicht an der ein oder anderen Stelle noch überzeugt werden. Dafür benötigen Sie eine gute Position im Unternehmen und ein gutes Standing im Unternehmen.
Zeigen Sie die Vor- und Nachteile für das Unternehmen und aber auch für die einzelnen Fachbereiche auf. Was haben Sie davon, wenn Sie diese Lösung nutzen, die es schon im Unternehmen gibt? Was sind die Vor- und Nachteile, zum einen fürs Unternehmen, aber wirklich auch für die einzelnen Bereiche? Und so haben Sie die Möglichkeit, die IT-Architektur im Sinne des Unternehmens zu steuern und vermeiden unnötigen Aufwand für den Betrieb von mehreren Lösungen, die die gleichen Anforderungen und fachlichen Zwecke abdecken. #00:08:01-9#
Das ist auf jeden Fall zu empfehlen. Wenn Sie da schon etwas nutzen können, das dann auch zu tun. Wie gesagt, es ist manchmal ein bisschen Überzeugungsarbeit nötig, weil die Leute dann sagen: Nein, ich möchte lieber mein eigenes Tool, und dann bin ich aber von der Abteilung XY irgendwie noch abhängig. Aber das ist glaube ich auch die Aufgabe der IT, das ein bisschen zu steuern und da eben auch aufzuzeigen, was diese Extra-Lösungen dann auch kosten im Betrieb, in der Wartung, in der Pflege und so weiter und eben halt auch zum Teil an Schnittstellenaufwand, der ja auch nicht gerade ohne ist. Und da kann man glaube ich dann ganz gut eingreifen und im Sinne der vernetzten Welt sollten Sie ja auch klarmachen, dass diese ganzen Tools ja nachher letztendlich auch miteinander kommunizieren müssen und letztendlich dann auch wieder in irgendeiner Form verknüpft werden müssen.
Und das macht es natürlich schwieriger, wenn man auf zwei völlig unterschiedlichen Datenmodellen womöglich unterwegs ist und da komplett ja mehr oder weniger unabgestimmt zwei Lösungen laufen hat, die aber eigentlich das Gleiche tun vom fachlichen Zweck her. #00:09:04-2#
Standardsoftware vs. Individualsoftware einführen (Option 2)
Die Option 2. Sie haben Anforderungen, die mit den aktuellen Systemen nicht abbildbar sind und da habe ich ja schon gesagt. Was ist eigentlich Ihr strategisches Ziel für diesen Fachbereich oder für diese Bereiche, für die Sie jetzt die Software suchen? Ist es eher Standardsoftware, ist es eher Individualprogrammierung? Ist es differenzierend oder ist es eher Commodity?
Beispiel:
Ich gebe Ihnen da jetzt das Beispiel, was ich eben schon mal angekündigt habe.
Nehmen Sie mal Google. Google würde für den Suchalgorithmus definitiv niemals eine Standardsoftware verwenden. Ganz einfach. Es gibt nämlich keine. Und das differenzierende Kriterium ist genau dieser Suchalgorithmus und diese ganze Suchlogik zum Wettbewerb. Das heißt, an der Stelle wäre Google ohne diese Individualprogrammierung nie in diese Wettbewerbsposition gekommen. #00:09:54-5#
Für die Finanzbuchhaltung zum Beispiel wäre es aber höchstwahrscheinlich unsinnig ein Tool selber zu programmieren, weil da gibt’s ja schon ganz viele und wenn Sie nicht gerade ein Anbieter für neue Finanzbuchhaltungssysteme werden wollen, dann ist es eigentlich nicht sinnvoll das selber zu programmieren und da lohnt es sich eben die Software-Auswahl am Markt zu machen.
Wenn Sie aber sagen, ich bin in dem und dem Bereich unterwegs und wir können uns mit dieser Logik und mit dieser Software echt differenzieren, dann macht das durchaus Sinn über individuell programmierte Software nachzudenken und da eben auch in dem Bereich aufzubauen. Und gehen wir mal die beiden Fälle durch.
Option 2.1 Softwareauswahl am Markt
Wenn Sie jetzt eine Software-Auswahl am Markt machen, wie geht man da geschickter Weise vor? Ich empfehle immer den Kunden Use Cases zu machen, also sich zu überlegen, für welche Fälle benötige ich eigentlich die Anwendung? Was sind meine fachlichen Anforderungen und was sind so klassische Use Cases, Anwendungsfälle, die ich durchlaufe mit dieser Software. Und die zu Papier zu bringen, die auch den Software-Anbietern zur Verfügung zu stellen und zu sagen:
„Bitte präsentieren Sie mir diese Anwendungsfälle mal abgespeckt in Ihrem Tool, wie das aussieht, wie das funktioniert.“
#00:11:04-0#
Dann kann man sich nämlich genau direkt anschauen, ob das Tool auch tatsächlich passt für diese Anwendungsfälle und wie kompliziert das ist die abzubilden. Geben Sie den Software-Herstellern vielleicht weiß ich nicht, zwei, drei Wochen Vorbereitungszeit und dann schauen Sie ja auch, was in diesen zwei, drei Wochen machbar ist, mit was für Lösungen die dann kommen. Ob die gerade das System aufgesetzt haben oder ob die wirklich schon ziemlich viel zeigen können von Ihren fachlichen Anforderungen.
Und wenn Sie dann die technischen Leitlinien noch spezifizieren und Rahmenparameter spezifizieren, die die Technik betreffen, also dass Sie sagen: Es muss in ein gewisses Schema passen vielleicht oder Sie müssen gewisse technische Anforderungen sicherstellen, Schnittstellenformate und so weiter, dann prüfen Sie die auch ob bei den Softwareanbietern und dann lassen Sie die präsentieren und machen sich eine Bewertungsmatrix, wonach Sie diese einzelnen Felder gewichten und klassifizieren. #00:11:59-3#
So können sie dann bei den Präsentationen der Softwareanbieter ganz gut sich Notizen machen. In dieser Bewertungsmatrix und das können dann auch die diversen Leute, die an dieser Software-Auswahl teilnehmen und Sie können das dann nachher letztendlich bewerten.
In vielen Unternehmen hat der Einkauf ja sowieso schon Bewertungsschemata. Die sind aber meistens ja, na ja eher kaufmännischer Natur und da kann man eben ganz gut auch technische Faktoren mit anreichern. Das empfehle ich immer, wenn Sie im Bereich der Standardsoftware-Auswahl am Markt unterwegs sind und das genau dann nochmal zu überprüfen.
Option 2.2 Individuell programmierte Software einführen
Bei der Individualprogrammierung ist das natürlich ein bisschen anders. Da gibt es auch die zwei Varianten. Entweder haben Sie die Leute selber im Unternehmen, die das für Sie programmieren können. Das macht das natürlich deutlich einfacher, als wenn Sie da jetzt erst noch extern Leute suchen müssen. Was aber natürlich auch geht.
Und da ist eben die Sache, wenn Sie es selber programmieren, brauchen Sie die fachlichen Anforderungen und die technischen Spezifikationen entlang Ihrer architektonischen Vorgaben, also entlang ihrer Designprinzipien für die Architektur, die sie festgesetzt haben, die ja auch Teil einer Architekturstrategie sind oder sein können. #00:13:09-7#
Und dann geht’s in die Umsetzung und bei der Individualprogrammierung, aber auch genau bei der Standardsoftware, die Sie dann letztendlich einführen, macht es aus meiner Sicht immer Sinn, das iterativ zu machen, sodass der Fachbereich die Möglichkeit auch hat, Feedback zu geben, aktiv mit am Entwicklungsprozess beteiligt ist und eingebunden ist und sich da aktiv mit einbringt. Ob Sie das jetzt agil nennen oder wie Sie das nennen ist irrelevant. Wichtig ist, dass der Fachbereich mit eingebunden ist und, dass Sie nicht hinterher irgendwie nach zwei Jahren, so lange sollte es gar nicht dauern, um das mal direkt vorweg zu sagen, aber um nach einem Zeitraum X irgendwie eine Softwarelösung zu haben, die man dann nicht einsetzen kann.
Also empfiehlt es sich wirklich kleine Abschnitte zu machen und zu sagen:
„Bis da und dahin schaffen wir das und das umzusetzen, bis da und dahin schaffen wir, das und das umzusetzen.“
#00:14:01-9#
Der Fachbereich ist mit beteiligt. Standardsoftware-Modulblöcke werden entweder bis dahin eingeführt, einzelne oder eben Individualprogrammierung, da haben Sie dann vielleicht Funktionen festgelegt, wo Sie sagen, das sind so die Standardfunktionen, die müssen wir auf jeden Fall haben, das ist die Minimalanforderung und die programmieren Sie dann stetig weiter und führen so die ausgewählte Software dann letztendlich auch ein. Das ist echt wichtig.
Parallelbetrieb mit anschließender Tool-Konsolidierung (Option 3)
Und dann hatten wir ja noch die Option 3. Der Parallelbetrieb von den zwei Tools beziehungsweise zunächst einmal ein Parallelbetrieb von zwei Tools und dann letztendlich die Ablösung von einem Tool. Und das ist auch aus meiner Sicht wichtig.
Sie können für eine gewisse Zeit durchaus diesen Parallelbetrieb aufrecht halten und ermöglichen, sollten aber immer schon von vornherein ganz klar die Strategie fahren, zu sagen: Okay, wenn wir es nicht müssen, wenn es nicht irgendeinen absolut zwingenden Grund gibt, dann versuchen wir das auf jeden Fall zu vermeiden und führen das dann hinterher wieder zusammen. #00:15:05-8#
Und da müssen Sie natürlich in der Umsetzung auch erst mal schauen, okay, dass das eine Tool, was Sie jetzt neu einführen, läuft. Wenn das irgendwie eine Stabilisierungsphase hatte und auch tatsächlich läuft, dann können sie ins Gespräch gehen mit den anderen Fachbereichen, die das alte Tool genutzt haben und sagen:
„Wir würden das gerne upgraden, wir haben da eine andere Lösung, die wir empfehlen.“
So können Sie den Fachbereich dann letztendlich dazu motivieren oder eben vielleicht auch als Unternehmensentscheidung, als Konsensentscheidung des Vorstands oder der Geschäftsleitung dann dieses neue Tool letztendlich auch einzuführen und dann auch umzusetzen.
Das wären eigentlich so die 3 Möglichkeiten, die ich so sehe.
Use Cases für die Softwareauswahl erstellen
Bei dem Thema Software-Auswahl wie gesagt, wenn Sie am Markt unterwegs sind, fordern Sie die Softwareanbieter ein bisschen heraus. #00:15:53-7# Diese Präsentationen, die normalerweise gezeigt werden, entstammen Standard-Situationen, die vorbereitet sind und wenn Sie da ein bisschen genauer schauen wollen, was wirklich spezifisch für ihr Unternehmen passt, dann machen Sie es nicht ganz so einfach, sondern erstellen Sie Anwendungsfälle, die spezifisch auf Ihr Unternehmen passen, die gewisse Grundfunktionalitäten abbilden und prüfen einfach so, ob die Software wirklich zu Ihren Rahmenparametern, zu Ihren Anforderungen passt und können das auch recht schnell dann damit beurteilen.
Und so haben Sie sich viel Zeit und Ärger gespart. So können Sie sich deutlich sicherer sein, dass diese Software, die Sie da auswählen mit dieser Methodik, auch letztendlich zu Ihren Anforderungen, zu Ihrem Unternehmen passt und haben schon einfach von vornherein das viel besser abgeklopft und abgeprüft und sind so in der Lage auch direkt zu starten und dieses Projekt dann auch anzufangen. Ja, das wäre es dann auch für diese Podcast-Folge schon wieder gewesen. #00:17:08-7#
Bildnachweis: © CC0 Public Domain/ pixabay.com
Ihr Feedback
Wir freuen uns über eine Bewertung des CIO Podcasts bei Apple Podcasts und den anderen Portalen!
Fünf Sterne stehen für „gefällt mir sehr gut“. Herzlichen Dank!
Wie gefällt Ihnen diese Folge des CIO Podcasts? Senden Sie Ihr Feedback, Anregungen und Wünsche einfach über das Kontaktformular direkt an die Redaktion des CIO Podcasts (nicht öffentlich):
[contact-form-7 id=“189″ title=“CIO Podcast“]
Weitere Podcast Folgen finden Sie hier.