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.
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.
Product definition
Turned the analytical concept into a usable product model.
Workflow design
Designed search, filtering, risk, detail, and remediation workflows.
Development
Built the React front end and parts of the Java/API layer.
Custom visualization
Created the critical-path visualization from scratch because existing tools did not represent the problem appropriately.
04 / What we built
Finding the orders that needed attention.
Search and filters narrowed orders by timeframe, business unit, plant or location, planning responsibility, and other operational dimensions.
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.
Detail views supported possible remediation such as excess inventory, swaps between projects, or supply redirects.
Compare opportunities across projects
The selected component stays in view while the table brings together plant, quantity, overseas status, and time left to requirement. These details support investigation of whether inventory allocated elsewhere could help.
Find a candidate part
Available inventory appears alongside the component hierarchy, with quantity, location context, and exact or similar matches. Users can select a candidate to investigate a possible alternative source.
Examine the evidence behind lead time
Historical lead times, a distribution summary, and supporting purchase-order records provide context for the selected component. Filters let users consider similar parts and parts with the same strategy.
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.