Warum die meisten IT-Konzepte nie eines waren – und was du stattdessen brauchst

Fünf Bausteine, eine Architektur. Wenn du einen davon nicht erklären kannst, hast du ein Loch im Konzept.

TL;DR: Die meisten Unternehmen haben kein IT-Konzept, sondern eine Sammlung gekaufter Tools mit nachgereichter Begründung. Ein echtes Konzept besteht aus fünf Bausteinen – Hardware, Software, Netzwerk, Daten, Sicherheit – die ineinandergreifen. Wer die Bausteine versteht, verhandelt mit Anbietern auf Augenhöhe statt sich erklären zu lassen. Wir zeigen, woran Konzepte typischerweise scheitern und wie du in fünf Schritten zu einem belastbaren kommst.

Warum die meisten „IT-Konzepte“ gar keine sind

Frag in zehn mittelständischen Unternehmen nach dem IT-Konzept, und du bekommst neun Mal dasselbe: eine PowerPoint mit Logos, ein paar Architektur-Boxen, irgendwo das Wort „Cloud-First“. Das ist kein Konzept. Das ist die Dokumentation einer Reihe von Anbieter-Entscheidungen, die jemand im Nachhinein zu einer Strategie umetikettiert hat.

Ein IT-Konzept beantwortet eine andere Frage: Wie greifen Hardware, Software, Netzwerk, Daten und Sicherheit ineinander, sodass die geschäftlichen Anforderungen damit getragen werden – und was tun wir, wenn ein Baustein wackelt?

Was ein Konzept von einer Tool-Liste unterscheidet

Eine Tool-Liste sagt: „Wir haben Microsoft 365, Veeam, Sophos, AWS.“ Ein Konzept sagt etwas Schwierigeres: Warum genau diese Kombination, was hält sie zusammen, wo sind die Bruchstellen, wann müssen wir umsteuern.

Drei Fragen trennen das eine vom anderen:

• Kannst du erklären, warum ein Baustein gewählt wurde – nicht nur, dass er da ist?
• Weißt du, welche anderen Bausteine kippen, wenn einer ausfällt oder gewechselt wird?
• Hast du einen Plan B für die zwei wichtigsten Anbieter-Abhängigkeiten?

Wer alle drei beantworten kann, hat ein Konzept. Wer bei einer dieser Fragen ins Stocken kommt, hat eine Sammlung. Mehr nicht.

Was passiert, wenn das Konzept fehlt

Die Kosten eines fehlenden Konzepts werden selten budgetiert – sie tauchen in anderen Posten auf. Ungeplante Migrationsprojekte, weil ein Anbieter die Preise verdreifacht hat. Audit-Mängel, die plötzlich eine NIS2- oder ISO-27001-Zertifizierung blockieren. Ransomware-Vorfälle, bei denen niemand sagen kann, welche Systeme isoliert werden müssen.

In zwei Mittelstands-Projekten, die wir aus der Nähe gesehen haben, lag der nachträgliche Ordnungs-Aufwand zwischen 80.000 und 240.000 Euro – jeweils ohne den Geschäftsausfall, den niemand sauber quantifizieren wollte.

Die fünf Bausteine in einem Satz

Vor dem Detailblick einmal die Gesamtsicht. Ein IT-Konzept ruht auf fünf Bausteinen:

• Hardware – das, was du anfassen kannst
• Software – das, was die Hardware zum Werkzeug macht
• Netzwerk – das, worüber Informationen fließen
• Daten – das, was am Ende den Wert ausmacht
• Sicherheit – das, was die anderen vier zusammenhält

Wer einen davon vernachlässigt, schwächt das Ganze. Im Folgenden gehen wir Baustein für Baustein durch, kritisch und mit klarer Empfehlung.

Hardware: Was du wirklich besitzen musst

Vor der Cloud-Welle war Hardware-Strategie ein Karrierethema – heute halten viele sie für irrelevant. Das ist ein Trugschluss. Auch in einer cloud-lastigen Architektur entscheidet Hardware über Latenz, Souveränität und Abhängigkeiten.

