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 decision-ready.

A requirements pack must define volume and SKU profiles, inbound and outbound patterns, and process boundaries. It should define performance targets, constraints, layout assumptions, and acceptance criteria. Include interface needs for ERP, WMS, and WCS, plus data templates for offers. This avoids scope drift and late surprises.

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.

Yes. Tidira provides logistics planning input for architects and industrial project teams, including material flows, functional area sizing, automation footprints, dock and staging assumptions, building interfaces, and planning risks. The goal is to make operational assumptions visible before layouts are difficult to change.

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 decision-ready 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.

Yes. Tidira has experience with GMP and validated logistics environments, including requirements, test strategy, evidence needs, acceptance planning, readiness gates, and operational handover.

Tidira uses structured templates, data tools, and controlled internal AI support for repetitive analysis, documentation consistency, and comparison tables. Client-facing output is reviewed and owned by the consultant.

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 leadership 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.

Fractional program leadership means operator-side leadership for 1 to 3 days per week with clear mandates. 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.