Skip to content
// the connected factory

Connecting systems produces coordinated work.

Orders, knowledge, and operating data connect the factory's context with your ERP and MES.

Start with one defined workflow. Order intake, work instructions, and shop-floor workflows run today with customer-specific integration. The overview separates available modules from the target picture.

  1. ContextConnect orders, knowledge, and operating data.
  2. Agents and toolsCoordinate tools and checks.
  3. Authorized actionComplete agreed work.
  4. FeedbackLearn from outcomes.
Verified outcomes improve the next context.
// the proof
20h2h

One module is already a product: inbox

  • CNC contract manufacturer: order-entry effort fell from 20 to 2 hours weekly.
  • 90 percent of entry now runs automatically.

Result from an iosys customer project, not a guarantee for other workflows.

View inbox →
// before you start

What to know before getting started.

What can I use today?

inbox is the packaged entry point for order intake. Order intake, work instructions, and shop-floor workflows run productively in customer projects, each with its own integration. Planning, lead time, orchestrator, knowledge, and drawing extraction are in development. An idea such as a factory-manager copilot or a predictive-maintenance agent is not a finished product unless it appears in the module list with a current status. The module list marks planned and simulated modules.

Sources:inboxModules and statusCapabilities and evidence

What is product and what is implementation work?

factorIQ provides reusable modules. iosys scopes the missing integration, data mapping, checks, and permissions around the outcome you choose. Cooperating agents are the target architecture, not one finished factory-wide package. We do not promise a fixed bundle or standard connectors.

Sources:Modules and statusResearchCustom software at iosys

How are ERP, MES and machines connected?

We begin with available APIs, database access or exports, and the permitted operations. The published cases show a cloud API for order intake, DUAP's undocumented database, and maxon's bridge between machines and ERP. Existing systems stay where feasible. Whether compatibility exists or controllers need changes is settled by an assessment. We do not promise that every older machine can be connected without changes to hardware or controls.

Sources:Order-processing caseDUAP casemaxon case

Where are data and AI processed?

There are three deployment options: operated by iosys in Switzerland or the EU, in your Azure, or, depending on the module, in your plant. Which one is available depends on the module. The location of the application and its data is not automatically the location where a model provider processes requests. Fully local-model production operation is not generally proven. MIND runs in production in maxon's Azure; that does not prove every module. No certification or legal assurance comes with this.

Sources:Deployment options on this pageiosys development data handling

Who approves actions and checks results?

Fixed checks, allowed read and write actions, and the responsibilities of your people are agreed per workflow. Uncertain fields and exceptions go to people. The event-log and control-point conventions are the target picture and are implemented unevenly today. There is no single audit interface across all modules, and no workflow bypasses machine safety.

Sources:Conventions on this pageOrder processing at iosys

What determines setup and running costs?

We do not publish a universal price for setting up or running factorIQ. These are scoped separately: interfaces and data access, workflow and checks, operating location, usage and support, and later changes. The published order-processing case at approximately CHF20,000 includes the ERP migration and is not a price list. The workshop is a separate service; its current prices are on the linked page.

Sources:Order-processing caseAI potential workshop

How do we choose the first workflow and success measures?

Pick an available workflow with usable data and an accountable owner, not automatically a factory-manager copilot. Before a bounded pilot, agree the baseline, time per operation, review workload, error workload, and release criteria, then expand after observed performance. Data and reporting pilots can begin with read-only access; writing to the ERP needs explicit permissions. Duration is scoped case by case, not promised as a universal number of weeks. The order-processing case took three months to a result plus two months of ERP migration; DUAP documents about 30 engineering hours. Those are different measures.

Sources:iosys servicesOrder-processing caseDUAP case

What evidence supports this?

The outcomes come from iosys customer projects: the CNC order-processing case and DUAP with figures, and the productive Azure bridge at maxon. They are not all standard installations of the complete factorIQ vision. The GEWO field-confidence example is not an accuracy benchmark. Drawing-extraction results stay limited to development stage and sample size.

