Infor VISUAL ERP Implementation: An Execution Guide for Enterprise Manufacturers

Software selection consumes most of the executive attention in an ERP programme and explains almost none of the variance in outcomes. By the time a manufacturer has shortlisted Infor VISUAL as the platform for order-driven production, the functional fit question is largely settled. What remains unsettled, and what actually determines whether the investment returns anything, is execution: how the engineering data is restructured before it is loaded, how the entity and site hierarchy is defined on day one, how much of the legacy process is forced into extensions rather than absorbed by configuration, and whether the shop floor is capturing usable labour and material transactions in week three or week thirty.

VISUAL is an unusually opinionated system. Its object model, built around engineering masters, the Manufacturing Window, and a scheduling engine that consumes that structure directly, rewards organisations that adapt their data to it and punishes organisations that try to replicate a legacy MRP model inside it. That single characteristic drives most of the implementation decisions described below.

Pre-Implementation Readiness

The readiness assessment is not a questionnaire exercise. It is a technical audit with three deliverables: a data quality baseline, a process-to-object-model gap register, and an honest organisational capacity assessment.

Data readiness and engineering structure

Start with the part master. Part numbering scheme, part ID length, and the decision to carry legacy identifiers as cross-references rather than primary keys are effectively irreversible once transactional history accumulates. The same applies to unit of measure conventions and the treatment of purchased versus fabricated parts that legacy systems frequently blur.

Bills of material and routings are where most enterprise programmes lose their schedule. VISUAL models manufacturing structure as engineering masters composed of legs and operations, and the scheduler consumes that structure directly. A flat, level-by-level BOM exported from a legacy system with phantom assemblies, floating operation sequences, and no resource linkage cannot simply be loaded. It has to be reconstructed. The practical decisions here include how many engineering masters to maintain per product family, whether to model sub-assemblies as separate masters or as legs within a parent, and how to represent outside service operations so that purchasing and costing both behave correctly. Infor’s VISUAL user and administration documentation library on docs.infor.com publishes separate manufacturing, inventory, purchasing and multi-site guides precisely because these object relationships are defined differently in each domain, and a design decision taken in one propagates into the others.

Expect BOM and routing remediation to take longer than the entire configuration phase for a manufacturer with tens of thousands of active part numbers. Resource it as an engineering workstream owned by engineering, not as a data task owned by IT.

Process mapping and organisational readiness

Map current-state processes against VISUAL’s transaction model rather than against a generic ERP capability list. The questions that matter are specific: does the site operate on actual cost or standard cost, and can finance live with that choice across all entities; how are labour tickets going to be raised and by whom; what happens to work in process when a job is split; how are inter-branch transfers between sites accounted for.

Executive sponsorship is measurable, not rhetorical. The test is whether the sponsor will personally adjudicate a scope dispute between a plant manager and the design authority within a week. If that decision path does not exist, the programme will absorb every local exception as a customisation request.

Implementation Methodology and Phasing

A defensible phase structure for a multi-site VISUAL deployment runs discovery, conference room design, configuration, data migration, integration build, testing, training, cutover, and hypercare, with the migration and integration tracks running in parallel from the end of design rather than sequentially after it.

Single-site deployments with clean data and limited integration scope typically run in months rather than quarters. Multi-entity or multi-site programmes at large manufacturers routinely run twelve to twenty-four months end to end, with the range driven far more by the number of legacy source systems and the condition of engineering data than by the number of users. Site rollouts after the first site compress substantially if, and only if, the first site produced a genuine template: a locked configuration baseline, a documented chart of accounts and dimension structure, and a repeatable migration toolkit. A broader treatment of phase gating, environment strategy and technical validation sequencing is set out in our technical framework for Infor implementation programmes.

The single highest-leverage methodology decision is whether the first site is a pilot or a template. Pilots are allowed to be exceptional. Templates are not. Declare which one you are building before design starts.

Data Migration Strategy

Treat migration as an engineering discipline with its own environments, its own test cycles, and its own acceptance criteria.

Extraction from legacy systems is rarely the constraint. Cleansing and reconciliation are. Build the migration around repeatable loads: every load is scripted, every load is counted, and every load produces an exception report that a named business owner signs. A minimum of three full dress rehearsals into a production-shaped environment is the standard I hold programmes to, with the final rehearsal executed against the actual cutover runbook and timed.

Sequencing matters because VISUAL enforces referential relationships. Sites, warehouses, entities and accounting structures load first, then customers, vendors and part masters, then engineering masters and routings, then open transactional data: open sales orders, open purchase orders, open work orders, inventory balances and financial opening balances. Work in process is the hardest category. Deciding whether to migrate open jobs at their current stage or to close them in the legacy system and re-open them in VISUAL is a cost accounting decision with audit consequences, and it should be made with the external auditor in the room rather than by the migration team. The tooling and validation approaches for large multi-source loads are covered in more depth in our guide to data migration into Infor platforms.

