IT Assessment und Investitionsentscheidungen
IT Assessment im Mittelstand: Welche Entscheidung soll danach möglich sein?
Ein IT Assessment im Mittelstand an der Entscheidung ausrichten: Systemgrenze, Datenbasis, Befunde, Ergebnisse und gesonderte Umsetzung.
Ein IT Assessment im Mittelstand ist sinnvoll, wenn du eine anstehende Investition oder ein technisches Risiko anhand nachvollziehbarer Befunde beurteilen möchtest. Dafür müssen die Entscheidungsfrage, die untersuchten Systeme und die erwarteten Ergebnisse zusammenpassen. Ein Auftrag wie "Bewerte einmal unsere IT" lässt zu viel offen.
Ich würde zuerst festhalten, was du nach der Untersuchung entscheiden willst. Geht es um die Weiterentwicklung einer Anwendung, den Austausch einer Plattform oder um die Abhängigkeit von einem Dienstleister? Davon hängt ab, welche Fachleute und welche Daten du brauchst. Ein Code Assessment kann dabei einen wichtigen Teil klären. Eine Untersuchung der gesamten IT-Landschaft umfasst weitere Fragen.
Die Investitionsfrage begrenzt die Untersuchung
Nehmen wir ein fiktives Unternehmen, das eine gewachsene Anwendung ersetzen möchte. Änderungen dauern lange, und im nächsten Jahr steht eine Erweiterung an. Im Raum steht die Annahme, dass eine Neuentwicklung günstiger wäre als die weitere Pflege.
Bevor dafür ein Budget freigegeben wird, möchte ich verstehen, wodurch der Aufwand entsteht. Liegt er in schwer veränderbarem Code? Fehlen passende Tests? Oder wartet das Team bei jeder Anpassung auf eine Freigabe, die außerhalb der Entwicklung liegt?
Diese Ursachen führen zu unterschiedlichen Maßnahmen. Die Untersuchung sollte deshalb die Annahme hinter der Investition prüfen. Ein technischer Maßnahmenplan ist nur dann hilfreich, wenn er auf die Entscheidung einzahlt, die tatsächlich ansteht.
Schreibe diese Frage vor dem Start in einem Satz auf. Dazu gehören die betrachteten Möglichkeiten und die bekannten Randbedingungen. Ein wichtiger Liefertermin oder ein auslaufender Vertrag kann die Abwägung verändern, ohne eine technische Schwäche des Systems zu sein.
Die Systemgrenze entscheidet, wer beteiligt sein muss
Ein Assessment einer Bestandsanwendung kann Architektur, Quellcode, Abhängigkeiten, Tests sowie Build und Deployment betrachten. Für eine Bewertung von Netzwerk, Identitäten, Endgeräten, Cloud-Verträgen oder Betriebsorganisation brauchst du jeweils passende Fachkenntnisse. Der Begriff IT Assessment allein beschreibt diesen Umfang noch nicht.
Ich würde die Grenze am betroffenen Geschäftsablauf ziehen. Welche Anwendungen, Schnittstellen und manuellen Übergaben sind daran beteiligt? Welche davon werden untersucht, und welche gelten zunächst als äußere Randbedingung?
Du brauchst dafür keinen vollständigen Architekturplan. Ein gemeinsamer Durchgang mit den verantwortlichen Personen kann die erste Übersicht liefern. Wichtig ist, dass erkennbare Lücken darin stehen bleiben. Ein unbekannter Datenfluss darf im Bericht nicht unbemerkt zu einer bestätigten Systemgrenze werden.
Mein Forensic Code Assessment untersucht ein abgegrenztes Softwaresystem anhand vereinbarter Fragen und Nachweise. Eine vollständige Bewertung der Unternehmens-IT ist damit nicht automatisch beauftragt.
Befunde brauchen einen fachlichen Zusammenhang
Für eine Investitionsentscheidung reicht eine Liste auffälliger Dateien kaum aus. Ich möchte erkennen können, welcher Befund einen Geschäftsablauf betrifft und wodurch daraus ein Risiko entsteht.
Ein häufig geänderter Teil des Systems kann besondere Aufmerksamkeit verdienen. Das Änderungsmuster allein sagt aber noch nicht, ob dort ein Problem liegt. Vielleicht gehört die häufige Anpassung zum fachlichen Zweck. Vielleicht fehlen klare Zuständigkeiten oder eine passende Absicherung. Diese Erklärungen müssen geprüft werden.
Qualitätsmerkmale helfen dabei, Untersuchungsfragen zu ordnen. Das Produktqualitätsmodell von ISO/IEC 25010 bietet dafür einen begrifflichen Rahmen. Welche Merkmale für deine Entscheidung relevant sind, muss im konkreten Auftrag festgelegt werden. Daraus folgt keine Zertifizierung der untersuchten Software.
Auch eine Kennzahl braucht ihren Bezug. Ein Messwert ohne untersuchten Versionsstand, Erhebungsmethode und fachliche Bedeutung lässt sich schlecht für eine Budgetentscheidung verwenden. Ich würde deshalb zu jedem priorisierten Punkt eine verständliche Begründung verlangen.
Mit einer nachvollziehbaren Datenbasis anfangen
Vor der Untersuchung sollten die Beteiligten klären, welche Unterlagen existieren und wer sie bereitstellen kann. Dazu gehören die betroffenen Repositories, Architekturinformationen, Testberichte, Build-Konfigurationen und bekannte Fehlerbilder. Technische und fachliche Ansprechpersonen liefern den Zusammenhang.
Die Unterlagen müssen nicht perfekt sein. Fehlende Daten können ein Ergebnis der Bestandsaufnahme sein. Dann muss sichtbar werden, welche Aussage dadurch offenbleibt und wie sie gezielt geprüft werden könnte.
Ich würde zunächst einen wichtigen Ablauf durchgehen und die verfügbaren Nachweise daran verbinden. Zum Beispiel: Welche Änderung betrifft diesen Ablauf, welche Tests prüfen ihn und wie gelangt die Version in die vorgesehene Umgebung?
Testabdeckung zeigt, welcher Code bei einem Testlauf ausgeführt wurde. Welche fachlichen Situationen damit geprüft sind, braucht eine zusätzliche Betrachtung. (Microsoft zur Testabdeckung)
Zugriffe und Vertraulichkeit gehören vorab geklärt. Für mein Forensic Code Assessment ist kein Produktionszugriff erforderlich. Eine Untersuchung des laufenden Verhaltens wäre ein gesondert abzugrenzender Umfang und darf nicht stillschweigend aus einer Repository-Analyse abgeleitet werden.
Ein Bericht muss Entscheidungen vorbereiten
Nach dem Assessment solltest du unterscheiden können, was belegt ist, wo ein technisches Risiko liegt und welche Erklärung noch eine Hypothese ist. Zu offenen Fragen gehört ein nächster Prüfpunkt. Zu Empfehlungen gehören Voraussetzungen und erkennbare Grenzen.
Für das fiktive Ablösevorhaben könnte das Ergebnis beispielsweise sein, zunächst einen fachlichen Bereich genauer abzugrenzen und dessen Testbarkeit zu prüfen. Das wäre eine begründete Folgeuntersuchung. Die Entscheidung für eine komplette Neuentwicklung wäre damit noch nicht getroffen.
Als Ergebnis vereinbare ich lieber eine nachvollziehbare Entscheidungsgrundlage als eine pauschale Gesundheitsnote. Im Forensic Code Assessment gehören Report, dynamischer Audit, Kurzform und Roadmap zu den veröffentlichten Ergebnissen. Was darin untersucht wird, richtet sich nach den vereinbarten Fragen und der Analysetiefe.
Die Umsetzung bleibt ein eigener Schritt. Auch Kosten und Nutzen möglicher Maßnahmen müssen anhand ihres konkreten Umfangs bewertet werden. Ein Assessment kann diese Abwägung vorbereiten; es garantiert keinen bestimmten wirtschaftlichen Erfolg.
Diese Punkte würde ich vor dem Auftrag festhalten
- Welche Entscheidung soll das Assessment ermöglichen?
- Welche Systeme und Geschäftsabläufe liegen innerhalb der Untersuchung?
- Welche Daten, Zugänge und Ansprechpersonen stehen bereit?
- Wie werden Befunde, Risiken, Hypothesen und offene Fragen unterschieden?
- Welche Ergebnisse werden übergeben, und wer bespricht sie mit dem Team?
- Welche Folgeuntersuchungen und Umsetzungsarbeiten sind gesondert zu vereinbaren?
Wenn diese Punkte geklärt sind, lässt sich ein Angebot nach Umfang und Nutzen vergleichen. Für eine gewachsene Softwareanwendung kann dann eine gezielte Code- und Architekturanalyse passen. Für andere Teile der IT-Landschaft muss die Untersuchung fachlich anders besetzt werden. Die Entscheidung darüber gehört an den Anfang des Vorhabens.