Diagnosing a fragmented product-update system
A professional systems case from Safran Defense & Space. Public detail is intentionally limited by confidentiality and export-control context.
StakeholdersEngineering · Technicians · Quality · Compliance
TranslationInterviews → workflow map → requirements
SystemControlled internal update path
BoundaryExpanded after discovery
I was assigned one broken step. Discovery showed the failure was end to end.
A post-merger product-update process had become fragmented across functions. The visible symptom was smaller than the system that produced it.
I interviewed people across engineering, technician, quality, compliance, and management roles. The work became a map of handoffs, version rules, operational constraints, and requirements for a controlled internal path.
What I can show: the problem-framing method, stakeholder breadth, product scope, and the reasoning that expanded the system boundary.
What I will not show: internal code, portal UI, product data, export-control detail, or a reconstruction of proprietary architecture.
Information crossing teams was the primary interface.
Different functions experienced different pieces of one broken process
Map the complete journey before designing the internal workflow
Requirements and automation covered a portfolio of 100+ products
Keep implementation and metric definitions private until public disclosure is explicitly cleared
The public case remains intentionally narrow.
Reported · individual
The workflow covered a portfolio of more than 100 products
reported
Confidentiality is part of the engineering context, not a missing design asset.
Public clearance for implementation detail, architecture, and measured result definitions
Which explanatory visuals can be published without reconstructing internal systems
The visible symptom was not the true system boundary.