Where the target database is being hosted on cloud infrastructure, continuous replication approaches can shorten the cutover window for the underlying database move. AWS documents change data capture and full load replication patterns in the AWS Database Migration Service user guide, which is relevant to the platform migration but not a substitute for application-level transformation, since legacy structures almost never map field-for-field into VISUAL’s schema.

Integration Architecture

Integration design belongs in the design phase, not in the month before go-live. The two decisions that shape everything else are which system is the system of record for each business object, and which flows are genuinely event-driven versus batch.

Infor ION exchanges Business Object Documents between connection points, where a BOD carries a noun such as SalesOrder, Item or BusinessPartner together with a verb, as described in Infor’s ION Desk documentation on document structure and BOD definitions. The practitioner-level work is in the mapping. VISUAL’s published BOD mappings determine which fields are populated on publication, and any attribute your downstream CRM, WMS or quality system expects that is not in the standard mapping becomes either a document extension, a mapping transformation, or a scope reduction. Decide which, explicitly, per document flow, and record it.

Middleware choice follows from that inventory. ION is the correct default for Infor-to-Infor and for BOD-shaped exchanges; a general-purpose integration platform earns its place where you have high-volume non-BOD traffic, complex orchestration, or third-party endpoints with their own protocol expectations. Running both is common and defensible provided ownership boundaries are written down. Our Infor ION integration services practice works to that boundary model on multi-platform estates.

For teams standing up their first document flows, the mechanics of connection points, authorised applications and flow modelling are walked through in our step-by-step introduction to ION integration.

Configuration Versus Customisation

Every VISUAL programme accumulates extension requests. The governance question is not whether to allow any, but what evidence a request must produce before it is approved.

The framework I use requires three things from any extension request: the business outcome expressed in operational or financial terms, evidence that no native configuration path exists, and a named owner who accepts the upgrade regression testing obligation for the life of the extension. Requests that fail the third test are almost always process preferences rather than requirements.

VISUAL provides substantial native flexibility before code is involved: user-defined fields, application global settings, workflow definitions and macros. It is worth understanding where those artefacts physically live, because it changes the support model. Infor’s VISUAL system-wide documentation notes that when a user runs a macro, the macro is read from the workstation, which makes uncontrolled macro proliferation an estate management problem rather than a database one. That is the sort of detail that determines whether year three of the deployment is manageable.

The long-term cost of over-customisation is not the build. It is the compounding tax on every service update, every schema change, and every new site rollout that must now be tested against a divergent baseline.

Shop Floor and Operational Data Capture

Shop floor capture is the component most often deferred to a phase two that never receives funding, and it is the component that determines whether costing and scheduling data are trustworthy. If labour and material transactions are captured retrospectively from paper, the scheduler is working from fiction and the actual cost comparisons that justified the investment cannot be produced.

Design the capture layer during implementation. The decisions are physical as much as functional: terminal placement and count, barcode and label standards, how indirect labour and setup time are recorded, how many concurrent sessions each shift requires, and how transactions behave when the network drops mid-shift. Infor positions real-time reporting of attendance, direct and indirect labour, material transactions and work in process logistics as core to the VISUAL value case, and that capability only materialises if the capture design is funded in the original scope. Where deployment extends into warehouse and mobile data collection across multiple sites, the Infor Factory Track capabilities should be scoped alongside the core build rather than bolted on afterwards.

Licensing intersects here. Concurrent licence allocation across office users, engineering, finance and shop floor terminals needs modelling against realistic shift overlap patterns, not headcount. Shift changeover peaks are where allocation models fail.

Reporting and Analytics Readiness

Design the reporting layer during implementation. Organisations that defer it discover at go-live that the operational reports the business actually runs on do not exist, and the resulting scramble produces a permanent estate of unmanaged extracts.

There is a technical dependency worth understanding early. Infor’s VISUAL system administrator documentation describes a reporting data service that maintains VISUAL reporting tables, with records written to a synchronisation table as transactions are created, updated or deleted, and with the administrator choosing whether updates run at a scheduled time or on a frequency check. Reporting latency expectations, therefore, are a configuration decision made during implementation, and the business needs to state whether it requires near real-time operational reporting or can accept scheduled refresh. Our Infor Birst analytics work typically starts with that latency and grain conversation, because it determines the data model, not the other way around.

Define no more than a dozen executive KPIs before go-live and instrument them properly. Everything else can follow.

Testing Strategy

Unit and string testing validate configuration. They do not validate the business. User acceptance testing must be scenario-based and executed by the people who will own the transactions, using migrated data in a production-shaped environment.