Endgeräte, Server, Spezialkram

Im Unternehmenskontext sortiert sich Hardware in drei Kategorien:

• Endgeräte – Notebooks, Workstations, Tablets, Smartphones, Drucker
• Zentrale Infrastruktur – Server, Storage, Switches, Router, Firewalls, USV
• Spezialgeräte – IoT-Sensoren, Edge-Devices, Industrie-Steuerungen, Backup-Bandlaufwerke

Endgeräte siehst du täglich. Die zentrale Infrastruktur steht entweder im Serverraum oder in einem fremden Rechenzentrum – unsichtbar, aber lebensnotwendig. Spezialgeräte gewinnen mit Industrie 4.0 stark an Bedeutung, weil sie Daten am Produktionsort erfassen, bevor sie überhaupt zentralisiert werden.

Eigene Hardware, Colocation oder Cloud

Drei Modelle stehen zur Auswahl. Jedes hat eine eigene Logik, und keine ist universell richtig:

Die ehrliche Antwort: kaum noch ein Unternehmen fährt rein eines dieser Modelle. Mischformen sind die Regel – sensible Workloads im eigenen RZ, Standard-Anwendungen aus der Cloud, Spezialfälle bei Branchen-Providern. Wer aber nicht weiß, welcher Anteil wo läuft, hat das Lock-in-Problem schon eingekauft.

Total Cost of Ownership, nicht Anschaffungspreis

Hardware-Entscheidungen werden gerne über den Listenpreis getroffen. Das ist falsch. Was wirklich zählt, ist die Total Cost of Ownership über den Lebenszyklus.

Server-Hardware ist nach drei bis fünf Jahren am Limit. Danach steigen Wartung, Energie und Ausfallrisiko. Notebooks halten oft länger physisch, werden aber durch wachsende Software-Anforderungen schneller obsolet. Storage skaliert mit den Datenmengen, nicht mit der Zeit. Wer den Lebenszyklus ignoriert, zahlt im vierten Jahr für etwas, das er im dritten hätte ersetzen sollen.

Souveränität und Lieferketten

Hardware ist seit den Sanktionen und Halbleiter-Engpässen kein neutraler Kostenpunkt mehr, sondern Teil deiner Lieferketten-Strategie. Wer Server aus Europa kauft, mit Open-Source-Firmware betreibt und auf offene Befehlssatz-Architekturen wie RISC-V achtet, reduziert Abhängigkeiten gegenüber einzelnen Herstellern.

Diese Diskussion ist nicht akademisch. Berichte über kompromittierte Firmware-Chips und die wiederholten Engpässe bei Server-CPUs haben gezeigt, dass die Frage „Wo kommt das eigentlich her?“ zu jeder Hardware-Bestellung gehört. Wer sie nicht stellt, vertraut blind auf eine Versorgungslage, die nachweislich nicht stabil ist.

Software: Wo die Lock-ins wirklich entstehen

Hardware ersetzt du in drei Jahren. Software bleibt zehn. Genau deshalb sind Software-Entscheidungen langfristig kostspieliger als die meisten Geschäftsführer wahrhaben wollen.

Drei Schichten, drei Logiken

Software organisiert sich in drei Schichten, die übereinander liegen:

• Betriebssystem – verwaltet Hardware, stellt Schnittstellen bereit
• Systemsoftware – Datenbanken, Webserver, Container-Laufzeiten, Virtualisierung
• Anwendungssoftware – Office, ERP, CRM, Branchen-Lösungen

Betriebssysteme sind träge und langlebig. Systemsoftware lebt von Standards. Anwendungssoftware ist der dynamische Teil, der ständig wächst und sich an Geschäftsprozesse anpasst. Wer alle drei Schichten als eine Masse behandelt, übersieht, dass jede ihre eigenen Wechselkosten hat.

Standard oder Individual – die teuerste Falle ist dazwischen

