Connected systems
System families are assessed from their actual interfaces. Koragence can work around SAP, Microsoft Dynamics, Odoo, Sage, or Cegid ERP environments without claiming a universal native connector for every version and installation.
The scope may also include MES, CMMS, WMS, QMS, LIMS, SCADA supervision, IoT gateways, equipment, a DMS, or a BI solution. API integration work defines objects, triggers, and recovery conditions.
One authoritative system for each data point
Each data point needs an authoritative system. The ERP may remain the owner of suppliers and orders, the MES of production execution, the CMMS of maintenance work, the QMS of deviations, and the custom application of the specific objects in the workflow it orchestrates.
Scoping defines who creates, who updates, who reads, what happens on failure, and how identifiers are matched. Useful software does not copy the same truth several times, it makes ownership and synchronization visible.
The right place between ERP, MES, SCADA, and the shop floor
Custom software can complete the information system instead of duplicating the same functions several times. It can translate a technical signal into a business decision, assemble an operator dossier, or provide a tailored interface without taking over a capability that belongs in the source system.
PLCs, sensors, gateways, SCADA, and control systems are assessed according to their role. Koragence mainly works on the business software, data, and integration layers. Specialized automation, machine safety, and control engineering remain with the relevant specialists when the project requires it.
Making machine data usable
OPC UA, MQTT, vendor APIs, files, or a local gateway can feed the software when the interface, security, and data quality allow it. The flow should retain the asset, measurement, unit, timestamp, and freshness state.
A delayed data point should not be displayed as current. Interfaces can distinguish received, calculated, estimated, and predicted values, with defined behavior when a sensor or connection becomes unavailable.
Interfaces designed for the shop floor
A shop-floor screen must account for the station, noise, gloves, light, pace, and consequences of an error. Workflows can run on a tablet, shared terminal, or fixed workstation with guided actions and understandable statuses.
If connectivity is intermittent, offline behavior must be defined precisely: accessible data, allowed actions, retained evidence, synchronization, and conflicts. Offline mode should not silently validate a critical decision without a recovery rule.
Traceability and data quality
Traceability connects the object, operation, user, timestamp, version, evidence, and decision. A readable audit trail makes it possible to understand who did what, in which context, and with which data.
Controls handle incompatible units, duplicates, missing values, impossible ranges, diverging reference data, and corrections. Documents, certificates, signatures, and approvals are attached to the right object and version.
Modernize without disrupting the existing system
Modernization starts with what must remain stable: users, identifiers, history, critical interfaces, production constraints, and ownership. The team can then choose a façade, gradual migration, new interface, or limited replacement.
Legacy Excel files can be temporary sources for understanding rules, but they should not become the default final model. Project takeover establishes a technical baseline and documented exit criteria.
Industrial software security
Security distinguishes users, roles, sites, environments, secrets, administration access, and actions that can change equipment or regulated data. Software does not bypass OT safety mechanisms or turn an interface into physical authorization.
Depending on scope, the project covers encryption, logs, session management, environment separation, backup, restoration, monitoring, and incident response. Critical access paths are tested with the teams responsible for the site.
From pilot to multi-site rollout
A pilot should isolate one useful decision, a data scope, and users able to provide precise feedback. Before scaling, the team must review differences in reference data, equipment, permissions, languages, processes, and network constraints.
Multi-site delivery relies on explicit configuration, local ownership, and common standards. Dashboards should not hide differences that materially change how an indicator is interpreted.
Architecture and technical choices
Architecture depends on criticality, connectivity, volumes, retention, hosting constraints, and available skills. Web architecture, edge gateway, asynchronous processing, or hybrid deployment can be combined.
The stack is chosen for maintainability and ecosystem compatibility, not as an isolated marketing argument. Decisions also cover performance, testing, observability, deployment, reversibility, and documentation.
Scoping, development, and deployment
Scoping starts with users, business objects, decisions, available data, and exceptions. It produces scope, acceptance criteria, an initial architecture, a migration plan, and the assumptions that influence budget.
Development progresses through verifiable increments. Business tests, permission reviews, integration tests, training, and gradual production rollout are part of the delivery. Decisions are documented so the client retains control of the product.
The work connects understanding the real workflow, users, systems, data, and constraints with building the business model, interfaces, integrations, tests, and a first usable release. Access, code, and documentation covered by the contract are then handed over with training, pilot follow-up, and the maintenance plan.
How much does industrial software cost and how long does it take?
Budget depends on the number of workflows, users, sites, integrations, assets, rules, documents, history, and validation requirements. A read-only pilot has a very different scope from a platform writing to several systems around critical decisions.
Timing depends on data access, business expert availability, existing-system takeover, and testing. Scoping should expose dependencies and propose a first release that provides useful evidence before expanding the scope.
A team that stays involved
The project starts with the workflow before the code. We seek to understand what must be decided, who owns it, which systems already exist, and which evidence must remain available.
Koragence runs projects from France and mobilizes a team according to scope. The Onctuo and Good is Merch projects show two different contexts, equipment supervision on one side, data, documents, and workflow on the other, without presenting them as factories or industrial certifications.
When custom development becomes useful
Custom development becomes relevant when a critical decision depends on information scattered across ERP, MES, spreadsheets, PLCs, quality documents, and maintenance tools. The goal is not to replace every existing system, but to build the layer that makes the workflow genuinely usable.
A first version should start from a precise workflow: release a batch, prepare an intervention, track a deviation, steer a line, or retrieve evidence. This avoids turning an operational need into an unfocused feature catalogue.
A complete industrial software scope
Scoping describes the equipment, business objects, states, roles, approvals, documents, histories, and rules that make the workflow work. It also defines which system is authoritative for each data point and which action must remain human.
Normal cases are not enough. The design must also cover missing measurements, delayed data, shift changes, unavailable equipment, corrections, insufficient permissions, and recovery after errors.
Connecting ERP, MES, SCADA, and business tools
Interfaces are chosen from the systems actually in place: APIs, files, messages, existing databases, OPC UA, MQTT, or vendor connectors. Custom software must make identifiers, units, timestamps, errors, and replay rules explicit.
API integration can be handled as a separate workstream. The industrial application remains responsible for its business objects while source systems retain the data they own.
MES, CMMS, and QHSE scopes
Custom MES software structures production events, work orders, stations, traceability, and quality close to the shop floor. An industrial CMMS focuses on assets, maintenance work, and service history.
Custom QHSE software connects audits, deviations, evidence, and actions. Metrology and calibration tracking cover specialized objects. The hub should route to the right scope rather than mixing everything together.
Deploy without blocking production
Deployment usually starts with a pilot scope, identified data, and a rollback scenario. Users test the workflows that matter while the team keeps visibility into errors, synchronization, and permissions.
Documentation, business tests, monitoring, and training are part of the product. Industrial software that only works while its creator is present is not a durable foundation.
Existing systems and data takeover
Takeover starts with an inventory of sources, identifiers, duplicates, useful history, and data that must be retained for traceability. A migration should not blindly move errors into a new interface.
Depending on risk, the first release can read existing systems before writing back to them. This reduces dependencies and validates the business model before automating irreversible changes.
Security and maintenance over time
Permissions should follow site responsibilities: operator, quality, maintenance, production, management, and administrator. Sensitive actions, rule changes, and approvals should leave a readable trail.
Maintenance covers software changes, dependencies, connectors, and third-party system changes according to the contractual scope. Application maintenance can extend the work once the pilot is stable.
Standard software or custom industrial development?
Standard software is often preferable when the need matches a common process, integrations are simple, and rules can be configured without workarounds. Custom development becomes relevant when responsibilities, equipment, or exchanges make the standard model too rigid.
Koragence starts with a fit-gap review: what exists, what can be configured, what must be integrated, and what genuinely deserves custom development. This protects the budget and avoids rebuilding a capability already handled by a vendor.
Our project method
We start from a real workflow, then define the data model, rules, interfaces, screens, approvals, and degraded cases. The first release remains tied to a measurable operational decision.
The work can then extend into a broader platform with production, quality, maintenance, monitoring, portal, or steering modules. Each extension should preserve explicit ownership and sources of truth.