Build UAT scripts around end-to-end business events rather than screens: quote to cash for a make-to-order product, engineering change on an in-flight job, a customer return with rework, a period close. Every script needs an expected financial and inventory outcome, not just a completion tick.

Parallel running has a real cost and is not always the right answer. A full financial parallel is justified where costing methodology is changing or where regulatory audit exposure is material. Where it is not, a targeted parallel on financial reporting alone, combined with rigorous reconciliation of opening balances, achieves most of the assurance at a fraction of the operational load.

Cutover rehearsal is non-negotiable. Rehearse the full runbook, timed, with the actual people who will execute it, including the decision points and the rollback criteria. The rehearsal that finds the problem is cheaper than the go-live that finds it.

Change Management in Shift-Based Environments

Manufacturing change management is constrained by physics. Training cannot be delivered to a single cohort in a classroom when three shifts are running and the plant is committed to customer delivery dates.

Plan training in short, role-specific modules delivered at shift changeover or in dedicated production stand-downs, repeated per shift, with the same content. Night shift consistently receives inferior training and consistently generates a disproportionate share of post-go-live data quality issues; budget explicitly to prevent that.

Superusers embedded on the floor are worth more than any volume of documentation. Identify them early, involve them in UAT so they build the system knowledge themselves, and formalise their role in writing with their line managers so that floor support is a recognised duty rather than an imposition on top of a full workload.

Go-Live and Hypercare Exit

Hypercare without exit criteria becomes an indefinite second support tier. Define the criteria before go-live and publish them.

Reasonable exit criteria are quantitative and operational: transaction volumes at or above pre-go-live baseline for a sustained period, no open severity one defects, inventory accuracy verified by cycle count against physical, financial close completed within the target window using standard processes, integration error queues cleared within agreed thresholds, and incident volume trending down for consecutive weeks rather than plateauing.

Exit is a decision, not a date. Move to steady-state operations when the criteria are met, and hold the line when they are not.

Common Failure Modes at Enterprise Scale

Four failure patterns recur specifically in large VISUAL deployments.

The first is treating BOM restructuring as a data cleanup task. It is an engineering redesign, and when it is under-resourced the scheduler produces unusable output and the business loses confidence in the system within weeks of go-live. Mitigate by starting engineering remediation before design completes and by measuring it as a tracked deliverable.

The second is deferring shop floor capture. The mitigation is scope discipline at the outset: if capture is not in phase one, the costing benefits case should be reduced accordingly and stated as such to the board.

The third is late integration design, which surfaces as document flow rework during test. Mitigate by producing the system-of-record matrix and the document flow inventory during design, and by building the highest-volume flow first as a proving exercise.

The fourth is site-level configuration divergence during rollout, where each plant negotiates its own variations and the template dissolves. Mitigate with a design authority holding named veto rights and a written variation process that requires sponsor approval.

Platform Context

VISUAL is one component of a broader estate. Manufacturers running multi-plant operations frequently pair it with warehouse, quality, asset management and analytics capabilities that share the same integration and identity layers, and implementation decisions taken in VISUAL constrain what that wider estate can do later. Understanding how the pieces fit is worth doing before the first configuration workshop, which is the perspective we bring through our Infor CloudSuite platform practice.

Frequently Asked Questions

How long does an Infor VISUAL implementation take?

A clean single-site deployment with limited integration scope is typically measured in months. Multi-entity or multi-site programmes at large manufacturers commonly run twelve to twenty-four months end to end. The dominant variables are the number of legacy source systems and the condition of engineering data, not user count.

What drives budget overrun most often?

Underestimated BOM and routing remediation, and customisation scope that accumulates one approved exception at a time. Both are governable. A tracked engineering remediation workstream and a design authority with real veto rights address the majority of the exposure.

What staffing model should we plan for?

A full-time programme manager, a design authority with decision rights, functional leads per domain, dedicated migration and integration resources, and named business process owners who are released from operational duties. Superusers on each shift are a requirement, not a nice to have. Partner resources should transfer capability rather than occupy permanent seats.

How do we control data migration risk?

Script every load, reconcile every load, and rehearse the full cutover at least three times against the actual runbook. Assign named business owners to sign off each data domain. Decide the treatment of open work in process early and with the auditor involved.

How much integration scope should be in phase one?

Only the flows required to run the business on day one, built and proven early rather than late. Everything else belongs to a sequenced backlog. Producing the system-of-record matrix during design is what makes that separation defensible.

What does post-go-live support look like?

Hypercare with published quantitative exit criteria, followed by a defined steady-state support model with clear ownership of configuration changes, integration monitoring and release regression testing. Exit hypercare when the criteria are met, not when the calendar says so.