Eine grundlegende Software-Entscheidung lautet: Standardsoftware kaufen, Individualsoftware bauen, oder mit Low-Code dazwischen schichten?

• Standard ist günstiger in der Anschaffung, deckt 80 Prozent der typischen Anforderungen ab
• Individual passt exakt zum Prozess, kostet aber dauerhaft
• Low-Code verspricht den Mittelweg, liefert in vielen Fällen aber das Schlechteste aus beiden Welten

Die teuerste Variante ist tatsächlich der Mittelweg, wenn er ohne klare Governance gefahren wird. Standardsoftware, die so stark individualisiert wurde, dass kein Update mehr ohne Customizing-Anpassung läuft, blockiert dich für Jahre. Faustregel: differenzierende Geschäftsprozesse rechtfertigen Individual, alles andere fährst du besser mit unkonfiguriertem Standard.

Subskription ist die Norm geworden – nicht zwingend zu deinem Vorteil

Klassischer Lizenzkauf ist die Ausnahme, Software-as-a-Service die Regel. Das hat dir niemand zur Wahl gestellt, das hat sich der Markt selbst verordnet.

Drei Konsequenzen, die du im Auge behalten solltest:

• Niedrigere Anfangs-Investition, dauerhaft höhere Betriebskosten
• Automatische Updates – mit weniger Kontrolle, wann sie kommen
• Tiefe Abhängigkeit vom Anbieter, die bei Vertragsänderungen schmerzt

Wenn du heute Subskription kaufst, schreibst du Exit-Klauseln in den Vertrag. Datenexport-Format, Wechselkosten-Schätzung, Mindestkündigungsfristen. Wer das später nachverhandeln will, hat schon verloren.

Open Source ist Marktführer, nicht Alternative

Bei der Software-Wahl gilt eine Realität, die viele Geschäftsführer noch immer überrascht: Open Source dominiert weite Teile des Stacks. Linux trägt die Server-Welt, Kubernetes orchestriert Container, PostgreSQL ist die wohl robusteste Datenbank am Markt.

Open Source bedeutet nicht kostenlos. Es bedeutet Kontrolle über den Quellcode und Unabhängigkeit von einzelnen Anbietern. Professionellen Support gibt es bei Red Hat, SUSE, Canonical und anderen kommerziellen Distributoren. Für regulierte Branchen ist Open Source oft Voraussetzung für die Audit-Fähigkeit – nur quelloffene Komponenten können unabhängig geprüft werden.

Netzwerk: Das, woran Architekturen still scheitern

Netzwerke sind unsichtbar, bis sie ausfallen. Genau darin liegt die Falle. Wer Netzwerk-Konzepte erst dann anfasst, wenn etwas nicht funktioniert, baut sie unter Stress – und schlecht.

LAN: die Vier-Buchstaben-Welt

Im lokalen Netzwerk laufen vier Protokolle, die du verstehen solltest, auch wenn du sie selbst nie konfigurierst:

• TCP/IP – zerlegt Daten in Pakete, sortiert sie am Ziel wieder zusammen
• DNS – macht aus technavigator.de eine IP-Nummer
• DHCP – verteilt automatisch Adressen an neue Geräte
• Ethernet/WLAN – die physische Übertragung, kabelgebunden oder per Funk

Wenn dein DNS ausfällt, fällt nicht „das Internet“ aus, sondern nur die Namensauflösung. Wenn dein DHCP-Server hängt, kommt niemand mehr neu ins Netz. Wer diese Unterscheidungen kennt, diagnostiziert in zehn Minuten statt zwei Stunden.

WAN: Vier Varianten, ein Ziel

Weitverkehrsnetze verbinden Standorte oder bringen dich ins Internet. Vier Varianten dominieren:

Für KRITIS-relevante Branchen gehört eine redundante Anbindung mit zwei unabhängigen Anbietern zum Pflichtprogramm – nicht weil es schick ist, sondern weil NIS2 und sektorale Vorgaben das fordern.

