Intralogistics, factory logistics and automation FAQ

An RFP focuses on solution approach and delivery model, while an RFQ asks for a priced offer when requirements are fixed. In automation programs, it is common to start with an RFP, then move to an RFQ after clarifications. The goal is to make offers comparable and usable for the decision.

A requirements pack should describe volume and SKU profiles, inbound and outbound patterns, process boundaries, performance targets, constraints, layout assumptions and acceptance criteria. It should also define interface needs for ERP, WMS and WCS and provide data templates for supplier offers.

Requirements state what the operation needs and the constraints it must meet, while a functional specification describes how a supplier will meet them. Keeping them separate avoids locking in a design too early and improves comparability.

Offers become comparable when scope, data templates, and assumptions are standardized across bidders. Use a single data template and a clear scope definition. Normalize scope differences and document assumptions. Apply a scoring model that blends technical fit, delivery risk, and TCO. Clarification logs and structured workshops keep everyone aligned.

A scoring model turns criteria and weights into a transparent decision. Typical dimensions are technical fit, delivery risk, serviceability, and TCO. Define weights with the sponsor and operations before offers arrive. Use the same evidence for each bidder.

TCO includes CAPEX, software, maintenance, energy, and staffing, and the most common omissions are integration costs, testing effort, change management, and internal FTE time. It also covers spares, upgrades, and downtime risk. A realistic TCO makes vendor offers comparable and defensible.

Tidira translates logistics requirements into building-relevant planning input: material flows, functional adjacencies, dock and yard logic, shafts, staging, vertical transport, clear heights, floor loads, fire compartments, automation footprints and expansion reserves. The aim is to give architects and general planners usable input early enough for the relevant planning phase.

Logistics should be involved as soon as building geometry, docks, shafts, floor loads, clear heights, traffic routes, or fire compartments are discussed. The exact supplier technology can be defined later, but the building must reserve the right envelopes, routes, and interfaces early.

Both. Many projects sit between warehouse, production, and building planning. Tidira supports production-adjacent logistics, line supply, internal transport, buffers, kitting, staging, and automation concepts where warehouse and factory processes meet.

Yes. Tidira builds business cases with volume data, scenarios, utilization, CAPEX and TCO assumptions, staffing effects, sensitivity, and open decision points. The purpose is to show what is known, what is assumed, and which decisions change the result.

Start with classes, not opinions. Define cleanliness, ESD, handling sensitivity, and robot-pickability. Then link these classes to load carriers, inlays, washing rules, routing, speed profiles, pick logic, and test requirements.

No. Robot picking only makes sense when volume, part suitability, data quality, and the economic case fit. A good concept can reserve space, interfaces, and data structures for later robot cells without forcing them into the first implementation.

Tidira does not replace QA, validation management or the qualification lead. The role is to structure logistics, process and interface requirements so URS, DQ/IQ/OQ/PQ support, test evidence, material status, labels, deviations and handover logic are practical and traceable.

FAT is the factory acceptance test at the supplier site, and SAT is the site acceptance test after installation. FAT focuses on functional scope and performance under controlled conditions. SAT verifies integration, safety, and acceptance criteria in the real environment.

SIT validates technical integration across WMS, WCS, ERP, and automation controls, while UAT validates business processes with real operational scenarios. Both need clear test cases, data, and evidence. These tests are critical for go-live readiness.

Go-live readiness means defined criteria are met for system stability, data quality, training, and cutover planning, and readiness gates are formal checkpoints that verify those criteria with evidence. They make risk visible and keep project teams aligned. This prevents late surprises at go-live.

Interface ownership should be assigned per interface, data field, and test case, with operator-side control of the integration test plan. This should be agreed across suppliers and internal IT. Operator-side control of evidence requirements avoids gaps between scopes.

A second opinion is useful when scope, tests, or timelines drift and you need a rapid risk reset. In 1 to 2 weeks you can assess current status, isolate critical gaps, and set a recovery plan. You will also get a clear view of readiness and decision points. This creates a focused path to stabilize delivery.

Operator-side program support means focused support for 1 to 3 days per week with a clear mandate. The focus is governance, scope control, integration, and test readiness. It is a good fit when internal resources are limited but risk is high.

A focused tender typically takes 8 to 14 weeks from requirements to decision, depending on scope complexity and number of bidders. Early alignment on decision criteria and data templates can shorten the cycle.

Bring in operator-side delivery oversight when scope is large, multiple suppliers are involved, or integration risk is high. Early involvement improves requirements clarity and reduces late changes. It also protects operator interests during delivery and acceptance.