Industries
Manufacturing first, then the operations that behave like it
The capability is modelling complex physical operations. It transfers between domains because queueing, contention, failure and resource constraint transfer. Each section below sets out the problem, what gets built, what you receive, and how the engagement runs.
Engagement model
Discovery, deployment, then an annual agreement
The commitment at each step is proportionate to what is known at that point. Nothing here obliges you to the next stage.
Discovery
A fixed-price assessment that ends in a document you can act on with or without us.
Deployment
A pilot or an operational deployment, fixed price against a scope set in Discovery.
Annual platform agreement
Keeps the deployment current as the operation changes. Priced against the deployment, renewed annually.
Support agreement
A defined support tier alongside the platform agreement, with response commitments written into the contract.
Expansion
Further processes, sites or systems added to a model that already exists rather than built from nothing.
Primary market
Manufacturing
Production lines, work cells, buffers, changeovers, internal logistics and the workforce that runs them, modelled as one system rather than as separate studies.
- Problem
- Output is limited by something, and the reporting rarely says what. Utilisation figures describe how busy equipment was, not what constrained the line, and the constraint moves as soon as it is relieved. Capital decisions about a machine, a cell or a shift get made on estimates that cannot be tested before the money is committed.
- What gets built
- An executable model of the lines, buffers, workforce and internal logistics, calibrated on your production history and validated against a period it was not fitted to. Capacity and staffing questions are answered by running the alternative from an identical starting state and measuring the difference.
- Deliverables
- Operational model of the lines and processes in scope
- Validation report with the out-of-sample deviation stated
- Baseline throughput, utilisation, lead time and OEE decomposed into availability, performance and quality
- Constraint identification, corroborated independently by queue depth
- Scenario comparisons for the specific changes you are weighing
- A working model your engineers run without us
- How the engagement runs
- Discovery on one area, then a pilot on the line where the decision is most expensive, then extension across the plant once the first model has been checked against reality.
What the model holds
- Machines, cycle times and failure distributions
- Buffers, WIP limits and blocking
- Changeover and setup sequences
- Operators, shifts and skill constraints
- Material supply and internal movement
- Maintenance windows and downtime
- Order mix, batch sizing and due dates
Decisions it informs
- Where the constraint actually is, and where it moves to once it is relieved
- Whether an additional machine, cell or shift pays for itself
- How much buffer a line needs to absorb its own variability
- What a product mix change does to throughput before it is scheduled
- Which maintenance policy costs least in lost output
Secondary market
Logistics and warehousing
Storage strategy, picking, replenishment, dock scheduling and fleet movement, evaluated against real order profiles rather than averages.
- Problem
- Layout, slotting and headcount decisions are made against average demand, and the site fails on its worst day rather than its average one. Automation cases are argued on vendor throughput figures that assume no contention at the points where contention actually happens.
- What gets built
- A model of storage, picking, replenishment, dock scheduling and fleet movement driven by your real order profiles rather than by averages, so a change can be tested against the peak that sized the building.
- Deliverables
- Model of the storage layout, pick paths, replenishment and dock operations
- Travel, congestion and queueing measured rather than estimated
- Fleet and headcount sizing against real demand profiles
- Automation cases evaluated with contention included
- Peak-day and disruption scenarios
- How the engagement runs
- Discovery against your order history, then a pilot on one area or one shift pattern, then extension to the site.
What the model holds
- Storage layout, slotting and travel distance
- Pick paths, wave structure and batching
- Replenishment triggers and congestion
- Dock doors, yard moves and appointment windows
- Fleets, charging and traffic rules
Decisions it informs
- Whether a layout change reduces travel or moves the queue somewhere else
- How many vehicles or pickers a demand profile actually requires
- Where automation earns its capital and where it does not
- How the site behaves on its worst day rather than its average one
Secondary market
Aviation operations
Terminal and airside operations as one connected model: passengers, aircraft, baggage, ground handling, weather and disruption together.
- Problem
- Terminal capacity is not a property of any one subsystem. Check-in, security, gates, stands, runways, ground handling and baggage each bind at different times, and which one binds changes with the schedule, the weather and whatever went wrong that morning. Studying them separately produces answers that do not survive an irregular operation.
- What gets built
- One connected model in a single clock: passengers, aircraft rotations, stands, ground service fleets, baggage and weather together, with disruption injected into a running model so it propagates by mechanism rather than by script.
- Deliverables
- Connected model of terminal and airside operations in scope
- Passenger flow through check-in, security and boarding on real demand curves
- Stand allocation, turnaround sequencing and runway queueing
- Irregular operations and weather scenarios
- Resource levels that hold a service target under a bad day
- How the engagement runs
- Discovery on one process, typically the one with a known service-level problem, then a pilot covering it end to end, then extension airside.
What the model holds
- Passenger arrival profiles through check-in, security and boarding
- Stand allocation and aircraft turnaround sequencing
- Baggage handling and transfer connections
- Ground service resources and their contention
- Weather and irregular operations
Decisions it informs
- Where terminal capacity binds, and at which hour
- How a disruption propagates through the rest of the day
- What resource level holds a service target under a bad weather scenario
- Whether an infrastructure change survives the peak it was sized for
Secondary market
Robotics and autonomous fleets
Robot cells and mobile fleets with their control logic in the loop, so traffic rules, charging policy and task allocation are tested before hardware is committed.
- Problem
- Fleet sizing and control policy are decided before the hardware exists, and the failure modes that matter at scale, deadlock, contention at shared resources and the throughput cost of safety stops, only appear once enough units are deployed to make them expensive.
- What gets built
- Robot cells and mobile fleets modelled with the control logic in the loop, so traffic rules, charging policy and task allocation are tested against the real workload before hardware is committed.
- Deliverables
- Model of the cell or fleet with its control logic in the loop
- Fleet sizing with contention included
- Deadlock and traffic-rule analysis at target scale
- Charging policy evaluation against duty cycle
- Throughput cost of the safety regime, quantified
- How the engagement runs
- Discovery against the workload and the space, then a pilot on one cell or one zone, then extension as the deployment grows.
What the model holds
- Robot kinematics, task times and cell layout
- Fleet traffic, deadlock and right-of-way rules
- Charging policy and opportunity charging
- Task allocation and queueing at shared resources
- Human presence and safety-driven stops
Decisions it informs
- How many units a workload needs once contention is included
- Whether a control policy deadlocks at scale
- What a safety stop regime costs in throughput
Secondary market
Infrastructure and critical systems
Infrastructure where the cost of testing in production is unacceptable: security operations, spacecraft, and coupled physical estates.
- Problem
- For estates where testing in production is unacceptable, the questions that matter are about degradation: what the rest of the system does once one part of it fails, and whether detection and response hold up when they are needed. Those questions are usually answered by argument, which is how organisations arrive at confidence they have not earned.
- What gets built
- Coupled models of the subsystems and the paths between them, with faults injected into a running system so consequences propagate through the mechanism. Detection, escalation and operator response are modelled as part of the system rather than assumed around it.
- Deliverables
- Coupled model of the subsystems and their dependencies
- Fault injection with propagation through the coupling
- Detection and response modelled as part of the system
- Degraded-mode and autonomous protective behaviour analysis
- Scenario library for the failures that actually concern you
- How the engagement runs
- Discovery scoped to one failure mode with a known cost, then a pilot proving propagation is represented correctly, then extension across the estate.
What the model holds
- Coupled subsystems with real physical models
- Fault injection and propagation between them
- Detection, escalation and analyst or operator response
- Autonomous protective behaviour under degradation
Decisions it informs
- How a single fault propagates through everything downstream of it
- Whether detection coverage holds against a known adversary or failure model
- What the system does when it is left to protect itself
Value estimator
Arithmetic on your own numbers
Every calculator like this on every competitor’s site pre-fills the improvement figure with something flattering and calls the output a projection. We have delivered no engagement and therefore have no average to offer, so the number that decides the answer has to be yours.
What a utilisation change is worth
Enter your own figures. This multiplies them and shows the arithmetic. It is not a prediction, not a benchmark, and not a result any customer has measured.
Hours the line or facility is scheduled to run in a year.
Units per hour the system produces when nothing is limiting it.
Share of that capacity you actually achieve, across a normal year.
What one additional unit is worth after the variable cost of making it.
Percentage points of utilisation. This is your assumption, not ours.
Estimated annual impact
$0
The improvement field is zero, so the estimate is zero. That is deliberate. We have delivered no engagement from which to draw an average improvement, so the figure that decides this calculation has to be yours.
hours × capacity × (improvement ÷ 100) × contribution = annual impact
Estimate only. It assumes the gain is achievable, that demand exists for the additional output, and that nothing downstream becomes the new constraint. Whether any of those hold for your operation is precisely what a model is built to establish, and it is the reason Discovery comes before a number anyone should act on. Nothing entered here is sent anywhere.
Next step
Your operation is not on this list
The question that decides it is not the industry. It is whether the operation's behaviour is governed by contention, variability and failure between things that share resources. If it is, it can be modelled.
Prefer email? sales@alsadaany.com