Sources:Order-processing caseDUAP casemaxon casePublished drawing extraction

// layers

The layers of the factory

  • The layers connect context, tools, actions, and feedback.
  • iosys builds missing integrations and verifiable workflows to achieve your outcome.
Capabilities and evidence →
People
Interfaces
AI modules
Checks and approval
Your systems and data

Tasks

Purchase orders

Work instructions

KPIs

Workstations

Review screen

Shop-floor display

Control

Fixed rules check the details. Your people decide.

Integration

ERP

MES

Documents

Operation

At your site

At iosys

In your Azure

The status of each module is shown on the architecture page.
// ontology

One model for orders, parts and operations

From raw data to shared meaning

Orders, parts, operations: one model
  1. PDF purchase order in the mailbox

    Details sit as text in a PDF, not as fields in the ERP.

    becomesCustomerOrderPart

  2. Work instruction as PDF or DOC

    Unstructured; every extracted field carries a confidence rating.

    becomesOperationPart

  3. Scanned drawing

    No text layer, 8 of 11 sheets rotated, 7 title-block layouts.

    becomesPart

  4. ERP database

    Proprietary and undocumented: about 5,000 objects narrowed to six core tables.

    becomesOrderDepartment

  5. Handwritten check marks and notes

    A supplier's inspection remarks, not drawing content.

    becomesSupplierPart

  6. Promised delivery date

    When a supplier moves a date, planning recalculates by hand today.

    becomesSupplierPartOrder

  • Customer
  • Order
  • Part
  • Operation
  • Department
  • Supplier
  1. Customer places Order
  2. Order contains Part
  3. Part is made in Operation
  4. Operation runs in Department
  5. Supplier supplies bought-in parts Part

Today this model is built per workflow and it grows with every one. Company-wide data cleanup is not required for the first workflow.

where it runs

Where does your application run?

stays with you
Your plant
Your Microsoft tenant
Production data stays in the plant

YOUR SYSTEMS REMAIN IN CHARGE

ERP

MES

Machines

if present

reads, writes back

factorIQ

OPERATION: IOSYS, SWITZERLAND OR EU

OPERATION: IN THE CUSTOMER'S AZURE

OPERATION: ON YOUR PREMISES

Order entry

PDF to ERP

running

Planning

Material, due dates

in development

Work in­structions

PDF to MES

running

Shop floor

one screen per department

running

Condition

Motor data, good / bad

running

Cause analysis

explains deviations

planned

Utility duct

Event log · Model gateway · Control points · MCP to the outside

WHERE PEOPLE WORK

Own interface

Checks, dashboards

MCP

Teams, Copilot

connected via MCP

Back into the ERP

and the MES

THE MODEL

Cloud model

hosted by iosys, in Switzerland or the EU

Azure OpenAI

in your tenant

Local model

Target, not yet proven in production

Documents and order data reach iosys servers in Switzerland or the EU.Everything runs in your own Microsoft environment.A local AI model is not yet proven in production.

// technical view

The order flow in detail

factorIQ

Model choice

Cloud, tenant or local

Configuration

Suppliers

Bought-in parts, dates

Customer

orders and receives

Order intake

read, check, create

running

Lead time

Bought-in parts in the BOM

in development

Planning

Capacity and due dates

in development

Orchestrator

classifies, forwards

in development

ERP and MES

Orders, BOMs

Customer system

Shipping

Goods and documents

simulated

Manufacturing

Machines and feedback

simulated

Shop floor

KPIs per department

running

MCP integration

Teams, Copilot, Work IQ

Interface
Purchase order: Customer → Order intake
Order: Order intake → Planning
Plan: Planning → Manufacturing
Goods: Manufacturing → Shipping
Delivery: Shipping → Customer
Promises: Suppliers → Lead time
Shortage: Lead time → Orchestrator
triaged: Orchestrator → Planning
Feedback: Manufacturing → Shop floor
reads and writes: Orchestrator → ERP and MES
Tools: Shop floor → MCP integration
Inference: Model choice → Order intake

