Sie erhalten eine unabhängige Einschätzung mit klarer Handlungsempfehlung – herstellerunabhängig, methodisch belastbar, direkt einsetzbar in Freigabe und Steuerkreis.
ALTEMIS Consulting ist eine technische Unternehmensberatung mit Sitz in Kehl (Ortenaukreis), spezialisiert auf technische Reviews, Engineering-Consulting und Prozessautomatisierung für mittelständische Industrieunternehmen in Baden-Württemberg.
Das Ergebnis liegt vor – aber die Freigabe ist in zwei Wochen.
Keine interne Instanz, die das Ergebnis methodisch einordnet und die Entscheidung absichert.
Messung und Modell widersprechen sich. Serienstart: nächsten Monat.
Widersprüche ohne Ursache blockieren Freigaben – und keiner will die Verantwortung allein übernehmen.
Ihr bester Ingenieur verbringt 3 Stunden pro Woche mit Excel-Copy-Paste.
Kapazität, die in echte Entwicklungsarbeit fließen sollte – nicht in Datenpflege.
Kein Thermik-Spezialist im Team – der Meilenstein ist in 3 Wochen.
Dafür braucht niemand einen Vollzeit-Experten. Nur eine belastbare Einschätzung.
Belastbare Entscheidungsgrundlagen bei hoher technischer Unsicherheit.
Struktur in komplexe technische Fragestellungen bringen.
Entscheidungsrelevantes technisches Verständnis aufbauen.
Manuelle Prozesse automatisieren – ohne IT-Großprojekt.
Einzeln oder kombiniert buchbar. Projektbezogen, tageweise oder als monatlicher Retainer – angepasst an Ihre Situation.
Honorar auf Anfrage – leistungsbezogen und transparent. Vergütungsmodelle und typische Preisrahmen werden im Erstgespräch besprochen. Einen ehrlichen Überblick bietet der Artikel Was kostet technische Beratung?
„Ich hab vorher stundenlang manuell auf eBay Preise verglichen — oder es einfach gelassen. Jetzt sehe ich täglich auf einen Blick, wo ich zu teuer oder zu günstig bin, was die Wettbewerber verlangen und welche Produkte gerade gefragt sind. Preise passe ich direkt aus dem Dashboard an."
— Geschäftsführung · Online-Handel, Baden-Württemberg
„Zum ersten Mal weiß jeder Mitarbeitende, wo ein Vorgang liegt und wer zuständig ist. Die Einführung lief überraschend reibungslos — weil wir die Prozesse zuerst strukturiert haben, statt sofort eine Software einzuführen."
— Sachbereichsleitung · Stadtverwaltung, Südliches Baden-Württemberg
Klar, effizient, ohne Overhead.
Erstgespräch
45 Minuten. Kostenlos. Fragestellung einordnen, Rahmen klären.
Angebot & Scope
Klares Angebot mit definiertem Umfang, Zeitrahmen und Ergebnis.
Analyse & Bearbeitung
Methodisches Vorgehen, regelmäßige Abstimmung, transparenter Fortschritt.
Ergebnis & Übergabe
Dokumentierter Output, entscheidungsreif – für Fach- und Managementebene.
Ihre Frage ist nicht dabei?
Erstgespräch vereinbaren →Fachbeiträge von Alper Altay — Technische Einordnungen, Methodikfragen und ehrliche Antworten für Ingenieure und Entscheider in Industrieunternehmen.
Sie kennen das Gefühl: Das Ergebnis liegt vor – aber irgendetwas stimmt nicht.
Kostenloses Erstgespräch – unverbindlich, 45 Minuten.
Projektleiter und Entwicklungsingenieur aus der Konzern-Vorentwicklung. Lehrbeauftragter an der DHBW Karlsruhe.
Gründer von ALTEMIS Consulting – technische Beratung für Industrieunternehmen.
"Das Ergebnis liegt vor – aber irgendetwas stimmt nicht." Diesen Satz habe ich in der Konzern-Vorentwicklung oft gehört. Und meist hatte das Gefühl Recht.
Analysen lagen vor. Konzepte waren fertig. Aber niemand ordnete sie entscheidungsrelevant ein. Diese Lücke habe ich in der Konzern-Vorentwicklung immer wieder erlebt – und ALTEMIS gegründet, um sie zu schließen.
Ich stehe für unabhängige, methodisch fundierte technische Beratung. Nicht als Tool-Dienstleister, nicht als Kapazitätsressource – sondern als Urteilsinstanz, die einordnet, strukturiert und Entscheidungen absichert.
Branchenoffen mit Schwerpunkterfahrung in Automotive und Elektronik. Projektbezogen, tageweise oder als monatlicher Retainer.
„Technische Tiefe und klare Entscheidungen – das ist kein Widerspruch. Es ist das Ziel jedes Projekts."
Gründer, ALTEMIS Consulting
Aktuelle Tätigkeiten
DHBW Karlsruhe
Lehrbeauftragter · seit August 2025
Vorlesungen und Workshops zu Systemarchitekturen & MBSE.
„Herr Altay hat seine Lehrveranstaltung mit einem spektakulär guten Evaluationsergebnis abgeschlossen."
— Studiengangsleiter Wirtschaftsingenieurwesen, DHBW Stuttgart
Robert Bosch GmbH
Projektleiter & Entwicklungsingenieur · seit März 2022
Technologie-Vorentwicklung Leiterplattensysteme (PCB), thermische Analysen, Leitung technischer Arbeitsgruppen.
Frühere Stationen
DHBW Stuttgart
Lehrauftrag · 2023
Messtechnik.
Startup Karlsruhe
Nebenberufliche Mitarbeit · Oktober 2023 – Juni 2025
Programmierung, Digitalisierung und Prozessautomatisierung. Aufbau von Onlineshops und digitalen Vertriebsstrukturen. Unterstützung der Geschäftsleitung bei strategischen Entscheidungen.
Siemens AG
Masterarbeit · Oktober 2021 – Februar 2022
Technische und wirtschaftliche Bewertung sowie Feinkonzeptionierung von Matrix-Produktionssystemen in der Elektronikfertigung. Standort: Karlsruhe (Elektronikwerk).
KIT Karlsruhe
M.Sc. Maschinenbau · Oktober 2019 – Februar 2022
Studium mit Schwerpunkt Produktentwicklung, Mechatronik und Fertigungstechnik.
Veröffentlichungen
Simulationsgestütztes Vorgehensmodell zur Realisierung einer Matrixfertigung – Zeitschrift für wirtschaftlichen Fabrikbetrieb (ZWF). Artikel ansehen →
Technische und wirtschaftliche Bewertung sowie Feinkonzeptionierung eines Matrix-Produktionssystems für die Elektronikproduktion
Evaluation von Variationen in der PGE in der Entwicklung eines Prüf- und Kalibriersystems für Durchflussmessgeräte
Kein Tool-Interesse. Die Analyse folgt der Fragestellung.
Tiefe auf Fachebene. Klarheit auf Entscheidungsebene.
Strukturiert, dokumentiert, nachvollziehbar. Keine Blackbox.
Kostenloses Erstgespräch – unverbindlich, 45 Minuten.
Kostenloses Erstgespräch – 45 Minuten. Fragestellung einordnen, Aufwand klären, unverbindlich.
Wählen Sie einen freien Slot – ich bin vorbereitet und wir starten direkt ins Gespräch.
Kein Account erforderlich · Bestätigung per E-Mail
Alper Altay
Gründer · ALTEMIS Consulting
Sie schreiben direkt an mich.
Noch nicht sicher ob es passt? Schildern Sie kurz Ihre Situation – ich melde mich innerhalb von 24 Stunden.
Methodikfragen, Entscheidungslogik und ehrliche Antworten für Industrieunternehmen – von einem Ingenieur, der beide Seiten kennt.
Direkt herunterladen – kein Formular, kein Account erforderlich.
Ist Ihre Simulation entscheidungsreif?
10 Prüfpunkte aus der Praxis – bevor Sie auf Basis einer Simulation investieren oder freigeben.
PDF öffnen5 Fragen vor einem externen technischen Review
Damit das Review die richtige Antwort liefert – nicht nur eine zweite Meinung.
PDF öffnenTechnische Beratung beauftragen – worauf KMU achten sollten
Vergütungsmodelle, Scope-Definition und typische Stolperfallen – kompakt auf 3 Seiten.
PDF öffnenFDM-Simulationen (Finite-Differenzen-Methode) sind im PCB-Thermalmanagement weit verbreitet. Sie sind schnell, gut skalierbar und in Tools wie CR8000 oder Icepak tief integriert. Das Problem: Ihre Ergebnisse werden oft falsch interpretiert – nicht weil die Ingenieure schlecht ausgebildet sind, sondern weil bestimmte Modellfehler systematisch übersehen werden.
Im Folgenden zeige ich die fünf häufigsten Fehler aus meiner Praxis aus der Konzern-Vorentwicklung – und was sie im schlechtesten Fall bedeuten.
Der thermische Kontaktwiderstand (R_contact) zwischen Bauteil und Leiterplatte wird in FDM-Modellen häufig mit einem Standardwert belegt – oder gänzlich vernachlässigt. In der Praxis schwankt dieser Wert je nach Lötmaterial, Bondpad-Geometrie und Fertigungstoleranz erheblich.
Konsequenz: Die simulierte Junctiontemperatur liegt zu niedrig. Ein Bauelement, das im Modell bei 95 °C liegt, kann real 110–120 °C erreichen. Für einen Serienentscheid auf Basis dieser Simulation ist das gefährlich.
Rechenzeit ist begrenzt. Die Folge: Ingenieure wählen ein grobes, uniformes Gitter – und hoffen, dass die Temperaturgradienten im Bereich kritischer Komponenten trotzdem korrekt abgebildet werden. Das ist selten der Fall.
Besonders problematisch sind Via-Arrays und enge Bauteilgruppen. Hier entstehen starke lokale Gradienten, die ein grobes FDM-Gitter schlicht ausmittelt. Das Ergebnis sieht glatt aus – und ist es nicht.
„Freie Konvektion, 25 °C Umgebung" – das ist die häufigste Randbedingung in Review-Dokumenten. In vielen Fällen bildet sie die reale Einbausituation nicht ab. Ob ein Board in einem geschlossenen Gehäuse verbaut ist, ob es vorgewärmte Luft aus benachbarten Komponenten empfängt oder ob der Wärmeübertragungskoeffizient h aus einer Tabelle stammt: All das hat massiven Einfluss auf das Ergebnis.
Ich habe Projekte gesehen, in denen der Wechsel von h = 10 W/m²K auf h = 6 W/m²K die Maximaltemperatur um über 15 °C verschoben hat.
Simulationen ohne Messkorridor sind Hypothesen. Trotzdem werden in vielen Entwicklungsprojekten Designentscheidungen auf Basis nicht-validierter Simulationsmodelle getroffen – oft aus Zeitdruck.
Das ist kein Vorwurf, sondern eine strukturelle Realität. Aber es muss dokumentiert und kommuniziert werden. Eine Simulation, die nie gegen Messdaten abgeglichen wurde, hat eine unbekannte Unsicherheit. Diese Unsicherheit gehört in den Entscheidungsprozess.
Unterhalb von ~60–70 °C ist Strahlung gegenüber Konvektion und Leitung oft vernachlässigbar. Bei höheren Temperaturen (Hochleistungs-PCBs, Leistungselektronik) kann der Strahlungsanteil 10–20 % der abgeführten Wärme ausmachen. In vielen FDM-Tools ist Strahlung optional – und bleibt deshalb oft deaktiviert.
Das führt zu systematisch zu hohen Temperaturen im Modell – was klingt wie ein konservativer Ansatz, aber je nach Designmarge zu unnötigem Over-Engineering führt.
Keiner dieser Fehler bedeutet, dass eine Simulation wertlos ist. Sie bedeuten, dass Simulationsergebnisse ohne methodische Einordnung keine belastbare Entscheidungsgrundlage sind. Die Frage ist nicht, ob das Modell läuft – sondern ob es das abbildet, was es abbilden soll.
Genau das ist die Aufgabe eines technischen Reviews: nicht die Simulation neu zu erstellen, sondern ihre Aussagekraft methodisch einzuordnen. Wenn eine externe Einordnung nötig ist, beschreibt die Leistungsseite Technische Reviews den genauen Ablauf.
Weitere Artikel
Ich ordne FDM- und CFD-Simulationen methodisch ein – unabhängig vom Hersteller, entscheidungsrelevant aufbereitet.
Erstgespräch vereinbaren →Mehr zur Leistung: Technische Reviews & Gutachten →
„Wir brauchen eine CFD-Simulation" – diesen Satz höre ich oft. Manchmal ist er richtig. Manchmal wäre FEM die bessere Wahl. Und manchmal ist keine der beiden Methoden das eigentliche Problem.
Dieser Artikel klärt die methodischen Unterschiede – und zeigt, wann welcher Ansatz die Entscheidung stützt und wann er sie verschleiert.
CFD (Computational Fluid Dynamics) modelliert Strömungen: Luft, Kühlmittel, Gase. Für thermische Analysen bedeutet das: CFD ist stark, wenn Konvektion der dominierende Wärmepfad ist – also bei erzwungener Kühlung, Kanalgeometrien, Kühlkörpern mit komplexen Rippenstrukturen oder Flüssigkeitskühlung.
FEM (Finite-Elemente-Methode) modelliert Festkörper: Wärmeleitung, mechanische Spannungen, Strukturverhalten. Für thermische Analysen ist FEM stark, wenn Leitung und Kontaktwiderstände dominieren – also bei kompakten Baugruppen, Wärmespreizung über Substrat, Chip-Package-Interface.
Die Wahl der Methode folgt der Physik – nicht dem Tool-Bestand. Die entscheidende Frage lautet: Wo entsteht der größte thermische Widerstand im System? Ist es die Konvektion zur Umgebungsluft? Dann CFD. Ist es die Leitung durch Materialschichten und Kontakte? Dann FEM.
In der Praxis ist die Antwort oft: beides. Dann braucht man keine neue Simulation – sondern eine methodische Einordnung, welcher Wärmepfad für die aktuelle Entscheidung relevant ist.
Ich erlebe regelmäßig Situationen, in denen Teams eine aufwändige CFD-Analyse beauftragen – und am Ende trotzdem keine Entscheidung treffen können. Nicht weil die Simulation falsch war, sondern weil die Fragestellung nicht scharf genug definiert war.
In solchen Fällen hilft ein unabhängiges Technisches Review, das die Methode – nicht nur das Ergebnis – bewertet.
| Fragestellung | Empfehlung | Hinweis |
|---|---|---|
| Gehäusebelüftung, Lüfterauslegung | CFD | Turbulenzmodell kritisch prüfen |
| Junctiontemperatur, Chip-Package | FEM / FDM | Kontaktwiderstände validieren |
| Systemebene, mixed-mode | CFD + FEM gekoppelt | Hoher Aufwand, gut begründen |
Weitere Artikel
Die Methodenwahl ist keine akademische Frage – sie beeinflusst direkt, wie belastbar Ihre Entscheidungsgrundlage ist. Wer CFD oder FEM als Blackbox beauftragt, bekommt Zahlen. Wer die Methode zur Fragestellung passend wählt, bekommt Entscheidungssicherheit. Der Unterschied liegt nicht in der Software, sondern in der methodischen Einordnung davor.
Ich bewerte CFD- und FEM-Simulationen unabhängig – und zeige, ob die gewählte Methode zur Fragestellung passt.
Erstgespräch vereinbaren →Mehr zur Leistung: Technische Reviews & Gutachten →
„Wir brauchen Power BI" – das ist oft der erste Gedanke, wenn ein Unternehmen merkt, dass seine Excel-Prozesse zu langsam, fehleranfällig oder unübersichtlich werden. Manchmal stimmt das. Häufig ist es aber eine teurere Lösung als nötig.
Dieser Artikel gibt eine ehrliche Entscheidungshilfe – aus der Perspektive eines Ingenieurs, der beide Welten aus der Praxis kennt.
Excel ist nicht trotz seiner Schwächen so verbreitet – es ist wegen seiner Stärken so verbreitet. Es ist überall vorhanden, jeder kennt es, Daten lassen sich flexibel eintippen und strukturieren. Für viele Prozesse in der Industrie – Stücklisten, Messkurvenauswertung, Projekttracking – ist Excel nicht das Problem. Das Problem ist die Art, wie es genutzt wird.
Manuelle Dateneingabe, Copy-Paste zwischen Dateien, keine Versionskontrolle, Formeln die niemand mehr versteht: Das kostet Ingenieurzeit. Und das ist lösbar – ohne Power BI.
Excel mit VBA oder Python (via xlwings/openpyxl) lohnt sich, wenn:
Ein Entwicklungsteam wertet wöchentlich Messdaten aus 12 Prüfständen aus, kopiert Werte in ein Template und erstellt manuell Diagramme. Aufwand: 3–4 Stunden pro Woche. Nach einer Excel-VBA-Automatisierung: 10 Minuten. Kein Power BI, keine neue IT-Infrastruktur, keine Schulung.
Für Unternehmen, die Automatisierungspotenzial identifizieren wollen, gibt es mehr Details auf der Leistungsseite Prozessautomatisierung.
Power BI lohnt sich, wenn:
Für die meisten mittelständischen Industrieunternehmen lautet die Reihenfolge:
Der häufigste Fehler ist, Schritt 3 vor Schritt 1 zu machen.
Was oft übersehen wird: Die Entscheidung zwischen Excel und Power BI ist nicht endgültig. Viele mittelständische Unternehmen nutzen beide Werkzeuge parallel – Excel für operative Automatisierungen einzelner Fachbereiche, Power BI für das übergreifende Reporting. Entscheidend ist, dass diese Aufgabentrennung bewusst getroffen und dokumentiert wird. Werkzeugkonflikte entstehen fast immer dort, wo diese Entscheidung implizit geblieben ist.
Weitere Artikel
Ich analysiere Ihre Prozesse und empfehle die passende Lösung – pragmatisch, ohne IT-Großprojekt.
Erstgespräch vereinbaren →Mehr zur Leistung: Prozessautomatisierung & Digitalisierung →
Es war ein Dienstagmorgen in der Vorentwicklung. Das Team hatte drei Wochen an einer thermischen Simulation gearbeitet. Die Ergebnisse lagen vor: Heatmaps, Maximaltemperaturen, Vergleich zwischen vier Varianten. Alles sauber dokumentiert. Und trotzdem konnte die Runde keine Entscheidung treffen.
Nicht weil die Simulation schlecht war. Sondern weil niemand wusste, wie sicher die Ergebnisse waren.
In vielen Entwicklungsprojekten entsteht eine stille Übereinkunft: Wer eine Simulation vorlegt, hat eine Antwort geliefert. Das Ergebnis wird akzeptiert – nicht weil es verstanden wird, sondern weil es existiert.
Diese Ergebnisgläubigkeit ist gefährlich. Nicht weil Simulationen unzuverlässig sind, sondern weil sie immer Modelle der Realität sind – mit Annahmen, Grenzen und Unsicherheiten, die selten explizit kommuniziert werden.
Ein Simulationsergebnis beantwortet die Frage: Was sagt das Modell? Eine Entscheidungsgrundlage beantwortet die Frage: Was können wir mit diesem Ergebnis sicher schlussfolgern?
Der Unterschied liegt in drei Dimensionen:
Diese drei Fragen werden in vielen Projekten nicht gestellt – oft aus Zeitdruck, manchmal weil niemand zuständig ist.
Ein Entwicklungsteam hat eine FEM-Simulation für ein Leistungsmodul erstellt. Die Maximaltemperatur liegt laut Simulation bei 118 °C – der Grenzwert ist 125 °C. „Passt, haben 7 K Reserve." Projekt weiter.
Was nicht kommuniziert wurde: Der Wärmeübergangskoeffizient wurde aus einer Literaturquelle übernommen. Die Sensitivitätsanalyse zeigt: ±20 % Variation in diesem Parameter bedeutet ±9 K in der Junctiontemperatur. Die 7 K Reserve sind methodisch nicht belastbar.
Das ist kein Fehler des Ingenieurs. Es ist ein strukturelles Problem: Der Übergang vom Ergebnis zur Entscheidung wurde nicht explizit gestaltet.
Ein gutes technisches Review erstellt keine neue Simulation. Es ordnet das Bestehende methodisch ein. Mehr zum konkreten Ablauf und Scope: Technisches Review & Gutachten.
Das Ziel ist nicht Kritik um der Kritik willen. Es ist Klarheit: Was wissen wir sicher – und was nicht?
Immer dann, wenn Entscheidungen mit hoher Tragweite auf technischen Ergebnissen basieren – und niemand im Team die methodische Unabhängigkeit oder die Zeit hat, das Ergebnis wirklich einzuordnen. Das betrifft Meilensteinentscheidungen, Investitionsfreigaben, Serienfreigaben und externe Gutachten.
Weitere Artikel
Genau das ist meine Kernleistung: methodische Einordnung, die aus Daten belastbare Entscheidungen macht.
Erstgespräch vereinbaren →Mehr zur Leistung: Technische Reviews & Gutachten →
MBSE (Model-Based Systems Engineering) gilt in vielen mittelständischen Unternehmen als zu komplex, zu teuer und zu akademisch. Diese Wahrnehmung ist verständlich – und teilweise berechtigt. Wer MBSE mit Cameo Enterprise oder IBM Rhapsody gleichsetzt, versteht es als IT-Projekt, das Millionen kostet.
Das ist eine falsche Gleichsetzung. MBSE ist eine Denkweise. Die Tools sind optional.
Im Kern bedeutet MBSE: Ein System wird nicht primär durch Dokumente beschrieben, sondern durch ein strukturiertes Modell – Funktionen, Anforderungen, Komponenten und ihre Beziehungen sind explizit verknüpft.
Der praktische Nutzen: Wenn sich eine Anforderung ändert, sieht das Team sofort, welche Komponenten und Funktionen davon betroffen sind. Wenn ein Subsystem neu ausgelegt wird, ist klar, welche Systemziele es erfüllen muss.
Nicht SysML. Nicht Cameo. Was gebraucht wird, ist eine klare Struktur, die das Team versteht und anwendet. In meiner Arbeit mit Entwicklungsteams nutze ich einen tool-neutralen, MBSE-nahen Ansatz:
Das lässt sich in PowerPoint, Confluence oder einem strukturierten Excel aufbauen. Der Mehrwert entsteht nicht durch das Tool – sondern durch die Konsequenz, mit der die Struktur gepflegt wird.
Ein Team entwickelt ein aktives Kühlsystem für ein Leistungsmodul. Die typische Situation: Anforderungen in einem Word-Dokument, Simulationen in separaten Ordnern, Komponentenauswahl in einer Excel-Tabelle. Niemand hat den Überblick, welche Anforderung durch welche Komponentenentscheidung erfüllt – oder gefährdet – wird.
Ein MBSE-naher Ansatz in 4 Sessions: Systemkontext definieren, Funktionsstruktur aufbauen, Anforderungen verknüpfen, Komponenten zuordnen. Ergebnis: Ein Dokument, das das Team nutzt – kein Modell, das in einem Tool verstaubt.
MBSE-Einführung scheitert selten an der Methodik. Sie scheitert daran, dass niemand im Team die Zeit hat, die Struktur initial aufzubauen und zu moderieren. Ein externer Begleiter bringt Methodik, Moderationserfahrung und die Fähigkeit, Komplexität zu reduzieren ohne Inhalte zu vereinfachen. Wie externe methodische Begleitung in der Praxis aussieht, zeigt die Leistungsseite Engineering-Consulting.
Das Format: 4–8 Sessions à 2 Stunden, mit definierten Outputs nach jeder Session. Kein Dauerprojekt, keine Tool-Einführung, keine Zertifizierung.
Weitere Artikel
Was am Ende bleibt: ein Team, das systemisch denkt. Das Modell, die Sprache und die Methode gehören dem Unternehmen – nicht dem Berater. Keine Abhängigkeit von externen Werkzeugen, keine Zertifizierungspflicht. Systemdenken ist eine Fähigkeit, kein Tool. Das ist der eigentliche Mehrwert eines pragmatischen MBSE-Einstiegs.
Ich begleite mittelständische Teams beim Aufbau von Systemdenken – tool-neutral und sofort anwendbar.
Erstgespräch vereinbaren →Mehr zur Leistung: Engineering & System-Consulting →
Aber wann ist der richtige Zeitpunkt? Hier sind fünf Situationen, die in der Praxis ein klares Signal sind.
Entscheidungen mit hoher finanzieller oder strategischer Tragweite brauchen eine belastbare technische Grundlage. Wenn interne Simulationen und Analysen die Basis dieser Entscheidung bilden, ist eine unabhängige Einordnung keine Absicherung gegen das eigene Team – sondern gegen systematische Blindstellen, die jedes Team hat.
Widersprüchliche Daten sind eines der häufigsten Projektsignale, das ich erlebe. Simulation sagt X, Messung sagt Y, beide Werte liegen im „möglichen" Bereich. Das Team diskutiert seit Wochen. Kein Fortschritt.
Hier hilft ein externes Review nicht primär durch eine neue Simulation – sondern durch methodische Einordnung: Wo liegt die Ursache des Widerspruchs? Was muss geprüft werden, bevor eine Entscheidung getroffen wird?
Viele Unternehmen erhalten Gutachten von Lieferanten, Instituten oder externen Dienstleistern – und können die Qualität der Annahmen nicht einschätzen. „Das klingt plausibel" ist keine Entscheidungsgrundlage.
Ein Review prüft: Welche Annahmen trägt das Gutachten? Sind sie für Ihren spezifischen Anwendungsfall gültig? Was würde sich ändern, wenn eine Annahme nicht hält?
Nicht jedes Unternehmen hat für jede Fragestellung einen internen Experten. Ein PCB-Thermik-Spezialist fehlt? Ein MBSE-erfahrener Systemingenieur ist nicht im Team? Das ist keine Schwäche – das ist der Normalfall im Mittelstand.
In diesen Situationen ist ein projektbezogenes externes Review kosteneffizienter als eine Festanstellung oder eine Großberatung.
Zeitdruck ist der häufigste Feind methodischer Qualität. Wenn ein Team weiß, dass eine Analyse lückenhaft ist, aber keine Kapazität hat, sie zu verbessern – dann ist das der richtige Moment für einen externen Beitrag. Nicht um Arbeit abzunehmen, sondern um die methodische Einordnung zu liefern, die das Team nicht leisten kann.
Weitere Artikel
Ein externes technisches Review ist kein Misstrauensvotum gegen das interne Team. Es ist kein Audit und kein Qualitätsmanagementsystem. Es ist eine zeitlich begrenzte Erweiterung der methodischen Perspektive – durch jemanden, der ähnliche Fragestellungen aus anderen Kontexten kennt und keinen internen Erwartungsdruck hat.
Teams, die das verstanden haben, setzen externe Reviews gezielt und vorausschauend ein – nicht als Reaktion auf Probleme, sondern als strukturelles Element ihrer Qualitätssicherung. Der Unterschied: reaktive Reviews retten Projekte. Vorausschauende Reviews verhindern, dass sie gerettet werden müssen.
Im kostenlosen Erstgespräch ordne ich ein, ob und welcher Review-Umfang für Ihre Situation sinnvoll ist.
Erstgespräch vereinbaren →Mehr zur Leistung: Technische Reviews & Gutachten →
„Was kostet das ungefähr?" ist die häufigste Frage im Erstgespräch. Und die ehrliche Antwort lautet: Es hängt ab. Aber das ist keine Ausweichung – es ist der Ausgangspunkt für eine seriöse Einschätzung.
Dieser Artikel erklärt, wie technische Beratungsleistungen typischerweise bepreist werden, was die Preisunterschiede erklären – und was ein Unternehmen realistisch erwarten sollte.
Der klassische Ansatz. Ein Tagessatz für technische Fachberatung mit Senior-Profil liegt je nach Spezialisierung und Markt zwischen 1.200 € und 2.500 € pro Tag (netto). Für hochspezialisierte Nischen (Luft- und Raumfahrt, Medizintechnik, regulierte Bereiche) auch darüber.
Vorteil: Flexibel, transparent. Nachteil: Das Gesamtbudget ist nicht von Anfang an klar.
Für klar definierte Leistungen – z.B. ein technisches Review-Dokument mit definierten Inhalten und Umfang – eignet sich ein Pauschalpreis. Das schafft Planungssicherheit für beide Seiten.
Typischer Rahmen für ein strukturiertes Review-Dokument: 1.500–4.500 € je nach Umfang und Tiefe.
Für Unternehmen, die regelmäßig methodische Unterstützung brauchen – z.B. ein festes Stundenkontingent pro Monat. Das lohnt sich ab etwa 2–4 Engagements pro Monat.
Ich arbeite transparent mit Tagessatz oder Pauschalpreis, je nach Aufgabenstellung. Die genaue Einschätzung erfolgt nach dem Erstgespräch – dort kläre ich Fragestellung, Umfang und Format, bevor ich ein konkretes Angebot mache.
Das Erstgespräch ist kostenlos und unverbindlich. Es dient nicht dem Verkauf, sondern der methodischen Einordnung: Kann ich helfen? Wie? Mit welchem Aufwand?
Weitere Artikel
Technische Beratung ist kein Standardprodukt. Was im Honorar enthalten ist, hängt vom Modell ab – aber in jedem Fall gilt: Sie bezahlen nicht für Anwesenheit, sondern für methodische Einordnung und Entscheidungssicherheit.
Im Projekteinsatz bedeutet das: klare Dokumentation der Ergebnisse, nachvollziehbare Herleitung und eine Einordnung, die Ihr Team ohne externe Unterstützung weiternutzen kann. Im Retainer-Modell kommt strategische Kontinuität hinzu – das Wissen über Ihre Systeme, Prozesse und Entscheidungslogiken baut sich über Zeit auf und muss nicht nach jedem Auftrag neu erarbeitet werden.
Transparenz über Kosten ist kein Vertrauensbeweis, sondern eine Voraussetzung für eine seriöse Zusammenarbeit. Wenn ein Berater keine klare Auskunft über sein Vergütungsmodell gibt, ist das ein Signal – kein Einzelfall.
Im Erstgespräch ordnen wir Ihren Bedarf ein und ich nenne Ihnen einen klaren Rahmen – ohne versteckte Kosten.
Erstgespräch vereinbaren →Alle Leistungen im Überblick: Leistungsseite →
Dieser Artikel erklärt die Unterschiede zwischen Projektauftrag und Retainer, nennt Vor- und Nachteile beider Modelle – und gibt eine klare Entscheidungshilfe.
Ein Projektauftrag hat einen definierten Anfang, ein definiertes Ende und ein definiertes Ergebnis. „Review des thermischen Simulationsmodells für Bauteil X – Ergebnis: Review-Dokument mit Handlungsempfehlung" ist ein typischer Projektauftrag.
Ein Retainer ist ein monatliches Stundenkontingent – z.B. 8 oder 16 Stunden pro Monat – das flexibel für verschiedene Themen genutzt werden kann. Der Auftragnehmer ist verlässlich verfügbar; der Auftraggeber hat eine Ansprechperson, die das Unternehmen kennt.
| Projektauftrag wenn… | Retainer wenn… |
|---|---|
| Einmaliger, klar definierter Bedarf | Regelmäßiger Beratungsbedarf (2–4×/Monat) |
| Kein laufendes Commitment gewünscht | Laufendes Projekt mit wechselnden Fragen |
| Ergebnis klar definierbar | Kontinuität wichtiger als Einzelergebnis |
Starten Sie mit einem Projektauftrag. Wenn nach dem ersten Projekt klar ist, dass der Bedarf regelmäßig ist, ergibt ein Retainer Sinn. So entstehen keine falschen Erwartungen – auf keiner Seite.
Welches Modell für Ihre Situation passt, klären wir im Erstgespräch.
Weitere Artikel
Die meisten Zusammenarbeiten beginnen mit einem Projektauftrag. Ein klar umrissenes Problem, ein definiertes Ergebnis, ein zeitlicher Rahmen. Das gibt beiden Seiten die Möglichkeit zu verstehen, wie die andere arbeitet – ohne langfristige Bindung.
Wenn aus diesem ersten Auftrag eine Zusammenarbeit entsteht, die sich wiederholt oder vertieft, ist der Wechsel in ein Retainer-Modell oft der nächste logische Schritt. Nicht weil es günstiger ist – sondern weil es effizienter ist. Weniger Briefing-Aufwand, mehr Kontinuität, schnellere Reaktion auf neue Fragestellungen.
Ein Retainer muss dabei nicht bedeuten: fester wöchentlicher Termin und definierte Stundenzahl. Er kann auch bedeuten: Abrufbarkeit bei konkretem Bedarf, mit einem monatlichen Sockelbetrag, der Planbarkeit auf beiden Seiten sicherstellt. Die genaue Ausgestaltung ist verhandelbar – und sollte es auch sein. Was nicht verhandelbar sein sollte: Klarheit darüber, was beide Seiten voneinander erwarten.
Im Erstgespräch besprechen wir offen, welche Zusammenarbeit sinnvoll ist – ohne Verkaufsdruck.
Erstgespräch vereinbaren →Alle Leistungen im Überblick: Leistungsseite →
Im Jahr 2021 wurde die Siemens AG am Standort Karlsruhe als Fabrik des Jahres ausgezeichnet. Einer der Gründe: die konsequente Einführung eines Matrixproduktionssystems mit digitalen Zwillingen und fahrerlosen Transportsystemen. Was von außen wie ein großes IT-Projekt wirkt, begann mit einer sehr klassischen Ingenieursfrage: Wie bewerten wir drei verschiedene Konzeptalternativen – methodisch, transparent und entscheidungsrelevant?
Ich war an diesem Projekt beteiligt und habe das Vorgehensmodell sowie die technisch-wirtschaftliche Feinplanung erarbeitet. Was ich dabei gelernt habe, geht weit über Matrixfertigung hinaus – es betrifft jeden Planungsprozess, bei dem Simulation und Entscheidung zusammenkommen müssen.
Das Ausgangsszenario ist typisch für den Mittelstand: Ein bestehendes Fertigungssystem – in diesem Fall eine Festverkettung aus manuellen und automatisierten Bestückplätzen – kommt an seine Grenzen. Steigende Produktvarianten, kürzere Lebenszyklen, wechselnde Losgrößen.
Das Team hatte drei technisch unterschiedliche Konzeptalternativen erarbeitet. Alle plausibel. Alle vertretbar. Aber ohne methodische Einordnung war keine belastbare Entscheidung möglich.
Die erste Reaktion in vielen Teams: Kapazität ausrechnen, Taktzeiten vergleichen, Amortisation überschlagen. Das sind wichtige Bausteine – aber sie beantworten die eigentlich relevante Frage nicht: Wie verhält sich das System unter dynamischen Bedingungen? Was passiert, wenn Losgrößen schwanken, Maschinen ausfallen, Puffer voll laufen?
Mathematisch-analytische Methoden gehen von stabilen, konstanten Bedingungen aus. Die Realität in der Serienproduktion ist das Gegenteil. Genau hier entfaltet die diskrete ereignisbasierte Simulation ihren Mehrwert.
Das ereignisdiskrete Modell wurde in Tecnomatix Plant Simulation aufgebaut. In einer Reihe von Faktorexperimenten wurden Modulanzahl, Konfiguration und FTF-Flotte systematisch variiert.
Das Ergebnis war eindeutig: Die optimal ausgelegte Variante (a) mit einem vorgelagerten Arbeitsplatz, fünf Bestückplätzen und vier Selektivlötanlagen, versorgt durch acht fahrerlose Transportfahrzeuge, erzielte eine Anlagenauslastung von durchschnittlich 70 % gegenüber der starren Festverkettung. Gleichzeitig war Konzept (a) kostengünstiger als die hochautomatisierten Alternativen – weil der höhere Automatisierungsgrad den Investitionsmehraufwand nicht rechtfertigte.
Diese Zahlen hätten sich analytisch nicht herleiten lassen. Sie entstanden erst durch die Simulation dynamischer Prozesse – und sie veränderten die Entscheidung fundamental.
Parallel zur Simulationsstudie wurde ein Digitaler Zwilling im Siemens-eigenen PLM-System Teamcenter aufgebaut. Dieser vereinte alle fertigungsrelevanten Daten, Modelle und Arbeitspläne in einer integrierten Umgebung.
Was das bedeutet: Der Zwilling ist nicht nur ein Planungswerkzeug – er ist ein Optimierungswerkzeug über den gesamten Lebenszyklus des Systems. Nach der Inbetriebnahme können Szenarien simuliert, Engpässe frühzeitig erkannt und Rekonfigurationen geplant werden, ohne den Produktivbetrieb zu unterbrechen.
Für mittelständische Unternehmen ohne eigene Simulationsabteilung klingt das nach einem Enterprise-Projekt. Das ist es nicht zwingend. Die Kernfrage ist: Welche Entscheidungen müssen getroffen werden, und welche Dynamiken sind dafür relevant? Oft reicht ein schlankes Simulationsmodell für die kritischen Fragen – es muss kein vollständiger Digitaler Zwilling sein.
Das Siemens-Projekt zeigt ein Muster, das ich seitdem in vielen Kontexten wiedersehe: Die Konzeptalternativen liegen vor. Die analytischen Zahlen sprechen für eine Variante. Aber niemand weiß, wie robust diese Aussage unter realen dynamischen Bedingungen ist.
Genau hier ist der Moment für eine methodische Einordnung – nicht durch eine neue, teure Simulationsstudie, sondern durch die Frage: Welche Unsicherheiten in den bestehenden Berechnungen sind entscheidungsrelevant? Und was braucht es, um sie zu quantifizieren?
Weitere Artikel
Ich erarbeite eine belastbare Entscheidungsgrundlage – mit Simulation, methodischer Einordnung und klaren Handlungsempfehlungen.
Engineering-Consulting ansehen →Oder direkt: Erstgespräch vereinbaren →
Es war ein Prüfstandsprojekt bei der Robert Bosch GmbH. Das bestehende Kalibrierungssystem für Dieseleinspritzpumpen sollte modernisiert werden: neue Hardware, neue Software, erweiterter Funktionsumfang. Was zunächst wie eine klare technische Aufgabe wirkte, entpuppte sich als komplexes Geflecht aus Abhängigkeiten – von Vorgängersystemen, von bestehenden Messverfahren, von impliziten Annahmen, die niemand mehr explizit kannte.
Die Bachelorarbeit, die ich damals im Kontext dieses Projekts schrieb, beschäftigte sich mit dem Modell der Produktgenerationsentwicklung (PGE) nach Albert Albers. Was ich dort gelernt habe, hat meine Art, über technische Entwicklung nachzudenken, nachhaltig verändert.
Das Modell der Produktgenerationsentwicklung stellt eine These auf, die einfach klingt, aber weitreichende Konsequenzen hat: Jedes neue Produkt ist eine Weiterentwicklung mindestens eines Referenzsystems. Es entsteht nicht aus dem Nichts – es baut immer auf bestehenden Lösungen, Prinzipien und Gestaltungen auf.
Diese Weiterentwicklung geschieht über drei Variationsarten:
Das PGE-Modell beschreibt nicht nur, wie Produkte entstehen – es zeigt auch, wo Entwicklungsprojekte systematisch schiefgehen.
In vielen Teams gibt es ein implizites Referenzsystem: das Vorgängerprodukt, das alte System, den bestehenden Prozess. Jeder im Team weiß intuitiv davon. Aber es wird selten explizit gemacht. Das bedeutet: Übernahmevariationen werden nicht als solche erkannt, Prinzipvariationen werden unterschätzt, und Abhängigkeiten bleiben unsichtbar – bis sie in der Integrations- oder Validierungsphase als Problem auftauchen.
Das PGE-Modell ist kein akademisches Konzept – es ist ein praktisches Werkzeug für drei konkrete Situationen:
Beim Start eines Entwicklungsprojekts: Was ist unser Referenzsystem? Welche Elemente übernehmen wir – und welche verändern wir fundamental? Wo liegen die Prinzipvariationen, und welcher Validierungsaufwand entsteht daraus?
Bei Engineering Changes: Jede Änderung in einem bestehenden System ist eine Variation. Die Frage ist nicht nur „Was ändern wir?" – sondern „Was ist das Referenzsystem dieser Änderung, und welche Abhängigkeiten trägt sie in sich?"
Bei technischen Reviews: Wenn Simulationsergebnisse und Messdaten sich widersprechen, liegt die Ursache häufig in nicht explizit gemachten Variationen. Das Modell setzt Annahmen voraus, die aus dem Referenzsystem stammen – und die in der realen Neuentwicklung nicht mehr gelten.
Die Antwort ist simpel: Zeitdruck. Das Referenzsystem explizit zu beschreiben, die Variationsarten zu kartieren, Abhängigkeiten sichtbar zu machen – das kostet Zeit zu Beginn eines Projekts, wenn der Druck am größten ist.
Die Konsequenz dieser Investition zeigt sich erst später – in der Integrationsphase, im Validierungsprozess, bei der Serienfreigabe. Projekte, die diese Arbeit frühzeitig leisten, treffen weniger Überraschungen. Projekte, die sie überspringen, erkaufen sich Geschwindigkeit am Anfang mit Aufwand am Ende.
Das ist kein Vorwurf an die Teams. Es ist eine strukturelle Realität. Und es ist einer der Gründe, warum ein externer methodischer Blick am Anfang eines Projekts – wenn er die richtigen Fragen stellt – mehr bewirkt als jeder Review am Ende.
Diese drei Fragen lassen sich in einem halbtägigen Workshop mit dem Entwicklungsteam beantworten. Der Aufwand ist überschaubar. Die Wirkung auf die Qualität späterer Entscheidungen ist erheblich.
Weitere Artikel
Ich helfe, Ihr Referenzsystem explizit zu machen – und die richtigen Fragen zu Beginn zu stellen, nicht am Ende.
Erstgespräch vereinbaren →Mehr zur Leistung: Leistungsseite →
Ich habe Produktentwicklungsmethoden zum ersten Mal nicht aus einem Lehrbuch gelernt. Ich habe sie in einem realen Projekt angewendet — unter Zeitdruck, mit einem echten Industriepartner, in einem Team das sich gerade erst gefunden hatte.
Das war das IP-Projekt am IPEK, dem Institut für Produktentwicklung am KIT. Vier Monate, sechs Personen, eine Aufgabe von Faurecia: Konzepte für den insassenzentrierten Innenraum der Zukunft entwickeln. Kein Übungsfall. Kein Musterlösungsblatt. Die Ergebnisse wurden vor Führungskräften des Unternehmens präsentiert.
Was ich dabei gelernt habe, hat mehr mit dem Scheitern von Methoden zu tun als mit ihrem Funktionieren.
Methoden werden in der Praxis aus zwei Gründen nicht angewendet: entweder kennt man sie nicht — oder man kennt sie, hat sie einmal ausprobiert, und es hat nicht funktioniert wie erwartet.
Der zweite Fall ist häufiger und gefährlicher. Denn er führt zu der falschen Schlussfolgerung, die Methode tauge nichts. Dabei liegt das Problem fast nie in der Methode selbst. Es liegt darin, dass sie zur falschen Situation eingesetzt wurde. Oder zu früh. Oder zu spät. Oder mit falscher Erwartungshaltung.
SPALTEN wurde am IPEK von Prof. Albers entwickelt und ist inzwischen in der VDI 2221 verankert. Das Akronym steht für Situationsanalyse, Problemeingrenzung, Alternative Lösungen, Tragweitenanalyse, Entscheiden und Umsetzen, Nachbereiten und Lernen.
Was das in der Praxis bedeutet: bevor man ein Problem löst, muss man verstehen was das Problem eigentlich ist. Das klingt trivial. Es ist es nicht.
Im Faurecia-Projekt hatten wir in Woche zwei eine scheinbar klare Aufgabenstellung — und drei verschiedene Interpretationen davon im Team. Nicht weil jemand nicht aufgepasst hatte, sondern weil komplexe Problemstellungen immer Interpretationsspielraum lassen. SPALTEN hat uns gezwungen, zuerst die Situation zu beschreiben bevor wir Lösungen entwickelt haben. Der erste Schritt — die Situationsanalyse — hat uns eine Woche "gekostet". Er hat uns vermutlich drei Wochen Fehlentwicklung erspart.
Was SPALTEN besonders macht: zwischen jedem Schritt steht ein expliziter Informationscheck. Man fragt sich: habe ich genug Informationen um weiterzumachen? Wenn nein — zurück. Das klingt nach Bürokratie. Es ist tatsächlich der Grund warum man am Ende nicht feststellt, dass man das falsche Problem gelöst hat.
Failure Mode and Effects Analysis — systematische Analyse was schiefgehen kann, bevor es schiefgeht. Das Problem in der Praxis: FMEA wird entweder als QS-Pflichtübung am Ende des Projekts gemacht — dann ist sie wertlos, weil alle Entscheidungen bereits gefallen sind. Oder sie wird so früh gemacht, dass das System noch gar nicht gut genug verstanden ist um sinnvolle Fehlerszenarien zu entwickeln.
Der richtige Zeitpunkt ist wenn das Konzept steht, aber die Detailkonstruktion noch nicht begonnen hat. Dann kann die FMEA noch Einfluss auf Designentscheidungen nehmen — und genau das ist ihr Zweck.
Quality Function Deployment ist in Deutschland verhältnismäßig wenig eingesetzt — obwohl es eines der nützlichsten Werkzeuge für die frühe Projektphase ist. Die Grundidee: man erfasst systematisch was der Kunde wirklich will, gewichtet diese Anforderungen, und übersetzt sie in messbare technische Merkmale.
Was das IP-Projekt gelehrt hat: ein lückenhaftes Lastenheft ist fast immer das Ergebnis übersprungener QFD-Logik. Man beginnt zu entwickeln bevor man wirklich verstanden hat was gebraucht wird. Anforderungen bleiben implizit — und explodieren dann später wenn Missverständnisse sichtbar werden.
Die Nutzwertanalyse ist die unscheinbarste Methode in dieser Liste — und gleichzeitig diejenige die ich am häufigsten in Beratungsprojekten einsetze. Mehrere Alternativen werden anhand gewichteter Kriterien bewertet. Das Ergebnis ist eine Zahl. Kein Konsens durch Dominanz des Lautesten, kein Bauchgefühl das sich als Rationalität verkleidet.
Vier Methoden, vier verschiedene Situationen. Das ist die eigentliche Lektion.
Wer gelernt hat wann er welches Werkzeug einsetzt, ist schneller, genauer und überzeugender als jemand der dieselben Methoden aus dem Lehrbuch kennt aber nicht angewendet hat. Der Unterschied zwischen Methodenwissen und Methodenkompetenz ist genau das: die Fähigkeit situativ zu entscheiden.
Im IP-Projekt am IPEK haben wir das unter Bedingungen gelernt die dem Industriealltag näher waren als jede Vorlesung. Vier Monate, echter Auftraggeber, echte Präsentation. Kein Netz.
Wenn ich heute in Workshops arbeite, bringe ich keine Methodenschulung mit. Ich bringe das Problem des Kunden mit — und die Methode die diesem Problem am besten hilft. Manchmal ist das SPALTEN. Manchmal eine FMEA. Manchmal ein leeres Whiteboard und die Frage: was ist hier eigentlich das eigentliche Problem?
Weitere Artikel
Ich moderiere Workshops mit etablierten Methoden aus der Produktentwicklung — SPALTEN, FMEA, Nutzwertanalyse. Kein Theorieblock: wir arbeiten an Ihrem konkreten Problem.
Workshop anfragen →Mehr zur Leistung: Schulungen & Workshops →
Der erste Schritt ist ein Gespräch – kein Angebot, kein Verkaufsgespräch. Ich kläre mit Ihnen, ob und wie ich helfen kann. Wir ordnen die Fragestellung ein: Was liegt vor? Was ist unklar? Welche Entscheidung soll das Review vorbereiten?
Am Ende des Gesprächs ist der Scope klar: Was wird geprüft, was nicht. Welche Unterlagen ich brauche. Und ob ein Review das richtige Format für Ihre Situation ist – oder ob etwas anderes sinnvoller wäre.
Damit ich inhaltlich arbeiten kann, brauche ich Zugang zu den relevanten Dokumenten. Was das konkret ist, hängt von der Fragestellung ab – aber typischerweise sind es:
Ich brauche keine vollständige Dokumentensammlung – aber ich brauche die Unterlagen, auf denen die Analyse basiert. Was fehlt oder unvollständig ist, klären wir im Erstgespräch.
Die eigentliche Arbeit. Ich prüfe die vorliegenden Unterlagen methodisch: Sind die Modellannahmen plausibel? Sind die Randbedingungen für den konkreten Anwendungsfall gültig? Gibt es Widersprüche zwischen Simulation, Messung und Spezifikation?
Ein wichtiger Teil der Analyse ist die Sensitivitätseinschätzung: Welche Annahmen sind kritisch für das Ergebnis? Was verändert sich, wenn eine Annahme nicht hält? Diese Einordnung ist oft der Kern dessen, was intern gefehlt hat.
Der Zeitrahmen von 1–3 Tagen gilt für klar abgegrenzte Reviews. Komplexere Fragestellungen mit mehreren Teilsystemen oder umfangreichen Datensätzen können länger dauern – das wird im Vorfeld geklärt.
Das Ergebnis der Analyse ist ein schriftliches Dokument – kein Foliensatz, keine mündliche Zusammenfassung. Das Dokument enthält:
Das Dokument ist so geschrieben, dass es ohne mich weitergenutzt werden kann – in internen Abstimmungen, bei Entscheidungsgremien, gegenüber Lieferanten oder als Grundlage für weitere technische Schritte.
Nach der Übergabe des Dokuments besprechen wir die Ergebnisse gemeinsam. Das dient nicht dazu, die Befunde nochmals zu referieren – das steht im Dokument. Es dient dazu, Rückfragen zu klären, Kontext zu ergänzen und nächste Schritte zu definieren.
Oft entstehen in diesem Gespräch die wichtigsten Folgefragen: Was bedeutet das für Entscheidung X? Welcher der Befunde hat Priorität? Braucht es einen weiteren Schritt – oder reicht das Review als Grundlage?
Weitere Artikel
Ein technisches Review ist kein Audit im Sinne einer formalen Zertifizierung oder Abnahme. Es hat keine rechtliche Bindungswirkung und ersetzt keine normative Prüfung, wenn eine solche erforderlich ist.
Es ist auch keine neue Simulation. Wenn vorhandene Ergebnisse und Unterlagen zur Einordnung ausreichen, erstelle ich keine eigenen Modelle. Das wäre aufwendiger, teurer – und in den meisten Fällen nicht das, was gebraucht wird.
Und es ist kein Gefälligkeitsgutachten. Die Einordnung folgt der Methodik, nicht der erwarteten Antwort. Wenn die Unterlagen eine andere Richtung nahelegen als intern erwartet, steht das im Dokument.
Im Erstgespräch klären wir Fragestellung und Scope – kostenlos, 45 Minuten, ohne Verkaufsabsicht.
Erstgespräch vereinbaren →Mehr zur Leistung: Technische Reviews & Gutachten →
Die Verordnung (EU) 2024/1689 – kurz: EU AI Act – ist das weltweit erste umfassende Regelwerk für Künstliche Intelligenz. Sie gilt unmittelbar in allen EU-Mitgliedstaaten, ohne nationalen Umsetzungsakt. Das bedeutet: Kein deutsches Begleitgesetz notwendig, kein Spielraum für länderspezifische Abweichungen.
Was der AI Act nicht ist: ein allgemeines Digitalisierungsgesetz, eine Erweiterung der DSGVO oder ein Verbot von KI-Werkzeugen. Er reguliert spezifische KI-Systeme nach Risikostufe – und knüpft an diese Risikostufen unterschiedlich starke Pflichten.
Für mittelständische Industrieunternehmen ist die entscheidende Frage nicht „Haben wir KI im Einsatz?" – denn das lässt sich in vielen Fällen nicht mehr verneinen. Die entscheidende Frage ist: Welche Risikostufe hat die KI, die wir einsetzen – und was müssen wir deshalb tun?
Der AI Act unterscheidet dabei grundlegend zwischen zwei Rollen: dem Anbieter (Provider), der ein KI-System entwickelt und auf den Markt bringt, und dem Betreiber (Deployer), der ein KI-System in seinem eigenen Kontext einsetzt. In den meisten Fällen sind mittelständische Industrieunternehmen Betreiber – nicht Anbieter. Das hat erhebliche Auswirkungen auf den Umfang der Pflichten.
Der AI Act teilt KI-Systeme in vier Risikostufen ein. Diese Einstufung bestimmt, welche Anforderungen gelten – und ob überhaupt besondere Anforderungen gelten.
Unakzeptables Risiko (verboten): KI-Systeme, die grundlegende Rechte oder die körperliche Unversehrtheit von Menschen gefährden, sind seit Februar 2025 verboten. Dazu gehören zum Beispiel biometrische Echtzeit-Massenüberwachung in öffentlichen Räumen, Social-Scoring-Systeme durch staatliche Stellen oder KI-Systeme, die unterbewusstes Verhalten manipulieren. Für typische Industrieunternehmen ist diese Kategorie in der Regel nicht relevant.
Hochrisiko-KI: Das ist die Kategorie, die für die meisten mittelständischen Industrieunternehmen relevant werden kann. Hochrisiko-KI-Systeme unterliegen strengen Anforderungen an Transparenz, Dokumentation, menschliche Aufsicht und Konformitätsbewertung. Die konkreten Anwendungsfälle erläutere ich im nächsten Abschnitt.
Begrenzte Risikostufe: Systeme wie Chatbots oder KI-generierte Inhalte müssen als solche gekennzeichnet werden – das betrifft die Transparenzpflicht. Wenn Sie auf Ihrer Website einen KI-gestützten Chat betreiben oder KI-generierte Texte veröffentlichen, fallen Sie in diese Kategorie. Die Anforderungen sind überschaubar: Kennzeichnungspflicht und Informationspflicht gegenüber Nutzern.
Minimales Risiko: Für die große Mehrheit der heute genutzten KI-Anwendungen – Spam-Filter, Produktionsoptimierung ohne Sicherheitsrelevanz, KI-gestützte Textverarbeitung intern, Bilderkennungssysteme in der Qualitätssicherung ohne sicherheitskritische Funktion – gelten keine spezifischen Pflichten. Verhaltenskodizes werden empfohlen, sind aber freiwillig.
Entscheidend für die Einordnung ist nicht der Name des Systems, sondern seine Funktion und sein Einsatzkontext. Dieselbe Software kann je nach Einsatzzweck in unterschiedliche Risikokategorien fallen.
Anhang III der AI-Act-Verordnung listet Bereiche auf, in denen KI-Systeme automatisch als hochriskant gelten. Für mittelständische Industrieunternehmen sind vor allem drei Bereiche praxisrelevant:
1. Sicherheitskomponenten in Maschinen und Anlagen
KI-Systeme, die als Sicherheitskomponente in Produkten eingesetzt werden, die unter EU-Harmonisierungsrechtsvorschriften fallen (wie die Maschinenverordnung 2023/1230 oder die Niederspannungsrichtlinie), gelten als Hochrisiko-KI. Das betrifft konkret: KI-gestützte Kollisionsschutz- oder Not-Halt-Systeme, autonome Sicherheitsfunktionen in Roboteranlagen, KI-basierte Überwachung sicherheitskritischer Produktionsparameter.
Wichtig: Hier greift der AI Act in Verbindung mit bestehenden CE-Kennzeichnungspflichten. Wer Maschinen mit integrierten KI-Sicherheitsfunktionen baut oder verkauft, muss die Konformitätsbewertung nach AI Act zusätzlich zur Maschinenverordnung durchführen.
2. Biometrische Systeme und Arbeitnehmerüberwachung
KI-Systeme, die zur biometrischen Identifikation oder Kategorisierung von Personen eingesetzt werden, sowie KI-Systeme, die Arbeitnehmer bei Personalentscheidungen bewerten oder beeinflussen – etwa KI-gestützte Leistungsanalysen, automatisierte Überwachung am Arbeitsplatz oder KI-gestützte Bewerberauswahl – sind hochriskant nach dem AI Act.
In der Praxis betrifft das Industrieunternehmen, die Mitarbeitertracking in der Produktion einsetzen, KI-basierte Zeiterfassungs- oder Anwesenheitssysteme nutzen oder automatisierte Leistungsauswertungen vornehmen. Auch hier gilt: der Einsatzkontext entscheidet, nicht der Produktname des eingesetzten Systems.
3. Kritische Infrastruktur
KI-Systeme in der Verwaltung und im Betrieb kritischer Infrastruktur – Energie, Wasser, Verkehr – gelten ebenfalls als hochriskant. Für die meisten mittelständischen Industrieunternehmen ist das nur dann relevant, wenn sie explizit in der Betreiber- oder Lieferantenrolle für kritische Infrastruktur tätig sind.
Was in der Regel nicht als Hochrisiko-KI gilt: interne Optimierungstools ohne Sicherheitsrelevanz, KI-gestützte Produktionsplanung ohne direkten Einfluss auf Sicherheitsfunktionen, KI-basierte Qualitätssicherung in nicht-regulierten Bereichen, Textanalyse- und Auswertungstools für interne Prozesse.
Weitere Artikel
Der AI Act unterscheidet konsequent zwischen zwei Hauptakteuren: dem Anbieter (Provider), der ein KI-System entwickelt und vermarktet, und dem Betreiber (Deployer), der ein KI-System im eigenen geschäftlichen Kontext einsetzt.
Für Anbieter sind die Anforderungen deutlich umfangreicher: Konformitätsbewertung vor der Markteinführung, technische Dokumentation, Registrierung in der EU-Datenbank, CE-Kennzeichnung, Qualitätsmanagementsystem, Risikomanagementsystem und laufende Überwachung nach dem Inverkehrbringen.
Betreiber haben geringere, aber nicht zu unterschätzende Pflichten. Für Hochrisiko-KI-Systeme gilt als Betreiber:
Für die Praxis bedeutet das: Wenn Sie als mittelständisches Unternehmen ein KI-System eines Drittanbieters einsetzen – etwa eine Qualitätssicherungssoftware mit KI-Funktion, eine Predictive-Maintenance-Lösung oder ein HR-Tool – sind Sie Betreiber. Ihre Pflichten hängen davon ab, ob das System als hochriskant einzustufen ist.
Eine häufige Grauzone: Viele Softwareanbieter bewerben ihre Produkte mit KI-Funktionen, ohne zu klären, ob diese Funktionen unter den AI Act fallen. Als Betreiber haben Sie das Recht – und die Pflicht –, diese Frage bei Ihrem Anbieter aktiv zu stellen. Erhält das System eine CE-Kennzeichnung nach AI Act? Existiert eine Betriebsanleitung mit Risikoklassifizierung? Wer trägt die Verantwortung für die Konformitätsbewertung?
Der AI Act tritt in Kraft gestaffelt – ein wichtiger Punkt, den viele unterschätzen: Die Verordnung gilt nicht erst „irgendwann in der Zukunft". Entscheidende Teile sind bereits in Kraft.
Für mittelständische Industrieunternehmen bedeutet das: Der relevante Stichtag für die meisten Pflichten ist August 2026. Das klingt nach ausreichend Zeit – ist es aber nur, wenn Sie jetzt mit der Bestandsaufnahme beginnen. Eine vollständige KI-Inventur, Risikoklassifizierung und ggf. Anpassung von Beschaffungsprozessen und Verträgen braucht in der Praxis 6–12 Monate.
Es gibt keine universelle Checkliste, die für jedes Unternehmen gilt – das hängt zu stark vom Einzelfall ab. Aber es gibt eine sinnvolle Reihenfolge, die in den meisten Fällen funktioniert.
Schritt 1: KI-Inventur durchführen
Erfassen Sie systematisch, welche Systeme in Ihrem Unternehmen KI-Funktionen nutzen. Das ist schwieriger als es klingt, weil KI-Funktionen oft in bestehende Software integriert sind, ohne dass das explizit kommuniziert wird. Softwarehersteller von MES-, ERP-, QM- oder HR-Systemen haben in den letzten Jahren KI-Funktionen nachgerüstet. Fragen Sie Ihre Softwareanbieter aktiv: „Setzt Ihre Lösung Machine-Learning- oder KI-Algorithmen ein, die Entscheidungen beeinflussen oder automatisieren?"
Erfassen Sie für jedes System: Funktion, Einsatzkontext, Hersteller, Kauf- oder Eigenentwicklung, und ob menschliche Entscheidungen durch das System beeinflusst werden.
Schritt 2: Risikoklassifizierung vornehmen
Prüfen Sie für jedes identifizierte KI-System: Fällt es unter einen der Hochrisiko-Bereiche aus Anhang III? Handelt es sich um eine Sicherheitskomponente in einem CE-pflichtigen Produkt? Hat das System Einfluss auf Arbeitnehmerentscheidungen?
In den meisten mittelständischen Betrieben wird das Ergebnis sein: Der größte Teil der eingesetzten KI fällt in die minimale Risikostufe und erfordert keine spezifischen Maßnahmen. Aber es ist wichtig, das explizit festzustellen – und zu dokumentieren.
Schritt 3: Verträge mit Softwareanbietern prüfen
Klären Sie für alle als hochriskant eingestuften Systeme: Wer ist nach dem AI Act der Anbieter? Welche Konformitätsunterlagen stellt der Anbieter bereit? Sind Betriebsanleitungen vorhanden, die Ihren Betreiberpflichten entsprechen? Passen Sie Beschaffungsverträge an, um AI-Act-Konformität als Anforderung aufzunehmen.
Dieser Punkt ist besonders relevant, wenn Sie Maschinen oder Anlagen bauen, die KI-Sicherheitsfunktionen enthalten – hier sind Sie möglicherweise selbst Anbieter, nicht nur Betreiber.
Schritt 4: Governance-Struktur aufbauen
Legen Sie intern fest, wer für AI-Act-Compliance verantwortlich ist. In einem mittelständischen Unternehmen ist das meist keine neue Stabsstelle, sondern eine klare Zuständigkeit – typischerweise beim Geschäftsführer mit technischem Hintergrund, beim Datenschutzbeauftragten oder beim Qualitätsmanagement.
Stellen Sie sicher, dass Ihre Mitarbeiter, die KI-Systeme bedienen, über die Funktion und Grenzen dieser Systeme informiert sind. Das ist keine optionale Empfehlung – für Hochrisiko-KI ist menschliche Aufsicht eine rechtliche Anforderung.
Schritt 5: Dokumentation anlegen
Halten Sie Ihre KI-Inventur, Risikoklassifizierungen und getroffenen Maßnahmen schriftlich fest. Auch wenn Sie aktuell keine Hochrisiko-KI einsetzen, ist eine dokumentierte Einschätzung ein wertvoller Nachweis – gegenüber Behörden, Kunden oder Geschäftspartnern.
„Wir setzen keine KI ein – das betrifft uns nicht." In der Praxis stimmt das für die meisten Unternehmen nicht mehr. KI-Funktionen sind in ERP-, MES-, QM- und HR-Software integriert. Wenn Sie Software der letzten fünf Jahre nutzen, lohnt die Inventur.
„Wir kaufen die Software nur – der Anbieter muss sich darum kümmern." Das stimmt für die Anbieter-Pflichten. Für Betreiber-Pflichten – menschliche Aufsicht, Mitarbeiterinformation, Vorfallsmeldung – sind Sie als Unternehmen selbst verantwortlich. Beschaffung schützt nicht vollständig vor Compliance-Verantwortung.
„August 2026 ist noch weit weg." Ein Jahr Vorlauf klingt komfortabel. KI-Inventur, Risikoklassifizierung, Vertragsanpassungen und Mitarbeiterschulungen brauchen in der Praxis Zeit. Wer im Sommer 2026 anfängt, ist zu spät.
„Als kleines Unternehmen sind wir ausgenommen." Der AI Act enthält einige erleichterte Regelungen für KMU – vor allem bei Gebühren für Konformitätsbewertungen und beim Zugang zu technischer Unterstützung. Die inhaltlichen Anforderungen (Hochrisiko-KI) gelten aber auch für kleine Unternehmen, wenn sie entsprechende Systeme einsetzen oder entwickeln.
„ChatGPT und Co. fallen unter den AI Act." Ja – aber als GPAI-Systeme nach Kapitel V, mit deutlich anderen Regeln als Hochrisiko-KI. Als Nutzer von Sprachmodellen sind Sie Betreiber eines begrenzten-Risiko-Systems. Transparenzpflicht: KI-generierte Inhalte kennzeichnen. Das ist überschaubar – und seit August 2025 Pflicht.
Der EU AI Act ist kein Bürokratieprojekt, das irgendwann erledigt ist. Er ist der Beginn einer dauerhaften Regulierung, die in den nächsten Jahren weiter konkretisiert wird – durch technische Standards, delegierte Rechtsakte und Auslegungsleitlinien der Marktüberwachungsbehörden.
Für mittelständische Industrieunternehmen bedeutet das: KI-Compliance wird ein fester Bestandteil des Qualitätsmanagements. Nicht anders als Maschinensicherheit oder Datenschutz heute. Die Unternehmen, die jetzt strukturiert beginnen – mit einer vollständigen Inventur, klarer Risikoklassifizierung und sauberer Dokumentation – haben 2026 einen klaren Vorteil gegenüber denen, die reaktiv handeln.
Der pragmatische Einstieg: Beginnen Sie mit der Inventur. Nicht mit externen Beratern oder aufwendigen Projekten – sondern mit einer internen Liste aller Software-Systeme, die KI-Funktionen nutzen. Das braucht zwei bis drei Stunden. Was danach zu tun ist, ergibt sich aus dem Ergebnis.
Einordnung aus der Praxis: Ich sehe in Erstgesprächen mit Industrieunternehmen oft die gleiche Situation: Das Thema AI Act ist bekannt, aber niemand hat bisher konkret festgestellt, welche der eigenen Systeme unter die Verordnung fallen. Die Inventur ist der erste sinnvolle Schritt – und sie zeigt in den meisten Fällen, dass die Situation weniger komplex ist als befürchtet.
Im Erstgespräch klären wir gemeinsam, welche KI-Systeme in Ihrem Umfeld relevant sind – und was das für Ihre Situation konkret bedeutet.
Erstgespräch vereinbaren →Mehr zur Leistung: Engineering & System-Consulting →
Die Verordnung (EU) 2024/2847 – kurz: Cyber Resilience Act – ist das erste EU-weit verbindliche Regelwerk für die Cybersicherheit von Produkten mit digitalen Elementen. Sie trat am 10. Dezember 2024 in Kraft und gilt unmittelbar in allen EU-Mitgliedstaaten, ohne nationalen Umsetzungsakt.
Was der CRA reguliert, ist klar: Produkte, die Software oder Firmware enthalten oder mit einem Netz verbunden werden können – unabhängig davon, ob dieses Produkt primär als Hardware oder als Software vermarktet wird. Was der CRA nicht ist: ein allgemeines IT-Sicherheitsgesetz, eine Erweiterung der DSGVO oder eine Variante der NIS-2-Richtlinie.
Hier liegt ein häufiges Missverständnis: NIS-2 reguliert Cybersicherheit für Betreiber – also Organisationen, die kritische Infrastrukturen oder wichtige Dienste betreiben. Der CRA reguliert Hersteller von Produkten. Eine Fabrik, die Maschinen baut, ist in der Regel kein NIS-2-Betreiber – aber sehr wohl CRA-Hersteller, wenn in diesen Maschinen Software oder Netzwerkkommunikation steckt.
Der zweite häufige Irrtum: „Der CRA gilt doch erst 2027." Das stimmt für die Hauptpflichten. Die Meldepflichten für Schwachstellen und Sicherheitsvorfälle gelten bereits ab 11. September 2026 – mehr als ein Jahr früher. Wer erst zum zweiten Stichtag anfängt, ist zum ersten bereits in der Pflicht.
Der Begriff „Produkt mit digitalen Elementen" ist absichtlich weit gefasst. Er umfasst jede Hardware, die direkt oder indirekt mit einem anderen Gerät oder Netz verbunden werden kann – und jede Software, die selbstständig auf dem Markt angeboten wird.
In der Praxis bedeutet das für mittelständische Industrieunternehmen:
Betroffen: Steuergeräte, Microcontroller-Boards und Edge-Computing-Module, die in Maschinen verbaut und über Ethernet, WLAN, OPC-UA oder CAN-Bus kommunizieren. Sensoren, Aktoren oder Gateways mit eigenem Betriebssystem oder aktualisierbarer Firmware. Industrielle HMI-Systeme, auch wenn sie nur im internen Netz eingebunden sind. Embedded Software, die als eigenständiges Lizenzprodukt verkauft wird. Geräte mit Bluetooth, Zigbee, NB-IoT oder vergleichbarer Funktechnik.
Nicht betroffen: Rein mechanische Produkte ohne jede digitale Komponente. Produkte unter sektorspezifischen Ausnahmen des CRA (Medizinprodukte nach MDR, Fahrzeuge nach Typgenehmigungsverordnung, bestimmte Marine- und Luftfahrtprodukte).
Die Abgrenzung ist im Einzelfall nicht immer trivial. Eine Fräsmaschine mit mechanischer NC-Steuerung ohne Netzwerkanbindung fällt nicht unter den CRA. Dieselbe Maschine mit einer SPS, die per OPC-UA ins Firmennetz eingebunden ist, schon. Entscheidend ist nicht die Kategorie des Produkts, sondern seine tatsächliche digitale Vernetzbarkeit.
Der CRA unterscheidet drei Kategorien, die bestimmen, welches Konformitätsbewertungsverfahren gilt:
Standard-Produkte: Die große Mehrheit der betroffenen Produkte fällt hierunter. Eine Eigenkonformitätserklärung des Herstellers ist ausreichend – keine externe Prüfstelle ist zwingend notwendig. Der Hersteller erklärt selbst, dass sein Produkt die Sicherheitsanforderungen erfüllt.
Klasse I – Wichtige Produkte: Hier besteht die Wahl: Entweder der Hersteller wendet harmonisierte Normen an und erklärt die Konformität selbst, oder er lässt das Produkt von einer akkreditierten Prüfstelle bewerten. Konkrete Beispiele aus dem industriellen Umfeld: Webbrowser, VPN-Produkte, Passwortmanager, allgemeine Betriebssysteme, industrielle IACS-Komponenten (Industrial Automation and Control Systems), industrielle IoT-Geräte, Netzwerkverwaltungstools.
Klasse II – Kritische Produkte: Hier ist eine Prüfung durch eine benannte Stelle (Notified Body) verpflichtend. Beispiele: Steuerungssysteme kritischer Infrastruktur (Energie, Wasser, Verkehr), bestimmte Router und Switches für kritische Infrastruktur.
Für die Praxis bedeutet das: Ein Hersteller von industriellen IoT-Sensoren oder IACS-Komponenten muss prüfen, ob sein Produkt unter Klasse I fällt – und ob er den Nachweis durch harmonisierte Normen erbringen kann oder eine externe Bewertung einplanen muss. Klasse-II-Hersteller müssen Notified Bodies frühzeitig einbeziehen – die Kapazitäten werden mit steigendem Bedarf knapp werden.
Die Pflichten gliedern sich in vier Bereiche:
Sicherheitsanforderungen an das Produkt: Security by Design – Sicherheit muss von Beginn der Entwicklung integriert werden, nicht nachträglich. Minimale Angriffsfläche: nur notwendige Ports, Protokolle und Dienste aktivieren. Standardmäßig sichere Konfiguration. Schutz vor unbefugtem Zugriff und kryptografisch gesicherte Kommunikation, wo relevant. Vertraulichkeit und Integrität gespeicherter und übertragener Daten.
Schwachstellenmanagement (laufend, für die gesamte Lebensdauer des Produkts, mindestens 5 Jahre): Aktive Identifikation und Behebung von Schwachstellen. Kostenlose Sicherheitsupdates für die erwartete Produktnutzungsdauer, in der Praxis typischerweise mindestens fünf Jahre. SBOM (Software Bill of Materials) – vollständige Auflistung aller Software-Komponenten – als Pflicht ab Dezember 2027. Koordiniertes Schwachstellenoffenlegungsverfahren (CVD-Policy) veröffentlichen.
Meldepflichten (ab 11. September 2026): Aktiv ausgenutzte Schwachstellen: 24-Stunden-Frühwarnung an ENISA (und über das nationale CSIRT an das BSI), 72-Stunden-Meldung mit ersten Details, Abschlussbericht innerhalb von 14 Tagen. Für erhebliche Sicherheitsvorfälle gelten dieselben Fristen.
Konformitätsbewertung und Dokumentation: Technische Dokumentation erstellen. EU-Konformitätserklärung ausstellen. CE-Kennzeichnung anbringen. Registrierung in der EU-Datenbank (verpflichtend für Klasse II und auf Verlangen der Aufsichtsbehörde).
Bei Verstößen drohen erhebliche Bußgelder: bis zu 15 Mio. € oder 2,5 % des weltweiten Jahresumsatzes bei Verstößen gegen Sicherheitsanforderungen, bis zu 10 Mio. € / 2 % bei Dokumentations- und CE-Verstößen, bis zu 5 Mio. € / 1 % bei falschen Angaben gegenüber Behörden.
Weitere Artikel
Nicht nur Hersteller, sondern auch Importeure und Händler tragen Pflichten nach dem CRA – allerdings geringere.
Importeure müssen sicherstellen, dass Produkte aus Drittstaaten, die sie in der EU in Verkehr bringen, die CRA-Anforderungen erfüllen. Sie müssen die technische Dokumentation auf Anfrage vorlegen können, die EU-Konformitätserklärung aufbewahren und nicht konforme Produkte vom Markt nehmen.
Händler – also Unternehmen im Vertrieb, die weder Hersteller noch Importeur sind – müssen vor der Weitergabe prüfen, ob CE-Kennzeichnung und Konformitätserklärung vorliegen. Bei selbst markierten oder wesentlich modifizierten Produkten gelten sie als Hersteller.
Praxisrelevanz: Wenn Sie als Maschinenbauer Steuerkomponenten aus Asien beschaffen und in Ihre Anlage einbauen, die Sie dann in der EU verkaufen, sind Sie möglicherweise Importeur – mit entsprechenden Prüf- und Dokumentationspflichten.
Der entscheidende Punkt: Zwischen dem ersten Stichtag (Meldepflichten, September 2026) und dem zweiten Stichtag (vollständige Compliance, Dezember 2027) liegen 15 Monate. Wer erst zum zweiten Stichtag anfängt, ist zum ersten bereits in der Pflicht – und hat keine Meldeprozesse eingerichtet.
Schritt 1: Produkt-Inventur
Erstellen Sie eine Liste aller Produkte, die Sie herstellen oder importieren. Kennzeichnen Sie, welche davon eine digitale Komponente enthalten – Software, Firmware, Netzwerkkommunikation. Rein mechanische Produkte ohne Netzwerkfähigkeit können Sie herausstreichen.
Schritt 2: Risikoklassen-Einordnung
Prüfen Sie für die verbleibenden Produkte: Fällt das Produkt unter Klasse I oder II des CRA-Anhangs? Wenn nicht, gelten die Standardanforderungen. Halten Sie die Einordnung und ihre Begründung schriftlich fest – das ist bereits Teil der Dokumentationspflicht.
Schritt 3: Sicherheitsanforderungen gegen den Ist-Stand abgleichen
Analysieren Sie Ihre aktuellen Entwicklungsprozesse: Gibt es einen Prozess für Security by Design? Wird die Angriffsfläche bei der Produktentwicklung berücksichtigt? Werden Software-Abhängigkeiten dokumentiert? Wer für strukturiertes Systems Engineering in der Produktentwicklung bereits einen Rahmen hat – etwa über MBSE-Methodik –, kann diese Struktur für die CRA-Dokumentation nutzen. Identifizieren Sie Lücken: Das sind Ihre Handlungsfelder bis Dezember 2027.
Schritt 4: Meldewege einrichten (bis August 2026)
Richten Sie bis September 2026 die Meldewege für sicherheitsrelevante Vorfälle und Schwachstellen ein. In Deutschland ist das BSI die relevante nationale Behörde. Klären Sie intern: Wer meldet? In welchem Format? Mit welchen Informationen innerhalb der 24-Stunden-Frist?
Schritt 5: CVD-Policy veröffentlichen
Veröffentlichen Sie eine Coordinated Vulnerability Disclosure Policy – eine öffentlich zugängliche Beschreibung, wie Sicherheitsforscher oder Kunden Schwachstellen an Sie melden können. Das ist eine explizite Anforderung des CRA und oft schneller umzusetzen als gedacht.
Schritt 6: Technische Dokumentation aufbauen
Beginnen Sie mit der technischen Dokumentation gemäß CRA-Anforderungen. Das ist zeitaufwendig – und das, was die meisten Unternehmen am stärksten unterschätzen. Eine externe methodische Einordnung in dieser Phase reduziert spätere Nacharbeit.
„CRA betrifft nur Software-Unternehmen." Falsch. Der CRA betrifft jeden Hersteller von Produkten mit digitalen Elementen. Maschinenbauer, Elektronikentwickler und Automatisierungstechnik-Hersteller sind eindeutig im Scope.
„Open-Source-Software ist ausgenommen." Teilweise richtig – und oft irreführend: Nicht-kommerzielle Open-Source-Projekte sind ausgenommen. Aber wenn ein Unternehmen Open-Source-Software kommerziell in sein Produkt einbettet, trägt es als Hersteller die volle CRA-Verantwortung für das Endprodukt.
„NIS-2 haben wir schon – CRA ist damit abgedeckt." Nein. NIS-2 betrifft Betreiber von Diensten. CRA betrifft Hersteller von Produkten. Die Regelungskreise überschneiden sich kaum. Ein Unternehmen kann unter beide fallen – muss aber nicht.
„Die RED-DA hat das schon geregelt." Die Radio Equipment Directive Delegated Act (RED-DA) wurde mehrfach verschoben. Der CRA hat diesen Bereich faktisch übernommen und abgelöst – die Anforderungen gelten jetzt über den CRA, nicht die RED-DA.
„Mit CE ist alles erledigt." CE ist eine Konformitätskennzeichnung, keine Aussage über Cybersicherheit. Erst wenn die CRA-Sicherheitsanforderungen erfüllt und entsprechend dokumentiert wurden, darf CE im CRA-Kontext angebracht werden.
Für mittelständische Industrieunternehmen ist die Überschneidung mit anderen EU-Regelwerken praktisch relevant:
CRA und AI Act: Wenn ein Produkt mit digitalen Elementen auch KI-Funktionen enthält, kann es gleichzeitig unter den AI Act und den CRA fallen. Der AI Act fokussiert auf das Risiko, das vom KI-System ausgeht (Risikostufen nach Funktion und Einsatzkontext). Der CRA fokussiert auf die Cybersicherheit des Produkts (Schwachstellen, Updates, Meldepflichten). Wer KI-Funktionen in vernetzten Industrieprodukten einsetzt, muss beide Verordnungen prüfen – die Dokumentationspflichten ergänzen sich, überschneiden sich aber auch.
CRA und Maschinenverordnung (EU) 2023/1230: Die neue Maschinenverordnung (gilt vollständig ab Januar 2027) enthält bereits Anforderungen an die Cybersicherheit von Maschinen, soweit sie die Maschinensicherheit betreffen. Der CRA ergänzt das durch produktübergreifende Cybersicherheitspflichten. Wer Maschinen mit Netzwerkanbindung entwickelt, muss ab 2027 beide Regelwerke gleichzeitig erfüllen. Wer strukturiertes Systems Engineering in der Produktentwicklung einsetzt, kann Dokumentationspflichten aus beiden Verordnungen effizienter bündeln.
CRA und NIS-2: Wie beschrieben: NIS-2 betrifft Betreiber, CRA betrifft Hersteller. Wenn Ihr Unternehmen beides ist – zum Beispiel ein Energieversorger, der seine eigene Steuertechnik entwickelt – gelten beide Regelwerke parallel, mit getrennten Anforderungen und Fristen.
Einordnung aus der Praxis: Ich spreche regelmäßig mit Konstrukteuren und Entwicklungsleitern, die vom CRA zum ersten Mal hören – und anschließend feststellen, dass mindestens eines ihrer aktuellen Produkte eindeutig im Scope liegt. Die häufigste Reaktion: „Das haben wir nicht so gesehen, weil wir uns als Maschinenbauer und nicht als Software-Hersteller verstehen." Diese Unterscheidung macht der CRA nicht. Wer ein vernetztes Produkt auf den Markt bringt, ist Hersteller im Sinne des CRA – mit allen Pflichten, die das bedeutet.
Im Erstgespräch klären wir gemeinsam, welche Ihrer Produkte unter den CRA fallen – und was das für Ihre Entwicklungsprozesse und Dokumentation konkret bedeutet.
Erstgespräch vereinbaren →Mehr zur Leistung: Technische Reviews & Gutachten →
Gemäß § 5 TMG und § 18 Abs. 2 MStV
Alper Altay
ALTEMIS Consulting · Einzelunternehmen
Richard-Wagner-Str. 68
77694 Kehl
Deutschland
Telefon: +49 1522 5304644
E-Mail: info@altemis-consulting.de
Website: www.altemis-consulting.de
Gemäß § 19 UStG wird keine Umsatzsteuer berechnet (Kleinunternehmerregelung).
Berufsbezeichnung: Unternehmensberater
Verliehen in: Deutschland
Alper Altay
Richard-Wagner-Str. 68
77694 Kehl
Die Leistungen von ALTEMIS Consulting richten sich ausschließlich an Unternehmen, Gewerbetreibende, Freiberufler und juristische Personen (B2B). Eine Vertragsanbahnung mit Verbrauchern im Sinne des § 13 BGB ist ausgeschlossen.
ALTEMIS Consulting erbringt ausschließlich Leistungen gegenüber Unternehmern (B2B). Eine Pflicht zur Teilnahme an einem Verbraucherstreitbeilegungsverfahren gemäß § 36 VSBG besteht daher nicht und wird auch nicht freiwillig eingegangen.
Gemäß DSGVO, BDSG und TTDSG – Stand: März 2026
Vielen Dank für Ihr Interesse an unserem Online-Angebot. Nachfolgend informieren wir Sie über die Erhebung, Verarbeitung und Nutzung Ihrer personenbezogenen Daten. Personenbezogene Daten sind alle Daten, die sich auf Sie als Person beziehen, also z. B. Name, Adresse, E-Mail-Adresse oder Nutzerverhalten auf einer Website.
Verantwortlicher gemäß Art. 4 Abs. 7 DSGVO ist:
Alper Altay – ALTEMIS Consulting
Richard-Wagner-Str. 68, 77694 Kehl, Deutschland
E-Mail: info@altemis-consulting.de · Telefon: +49 1522 5304644
Sie können unser Online-Angebot nutzen, ohne Angaben zu Ihrer Person zu machen. Dabei erheben wir nur die Daten, die Ihr Browser an unseren Server übermittelt und die technisch erforderlich sind, um Ihnen die Website anzuzeigen sowie Stabilität und Sicherheit zu gewährleisten (Rechtsgrundlage: Art. 6 Abs. 1 S. 1 lit. f DSGVO):
Diese Logfile-Informationen werden aus Sicherheitsgründen für maximal 7 Tage gespeichert und danach gelöscht. Daten, deren weitere Aufbewahrung zu Beweiszwecken notwendig ist, werden bis zur endgültigen Klärung des jeweiligen Vorfalls aufbewahrt.
Wenn Sie uns über das Kontaktformular kontaktieren, werden Ihre eingegebenen Daten (Name, Unternehmen, E-Mail-Adresse, Telefonnummer, Nachrichteninhalt) zur Bearbeitung Ihrer Anfrage gespeichert. Angaben, die zur Bearbeitung zwingend erforderlich sind, sind als Pflichtfelder gekennzeichnet. Die Übermittlung erfolgt verschlüsselt. Eine Weitergabe an Dritte findet nicht statt.
Zusätzlich speichern wir bei Anfragen über unsere Website die IP-Adresse und den Zeitpunkt der Nutzerhandlung. Dies erfolgt aufgrund unserer berechtigten Interessen sowie dem Interesse der Nutzer am Schutz vor Missbrauch und unbefugter Verwendung ihrer Daten.
Rechtsgrundlage: Art. 6 Abs. 1 lit. b DSGVO (Vertragsanbahnung) sowie Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse). Speicherdauer: Löschung nach abschließender Bearbeitung, sofern keine gesetzliche Aufbewahrungspflicht entgegensteht.
Bei direkter Kontaktaufnahme werden Ihre übermittelten Daten zur Bearbeitung gespeichert. Rechtsgrundlage und Speicherdauer entsprechen Abschnitt 2.2.
Im Rahmen der Anbahnung und Durchführung von Beratungsverträgen verarbeiten wir Daten von Ansprechpartnern unserer Geschäftspartner (Name, Funktion, Geschäfts-E-Mail, Telefonnummer). Diese Verarbeitung erfolgt zur Vertragserfüllung gemäß Art. 6 Abs. 1 lit. b DSGVO bzw. auf Basis berechtigter Interessen gemäß Art. 6 Abs. 1 lit. f DSGVO. Speicherdauer: Dauer der Geschäftsbeziehung zuzüglich gesetzlicher Aufbewahrungsfristen (siehe Abschnitt 5).
Im Rahmen der Leistungserbringung können KI-gestützte Werkzeuge (z. B. Sprachmodelle, Analyse-Tools) eingesetzt werden. Dabei werden keine personenbezogenen Daten des Auftraggebers in KI-Systeme eingegeben, es sei denn, dies ist für die konkrete Leistung erforderlich und wurde vorab vereinbart. In diesem Fall erfolgt die Verarbeitung auf Grundlage von Art. 6 Abs. 1 lit. b DSGVO (Vertragserfüllung). Der Auftraggeber wird über den Einsatz solcher Werkzeuge im Zusammenhang mit seinen Daten informiert.
Wir verarbeiten Ihre Daten im Rahmen der Organisation unseres Betriebs zu Zwecken der Büroorganisation, der Finanzbuchhaltung, der Einhaltung gesetzlicher Archivierungspflichten sowie der allgemeinen Abwicklung des Zahlungsverkehrs. Hierbei werden dieselben Daten verarbeitet, die auch zur Erbringung vertraglicher Leistungen verarbeitet werden.
Rechtsgrundlagen: Art. 6 Abs. 1 lit. c DSGVO (gesetzliche Pflicht) und Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse an der Aufrechterhaltung des Geschäftsbetriebs).
Wir übermitteln in diesem Rahmen Daten an Berater wie Steuerberater oder Wirtschaftsprüfer sowie an die Finanzverwaltung, soweit dies gesetzlich erforderlich ist.
Eine Übermittlung personenbezogener Daten an Dritte findet grundsätzlich nicht statt, außer:
Nach Maßgabe der Art. 17 und 18 DSGVO werden von uns verarbeitete Daten gelöscht oder ihre Verarbeitung eingeschränkt, sobald sie für ihren Zweck nicht mehr erforderlich sind.
Sofern der Löschung gesetzliche Aufbewahrungspflichten entgegenstehen, wird die Verarbeitung der Daten eingeschränkt – sie werden also für die weitere Verwendung gesperrt und können nicht für andere Zwecke verarbeitet werden.
Die relevantesten gesetzlichen Aufbewahrungsfristen sind:
Diese Website wird gehostet bei: IONOS SE, Elgendorfer Str. 57, 56410 Montabaur, Deutschland · www.ionos.de
Mit IONOS SE besteht ein Auftragsverarbeitungsvertrag (AVV) gemäß Art. 28 DSGVO. Die Datenverarbeitung durch IONOS erfolgt ausschließlich innerhalb der EU bzw. des EWR. IONOS ist nach ISO 27001 zertifiziert.
Das Kontaktformular auf dieser Website wird über den Dienst Formspree verarbeitet. Anbieter: Formspree, Inc., 3 East Read Street, Baltimore, MD 21202, USA · formspree.io
Wenn Sie das Kontaktformular nutzen, werden Ihre eingegebenen Daten (Name, E-Mail-Adresse, Nachricht sowie optional Unternehmen und Leistungsfeld) an Server von Formspree übermittelt und von dort an unsere E-Mail-Adresse weitergeleitet. Die Übertragung erfolgt verschlüsselt (HTTPS). Formspree speichert die Formulardaten auf Servern in den USA. Die Datenübertragung in die USA erfolgt auf Grundlage der Standardvertragsklauseln der EU-Kommission gemäß Art. 46 Abs. 2 lit. c DSGVO. Mit Formspree besteht ein Auftragsverarbeitungsvertrag gemäß Art. 28 DSGVO. Weitere Informationen: Formspree Datenschutzerklärung.
Für die Online-Terminbuchung nutzen wir den Dienst Zeeg. Anbieter: Zeeg GmbH, Ludwigstraße 8, 80539 München, Deutschland · zeeg.me
Wenn Sie über den Buchungslink einen Termin vereinbaren, werden Sie auf die Plattform von Zeeg weitergeleitet. Dabei werden personenbezogene Daten (Name, E-Mail-Adresse, ggf. weitere von Ihnen eingegebene Informationen) von Zeeg verarbeitet. Die Verarbeitung erfolgt auf Servern innerhalb der EU. Mit Zeeg besteht ein Auftragsverarbeitungsvertrag gemäß Art. 28 DSGVO. Rechtsgrundlage der Verarbeitung ist Art. 6 Abs. 1 lit. b DSGVO (Vertragsanbahnung). Weitere Informationen: Zeeg Datenschutzerklärung.
Wir setzen ausschließlich technisch notwendige Cookies ein, die nach § 25 Abs. 2 Nr. 2 TTDSG keine Einwilligung erfordern. Analyse-, Tracking- oder Marketing-Cookies werden nicht eingesetzt. Weitere Informationen entnehmen Sie der Cookies.
Sie haben das Recht, von uns eine Bestätigung zu verlangen, ob Sie betreffende personenbezogene Daten verarbeitet werden. Im Falle einer Verarbeitung haben Sie ein Recht auf Auskunft über diese Daten sowie auf die in Art. 15 DSGVO aufgeführten Informationen.
Sie haben das Recht, von uns unverzüglich die Berichtigung unrichtiger oder die Vervollständigung unvollständiger Sie betreffender Daten zu verlangen (Art. 16 DSGVO).
Sie haben das Recht, die Löschung Sie betreffender Daten zu verlangen, sofern einer der in Art. 17 DSGVO genannten Gründe zutrifft (Art. 17 DSGVO).
Sie haben das Recht, die Einschränkung der Verarbeitung zu verlangen, wenn eine der in Art. 18 DSGVO aufgeführten Voraussetzungen gegeben ist (Art. 18 DSGVO).
Sie haben das Recht auf Datenübertragbarkeit (Art. 20 DSGVO).
Sie haben das Recht, sich bei einer Datenschutz-Aufsichtsbehörde zu beschweren (Art. 77 DSGVO). In der Regel können Sie sich hierfür an die Aufsichtsbehörde Ihres Aufenthaltsortes, Arbeitsplatzes oder unseres Unternehmenssitzes wenden.
Zur Ausübung Ihrer Rechte: info@altemis-consulting.de
Sie haben das Recht, aus Gründen, die sich aus Ihrer besonderen Situation ergeben, jederzeit gegen die Verarbeitung Sie betreffender personenbezogener Daten Widerspruch einzulegen (Art. 21 DSGVO).
Wir verarbeiten die Daten dann nicht mehr, es sei denn, wir können zwingende schutzwürdige Gründe nachweisen, die Ihre Interessen, Rechte und Freiheiten überwiegen, oder die Verarbeitung dient der Geltendmachung, Ausübung oder Verteidigung von Rechtsansprüchen.
Der Landesbeauftragte für den Datenschutz und die Informationsfreiheit Baden-Württemberg
Lautenschlagerstraße 20, 70173 Stuttgart
www.baden-wuerttemberg.datenschutz.de
Unsere Website verwendet SSL/TLS-Verschlüsselung, erkennbar an „https://" und dem Schloss-Symbol in der Adresszeile Ihres Browsers.
Wir behalten uns vor, diese Datenschutzerklärung anzupassen, um sie an geänderte Rechtslagen oder Änderungen unserer Leistungen und Datenverarbeitung anzupassen. Dies gilt jedoch nur für Erklärungen zur Datenverarbeitung. Soweit Einwilligungen der Nutzer betroffen sind, erfolgen Änderungen nur mit deren Zustimmung.
Stand: März 2026
Diese AGB gelten für alle, auch zukünftigen Verträge, Lieferungen und sonstigen Leistungen zwischen Alper Altay – ALTEMIS Consulting · Einzelunternehmen, Richard-Wagner-Str. 68, 77694 Kehl (nachfolgend „Auftragnehmer") und seinen Kunden (nachfolgend „Auftraggeber") über Beratungs- und Dienstleistungen. Es gilt stets die zum Zeitpunkt des Vertragsschlusses gültige Fassung der AGB.
Die Leistungen richten sich ausschließlich an Unternehmer im Sinne des § 14 BGB, d. h. natürliche oder juristische Personen oder rechtsfähige Personengesellschaften, die bei Abschluss des Vertrages in Ausübung ihrer gewerblichen oder selbständigen beruflichen Tätigkeit handeln. Der Vertragsschluss mit Verbrauchern im Sinne des § 13 BGB ist ausgeschlossen. Mit Auftragserteilung bestätigt der Auftraggeber, Unternehmer im Sinne des § 14 BGB zu sein.
Abweichende AGB des Auftraggebers werden nur Vertragsbestandteil, wenn der Auftragnehmer ihrer Geltung ausdrücklich schriftlich zugestimmt hat. Mündliche Vereinbarungen und Zusicherungen werden erst durch schriftliche Bestätigung des Auftragnehmers verbindlich.
Angebote des Auftragnehmers sind freibleibend und unverbindlich. Der Vertrag kommt zustande durch schriftliche Auftragsbestätigung des Auftragnehmers oder durch Beginn der Leistungserbringung.
Wir behalten uns vor, Aufträge abzulehnen, falls bei der Auftragsabwicklung Rechte Dritter verletzt oder gegen Gesetze verstoßen würde. In diesem Fall informieren wir den Auftraggeber unverzüglich per E-Mail.
Art und Umfang der Leistungen ergeben sich aus dem jeweiligen Angebot oder Projektvertrag. Der Auftragnehmer erbringt Beratungsleistungen mit der Sorgfalt eines ordentlichen Kaufmanns. Beratungsleistungen sind grundsätzlich Dienstleistungen (§ 611 BGB) und keine Werkleistungen (§ 631 BGB), sofern nicht ausdrücklich anders vereinbart.
ALTEMIS Consulting setzt zur Erbringung seiner Leistungen digitale Werkzeuge ein, darunter KI-gestützte Software zur Textverarbeitung, Datenanalyse und Visualisierung. Der Einsatz dieser Werkzeuge erfolgt unterstützend – die fachliche Einordnung, methodische Bewertung und Qualitätssicherung aller Arbeitsergebnisse liegt ausschließlich beim Berater. Kein Ergebnis wird ungeprüft an den Auftraggeber übergeben.
Der Auftraggeber wird auf Nachfrage über die im Rahmen seines Auftrags eingesetzten Werkzeuge informiert.
Der Auftraggeber ist verpflichtet:
Verzögerungen aus unterlassener Mitwirkung gehen nicht zu Lasten des Auftragnehmers. Mehraufwände werden nach tatsächlichem Aufwand berechnet.
Die Vergütung richtet sich nach dem jeweiligen Angebot oder vereinbarten Tagessatz. Alle Preise sind Endpreise (§ 19 UStG – Kleinunternehmerregelung).
Rechnungen sind zahlbar innerhalb von 14 Tagen nach Rechnungsdatum ohne Abzug. Bei Zahlungsverzug werden Verzugszinsen gemäß § 288 Abs. 2 BGB (9 Prozentpunkte über Basiszinssatz) berechnet. Die Geltendmachung eines weitergehenden Verzugsschadens bleibt vorbehalten.
Das Recht des Auftraggebers zur Aufrechnung besteht nur, wenn seine Gegenansprüche vom Auftragnehmer anerkannt oder rechtskräftig festgestellt sind. Ein Zurückbehaltungsrecht kann der Auftraggeber nur insoweit ausüben, als sein Gegenanspruch auf demselben Vertragsverhältnis beruht.
Zahlungsmethode: Überweisung. Bankverbindung wird nach Auftragsbestätigung auf der Rechnung mitgeteilt.
Vereinbarte Termine sind verbindlich, sofern schriftlich als solche bezeichnet. Bei Verzug des Auftragnehmers ist eine angemessene Nachfrist von mindestens 14 Tagen zu setzen, bevor Rücktritt oder Schadensersatz verlangt werden kann.
Falls die Nichteinhaltung einer Leistungsfrist auf höhere Gewalt, Arbeitskampf, unvorhersehbare Hindernisse oder sonstige vom Auftragnehmer nicht zu vertretende Umstände zurückzuführen ist, wird die Frist angemessen verlängert. Etwaige gesetzliche Ansprüche des Auftraggebers bleiben unberührt.
Beide Parteien halten alle erlangten vertraulichen Informationen dauerhaft geheim und verwenden sie nur zur Vertragserfüllung. Diese Pflicht gilt auch nach Vertragsende für die Dauer von 5 Jahren.
Alle erstellten Arbeitsergebnisse sind urheberrechtlich geschützt. Mit vollständiger Zahlung überträgt der Auftragnehmer ein einfaches, nicht übertragbares Nutzungsrecht für den vereinbarten Zweck.
Verwertung für andere Zwecke bedarf schriftlicher Zustimmung. Der Auftragnehmer behält das Recht zur Referenznennung, sofern keine Geheimhaltungsvereinbarung entgegensteht.
Der Auftragnehmer haftet unbeschränkt, soweit die Schadensursache auf Vorsatz oder grober Fahrlässigkeit beruht sowie bei Schäden aus der Verletzung des Lebens, des Körpers oder der Gesundheit.
Der Auftragnehmer haftet auch für die leicht fahrlässige Verletzung von wesentlichen Pflichten (Pflichten, deren Verletzung die Erreichung des Vertragszwecks gefährdet) sowie für die Verletzung von Kardinalpflichten (Pflichten, deren Erfüllung die ordnungsgemäße Durchführung des Vertrages überhaupt erst ermöglicht und auf deren Einhaltung der Auftraggeber regelmäßig vertrauen darf), jedoch jeweils nur für den vorhersehbaren, vertragstypischen Schaden und begrenzt auf den Netto-Auftragswert des betroffenen Projekts.
Für die leicht fahrlässige Verletzung anderer als der vorstehend genannten Pflichten haftet der Auftragnehmer nicht. Die Haftung für mittelbare Schäden, Folgeschäden, entgangenen Gewinn und Datenverlust ist in diesen Fällen ausgeschlossen.
Die Haftungsbeschränkungen gelten auch zugunsten der Erfüllungsgehilfen des Auftragnehmers.
Rahmenverträge können von beiden Seiten mit 4 Wochen Frist zum Monatsende schriftlich gekündigt werden. Das Recht zur außerordentlichen Kündigung aus wichtigem Grund bleibt unberührt. Bereits erbrachte Leistungen sind stets zu vergüten.
Die Geschäftsbeziehungen zwischen den Parteien unterliegen dem Recht der Bundesrepublik Deutschland unter Ausschluss des UN-Kaufrechts (CISG). Da die Leistungen ausschließlich gegenüber Unternehmern erbracht werden, ist ausschließlicher Gerichtsstand für alle Streitigkeiten aus oder im Zusammenhang mit diesem Vertrag das Amtsgericht Offenburg. Unwirksame Bestimmungen werden durch wirksame ersetzt, die dem wirtschaftlichen Zweck am nächsten kommen. Änderungen dieser AGB bedürfen der Schriftform, einschließlich der Aufhebung dieses Erfordernisses.
Gemäß TTDSG und DSGVO – Stand: März 2026
Cookies sind kleine Textdateien, die beim Website-Besuch auf Ihrem Endgerät gespeichert werden und bestimmte Einstellungen im Browser speichern.
Wir verwenden ausschließlich technisch notwendige Cookies:
Analyse-, Tracking- oder Marketing-Cookies werden nicht eingesetzt.
Technisch notwendige Cookies erfordern nach § 25 Abs. 2 Nr. 2 TTDSG keine Einwilligung.
Sie können Cookies jederzeit über Ihren Browser löschen oder deaktivieren. Bei Deaktivierung technisch notwendiger Cookies kann die Funktionsfähigkeit der Website eingeschränkt sein. Fragen: info@altemis-consulting.de
Stand: März 2026
Die Inhalte dieser Website wurden mit größtmöglicher Sorgfalt erstellt. Für Richtigkeit, Vollständigkeit und Aktualität übernehmen wir jedoch keine Gewähr. Als Diensteanbieter sind wir gemäß § 7 Abs. 1 TMG für eigene Inhalte verantwortlich. Nach §§ 8–10 TMG sind wir nicht verpflichtet, fremde Informationen zu überwachen oder nach Umständen zu forschen, die auf eine rechtswidrige Tätigkeit hinweisen.
Unser Angebot enthält Links zu externen Websites Dritter, auf deren Inhalte wir keinen Einfluss haben. Für diese Inhalte übernehmen wir keine Gewähr. Zum Zeitpunkt der Verlinkung waren keine Rechtsverstöße erkennbar. Bei Bekanntwerden von Rechtsverletzungen entfernen wir entsprechende Links umgehend.
Die von uns erstellten Inhalte unterliegen dem deutschen Urheberrecht. Vervielfältigung, Bearbeitung und Verwertung außerhalb der gesetzlichen Grenzen bedürfen schriftlicher Zustimmung. Downloads sind nur für den privaten, nicht kommerziellen Gebrauch gestattet.
Bei Bekanntwerden von Urheberrechtsverletzungen entfernen wir entsprechende Inhalte umgehend.
Ich habe Ihre Terminbuchung erhalten und melde mich umgehend – spätestens innerhalb von 24 Stunden mit einer Bestätigung und allem, was wir für ein produktives Gespräch brauchen.
Falls Sie die Wartezeit nutzen möchten – diese Artikel geben einen guten Eindruck davon, wie ich technische Fragestellungen einordne:
Die folgenden Projekte sind anonymisiert — aus Gründen der Vertraulichkeit werden keine Firmennamen oder Personen genannt.
Was bleibt: die Situation, die eigentliche Fragestellung und das Ergebnis.
Jedes Projekt hatte einen sichtbaren Anlass — und ein eigentliches Problem darunter.
Ausgangssituation
Ein wachsender Online-Händler mit 708 Artikeln auf eBay und Shopify hatte keinen systematischen Überblick über Wettbewerberpreise. Manuelle Recherche war stundenintensiv oder wurde schlicht weggelassen — Preisentscheidungen basierten auf Bauchgefühl.
Das eigentliche Problem
Die Daten lagen im Markt — aber unstrukturiert und nicht automatisiert abrufbar. Wer teurer als die Konkurrenz war, merkte es erst am ausbleibenden Verkauf. Wer zu günstig war, ließ Marge liegen, ohne es zu wissen.
Was getan wurde
Aufbau eines lokalen Dashboards, das täglich alle Wettbewerber-Listings von eBay zieht, sie automatisch gegen den eigenen Bestand matcht (via Artikelnummer) und farblich markiert: zu teuer, zu günstig, Abstand in Euro. Dazu ein Markt-Radar für gefragte Produkte, die noch nicht im Sortiment sind. Preise direkt aus dem Dashboard heraus pushbar — kein manuelles eBay-Login mehr. Kein Cloud-Abo, kein monatlicher Kostenpunkt.
Ausgangssituation
Eine Stadtverwaltung im südlichen Baden-Württemberg kämpfte mit gewachsenen Strukturen: Vorgänge in Ordnern, Genehmigungsabläufe per E-Mail-Kette, Ablage nach Mitarbeitergedächtnis. Neue Kolleginnen und Kollegen fanden sich kaum zurecht — und die Verwaltungsleitung spürte, dass Digitalisierung allein das Problem nicht lösen würde.
Das eigentliche Problem
Software war nicht das Problem — Struktur war es. Welcher Vorgang gehört wohin? Wer darf was sehen? Wie läuft ein Genehmigungsprozess ab? Diese Fragen waren nie formal beantwortet worden. Eine Software-Einführung ohne diese Klärung hätte dieselben Probleme einfach digitalisiert.
Was getan wurde
Beratende Begleitung bei Anforderungsanalyse, Prozessstrukturierung und DMS-Einführung. Von der Konzeptphase bis zur Inbetriebnahme: sechs Wochen. Übergabe inkl. vollständig dokumentierter Ablagestruktur und internen Schulungen — kein externer Support mehr nötig.
Ausgangssituation
Ein Entwicklungsteam stand kurz vor der Serienfreigabe eines thermischen Managementsystems für Leiterplatten. Die Analyse zeigte grüne Werte — aber das Prüfstandsverhalten stimmte nicht mit den Modellen überein. Freigabetermin: drei Wochen.
Das eigentliche Problem
Nicht das Ergebnis war falsch — die Randbedingungen waren es. Ein Wärmequellenwert war aus einem früheren Produktdesign übernommen worden, ohne je hinterfragt zu werden. Eine Lücke, die nur durch eine externe Perspektive sichtbar wurde.
Was getan wurde
Systematische Prüfung aller Modellannahmen gegen Datenblätter, Messprotokolle und physikalische Plausibilität. Identifikation der abweichenden Randbedingung. Dokumentiertes Review-Ergebnis mit Handlungsempfehlung und angepasstem Parametervorschlag.
Ausgangssituation
Ein Entwicklungsteam arbeitete an einem neuen Steuergerät-Konzept bei einem Automobilzulieferer in Süddeutschland. Drei Subsysteme wurden parallel von verschiedenen Teams entwickelt — jedes für sich dokumentiert. Im Gesamtsystem entstanden unklare Schnittstellen und endlose Abstimmungsschleifen.
Das eigentliche Problem
Es gab keine gemeinsame Systemebene. Jedes Team dachte in seinem Subsystem — eine übergreifende Struktur, die Abhängigkeiten und Entscheidungspunkte sichtbar machte, fehlte vollständig. Meetings wurden länger, Entscheidungen immer schwieriger.
Was getan wurde
Vier strukturierte Sessions à zwei Stunden. Aufbau einer schlanken Systemarchitektur ohne Enterprise-Tool, die alle Subsysteme verbindet. Definition der kritischen Schnittstellen und offenen Entscheidungspunkte — vom Team selbst weiterführbar.
Alle vier Projekte sind real. Namen und personenbezogene Details wurden aus Gründen der Vertraulichkeit anonymisiert. Branchen, Ortsangaben, Vorgehensweisen und Ergebnisse entsprechen dem tatsächlichen Projektverlauf.
Ein guter Berater kennt seine Grenzen — und kommuniziert sie klar. Das erspart beiden Seiten Zeit.
Wenn Ihre Fragestellung in diese Bereiche fällt, empfehle ich Ihnen gerne spezialisierte Ansprechpartner.
Kostenloses Erstgespräch – unverbindlich, 45 Minuten.
Diese URL existiert nicht. Möglicherweise haben Sie sich vertippt – oder die Seite wurde verschoben.
Diese Website verwendet ausschließlich technisch notwendige Cookies. Keine Analyse-, Tracking- oder Marketing-Cookies. Mehr erfahren
