The idea for TeepTrak came out of that frustration. This article is for the consultants still inside the firm \u2014 BCG, McKinsey, Bain, Kearney, Roland Berger, Sia Partners, and adjacent \u2014 who recognize the pattern. It is also for the alumni who have left and are thinking about what to build next. The specific lessons I took from four years in consulting shaped every major design decision in TeepTrak, and most of them are transferable.<\/p>\n
![\"Fran\u00e7ois](\"https:\/\/teeptrak.com\/wp-content\/uploads\/2026\/04\/TeepFrancois-Coulloudon-1-modified-1.jpg\")
<\/p>\n\nThis article reflects perspectives built during 4 years at BCG working on LEAN programs, operational performance and cost reduction missions across Europe, Asia and the Americas.<\/em>\n<\/div>\n<\/div>\n
Lesson 1: the 80\/20 on what operators actually tag<\/h2>\n
Every MES I saw deployed during my BCG years had the same downtime reason taxonomy: 50 to 200 codes, organized in nested menus, with mandatory fields for batch number, material, shift and operator. Every MES also had the same data quality problem: operator entry rates below 40%, with “other” being the single most common code.<\/p>\n
The root cause was not operator laziness. On a line running at normal cadence, a one-minute micro-stop gives the operator roughly 45 seconds of actual time to react, diagnose, reset and resume production. The MES interaction asks for 20-40 seconds of that. If the operator is also supposed to be watching the line, the math does not work. Human attention is a finite budget and the MES was spending more of that budget than was available.<\/p>\n
When we designed TeepTrak’s operator interface, this was the first constraint. We fixed the interaction to under 3 seconds: five large buttons for the top-level categories (downtime, micro-stop, changeover, maintenance, other), with the detailed reason defaulting to a smart suggestion based on recent patterns at that workstation. Operators can correct the suggestion in a second tap, but the default is usually right because the tool has seen the last hundred events at that station. Entry rates in production typically run at 92-97%, which is the specific data quality difference that makes every downstream analysis actually work.<\/p>\n
Lesson 2: IT integration is where projects die<\/h2>\n
The second insight came from watching MES deployments stall in the integration phase. On one BCG mission for a Moroccan auto supplier, the MES implementation was six months behind schedule. The reason was not the MES itself. It was the PLC integration: 47 machines, 11 different PLC vendors, three separate SCADA systems, and a firewall architecture that required IT team approval for every data read. Every connector took weeks to validate because every read touched a production system that nobody wanted to put at risk.<\/p>\n
This is the universal pattern. The MES specification looks simple on paper \u2014 read run\/stop state, read throughput, read cycle time \u2014 until you hit the reality of a live brownfield plant. PLC programs are old, often undocumented, often running firmware that the OEM will not support modifications to. OT\/IT coordination is political. Every integration touches a production risk that someone has to own.<\/p>\n
When we designed TeepTrak, we made a hard architectural choice: no PLC reads, ever<\/strong>. The system uses external sensors \u2014 current clamps on the main power feed, vibration sensors attached to the equipment chassis, photoelectric sensors at line outputs \u2014 that measure equipment state without touching the PLC or the control network. This approach sacrifices some signal granularity (you cannot read specific PLC variables) but buys something far more valuable: the ability to deploy in one to two weeks on any plant, regardless of equipment age, PLC brand, or IT posture. Every consultant who has watched an MES slip by six months because of PLC integration understands why this trade-off is worth it.<\/p>\n A BCG mission for a large pharma client in Thailand around 2014 crystallized the third lesson. The client had spent 18 months and several million dollars on an MES deployment. The dashboards worked. The integration worked. The reports ran. And the operational performance had not meaningfully improved. OEE was still around 58% on the packaging lines, roughly where it had been before the project started.<\/p>\n What the client bought was a measurement infrastructure. What they actually needed was an improvement loop \u2014 data connected to decisions connected to actions connected to verified results. The MES gave them the first link and assumed the rest would happen organically. It did not.<\/p>\n This lesson pushed us to build TeepTrak around the improvement loop, not the measurement infrastructure. The 48-hour POC is designed to produce not just a baseline OEE number but an initial root-cause analysis with three to five specific improvement hypotheses. The JEMBA AI layer is explicitly about closing the analysis-to-action gap that MES projects leave open. The dashboards are tiered by role \u2014 operator, line lead, plant manager, global ops \u2014 so each audience sees the slice that leads to a decision they can make, not the full data lake that leads to paralysis.<\/p>\n Instant download. No email confirmation needed.<\/p>\n \n Lesson 3: the client cares about improvement, not the tool<\/h2>\n
Free Download<\/h3>\n