Order flow

Customer

orders and receives

Purchase order: Customer → Order intake

Order intake

read, check, create

running
Order: Order intake → Planning

Planning

Capacity and due dates

in development
Plan: Planning → Manufacturing

Manufacturing

Machines and feedback

simulated
Goods: Manufacturing → Shipping

Shipping

Goods and documents

simulated
DeliveryCustomer

Supporting work

Suppliers

Bought-in parts, dates

Promises: Suppliers → Lead time

Lead time

Bought-in parts in the BOM

in development
Shortage: Lead time → Orchestrator

Orchestrator

classifies, forwards

in development
triagedPlanning
ManufacturingFeedback

Shop floor

KPIs per department

running

System integration

Model choice

Cloud, tenant or local

Configuration
InferenceOrder intake
Orchestratorreads and writes

ERP and MES

Orders, BOMs

Customer system
Shop floorTools

MCP integration

Teams, Copilot, Work IQ

Interface
  • Legend
  • factorIQ module
  • Interface
  • Customer system
  • Model
  • Integration
  • External
  • Order flow: solid; supporting work: thin; system integration: dashed.
  • Colors show the type of module.
// modules

Modules and their current status

Available and in use

Order entry

available as SaaS

The model reads PDF purchase orders from the mailbox; deterministic checks validate the result, and a person approves. The approved result enters the ERP in structured form.

Evidence: 20 → 2 hours per week at a CNC contract manufacturer

to the product →

Work instructions

running at customers

Unstructured instructions from PDF and DOC are extracted and entered into the MES, with a confidence rating per field and a check by the operator.

Evidence: in production, export to the Hummingbird MES

Shop floor

running at customers

KPIs from ERP and MES where the work happens: one screen per department, orders, due dates, and deviations as soon as they occur.

Evidence: ten screens in around 30 hours of engineering effort

In development

Planning

in development

Stock, bills of materials, and capacity over six months. Changes remain a preview until the planner confirms them.

Evidence: demonstrable version with preview, confirmation, and reset

Lead time

in development

Tracks the bought-in parts from the bill of materials: promised dates, delays, stock. Reports bottlenecks before they show up in manufacturing.

Orchestrator

in development

The module receives, classifies, and forwards. Fixed rules and people decide.

Knowledge

in development

Manuals, work instructions, and file stores can be queried. Every answer names its source.

Planned

Root-cause analysis

planned

Explains deviations from measurements, machine data, and tool changes. A person chooses the action.

Service

planned

Queries after delivery: order, drawing, and inspection report pulled together, with a draft reply ready for approval.

// the framework

What connects the modules

Four conventions for the design

  • Current installations implement the four conventions unevenly.
  • A product-wide event interface is missing; details identify each deployment's status.

Event log

  • Modules record actions with a reason and a source.
  • Interfaces read only events; module internals remain separate.

Model choice

  • Modules use shared model selection instead of direct calls.
  • Cloud, customer-tenant, and local computation are configured.

Control points

  • Each module has at least one human decision point.
  • Models interpret uncertainty; deterministic tools check calculated results.

External integration

  • MCP exposes capabilities for your AI environment.
  • Teams, Copilot, and Work IQ can use these tools.
deployment options

Three deployment options, the same software

  • Which deployment option is available depends on the module.

Operated by iosys

  • iosys runs the application in Switzerland or the EU.
  • You use your own review screen.
running today

In your Azure

  • The application runs in your Microsoft environment. maxon runs MIND there in production.
  • This does not prove every module. Teams/Copilot integration is partly proven.
partly proven

In your plant

  • Production data stays in the plant.
  • Complete production operation with a local AI model remains unproven.
partly proven
get started

What outcome should your factory achieve?

Arrange a call →