Segmentierung ist kein Luxus

Eine Netzwerk-Architektur sollte segmentiert sein. Das heißt: nicht jedes Gerät erreicht jedes andere. Produktionssteuerung getrennt von Bürokommunikation. Gäste-WLAN getrennt von internen Servern. IoT-Sensoren auf einem eigenen Segment.

Diese Trennung – meist mit VLANs realisiert – ist der Unterschied zwischen einem lokalen Ransomware-Vorfall und einem unternehmensweiten Stillstand. Zero-Trust geht den Gedanken konsequent zu Ende: keine Verbindung ohne explizite Authentifizierung, unabhängig davon, ob sie aus dem internen Netz kommt oder von außen.

Die Firewall ist nur so gut wie ihr Regelwerk

Beim Übergang ins Internet steht die Firewall. Moderne Firewalls können mehr als Adressen filtern – Deep Packet Inspection, Intrusion Prevention, URL-Filter, Logging für Forensik. Aber jede Firewall ist nur so gut wie das Regelwerk dahinter.

Wir sehen regelmäßig Firewall-Konfigurationen, die über zehn Jahre gewachsen sind: Regelwerke aus Hunderten Ausnahmen, die niemand mehr versteht, die aber alle „aus Sicherheitsgründen“ nicht angefasst werden. Das ist keine Firewall mehr, sondern eine archäologische Schicht. Mindestens einmal im Jahr gehört ein Regel-Review auf den Tisch.

Daten: Das, was am Ende den Wert ausmacht

Ohne Daten ist IT bedeutungslos. Eine sinnvolle Datenstrategie regelt vier Dinge: wo gespeichert wird, wie strukturiert ist, wer Zugriff hat, wie gesichert wird.

Block, Datei, Object – drei Welten

Bei der Speicherung gibt es drei Grundarchitekturen, jede für andere Anwendungsfälle:

Datenbanken brauchen Block-Speicher mit hoher IOPS-Leistung, Backup-Archive sind in Object-Stores wie S3 am besten aufgehoben, klassische Filesystem-Ablagen funktionieren nach wie vor mit Datei-Speicher. Wer alles in eine Schublade wirft, zahlt drauf – entweder über Performance oder über Kosten.

Strukturiert und unstrukturiert

Daten kommen in zwei Welten vor, die kaum miteinander reden:

• Strukturierte Daten passen in Tabellen – das klassische Feld relationaler Datenbanken wie PostgreSQL, MySQL oder Oracle
• Unstrukturierte Daten sind PDFs, Bilder, E-Mails, Chats. Diese Datenmengen bilden inzwischen den Großteil dessen, was Unternehmen erzeugen

Für unstrukturierte Daten brauchst du andere Werkzeuge: Dokumentendatenbanken, Suchindexe, Data Lakes. Mit dem Vormarsch generativer KI wird der saubere Umgang mit dieser Welt zusätzlich wichtig – die meisten LLM-Anwendungen für Unternehmen leben von dem, was in PDFs und Wikis schlummert.

Die 3-2-1-Regel ist kein Ratschlag, sondern Pflicht

Wer Daten speichert, muss sie auch wiederherstellen können. Die 3-2-1-Regel ist der bewährte Standard:

• 3 Kopien der Daten halten
• 2 verschiedene Medien verwenden
• 1 Kopie an einem anderen Ort lagern

Damit übersteht eine Organisation Hardware-Defekte, lokale Katastrophen wie Brände und gezielte Angriffe wie Ransomware. Wichtiger Zusatz: ein Backup, das nie wiederhergestellt wurde, ist kein Backup. Es ist Hoffnung. Quartalsweise eine echte Restore-Übung gehört zum Pflichtprogramm.

Klassifizierung als Brücke zur Sicherheit

Datenklassifizierung legt fest, wie sensibel ein Datensatz ist und welche Schutzmaßnahmen daraus folgen. Vier Stufen reichen in den meisten Unternehmen:

