Go back to Market Research
MJC² develops scheduling and optimization software for transport operators, manufacturers, and supply chain organizations. Its applications plan vehicle movements, warehouse activity, production sequences, workforce assignments, inventory replenishment, and demand. The company combines these components with custom development and interfaces to customers’ operating systems. (1, 2, 3, 4, 9)
Overall supply chain score: 4.8/10
| Dimension | Score |
|---|---|
| Supply chain depth | 5.4/10 |
| Decision and optimization substance | 5.2/10 |
| Product and architecture integrity | 4.2/10 |
| Technical transparency | 4.6/10 |
| Vendor seriousness | 4.6/10 |
MJC²’s strongest proposition is operational scheduling: representing interdependent resources, producing executable plans, and recalculating them when conditions change. Its public record includes a substantial milk-collection deployment and unusually concrete descriptions of transport, warehouse, and production constraints. The central limitation is the economic treatment of the future. Fast replanning after a disruption does not establish that the original decision properly valued uncertain demand, supply, and downstream consequences. The published commercial descriptions leave that calculation largely unspecified. (1, 2, 5, 6)
The business also depends on tailored engineering. That can accommodate difficult operations, but makes the maintenance of models and integrations part of the product’s cost. Public evidence is much stronger on schedules produced and constraints represented than on net economic returns, continuing engineering effort, or production security boundaries. (9, 10, 11)
MJC² versus Lokad
MJC² approaches an operation through its resources and schedules: which vehicle, production line, worker, or loading bay should perform which task, and when. Lokad’s inventory optimization approach starts with the financial consequences of recurring decisions under uncertainty. The overlap includes replenishment and production; the distinction concerns the governing model, not just the list of applications.
A delivery schedule can minimize driving and respect every time window while making an expensive promise to a low-value customer. A production sequence can reduce changeovers while manufacturing stock that will never sell. Resolving these conflicts requires valuing the consequences across the business. MJC² documents substantial operational coordination, but gives little detail about the common economic objective connecting transport, production, purchasing, and inventory.
Lokad’s Supply Chain Scientists maintain that decision logic as part of the service. Their task includes changing a model when its apparently optimal recommendation loses money. The perspective developed in Introduction to Supply Chain therefore treats forecast uncertainty, economic priorities, and continuing model revision as one operating responsibility. The relevant comparison is realized value after all modeling and operating labor. A routing specialist’s task-level cost saving and a supply chain’s financial return are different measurements.
What the commercial software actually decides
Joint scheduling goes beyond a vehicle-routing tool
DISC combines primary transport, customer deliveries, returns, and backhauls with warehouse operations. Its documented model includes drivers, trailers, shunters, warehouse workers, loading bays, picking capacity, and product availability. Outputs include vehicle and driver schedules, warehouse assignments, and docking movements. Time windows, temperature compatibility, working hours, and shelf life constrain the plan. (1)
This coordination matters. A shorter vehicle route can be worthless if a warehouse cannot load the vehicle on time. Optimizing those activities together addresses a genuine source of operational waste. The remaining question is which costs the coordination minimizes and what consequences remain outside its boundary. Distance, utilization, and labor hours are useful inputs; they are not interchangeable measures of economic value.
PIMSS extends the scheduling approach to production. It represents materials, labor, intermediate products, machine routings, sequence-dependent changeovers, cleaning, and maintenance. It also works with minimum, maximum, and preferred stock levels and can preserve master-schedule constraints during replanning. These are meaningful industrial details, particularly for perishables and tightly coupled processes. (2)
The weakness lies in the targets supplied to that machinery. Maintaining a prescribed stock range does not establish that the range is economically appropriate. Once a target enters as a constraint, the scheduler can become very efficient at enforcing a poor inventory decision. The commercial explanation needs to connect those targets to uncertain demand, uncertain supply, expiry, lost margin, and the alternatives competing for the same resources.
Inventory and forecasting are part of the offering
e-Stock generates replenishment orders using stock positions and forecasts. Its documented inputs include minimum and maximum order quantities, lead times, supplier availability, transport costs, purchase discounts, and storage capacity. It also supports vendor-managed inventory and automatic responses to changing conditions. (3)
i-Data supplies short- and long-term forecasts and offers customer-specific algorithms and trend treatment. Its public page does not disclose forecast distributions, calibration tests, or how demand uncertainty combines with supplier delays. (4)
That omission limits the replenishment claim. An order quantity depends on the range of demand accumulated before the next usable receipt, not just a demand estimate and a nominal lead time. Constraints such as minimum orders and shared transport make the choices interdependent. The product descriptions establish that many restrictions can be represented; they do not establish a joint stochastic economic policy for choosing among feasible orders.
Uncertainty: contingency planning and the limits of risk scoring
MJC² explicitly addresses supply uncertainty in its CORE work. Its LARG+O tools model disrupted ports and transport links, estimate consequences for SKU-level inventory, and choose alternative multimodal routes. The documentation includes changes in transit times and comparisons between ports. This is a concrete contingency-planning mechanism. (6)
Its value depends on the question asked. Calculating a response to a specified closure helps prepare an intervention. Deciding how much inventory or spare capacity to buy before any closure requires probabilities, dependencies, and costs across possible futures. The reviewed CORE description does not explain that second calculation or its predictive validation. A digital representation of the network does not remove the forecasting problem.
The 2019 SYNCHRO-NET paper provides a more inspectable historical example. The consortium’s strategic planner first constructed routes under deterministic assumptions, using adapted shortest-path algorithms. A separate Monte Carlo module simulated disruptions and calculated risk indicators afterward. The authors explicitly left direct integration of risk into optimization as future work. MJC² developed the real-time tools; Politecnico di Torino and Syco developed the strategic toolset, with Fraunhofer IVI contributing to risk analysis. (7)
Sampling disruptions is straightforward. The difficult work is representing the right uncertainties and letting their economic consequences change the decisions being optimized. Scoring already-generated routes can miss an attractive alternative that the initial deterministic objective never considered. User-selected weights also require an economic justification: a risk score cannot determine how much money a particular delay is worth. This historical design is useful evidence of the consortium’s actual method, while the current commercial pages leave subsequent changes to that method unspecified.
Deployment evidence, productivity, and accountability
Fonterra establishes operational substance
MJC²’s Fonterra account describes Genesis, a milk-collection system built using DISC and REACT. The published case gives a workload of up to 15,000 daily collections and 500 trucks, with variable milk supply, changing factory demand, and food-quality restrictions. It says the teams had worked together since 2006 and identifies an award for development and continuing support. Those figures describe the historical case, not Fonterra’s current fleet. (5)
The deployment connects optimization with a difficult physical operation. Its evidential limit is financial and organizational: the account provides no comparable before-and-after operating cost, dispatch staffing, or continuing engineering workload. It supports practical scheduling capability without establishing the amount of net value created or how that value changed over time.
The SYNCHRO-NET final report separately describes three demonstrators and reports, among other outcomes, a 14% reduction in last-mile truck costs and a 10% reduction in driver-shift length. These are consortium-reported project results. Their commercial significance depends on the baseline, observation period, and ongoing costs; the percentages do not describe every MJC² deployment. (8)
Automation has several different boundaries
The current freight page distinguishes two workflows. For a disrupted multimodal shipment, the system presents alternatives to a freight forwarder. For real-time haulage, it can update schedules and reissue them to hauliers automatically. These imply different remaining labor requirements. (19)
Repeated human selection can become the bottleneck even when calculations take seconds. Conversely, unattended dispatch can remove substantial routine work. The useful productivity measure is the volume and value of successfully executed decisions per total operating hour, including exceptions, integration support, and model changes. MJC² does not publish that measure. Its more general discussion of reduced overtime and agency use concerns transport resources; it cannot establish how much planning work has disappeared. (20)
MJC²’s recruitment page goes further, claiming its systems have never been beaten in customer benchmarks. It supplies no benchmark population, workloads, objectives, or results. That categorical statement is considerably less credible than the specific operational descriptions. A favorable comparison on one scheduling problem cannot establish universal superiority, and a fast result says little about whether the model omitted a valuable alternative. (10)
Configuration maintenance and total ownership cost
Custom development is explicit in MJC²’s offering. Its examples include a manufacturer’s S&OP application connected to production and distribution, and a crop-storage system built around quality information. The company sells reusable components together with engineering for particular operations. (9)
This model can represent details that standardized applications omit. It also creates an ongoing obligation to maintain the meaning of data, operational rules, and interfaces. A new collection contract can change admissible routes; a different cleaning procedure can change the value of a production sequence; a supplier’s deterioration can invalidate a replenishment policy. Updating those relationships requires knowledge of both the software and the operation.
The recruitment description assigns staff responsibility for algorithm design, implementation, and installation at customers. It does not quantify deployment effort, release procedures, or the engineering required for later changes. (10)
The decisive maintenance question is whether failures lead to better formulations. If a schedule repeatedly creates expensive expediting, changing a time-window parameter may conceal a missing cost or decision. Holimization requires revising the problem itself and testing the resulting economic improvement. MJC²’s custom-engineering model permits such work, but the public cases do not trace a costly recommendation through reformulation and validation.
That unresolved workload belongs in total ownership cost. Reusing existing components can reduce initial development, while a bespoke production model can keep the customer dependent on its original engineering team. Public pricing, model-export specifications, and a documented transfer process would make that dependency easier to assess. None is supplied by the reviewed product and development pages.
Bill of software materials and security
| Scope | Publicly documented materials | Practical consequence |
|---|---|---|
| Commercial applications | DISC, REACT, PIMSS, e-Stock, and i-Data components with customer-specific development | The product family has a coherent scheduling purpose; operating it still requires maintaining the interfaces and configured logic. |
| Forecasting integration | Configurable APIs to ERP and legacy databases | Integration is an explicit delivery activity; a public executable interface specification is missing. |
| Manufacturing integration | PIMSS at production-control and scheduling levels 3 and 4 | The software consumes plant and enterprise information and changes production plans. Access boundaries matter. |
| Historical SYNCHRO-NET consortium | Java/OpenTripPlanner, REST interfaces, and MySQL configuration storage | These identify the research platform, not the current proprietary DISC or PIMSS backend. |
| Current recruitment | Algorithm development, implementation, and customer installation | The employer does not name the production languages, databases, dependency inventory, or deployment environment. |
Sources: 1, 2, 3, 4, 7, 10, 11.
The material uncertainty is the commercial software’s maintenance surface. Public pages do not identify its infrastructure footprint, supported component versions, upgrade responsibilities, or resource requirements at representative workloads.
The SCADA explanation usefully locates PIMSS above the sensor and programmable-controller layers. It describes production scheduling and control, receiving equipment performance and availability alongside orders and labor information. It does not explain authentication between systems, restricted write privileges, update integrity, or the separation between enterprise access and plant access. (11)
Those omissions are material for software issuing operational plans. A compromised integration account or an incorrectly authorized update could affect many production decisions. The appropriate evidence is a concrete privilege and deployment design. Research participation and physical freight-security applications do not provide that design.
Technology history and follow-through
MJC2 Limited was incorporated in August 1990 and remains active in the UK register. Its research portfolio shows a long-running focus on scheduling, logistics, and production. Company age establishes continuity; the technical record needs to show what each research wave delivered. (17, 18)
| Period or initiative | Evidence of delivery | Remaining limit |
|---|---|---|
| Fonterra collaboration, beginning in 2006 | A named operational system and continuing support relationship | The case does not provide a time series of net returns or maintenance effort. |
| SYNCHRO-NET, 2015–2018 | Demonstrators, a technical publication, and identified real-time and strategic modules | The historical risk architecture separated route optimization from subsequent risk evaluation. |
| Industry 4.0 positioning | PIMSS’s documented connection to plant, order, and workforce information | Better data access does not by itself improve the objective being optimized. |
| ePIcenter, 2020–2024 | A completed consortium project investigating multimodal logistics, data sharing, and new transport technologies | Hyperloop appears among research topics, not as evidence of a deployed MJC² transport system. |
| Quantum-computing research | The vendor explicitly describes work for future hardware | No disclosed implementation or benchmark establishes a commercial advantage. |
| HOLOGISTICS, current | A new consortium with identified MJC² scheduling responsibilities | Its listed MJC² toolset and FreightBot deliverables are due in June 2027 and June 2028. |
Sources: 5, 7, 8, 11, 12, 13, 14, 15, 16.
The continuity of scheduling work is stronger than a sequence of unrelated AI announcements. Nevertheless, the research pages accumulate fashionable themes without consistently showing their commercial contribution. ePIcenter’s vendor page still describes prospective work although the project closed in May 2024. The quantum page discusses possible savings without a reproducible algorithm-and-hardware result. These remain research claims, with no demonstrated increment to the customer’s present decision quality. (12, 13, 14)
HOLOGISTICS continues the multimodal agenda and adds digital twins, connected logistics, and future automation. Its scheduled deliverables provide a useful test of follow-through. As of this review, the announced future tools cannot establish current labor savings or autonomous planning capability. (15, 16)
The economic accountability gap is more persistent than the vocabulary. Public material describes cooperation and technical achievement, but does not define a failed economic deployment, the customer’s bounded obligations, or the remedial work the vendor undertakes when the expected return fails to appear. The absence of those terms leaves testimonials and technical benchmarks doing work they cannot perform.
Supply chain score
Each dimension averages five criteria on a 0–10 scale. The overall score is the mean of all 25.
Supply chain depth
| Criterion | Score |
|---|---|
| Economic framing | 6/10 |
| Decision end-state | 7/10 |
| Conceptual sharpness on supply chain | 6/10 |
| Freedom from obsolete doctrinal centerpieces | 4/10 |
| Robustness against KPI theater | 4/10 |
Average: 5.4/10.
Economic framing — 6/10. Reducing transport and resource costs gives the applications a tangible economic purpose. The model connecting those costs with downstream margin, inventory risk, and service commitments remains insufficiently explained. (1, 3)
Decision end-state — 7/10. The offering reaches operational schedules and orders. Human selection remains in some freight workflows, so the execution boundary varies by application. (3, 19)
Conceptual sharpness on supply chain — 6/10. Joint resource planning addresses dependencies that isolated route optimization misses. Its breadth is clearer than the economic policy governing trade-offs across functions. (1, 2)
Freedom from obsolete doctrinal centerpieces — 4/10. Stock targets and master plans can preserve decisions whose economic basis has not been tested. Frequent recalculation does not correct that underlying limitation. (2, 3)
Robustness against KPI theater — 4/10. Published results concern identifiable operations, but do not reconcile resource improvements with total net return. The universal benchmark claim lacks the information needed to challenge it. (5, 8, 10)
Decision and optimization substance
| Criterion | Score |
|---|---|
| Probabilistic modeling depth | 4/10 |
| Distinctive optimization or ML substance | 5/10 |
| Real-world constraint handling | 8/10 |
| Decision automation and labor productivity | 5/10 |
| Resilience under real operational complexity | 4/10 |
Average: 5.2/10.
Probabilistic modeling depth — 4/10. Supply disruptions receive concrete attention. Current commercial evidence does not establish calibrated joint uncertainty feeding the economic choice, rather than the evaluation of a prescribed scenario. (4, 6)
Distinctive optimization or ML substance — 5/10. The operational deployment and research record support genuine engineering. The proprietary engines remain inaccessible, and their claimed superiority lacks a reproducible comparison. (5, 7, 10)
Real-world constraint handling — 8/10. The descriptions identify consequential physical restrictions and shared resources in considerable detail. Evidence is strongest on feasibility and coordination, with less visibility into what the optimization omits. (1, 2)
Decision automation and labor productivity — 5/10. Operational execution can remove recurring scheduling work. The publications do not measure sustained throughput per total human hour, including support and exception handling. (5, 19)
Resilience under real operational complexity — 4/10. Replanning and custom engineering offer mechanisms for adaptation. Public examples do not show an economically inadequate formulation being corrected and retested successfully. (6, 9)
Product and architecture integrity
| Criterion | Score |
|---|---|
| Architectural coherence | 5/10 |
| System-boundary clarity | 5/10 |
| Security seriousness | 3/10 |
| Software parsimony and ownership cost | 4/10 |
| Compatibility with programmatic and agent-assisted operations | 4/10 |
Average: 4.2/10.
Architectural coherence — 5/10. Related scheduling components form a recognizable product family. Customer-specific integration makes consistency an ongoing engineering task, with limited public architectural detail. (2, 9)
System-boundary clarity — 5/10. The production hierarchy and freight workflows locate several important interfaces. The authority and failure behavior at those interfaces remain less clear. (11, 19)
Security seriousness — 3/10. Production connections make access control consequential. The vendor does not publicly describe the privileges, update controls, and isolation mechanisms needed to assess that boundary. (11)
Software parsimony and ownership cost — 4/10. Reusable components support tailored applications, but the infrastructure and continuing maintenance effort are opaque. Buyers cannot establish the full operating burden from the public offering. (9, 10)
Compatibility with programmatic and agent-assisted operations — 4/10. Automatic execution and integration provide useful foundations. Missing public interfaces and reproducible model definitions limit independent testing and agent-assisted maintenance. (4, 19)
Technical transparency
| Criterion | Score |
|---|---|
| Public technical documentation | 5/10 |
| Inspectability without vendor mediation | 3/10 |
| Portability and lock-in visibility | 3/10 |
| Implementation-method transparency | 6/10 |
| Evidence density behind technical claims | 6/10 |
Average: 4.6/10.
Public technical documentation — 5/10. Operational descriptions and a detailed consortium publication expose useful mechanisms. Current commercial algorithms and runtime specifications remain undocumented. (1, 7)
Inspectability without vendor mediation — 3/10. Research methods can be examined, but buyers lack an equivalent runnable commercial example. Assessing a customer-specific engine requires engagement with its developer. (7, 9)
Portability and lock-in visibility — 3/10. Data integration is described more clearly than the transfer of configured decision logic. No public export-and-redeployment procedure establishes how a customer could move its models elsewhere. (4, 9)
Implementation-method transparency — 6/10. The company openly sells engineering and installation alongside components. It leaves the effort, acceptance criteria, and subsequent change obligations unspecified. (9, 10)
Evidence density behind technical claims — 6/10. Specific constraints, named operational use, and research methods support the core scheduling proposition. They provide weaker support for universal performance claims and commercial stochastic optimization. (1, 5, 7)
Vendor seriousness
| Criterion | Score |
|---|---|
| Technical seriousness of public communication | 4/10 |
| Technology roadmap integrity | 5/10 |
| Conceptual sharpness | 5/10 |
| Economic accountability | 4/10 |
| Defensibility in an agentic-software world | 5/10 |
Average: 4.6/10.
Technical seriousness of public communication — 4/10. Concrete operational explanations are undermined by sweeping speed and superiority language. Those claims need defined workloads and objectives, not customer enthusiasm alone. (1, 10)
Technology roadmap integrity — 5/10. Sustained scheduling work and completed projects establish continuity. Research themes need clearer links to current releases and measured customer improvements. (8, 12, 14, 16)
Conceptual sharpness — 5/10. Operational interdependencies are well understood. The distinction between rapid response, risk measurement, and an economically justified policy remains underdeveloped in commercial communication. (1, 6, 7)
Economic accountability — 4/10. The customer relationship and project results are identifiable. Published evidence leaves total costs, failed economic outcomes, and the vendor’s corrective obligations unmeasured. (5, 8, 9)
Defensibility in an agentic-software world — 5/10. Physical constraints and operational integrations remain valuable engineering assets. The enduring advantage depends on improving decision quality and total labor productivity beyond what accessible programming agents make cheaper. (1, 2, 19)
Sources
Sources were accessed on November 4, 2026.
[1] Distribution and integrated warehouse scheduling
Distribution and integrated warehouse scheduling. Undated; accessed November 4, 2026.
PIMSS production planning. Undated; accessed November 4, 2026.
[3] e-Stock inventory and replenishment
e-Stock inventory and replenishment. Undated; accessed November 4, 2026.
i-Data forecasting. Undated; accessed November 4, 2026.
[5] Fonterra Genesis customer service award
Fonterra Genesis customer service award. Undated; accessed November 4, 2026.
[6] CORE supply chain contingency optimization
CORE supply chain contingency optimization. Undated; accessed November 4, 2026.
[7] Sustainable and De-Stressed International Supply-Chains Through the SYNCHRO-NET Approach
Sustainable and De-Stressed International Supply-Chains Through the SYNCHRO-NET Approach. Published 2019-02-19; accessed November 4, 2026.
[8] SYNCHRO-NET final project report
SYNCHRO-NET final project report. Published 2024-06-11 (record updated); accessed November 4, 2026.
[9] Custom software development
Custom software development. Undated; accessed November 4, 2026.
MJC2 recruitment. Undated; accessed November 4, 2026.
[11] PIMSS and SCADA production control
PIMSS and SCADA production control. Undated; accessed November 4, 2026.
[12] Quantum computing research
Quantum computing research. Undated; accessed November 4, 2026.
[13] MJC2 ePIcenter project description
MJC2 ePIcenter project description. Undated; accessed November 4, 2026.
[14] ePIcenter final project report
ePIcenter final project report. Undated; accessed November 4, 2026.
[15] MJC2 HOLOGISTICS project description
MJC2 HOLOGISTICS project description. Undated; accessed November 4, 2026.
[16] HOLOGISTICS deliverables and deadlines
HOLOGISTICS deliverables and deadlines. Undated; accessed November 4, 2026.
[17] MJC2 Limited company record
MJC2 Limited company record. Undated; accessed November 4, 2026.
[18] MJC2 scheduling research portfolio
MJC2 scheduling research portfolio. Undated; accessed November 4, 2026.
[19] Multimodal freight scheduling and dispatch
Multimodal freight scheduling and dispatch. Undated; accessed November 4, 2026.
[20] Integrated fleet dispatch benefits
Integrated fleet dispatch benefits. Undated; accessed November 4, 2026.