Development of a portal for a manufacturing enterprise

Portal development for manufacturing: where data gets lost

A request from the shop floor goes to a messenger, warehouse balances live in the accounting system, and order status lives in a spreadsheet with the department head.

Each area works with its own copy of reality: procurement sees one quantity of blanks, the area foreman sees another, and the planning department sees a third, one day out of date.

A batch is launched into production when the material is already reserved for another order, and this comes to light at the assembly stage.

The reason is not people, but the absence of a single data loop. An order, batch, warehouse item, and operation at an area are not linked by a common identifier: exports from 1C, shop-floor logs, and correspondence exist separately.

A gap arises between areas — the operator marks completion on paper, and the status reaches the system through manual reconciliation at the end of the shift. The longer the part's route, the more such gaps accumulate.

The cost of the gap is measurable: the plan is recalculated manually, some requests are lost during shift handover, and reconciling balances takes several hours a week. A balance error surfaces only in the shop — when the blank is needed physically, not in a report.

A unified data loop is built around one transactional model: an event at an area changes the state of the order rather than creating yet another version of the truth.

Access is configured by role — the foreman sees their area, procurement sees reserves, management sees a summary along the route. Below we look at how this is addressed in portal development for manufacturing.

Measurable effect: lead times, downtime, eliminated failure classes

When a request, work order, warehouse balance, and equipment operating hours live in one loop, metrics stop being assembled from memory and correspondence. Below is what actually shifts in the first months after the portal launch, and exactly what drives it.

Request approval times are reduced by the route, not by asking people to "decide faster." From the start, the request is tied to a department, item, and warehouse, so the approver sees the subject rather than an email subject, and the decision is made in one pass.

It is visible who is holding the document and how long it has been there — stalled items stop being invisible, and the typical cycle shrinks from days to hours.

Equipment downtime does not disappear entirely, but its nature changes. Maintenance is planned based on actual operating hours and failure history, not the calendar, so inspections coincide with real wear.

The share of unplanned stops falls where previously the problem was discovered at the moment of breakdown.

A separate category is failure classes that disappear as a phenomenon. A request lost between email and spreadsheet; an item duplicated under different codes; balances recalculated manually and diverging from reality. These are not minor errors but reasons why a deadline slips and a work order is redone.

And lastly, order transparency. Status, stage, and expected date are visible both internally and to the customer, so approval does not turn into "any update?" calls.

The order cycle becomes predictable, and deviations are caught at a stage when they can still be corrected without rework.

Portal deployment modes: cloud, enterprise perimeter, hybrid

The deployment mode is chosen not by preference but by data storage and access model requirements.

The difference between the schemes shows up in three places: speed of initial launch, the set of requirements for backup and retention periods, and operational constraints — who can update the environment and how often.

We separately specify where logs, attachments, and exports physically reside, who receives the media, and how recovery is organized. These points most often rule out the cloud option or, conversely, make the hybrid the only workable one.

The limitations of the modes are removed not by tools but by architecture and regulations.

A portal within the enterprise perimeter gives full control over data but lengthens the change cycle; cloud starts quickly but requires an external perimeter; hybrid resolves this contradiction at the cost of more labor-intensive maintenance.

Implementation stages: from shop-floor assessment to pilot operation

We implement the portal in waves rather than one big release: at every step, there must remain a working loop into which the shop continues to enter orders.

The sequence of work is the same for discrete and continuous manufacturing — only the set of data collected from equipment changes.

1. Shop-floor assessment. Engineers walk through the areas and record where data is entered manually and where it is duplicated. The result is an audit of production processes with a list of bottlenecks that the portal addresses.
2. Information flow map. The order's path from request to shipment: states, documents at each transition, points of divergence from reality. The map sets the automation order.
3. Integration scheme. What we take from the accounting system, what comes from lines and test benches, what remains manual entry; we fix the exchange direction, frequency, and behavior when the source is unavailable.
4. Role configuration. We build the access matrix by areas and positions before assembling interfaces: the foreman sees their orders, the process engineer sees routes, management sees a summary.
5. Assembly in waves. First the critical loop — order, route, completion fact, defects; then reporting. We show each wave on the customer's data, not on mockups.
6. Pilot operation. Launch in parallel with the current process on real orders, reconcile discrepancies daily. Exit is by criteria: the share of orders processed through the portal and the match of key reports.

Handover is not the finale: we provide regulations, the integration scheme, and the change log, and train shifts. After that, the portal lives in support, and enhancements follow the same cycle — from a short assessment to validation on real orders.

Handover package: configurations, integration schemes, regulations

The handover package is not a folder of documents "for compliance" but a set of artifacts by which the in-house IT service or another team can deploy the portal and run it without us.

We verify each item in practice: deploy the environment from scratch according to the instructions, run a training release of an update, and a training restore from backup.

If something cannot be reproduced from the document, we fix the document rather than explaining it verbally: verbal knowledge leaves with the team.