• Öffentlich – jeder darf es sehen
• Intern – Mitarbeitende, aber nicht jeder Externe
• Vertraulich – bestimmte Funktionen
• Streng vertraulich – kleinster Kreis, maximaler Schutz

Die DSGVO ergänzt diese Logik um Pflichten für personenbezogene Daten: Zweckbindung, Datensparsamkeit, Auskunftsrechte, Löschpflichten. Ein Datenkonzept ohne DSGVO-Berücksichtigung ist im EU-Geltungsbereich rechtlich verwundbar.

Cloud: Die ehrliche Bilanz nach zehn Jahren

Cloud-Computing hat die IT-Landschaft umgepflügt. Aber jetzt, nach gut zehn Jahren breiter Adoption, lohnt eine ehrliche Bilanz: was hat geliefert, was nicht, und was war das alles wert?

IaaS, PaaS, SaaS – drei Vertragstypen

Cloud-Angebote gliedern sich in drei Schichten, je nachdem wieviel der Anbieter übernimmt:

Die meisten Unternehmen nutzen alle drei parallel – Microsoft 365 als SaaS, Container-Plattformen als PaaS, virtuelle Server für Spezialfälle als IaaS. Die Schwierigkeit liegt nicht in der Auswahl, sondern in der Steuerung über alle drei Ebenen hinweg.

Virtualisierung und Container

Hinter der Cloud steckt technisch fast immer Virtualisierung. Eine physische Hardware wird per Software in mehrere virtuelle Maschinen aufgeteilt, die sich gegenseitig nicht stören.

Container-Technologien gehen einen Schritt weiter:

• Virtuelle Maschine – komplettes Gast-Betriebssystem auf dem Host
• Container – nur Anwendung plus Abhängigkeiten, teilt sich den Kernel
• Kubernetes – orchestriert Container über viele Hosts hinweg

Container sind bei Microservice-Architekturen das Mittel der Wahl, weil sich einzelne Services unabhängig ausrollen und skalieren lassen.

Multi-Cloud, Hybrid, Sovereign – drei Strategien

Die Cloud-Frage ist nicht binär. Drei strategische Varianten haben sich etabliert:

• Multi-Cloud – mehrere Anbieter parallel, reduziert Abhängigkeit
• Hybrid-Cloud – eigenes RZ plus Cloud, kombiniert Kontrolle und Flexibilität
• Sovereign Cloud – Angebote in Europa, ohne US-Zugriffsrechte

Wir halten Sovereign Cloud für unterschätzt. Solange du keine besonderen Anforderungen hast, ist der Hyperscaler bequem. Sobald du in regulierter Umgebung arbeitest oder Daten verarbeitest, an denen US-Behörden Interesse zeigen könnten, wird Sovereign Cloud schnell zum harten Kriterium. Anbieter wie OVHcloud, IONOS, Schwarz Digits oder die GAIA-X-Föderation sind hier die ernsthaften Spieler.

Vendor-Lock-in: der unbezahlte Preis

Bei aller Begeisterung bleibt ein wichtiger Punkt: Lock-in. Wer Daten und Prozesse tief in eine einzige Cloud-Plattform integriert, kann nicht mehr einfach wechseln. Anbieter-spezifische Dienste mit proprietären Schnittstellen sind besonders heikel.

Praxis-Test, den wir jedem Kunden vorschlagen: Kannst du in 90 Tagen deinen wichtigsten Workload zu einem anderen Anbieter migrieren? Wenn die Antwort „eher nicht“ lautet, ist der Lock-in zu tief. Drei Faustregeln helfen, die Wechselfähigkeit zu erhalten:

• Offene Standards bevorzugen, proprietäre Dienste meiden wo möglich
• Container-basierte Architekturen statt anbieter-spezifischer PaaS-Bindungen
• Exit-Klauseln in jeden Vertrag, mit klaren Datenexport-Pfaden

Sicherheit: Der Querschnitt, den keiner allein trägt

