SAP MRP Cockpit
Making material shortages visible at a glance
Client
SAP
Role
Visual designer; co-designed the shortage chart
Team
Interaction designer, UX advocate, product owners, 4 developers
Timeline
15 months · 2013–2014
Overview
MRP Cockpit is SAP’s tool for material requirements planning: making sure the parts a factory needs arrive before customer orders are due. I joined the project in March 2013 as its visual designer, partnered with an interaction designer who was also our front-end developer, and a scrum team of four developers in Munich. A first prototype already existed. Our job was to turn it into something SAP could show at SAPPHIRE, its biggest customer event, in May 2013, and then ship. Our central idea was a chart that shows each part’s supply, demand and shortages over time, and the decision-support work around it later grew into a US patent. I left SAP in June 2014, before the product launched.
1
US patent grew from the work
3
screen sizes in one chart spec
6
solution tile versions in code
Not usage metrics: I left SAP in June 2014, before MRP Cockpit launched. Solution tile versions are from the team’s prototype library. Patent: US 10,180,978 B2, granted January 2019.
01
Problem
Material planners had to dig through huge tables of supply and demand data to see which parts would run short, and when, so the shortages that mattered were hard to spot in time.
MRP planners live with two pressures: keep inventory as low as possible, but never run out of a part an order needs. Our persona, Gunther, was a near power user in a manufacturing plant.
Too much data, too little signal. His core job was teasing a few critical issues out of very large data volumes, in screens built around database tables rather than tasks.
Decisions needed context. To fix a shortage, a planner needed supply, demand and timing together in one place, not spread across several transactions.
Little access to real users. Customer visits (Coroplast, ERCO, Daimler and a call with Colgate) were run by product owners and focused on functionality. Designers rarely got to talk to planners themselves.
Everything was moving. We were designing inside a new shell, visual language and tile system that were all still changing, and for desktop, while the rest of SAP was going mobile-first.
02
How a stock table became a waterfall chart
We worked in short loops: sketches, wireframes in Balsamiq and Illustrator, many rounds of mock-ups in Photoshop, a rough build with SAP’s standard UI5 controls, then a final version styled with our own CSS. The chart also had to work for other SAP apps, not just MRP. Five decisions shaped the product:
Show the balance, not just the rows. A colleague’s first wireframe paired a table with a bar-and-line chart. My own first sketches tried several alternatives, including one I labeled “connected waterfall.” My design partner explored ideas in Balsamiq, inspired by the Google Finance chart, and I carried them into detailed wireframes in Illustrator. Overlapping supply and demand bars broke in edge cases, and an end-of-day stock line drawn through the middle of the bars was confusing, so we settled on a waterfall: each delivery steps stock up, each requirement steps it down, and a dot marks the balance at the end of the day. Days that dip below zero are shaded red, so the shortage is the first thing you see.
Lead with the problem. The detail view opens on the part’s days of supply and how much is missing, and when (“60 pcs missing in 5 days”), with every short material listed on the left.
Design for real data. Our spec covered the awkward cases: days with no supply or demand, many orders on one day, and spikes that would flatten everything else. A range slider under the chart lets planners zoom into a week without losing the month.
Put the fix next to the problem. A condensed view slides up solution tiles (accept, transfer, reschedule) beneath the chart, so a planner can act without leaving it. The chart answers “When will this part run short?” The tiles started on the planner’s next question: “If I choose this fix, what else changes?” That question grew into a patent that names me as a co-inventor.
Get it into code early. I set a 1,200px grid, a 10px baseline and responsive breakpoints, wrote type specs as CSS, and reviewed builds with annotated screenshots. Custom CSS over UI5’s default controls is what turned a rough draft into a demo.
Where we started: a colleague’s wireframe for the shortage view. The table told planners a part was short; the chart underneath tried to show why, but bars, a line and callouts competed for attention.
My first back-of-napkin sketches, before any wireframes. The one labeled “connected waterfall” is where the chart’s final shape started.
A few of the many rounds of high-fidelity mockups: grouped bars in the Blue Crystal theme, stepped columns, bars with a stock line, then the waterfall. The chart had to work for other SAP apps too, not just MRP.
Three views from the spec I created for developers. The condensed view slides solution tiles up under the chart so a planner can act on a shortage without leaving it.
Interactions from the same spec, for desktop, tablet and phone: double-click or double-tap a column to open its popover, drag to pan the chart, and drag the range slider to change the days in view.
My visual design specs for the chart, popover and legend. Sizes are in rem, and fonts and colors are SAP UI5 theme values, so developers could build it with the product’s own styles.
03
Outcome
Demoed at SAPPHIRE. We hit the May 2013 deadline. MRP Cockpit was shown at SAPPHIRE as a pilot for SAP’s new desktop shell and an early use of Fiori-style tiles on the desktop.
Specified for release. By October 2013 the chart had a full interaction and visual spec for desktop, tablet and phone, and the team was building toward the first release. I left in June 2014, before launch, so I don’t have usage results.
A patent. SAP filed the decision-support idea in 2015, after I’d left, and it was granted in 2019 as US Patent 10,180,978. It names me alongside two colleagues from the project, including the colleague whose wireframe we started from.
Shared inside SAP. My design partner and I presented the project, and how we worked as a designer-developer pair, to other teams in June 2013.
04
What I learned
Put designers and developers in the same room. My design partner was both our interaction designer and our front-end developer, and the best ideas came from sketching and arguing together, not handing files over a wall.
Validate in code, early. Our biggest jumps came from putting a mock-up into a quick HTML prototype and seeing it with real data. Next time I’d push for rougher prototypes sooner, and fight harder to talk to planners directly.
Design the handoff for its reader. My chart spec was one very long image. It covered everything, but the format didn’t suit the developers using it. Sections sized to fit a standard slide deck would have been easier to work from.
And know the difference between decoration and design. In a dense enterprise screen every color has to earn its place: if a button is blue, there should be a reason.