• Source code and change history — access to repositories, branching and merging rules, built artifacts of the latest release.
• Integration schemes — with the accounting system, warehouse, and equipment: exchange direction, formats, frequency, behavior when the counterparty is unavailable, and handling of stalled messages.
• Environment configurations — variables and secrets, differences between the test perimeter and production, infrastructure as code.
• Access regulations — role model, permissions matrix, procedure for granting and revoking access, operation of service accounts.
• User instructions — by role: area foreman, warehouse operator, dispatcher, portal administrator; standard operations and troubleshooting of common errors.
• Operations — update and rollback procedure, backup and recovery, monitoring scope, alert thresholds, and escalation.
• Support handover plan — work calendar, responsible parties, and the period of parallel support by two teams.

Case study: shop, warehouse, and procurement in one loop — before and after metrics

A mechanical engineering company with two sites kept procurement and the warehouse in the accounting system, while shop requests were in email and spreadsheets.

The warehouse operator learned about demand after the fact, procurement got involved after a phone call, and no one could name the request status more precisely than "in progress." Metrics before implementation: approval 3–5 days, about 18% of failures due to an item being out of stock, inventory reconciliation once a quarter with discrepancies of 30–40 items.

The portal brought the shop, warehouse, and procurement into one loop: a request with an item from a common catalog, balances and department limits, an approval route by category and amount.

Exchange with 1C is bidirectional — statuses and warehouse movements are pulled in without manual reconciliation, permissions are separated by role, and every action with a request remains in the log.

What changed in numbers

The transition was done without stopping production: first we migrated catalogs and balances, then open requests; discrepancies were reconciled before cutover.

The post-implementation metrics hold even during peak shipment season: the portal handles the peak of requests at the start of a shift normally, and rollback to the previous version takes minutes — the shop does not go without supplies because of an update.

What to do if accounting is already deployed in several systems

Starting with a total migration of "everything into one system" is the most expensive path. First comes an inventory: for each catalog and document, we determine the owning system, where primary entry happens, and where data is only read. This answer determines both the integration method and the scope of data migration.

An add-on layer is suitable when accounting systems are working and replacing them is not justified: the portal reads data through APIs and does not become a second storage.

At the same time, we introduce an end-to-end identifier for the counterparty, item, and order — without it, matching records falls to an employee and generates duplicates.

Data exchange between systems is handled by a separate layer: entity change events, redelivery without creating duplicates, and a discrepancy reconciliation log.

The rule is one — each entity has exactly one record owner, and others receive a read-only copy; otherwise version conflicts arise and "whoever wrote last is right."

Gradual migration proceeds module by module: first catalogs, then documents, then balances and operation history. Each module goes through a period of system coexistence, when the old and new run in parallel, and totals are reconciled line by line. Discrepancies are closed before cutover, not after.

In practice, the choice is not binary: an add-on layer and exchange often become a stage before migration. Describe which systems are already deployed and what is primary in each — we will come back with an estimate and a plan.

Technical concerns: access, integrations, fault tolerance

Before the project starts, engineers and department heads have the same questions: who will get access, how the portal integrates with the accounting system, and what happens if communication in the shop is interrupted. Below are brief answers; we will cover the remaining inputs during a task review.

How does the portal integrate with the accounting system?

The accounting system is the master: catalogs, orders, and balances come from it; the portal does not rewrite them or create a second version of the truth.

Exchange goes through an integration layer with a queue: if the accounting system is unavailable, messages accumulate and are sent again, and reprocessing does not create duplicates.

What happens during a communication outage and peak load?

Communication in the shop drops regularly, so shift records are stored locally and go to the server when the channel is restored, while conflicts are resolved by event time.

The server side runs in several instances with a database replica: an unhealthy node is automatically taken out of service. We calculate load by shifts — the peak usually falls at shift close, and we select capacity for it.

Let's discuss the task: what inputs are needed for an accurate estimate

The estimate for a manufacturing enterprise portal depends not on the number of pages but on the integration loop, roles, and data volumes. Below is the minimum set of inputs based on which we will come back with an estimate and work plan, not general statements.

• Current landscape diagram: which systems are already running — accounting, warehouse, dispatching — and what they exchange today.
• List of roles and their permissions: procurement, shop, quality control, managers — who sees what and changes what.
• Processes the portal must cover: requests, approvals, order statuses, documents, and their routes.
• Volumes and load: how many operations per day, how many concurrent users, what depth of history is needed.
• Constraints: what cannot be touched, whether an internal perimeter and access from production sites are required.
• Responsible parties: who approves mockups, who grants access to systems, and who confirms stage deadlines.

Based on these inputs, we fix the boundaries of the first wave, determine the team composition — analyst, integration engineer, developers, QA engineer — and break the work down by stages.

If some data appears later, the estimate is refined point by point, without rebuilding the entire plan. Describe the task — we will come back with an estimate and a plan.