IT-Sicherheit ist kein eigener Baustein, sondern eine Eigenschaft, die durch alle anderen hindurchgeht. Hardware kann manipuliert sein. Software hat Schwachstellen. Netzwerke sind belauschbar. Daten sind stehlbar. Und der Mensch ist immer der schwächste Punkt.

Mehrschichtige Verteidigung

Eine robuste Sicherheitsarchitektur setzt nicht auf eine einzige Mauer, sondern auf mehrere Schutzebenen:

• Physische Sicherung der Hardware-Standorte
• Netzwerk-Segmentierung und Firewalls
• Patch-Management mit klaren SLAs
• Mehr-Faktor-Authentifizierung statt Passwörtern
• Granulare Zugriffsrechte nach Bedarfs-Prinzip
• Monitoring und Logging mit Anomalie-Erkennung

Jede einzelne Ebene kann scheitern – das ist eingerechnet. Aber nicht alle gleichzeitig, jedenfalls nicht ohne deutliche Warnsignale vorher.

ISO 27001 und BSI IT-Grundschutz

Der Standard für strukturiertes Vorgehen ist ein Informationssicherheits-Management-System. Zwei Frameworks dominieren den deutschsprachigen Raum:

Eine Zertifizierung ist für viele Branchen Voraussetzung – nicht nur fürs Marketing, sondern für die Teilnahme an Ausschreibungen. Wer beide Welten bedient, kombiniert oft beide Frameworks. Das BSI veröffentlicht regelmäßig aktualisierte IT-Grundschutz-Kompendien, die als Referenz dienen.

EU-Regulierung: Vier Akronyme, die du kennen musst

Die EU-Regulierung ergänzt die technische Sicht um rechtliche Pflichten. Vier Regelwerke prägen die aktuelle Diskussion:

• NIS2 – Cyber-Sicherheits-Pflichten für mehr Branchen, mit Melde-Pflichten bei Vorfällen
• DSGVO – Datenschutz mit Bußgeldern bis 4 Prozent des Konzernumsatzes
• EU AI Act – Risikokategorien für KI-Systeme, mit unterschiedlichen Pflichten
• Cyber Resilience Act – Sicherheit ab Werk in IT-Produkten

Wer diese Regelungen ignoriert, riskiert nicht nur Bußgelder, sondern auch persönliche Haftung der Geschäftsleitung – unabhängig von D&O-Versicherungen. Das ist seit der letzten NIS2-Novelle keine theoretische Frage mehr.

Incident Response: Übung vor dem Ernstfall

Ein klarer Incident-Response-Plan ist Pflicht. Diese Fragen sollten beantwortet sein, bevor der Ernstfall eintritt:

• Wer wird bei einem erkannten Vorfall sofort benachrichtigt?
• Welche Systeme werden isoliert, und durch wen?
• Wer kommuniziert intern, mit Kunden, mit Behörden?
• Wer dokumentiert für Forensik, Versicherung und Meldepflichten?

Eine durchdachte Reaktion mit klaren Rollen reduziert den Schaden erheblich. Mindestens einmal im Jahr gehört eine Tabletop-Exercise auf den Tisch – ein durchgespieltes Szenario mit allen Beteiligten, ohne realen Druck. Wer erst während des Vorfalls anfängt zu klären, wer was tut, hat schon verloren.

Vom Konzept zur Umsetzung: Fünf Schritte, die wirklich funktionieren

Aus den fünf Bausteinen ein konkretes IT-Konzept zu bauen, ist weniger geheimnisvoll als viele Beratungsangebote suggerieren. Fünf Schritte führen zu einem belastbaren Ergebnis – mit oder ohne externe Hilfe.

Schritt 1: Ehrliche Bestandsaufnahme

Was steht im Haus, was läuft im Hintergrund, was wurde vergessen? Eine ehrliche Inventur deckt mehr auf als die Verantwortlichen erwarten:

