Axiarete reads the code, configuration and logs behind your manufacturing, supply-chain, R&D and business applications, the MES included. Fabs use it to rationalize the portfolio, modernize it, reduce technical debt, resolve incidents faster and deliver enhancements sooner, with every change validated against production.
90% less time to analyze an application, and 40–60% lower shop-floor latency in production MES estates.
Every tool has an OEE and every process a Cpk. Yet each lot still waits on software: an MES transaction, a recipe check, a hold that protects nothing until the MES enforces it. That software was built for a different fab, and it now carries AI-driven demand, new processes and a shrinking group of people who understand it.
Most fabs have the budget and the growth plans. What limits them is the software between the tools.
The MES is one part of a much larger estate of manufacturing, supply-chain, R&D and business applications. Axiarete works across all of it, and every initiative draws on the same model of the estate.
Custom code, model, database and configuration, tuned and validated against recorded production traffic.
How MES optimization works →Four applications to move one lot.
FDC sees the drift, but the MES can’t stop the next lot.
Process improvements wait months for a software release.
Routings and specs differ from one system to the next.
Fast yesterday, slow today, after a routine statistics refresh.
Three people understand the split and merge logic. Two of them are eligible to retire.
A system can report 99.99% availability while adding two seconds to every transaction. Application Health captures what availability misses: whether the software speeds the fab up or slows it down. It is tracked continuously, rather than in a study every few years.
Software now sits on the critical path of every lot, and it warrants the same management discipline as the tools themselves.
The platform parses and decompiles the artifacts that define your applications, from the MES to ERP, PLM, SPC and supply-chain systems, and assembles them into one dependency graph that is kept current release by release.
Every system, dependency, cost and risk, established from the code up.
Rank work by fab impact (frequency, duration and proximity to the bottleneck), then fix it.
Agents keep the graph current through every release and incident.
The platform finds and drafts each fix. Forward-deployed engineers validate it against recorded production traffic, ship it and hand over the knowledge.
Generic .NET and Oracle advice doesn’t fix an MES. Our analysis works on the MES constructs themselves, with the failure modes known for each.
It never registers as downtime, so it is rarely attributed to software. It shows up in four other measures instead.
The equivalent of four full-time operators waiting at terminals.
Four seconds of MES wait on each of 400 moves a shift costs 5.6% of the constraint tool’s capacity.
For every minute between a hold being applied and being enforced, nonconforming WIP keeps moving.
A lot stalled in the MES uses up its queue-time budget, and a breach means rework or scrap.
Change any figure and the results update as you type.
At these numbers, your MES is consuming 33.3 operator-hours a day and 5.6% of your bottleneck tool’s capacity.
These are your own numbers. Bring them to the first call.
A portfolio rationalization, a replaceability assessment and two production MES tuning engagements. Each followed the same method: read the estate from its code, measure it, act on the evidence and validate the result.
Knowledge base rebuilt from 12 million lines of code.
Hundreds of legacy applications assessed against Camstar and SAP.
Grid and track-in/track-out performance swung unpredictably from day to day.
| Finding | Before | After | Count |
|---|---|---|---|
| Setup-matrix lookups sorted entire tables to return one row | ROW_NUMBER() over a 25-level CASE sort after 28 joins; every row materialized | Indexed specificity score + FETCH FIRST 1 ROW ONLY; stops at the first row | 47 matrix queries re-engineered |
| Grid columns executed one query per displayed row | 16-join scrap-quantity query per row; a 100-row lot grid drove 400 history scans | Lookup folded into the grid query as a set-based join; one scan per render | 400 → 1 history scans per grid render |
| Predicate shapes that disabled every index | (col LIKE ? OR col IS NULL) stacked 20 deep; LIKE on Boolean and Integer columns | Exact-match / wildcard UNION ALL branches with typed equality; range scans restored | 365 index-killing predicates rewritten |
| Index estate and execution plans rebuilt on evidence | 125 redundant, 16 empty and 20-column-wide indexes; 20 on the hottest table alone | B-trees on 205 verified join paths; monitored drops; SQL Plan Baselines pinned | 125 redundant indexes retired |
Also: 102 copy-pasted self-joins eliminated · 417 unbounded grid queries capped · every rewrite golden-master validated.
A decade of customization had queued thousands of metadata calls ahead of every commit.
| Finding | Before | After | Result |
|---|---|---|---|
| One MoveOut fired thousands of metadata functions before commit | 110 custom logic functions wired to one event: 2,696 calls; seven SkipPlan CLFs alone burned 424 | Early-exit consolidation; printing and trace codes moved to AfterCommit | 2,696 → 1,500 functions per MoveOut; latency down 40–50% |
| A sixth of the schema had no index; history queries scanned tables | 335 of 2,064 tables bare; 22 phantom indexes defined with zero columns | Composite B-trees on history mainline (ContainerName, TxnDateGMT, CDODefId) | 335 → 0 unindexed tables; history reads up to 80% faster |
| Every dispatch recomputed a static CDO hierarchy, recursively | 254 queries ran CONNECT BY / derived-CDO lookups over an unchanging tree | Hierarchy materialized, refreshed on deploy | 254 recursive lookups materialized; 1–4 s back per sequence |
| Dispatch grids fetched all 190 container columns to display 15 | 48 SELECT * queries; every default dispatch grid pulled the full row | CDO queries column-pruned to the 15 shown | 190 → 15 columns; payloads down ~90%; 1–5 s per dispatch list |
Also: 51 PL/SQL TABLE() context switches re-engineered · 60–70% less I/O per lot after splitting a 309-column table.
We start from evidence rather than workshops. At week eight you decide, on the results, whether to continue, change scope or stop.
Inventory the applications and customizations in scope, and baseline the transactions and processes that matter most.
Publish the baseline; ship the first low-risk fixes.
Prioritize by fab impact while continuing to deliver.
A twelve-month plan, reviewed with your executives.
Application Health, and how software health connects to fab throughput and yield.
Read the paper →Four field cases from fab IT, and a 90-day plan for acting on them.
Read the paper →Why software stands between reshoring announcements and results.
Read the essay →Two hours a week from a project lead, stage access only, and a decision at week eight.
We’ve received your request and will reply shortly to agree which inputs to start from.
No. The MES is where we have gone deepest, but Axiarete works across the fab’s whole application estate: manufacturing, supply-chain, R&D and business systems. Rationalization, modernization, technical debt, incident intelligence and enhancement delivery all apply to any of them.
Our deepest experience is with Siemens Camstar and Opcenter Execution Semiconductor on Oracle, customized in .NET and WCF. Application Health and the portfolio, modernization and technical-debt work apply to any estate.
Usually both, in order: retire what is redundant, modernize what blocks your roadmap, and optimize the core you keep. The same evidence carries into a Camstar V7 to Opcenter upgrade when the time comes.
It is a platform, run with you by forward-deployed engineers. The platform reads the estate, ranks the problems and drafts the fixes; the engineers validate the fixes, ship them and hand over what they learned.
In a dedicated environment with customer-managed keys. Your code, models and logs are never used to train Axiarete or third-party models.
First findings arrive in week two, and quick wins are in production by week four. In our second tuning engagement, 20 to 30% of the total gain came in the first two to four weeks.
The operator-hour, capacity and hold figures are worked examples, not measurements. Engagement figures come from Axiarete engagement records, and engagements are described by the work performed rather than by the customer.