Monthly production output vs target (units)
Scrap units by work center
Downtime reasons — % of lost hours
Supplier on-time delivery %
Scrap by reject reason code
Consultant's Analysis
OEE of 74% sits 11 points below the 85% benchmark. The downtime breakdown reveals the root cause: 41% of lost production time is attributable to extended setup between shifts — not machine failure. This is a scheduling and handoff problem solvable without capital investment.
The scrap rate of 4.8% is more than double the target. Two work centers account for 67% of all scrap — a classic 80/20 pattern. The reject codes point to dimensional and deformation failures, suggesting tooling wear rather than systemic process issues.
Recommended actions: (1) Standardize shift changeover at the highest-downtime work centers — estimated 6–8 OEE point recovery within 60 days. (2) Audit tooling intervals before any broader quality initiative. (3) Close work orders aged 30+ days — open WOs delay variance recognition and distort cost reporting.
STAAR math proficiency — RGV districts vs Texas avg (%)
STAAR reading proficiency — RGV districts vs Texas avg (%)
Math proficiency trend — 2021 to 2024
Student population — at-risk vs not at-risk
Graduation rate vs dropout rate
Consultant's Analysis
RGV school districts serve one of the most challenging student populations in Texas — 59% at-risk, over 37% emergent bilingual. Against that backdrop, a 93.9% graduation rate represents a genuine district strength. It doesn't happen by accident and deserves protection and investment.
Math proficiency at 48% exceeds the state average but masks grade-level variation. TEA data shows proficiency gaps widening at the middle school level — suggesting elementary gains are not being sustained through the transition years. This is a curriculum alignment and early intervention problem, not a teacher performance problem.
Where analytics adds value for school districts: Most districts have the data — STAAR by campus, grade, and demographic; attendance by period; budget vs actual. What they lack is a system that surfaces the patterns early enough to act. A well-built dashboard gives curriculum coordinators the same real-time visibility over academic performance that an operations manager has over a production floor.
Digital vs branch transaction volume — monthly trend
Loan pipeline — applications by stage
Branch transaction volume by location
Digital channel mix — mobile vs web vs other
Support ticket volume — platform transition period
Consultant's Analysis
Digital adoption at 68% shows strong momentum, but the support ticket spike at go-live reveals a critical pattern — user adoption outpaced training and change management. When ticket volume peaks at launch, it signals users weren't prepared before the switch, not that the platform is failing.
Loan processing time at 11.4 days against an 8-day target is the most actionable gap. The pipeline stage breakdown consistently shows the bottleneck in document collection and underwriting review — not origination or closing. A focused process mapping exercise on those two stages would likely uncover manual handoffs that can be eliminated or automated.
Platform migrations create a data gap between old systems and new ones. Most organizations underestimate the reporting and process work required to close that gap. Dashboards leadership relied on before migration rarely transfer cleanly — they need to be rebuilt against the new data model. Getting ahead of that work before go-live is significantly less costly than rebuilding under pressure after the fact.
A $100M mid-size manufacturer operating across two sites across the US-Mexico border had never used MRP to manage production planning or inventory. The operation relied entirely on manual processes: shared spreadsheets, daily emails, and tribal knowledge held by individual planners. Demand forecasting was disconnected from the ERP system entirely, making it impossible to synchronize customer orders, material availability, and production schedules in real time.
A specific trigger for the first implementation phase was a recurring external problem: the company was incurring penalty charges from an external packaging container supplier for returning containers late. Over a six-month period, those penalties totaled approximately $23,000 — not because of negligence, but because there was no systematic way to plan container demand within the ERP. The data was there. The system had the capability. Nobody had connected the two.
The project was structured as a formal implementation with a project charter, defined scope, and a cross-functional team assembled from every department that touched the process. The team included the General Manager as project champion, the CFO/VP, the Master Scheduler as process owner, managers from Supply Chain, Production, Engineering, Quality, Shipping, Customer Service, Purchasing, and Costing — 15+ stakeholders in total.
The work was sequenced carefully to avoid disrupting live production:
- BOM verification and correction — ensuring the ERP had accurate bills of material before MRP would run against them
- Planning data setup — defining time fences, safety stock methodology, order policies, and lead times for each item in scope
- Process design — mapping the future-state flow from demand signal through planned order, release, material movement, and inventory transaction
- Team training — working with each department manager individually to ensure their team understood their role in the new process before go-live
- Performance metrics defined upfront — penalty charges, shipment delays due to container shortages, and inventory variance against perpetual records
A formal Gantt chart tracked each task by responsible owner, estimated duration, and completion date. Issues discovered during implementation — including BOM errors, allocation problems, and process gaps at the Mexico facility — were documented and resolved before expanding scope.
The most significant implementation challenge was organizational, not technical. The ERP system was capable of running MRP from day one. What was missing was alignment: each department had developed its own workarounds over years of manual planning, and getting 15 people from different functions to change established habits simultaneously — while production kept running — required careful change management. Real issues surfaced in the first weeks: night and weekend shifts weren't entering data on time, work orders were being released without following the new checklist, and allocation logic for cross-site transfers wasn't behaving as expected. Each issue was documented, assigned, and resolved through weekly review meetings.
The implementation successfully brought MRP planning into the ERP system for the targeted item scope, eliminating the manual tracking processes that had caused the penalty charge problem. Container demand was now visible within the same system that managed production orders, forecasts, and customer shipments — allowing the planning team to act on MRP signals rather than react to shortages. The penalty charges were eliminated. The project established the foundation, methodology, and cross-functional muscle for the broader MRP rollout that followed.
A recurring, unexplained balance had been accumulating in a general ledger account that the finance team had quietly categorized as rounding error. The account — a material rate variance account — was growing over time in a way that didn't match any known production event. Nobody in finance or operations could explain why it existed, where it was coming from, or how to stop it. It wasn't large enough to alarm auditors, but it was consistent, unexplained, and getting harder to ignore.
The investigation started with the transaction detail — pulling every ERP transaction that had posted to that specific GL account and working backward from there. The ERP system (the ERP system) tracks cost variances at the work order level, and each variance has a specific type: material rate variance, method variance, usage variance. The account in question was specifically a material rate variance — meaning the cost booked at WIP at time of issue was different from the standard cost in the system at time of close.
The transaction inquiry revealed the pattern: a specific type of component issue was generating the variance on work orders that had already been released. When the standard cost of a raw material was updated after a work order had been released and partially issued, any subsequent issues of that component at the new standard cost would create a variance — because the original WIP booking used the old cost, and the new issue used the new cost. The work order bill captures costs at release, not at issue. That difference posts to the material rate variance account automatically.
The root cause: the company's cost update process was not coordinated with open work order status. Standard costs were being updated mid-cycle, with no review of open work orders that had already been released and were actively running. Every time a raw material cost changed, any open WO that subsequently issued that material would generate an unplanned rate variance.
The resolution involved two components: operational and process. On the operational side, the specific transactions that had generated the variance were identified and explained to the cost accounting team, removing the mystery from the existing balance. On the process side, a new rule was implemented: standard cost updates would be reviewed against open work order status before being released. Work orders already in production against the old cost would be closed first, or the variance expectation would be documented and accepted as a known timing difference rather than an error.
The GL account was fully explained — every dollar traced to a specific transaction, work order, and cost event. Finance stopped categorizing it as rounding error and started managing it as a known, controllable variance type. The new process reduced the frequency of unplanned rate variances significantly, and when they did occur, the team knew exactly why and how to account for them. More broadly, the investigation produced a complete map of how ERP transactions flow to GL accounts — a reference the organization used going forward to understand, predict, and control cost postings.
The production floor of a $100M manufacturing operation was running completely blind. Leadership received daily KPI emails — output, scrap, downtime — but the numbers in those emails were based on manually compiled data that never changed between updates. When a manager asked "how are we doing right now?", there was no honest answer. Production reporting was done after the fact, often hours behind reality, and the data quality was unreliable enough that decisions made based on it frequently didn't match what was actually happening on the floor.
The ERP system (the ERP system) was collecting shop floor transactions — work order completions, scrap entries, labor reporting — but none of that data was being surfaced in a way that was usable for real-time management. The raw data existed. The visibility didn't.
The project started with a KPI design session — working with production managers, the general manager, and the cost team to identify what metrics actually mattered and what decisions they needed to support. The list was deliberately kept short: production output vs. target, scrap by work center, downtime by reason code, and work order status. Each metric was mapped to a specific ERP transaction so that the data source was unambiguous.
Custom programs were built directly in the ERP system using the ERP's native development language. This approach was deliberate: by building inside the ERP rather than pulling data into a separate system, there was no ETL lag, no synchronization problem, and no data discrepancy between the shop floor report and the official system of record. What you saw was what the ERP knew.
The shop floor entry screen was also redesigned — simplified to show only the fields operators needed to fill in, with defaults applied to everything else. This wasn't cosmetic; reducing the number of required decisions at entry directly reduced data entry errors and improved the quality of the data flowing into the reporting system.
The technical build was straightforward. The harder problem was behavioral: operators and supervisors who had been doing manual reporting for years had to change how and when they entered data. The system only showed current reality if data was entered in real time. Training focused not just on how to use the new screens, but on why timely entry mattered — connecting each supervisor's data entry to the management reports their general manager was reading.
For the first time, leadership had access to real-time production data tied directly to the ERP system of record. The daily KPI email was replaced by a live dashboard that updated continuously throughout the shift. Scrap patterns by work center became visible within the shift they occurred rather than the following morning. Downtime by reason code created an accountability structure that hadn't existed before — supervisors could see their numbers in real time, and so could their managers. The system became the foundation for subsequent analytics work, including the variance analysis tools and the outside service tracking system built on the same infrastructure.
A $100M manufacturer operating across the US-Mexico border had been running on the same ERP system (the ERP system) for over two decades. The system was stable and deeply embedded, but increasingly difficult to extend — the development environment was aging, integrations with modern tools were complex, and the vendor's long-term roadmap created uncertainty about support. Leadership recognized that a platform decision needed to be made, but the organization had no structured methodology for evaluating enterprise software. Previous technology decisions had been made based on vendor relationships and demonstrations rather than systematic requirements matching.
The evaluation was structured as a formal requirements-driven process. Discovery sessions were conducted across 12 departments — production, purchasing, engineering, quality, shipping, finance, customer service, costing, materials, IT, executive leadership, and the Mexico facility — to document current-state pain points, non-negotiable requirements, and future-state needs specific to each function.
Four platforms were brought into the evaluation:
- Plex Systems — cloud-native manufacturing ERP, strong shop floor capabilities
- Epicor (Cambia) — mid-market manufacturer focus, configurable workflows
- Infor CloudSuite Industrial — enterprise-grade, strong cross-border and multi-site support
- SYSPRO — manufacturing-focused, known for strong costing and inventory management
Each vendor was evaluated against the documented requirements using a structured scoring framework. Vendor demonstrations were scripted around real business scenarios — not generic product tours — so the evaluation team could see how each system handled their specific processes: cross-site inventory transfers, outside service (subcontract) management, multi-currency purchasing, and shop floor reporting at the Mexico facility.
The evaluation process surfaced requirements the organization hadn't fully articulated before starting — particularly around the Mexico facility's needs, which were often treated as an afterthought in previous technology discussions. Cross-border inventory visibility, dual-currency cost structures, and Spanish-language user interfaces emerged as non-negotiables that significantly narrowed the field. The process also revealed that several departments had requirements that conflicted with each other, requiring facilitated priority discussions before scoring could be completed honestly.
The evaluation produced a documented, defensible recommendation with scoring rationale — not a gut-feel vendor preference. Leadership had a structured basis for their platform decision, with each department's requirements accounted for and the trade-offs between platforms clearly articulated. The process itself — the discovery methodology, the requirements framework, the scripted demonstration approach — became a reusable asset for future technology evaluations within the organization.
Simplified Shop Floor Reporting Screen
Rebuilt the ERP entry screen to show only required fields and default all others — reducing data entry errors at the source.
Operation-Level Reject Cost Calculator
Calculated true reject cost at the operation level using BOM and routing data — a calculation the ERP was incapable of producing natively.
Bulk Work Order Scheduling Tool
Enabled planners to download, modify, and upload all open work orders at once — enabling visual capacity planning for the first time.
Standard Cost Calculator & Comparator
Compared calculated cost against system cost and released WO cost — enabling proactive identification of method variance before it hit the GL.
Outside Service Inventory Tracker
Real-time visibility into parts at external suppliers — replacing a manual Excel system with no audit trail.
Forecast Bulk Upload Tool
Reduced forecast update process from days to minutes — users modify and upload in bulk instead of individual ERP entries.
Machine Downtime Reporting System
Captured downtime by reason, shift, supervisor, and work center — providing the first historical downtime data the operation ever had.
Work Order Age Monitor
Flagged aging work orders daily — enabling timely variance analysis and preventing months-old variances from distorting financial statements.
Blanket vs Released PO Price Variance
Identified cost drift between released purchase orders and blanket agreements before invoices arrived.
Shop Floor Financial Transactions
Complete presentation mapping every ERP shop floor transaction to its GL impact — WO release, labor reporting, receipt, variance posting, and accounting close. Built to train finance and operations together on how the system actually behaves.
T-Account Chart — Work Order Process
Complete T-account mapping showing debits and credits at every step of the work order lifecycle. Built when activating shop floor reporting modules to predict and verify GL behavior before going live.
Outside Service Process — Step by Step
Detailed guide for the subcontracting process — blanket PO setup, WO creation, shipping to supplier, PO receipt, and transfer back. Designed for cross-functional teams across purchasing, shipping, and materials.
MRP Implementation Process & Rules
Documentation from a live MRP implementation — scheduling rules, WO status definitions, team responsibilities, safety stock methodology, and meeting notes. A complete reference for a cross-functional team.