01 / The situation
SAP contained the data. Sentinel’s job was to make the problem obvious.
TechnipFMC delivered complex equipment assembled from many components. A single late critical component could delay the larger order. SAP held supply-chain and manufacturing data, but understanding what threatened delivery could require substantial navigation and interpretation.
Sentinel began as an experiment initiated by a data scientist who brought the analytical concept and deep data/domain knowledge. We worked closely together to turn that idea into a product that could help someone decide where attention mattered now.
The latest critical component can determine how late the overall project becomes.
02 / What made it difficult
A list of late parts is not the same as understanding delivery risk.
An order could contain a deep bill of materials—a hierarchy of assemblies and components—with dependencies, changing dates, and different kinds of risk. People needed to see what was late, what might become late, and how component timing affected overall delivery.
Data → information → prioritization → anticipation → action
That progression became the product standard. Every view had to earn its place by helping the user move closer to a decision.
03 / My role
I designed and built the application.
I had unusually broad ownership: product designer, front-end developer, limited Java/backend/API contributor, and the person filling much of the product-management gap. There was no conventional dedicated PM managing the effort.
I was not working alone. The originating data scientist was an essential collaborator and source of analytical and domain understanding. My responsibility was translating that concept into a coherent, usable product.
- Turned the analytical concept into a usable product model
- Designed search, filtering, risk, detail, and remediation workflows
- Built the React front end and parts of the Java/API layer
- Created the critical-path visualization from scratch because existing tools did not represent the problem appropriately
04 / What we built
Two mental models for one complicated system.
The product represented the bill of materials in complementary ways: time and dependency through a custom critical-path timeline, and composition and hierarchy through a nested BOM navigator.
See which components are late or at risk, and how their timing changes projected delivery.
Move through assemblies and parts while preserving the context of the overall order.
Search and filters narrowed orders by timeframe, business unit, plant or location, planning responsibility, and other operational dimensions. Detail views supported possible remediation such as excess inventory, swaps between projects, or supply redirects.
05 / Reflection
The important move was from reporting the past to helping people intervene.
Sentinel was intended to show what was already late, anticipate what was at risk, and surface where an action might prevent further problems. That is the distinction between displaying enterprise data and creating decision support.
TODO: Add verified launch timing, adoption, qualitative feedback, and measurable operational outcomes. No figures are presented until they can be sourced.