• Schatten-IT einzelner Abteilungen, gekauft an der IT vorbei
• Vergessene Server mit veralteter Software und offenen Ports
• Aktive Zugänge ehemaliger Mitarbeitender
• Lizenzen für Software, die niemand mehr nutzt

Automatisierte Discovery-Tools beschleunigen die Inventur erheblich, aber sie ersetzen nicht das Gespräch mit den Abteilungen. Schatten-IT findest du nicht im Netzwerk-Scan, sondern im Gespräch über die echten Workflows.

Schritt 2: Bedarfsanalyse aus Geschäftssicht

Schritt zwei wechselt die Perspektive. Welche Geschäftsprozesse müssen unterstützt werden, welche Skalierungsfragen stehen an, welche externen Anforderungen gibt es?

Die Bedarfsanalyse gehört nicht in die IT-Abteilung allein. Sinnvoll wird sie erst mit Input aus Vertrieb, Produktion, HR und Finanzen – sonst entsteht eine technisch hübsche Antwort auf die falschen Fragen. Halbtägige Workshops mit jeder Abteilung sind das Mindeste.

Schritt 3: Lückenanalyse mit Risiko-Matrix

Die Lücke zwischen Ist und Bedarf ist der Handlungsraum. Jede gefundene Lücke wird in einer Matrix priorisiert:

Nicht alles muss sofort behoben werden – aber alle Lücken müssen sichtbar bleiben. Eine Lücke, die bewusst nicht angegangen wird, ist ein anderer Zustand als eine Lücke, die nicht erkannt wurde.

Schritt 4: Roadmap mit Budget und Terminen

Die Roadmap übersetzt die Priorisierung in einen Zeitplan. Welche Maßnahmen werden in welcher Reihenfolge umgesetzt, mit welchem Budget, durch wen, bis wann?

Eine realistische Roadmap denkt drei bis fünf Jahre voraus. Die Details des dritten Jahres dürfen unscharf bleiben, aber die Richtung muss stehen. Die Roadmap wird zur Steuerungsgrundlage für Geschäftsleitung, IT-Leitung und Fachbereiche.

Schritt 5: Umsetzung mit Review-Rhythmus

IT-Konzepte sind keine einmaligen Dokumente, sondern lebende Strukturen. Mindestens jährlich gehört das Konzept auf den Tisch, bei größeren Änderungen sofort.

Was die meisten Unternehmen unterschätzen: die Pflege. Ein einmal erarbeitetes IT-Konzept hat eine Halbwertszeit von wenigen Jahren. Wer es nicht pflegt, hat in fünf Jahren wieder Wildwuchs.

FAQ – Häufige Fragen zu IT-Konzepten

Was wir empfehlen – und wo wir skeptisch bleiben

Wenn du heute mit einem IT-Konzept startest, mach drei Dinge in dieser Reihenfolge: Ehrliche Bestandsaufnahme, Bedarfsanalyse mit den Fachbereichen, Risiko-Matrix. Alles weitere folgt daraus.

Wir bleiben skeptisch gegenüber zwei Trends: erstens dem Cloud-First-Reflex, der Souveränitäts-Fragen auf später vertagt. Zweitens dem KI-Hype, der in vielen Konzepten als Vorwand für teure Plattform-Käufe dient, ohne dass jemand sauber definieren kann, welches Geschäftsproblem damit gelöst wird.

Ein gutes IT-Konzept beantwortet weniger Fragen mit „mehr davon“ und mehr Fragen mit „weniger davon, dafür besser“.

Quellen

• BSI – Bundesamt für Sicherheit in der Informationstechnik: IT-Grundschutz-Kompendium
• ENISA – European Union Agency for Cybersecurity: Cybersecurity Frameworks
• DIN – Deutsches Institut für Normung: ISO/IEC 27001:2022
• EU-Kommission: NIS2-Richtlinie
• Bitkom: Branchenstudien zur IT-Infrastruktur
• ISACA: Frameworks für IT-Governance und Audit