01 / The problem
Knowing that a supplier’s score changed wasn’t enough. People needed to understand why.
TechnipFMC depended on a large network of third-party suppliers. Supplier Quality focused on quality and safety expectations, investigation, and facility audits. Category Management managed the strategic and commercial relationships. Both groups needed a shared understanding of supplier performance and risk.
Risk assessment relied heavily on an Excel-based model. Supplier details and performance metrics lived in additional spreadsheets, while audit information and reporting were tracked across Word documents and other files. Each month, quality or safety events contributed to supplier scoring. A poor or deteriorating score could lead to investigation, cross-functional discussion, or a supplier-site audit.
Knowing that a supplier’s score changed was like knowing your credit score dropped without seeing the factors that caused it.
The issue was not that Excel looked bad. The story behind the score was fragmented across spreadsheets, documents, reports, shared storage, and manually distributed information.
02 / Product approach
Connect the signal to the events that produced it.
A data-science team revisited and improved the underlying risk model. Instead of rebuilding and distributing an Excel report each month, the model ran through the application’s backend and published updated information into a database-backed product. The previous Excel calculation and tracking process was retired rather than maintained behind the scenes.
The product connected supplier → score → contributing events → historical context. Supplier Quality could explain what changed, what contributed to the score, and what needed attention without manually reconstructing the story from disconnected files.
03 / My role
From discovery through working software.
I worked across interviews, discovery and framing workshops, synthesis, stories and journeys, feature definition, wireframes, high-fidelity product design, validation, iteration, React UI implementation, launch, and a later revision. Based on my recollection, the original Supplier RAM moved from our first meeting to production in about nine months.
The breadth mattered because the product sat between product management, development, data science, Supplier Quality, and Category Management. I helped translate those different perspectives into one coherent workflow.
04 / Supplier risk platform
One supplier record connected the risk signal to the evidence behind it.
The experience starts at the portfolio level, where status makes suppliers that need attention visible. Opening a supplier moves from that signal into its scorecard, the safety, quality, and delivery events behind it, and the broader history needed for investigation.
Search, ownership, supplier type, and safety, quality, and delivery status make the directory a starting point for investigation.
View full-size image ↗The summary combines scorecard factors with financial context, ownership, regional support, and contact information.
View full-size image ↗The safety view exposes the history and supporting attachments behind the current status.
View full-size image ↗Quality notifications, reported impacts, field failures, and additional details explain what contributed to the score.
View full-size image ↗On-time delivery, average days late, purchase-order history, and reported impacts sit in the same view.
View full-size image ↗05 / Management reviews
Turn a risk signal into a shared plan.
When an issue required formal cross-functional attention, a Supplier Management Review gave Category Management and Quality Engineering one place to document who was involved, why the review was happening, the management strategy, required actions, attachments, and change history.
The review register makes status, reason, and recent activity visible without leaving the supplier record.
View full-size image ↗Category managers and quality engineers can capture participants, reasons for review, the management plan, required actions, attachments, and change history in one record.
View full-size image ↗06 / Supplier verification
Build the audit around the work being verified.
Supplier Performance Verification, or SPV, turned a generic audit into a configurable workflow. Engineers selected the checklist categories relevant to the supplier and the work being inspected, then completed the generated questions, explanations, evidence, and report.
The system supported both sides of the form: authorized users could manage and edit the questionnaire, while engineers could use it during a verification. It also preserved form versions as the questionnaire changed, keeping each completed SPV tied to the form that governed it.
Representative interface designs with fictitious supplier data.
The SPV register keeps verification status, reason, and recent activity connected to the same supplier context.
View full-size image ↗Before an SPV begins, the engineer selects only the checklist categories needed for that supplier verification—from assembly and welding to machining, NDE, and pressure testing.
View full-size image ↗The generated form combines inspection context, participants, category-specific questions, response states, explanations, image evidence, completion progress, and report generation.
View full-size image ↗07 / Mobile field workflow
Take the verification to the supplier site.
Quality Engineers previously combined paper forms, handwritten notes, separate cameras or phones, later transcription, and manually assembled reporting while working at supplier facilities. That duplicated work and fragmented the verification record.
The V2 mobile experience was designed around an iPhone used on site. Engineers could see assigned SPVs, choose the required checklists, capture cover-sheet information, answer one question at a time, dictate notes, attach photographs, review progress, complete the verification, and generate or share the report. The workflow could extend to an iPad, but the design focus was the iPhone.
Assignment → checklist → field evidence → completed verification → shared report
Nine representative states show the field workflow from the engineer’s work queue through checklist selection, question entry, photo evidence, completion, and report sharing.
View full-size image ↗08 / Outcome & lessons
The product earned enough trust for the team to ask for more.
The original Supplier RAM reached production, replaced the Excel-based risk model and supplier tracking process with a database and application backend, and gave previously fragmented work a shared home. The clearest adoption signal was what happened next: instead of asking us to retreat or rebuild, Quality Engineering asked us to bring another substantial workflow into the product.
That request became the V2 mobile SPV experience—a practical sign that the first release had earned enough trust for the team to ask for more.
Digitizing a workflow and transforming a workflow are not the same thing.
Supplier RAM successfully centralized a fragmented workflow and made it usable as software. In retrospect, we still mostly produced a strong digital implementation of the existing process.
The larger opportunity was predictive intervention: using historical and operational data to identify suppliers trending toward trouble before the situation became severe enough to trigger reactive action. Stakeholders were not necessarily ready to change the process that radically.
Reactive risk management → predictive intervention
That distinction now shapes how I evaluate product opportunities. Putting a spreadsheet in a browser can be valuable. The more important question is what becomes possible once the workflow is software.