Connect981 – Content Dev

RSC Topic: Program & Capacity Management

Ramp-up planning, make-vs-buy decisions, and constraint management.

  • Roadmap

    A roadmap is a structured view of planned work over time. In industrial operations, manufacturing systems, and regulated environments, it commonly refers to a prioritized plan that shows major initiatives, milestones, dependencies, and expected sequencing for areas such as MES deployment, ERP integration, quality system changes, digital work instructions, cybersecurity programs, or process improvement efforts.

    A roadmap is usually directional rather than fully detailed. It helps show what is expected to happen, in what order, and at what level of timing. It is not the same as a day-to-day production schedule, a detailed project plan, or a formal requirements specification.

    What it typically includes

    • Major initiatives or workstreams

    • Rough timing by quarter, phase, or release

    • Dependencies between systems, teams, or process changes

    • Milestones such as pilot, validation, rollout, or training readiness

    • Scope boundaries and priorities at a high level

    What it does not usually mean

    A roadmap does not normally contain the full task-level detail needed to execute work. It also does not guarantee delivery dates or outcomes. In regulated manufacturing, supporting records such as validation plans, change controls, test evidence, and training records are separate artifacts, even if the roadmap references when those activities are expected.

    Operational meaning in manufacturing

    In practice, a roadmap often appears as a cross-functional planning tool used by operations, quality, engineering, IT, OT, and supply chain teams. For example, a plant may use a roadmap to sequence barcode traceability first, electronic travelers second, and ERP-MES integration third, while showing where master data cleanup or operator training must occur before each phase.

    Common confusion

    Roadmap vs. project plan: a roadmap is higher level and more strategic, while a project plan is more detailed and execution-focused.

    Roadmap vs. schedule: a schedule assigns specific dates, tasks, and resources. A roadmap usually shows broader timing windows and sequencing.

    Roadmap vs. strategy: strategy explains why choices are being made; a roadmap shows how major work is expected to unfold over time.

    Product roadmap vs. implementation roadmap: a product roadmap focuses on planned product capabilities or releases, while an implementation roadmap focuses on rollout, adoption, integration, and operational change.

  • Scale-up

    Scale-up commonly refers to increasing a product, process, or operation from a smaller development, pilot, or early production stage to a larger and more repeatable commercial level. In manufacturing, it usually includes raising output volume, expanding batch size or throughput, and adapting equipment, staffing, controls, and quality methods so the process can run consistently at the new level.

    Scale-up is not simply making more units on the same setup. It often involves changes in process capability, material flow, line balance, automation, scheduling, data collection, and validation of whether the process behaves the same way at higher volume. A process that works in a lab, prototype cell, or pilot line may not perform the same way when cycle time, equipment loading, heat transfer, mixing, inspection demand, or operator handoffs change.

    How the term is used in operations

    In operational settings, scale-up shows up when an organization moves from engineering builds or pilot lots into sustained production, or when an existing line must support a major increase in demand. It can involve:

    • larger batch or lot sizes
    • additional lines, tools, shifts, or facilities
    • higher transaction volume in MES, ERP, QMS, or historian systems
    • more formal work instructions, training, and change control
    • tighter monitoring of yield, scrap, deviations, and bottlenecks

    In regulated environments, the term may also include demonstrating that records, traceability, approvals, and process controls remain intact as output grows.

    Common confusion

    Scale-up is often confused with ramp-up. Scale-up focuses on expanding a process or operation to a larger, sustainable level. Ramp-up usually refers to the period of progressively increasing actual production rate after launch or transfer.

    It can also be confused with technology transfer or process transfer. Those terms focus on moving a process between teams, sites, or systems. Scale-up focuses on increasing operational capacity or volume, even if no transfer occurs.

    In business contexts outside manufacturing, scale-up can also mean growing an organization overall. On this site, the manufacturing and operations meaning is usually the relevant one.

    Manufacturing example

    A process proven in pilot production may require different fixtures, revised routings, added in-process inspection, more operator training, and stronger MES-ERP coordination before it can support full-rate manufacturing. That transition is part of scale-up.

  • Multi-site rollout

    Multi-site rollout commonly refers to the planned deployment of a process, digital system, or operational change across multiple plants, facilities, or business units. In industrial and regulated environments, it usually describes how a manufacturing execution system (MES), quality workflow, ERP integration, or standard work model is introduced and scaled beyond a single pilot site.

    A multi-site rollout typically includes activities such as standardizing core processes, adapting configurations to local requirements, aligning data models and master data, coordinating change management and training, and sequencing go-lives to manage risk. The intent is to achieve comparable ways of working and data structures across locations, while allowing for controlled site-specific differences such as local regulations, customer requirements, or equipment constraints.

    How it appears in manufacturing and regulated operations

    In manufacturing, a multi-site rollout may involve:

    • Deploying an MES or digital work instruction platform from a pilot plant to additional factories
    • Rolling out standardized nonconformance, CAPA, or inspection workflows across multiple sites
    • Extending an ERP or PLM integration pattern to new locations using a common data model
    • Implementing shared traceability and genealogy structures across geographically distributed operations
    • Coordinating training, role definitions, and access controls for operators and engineers at each site

    Multi-site rollout planning often addresses governance (who owns the global template), site readiness criteria, validation or qualification approaches in regulated sectors, and how feedback from early sites is incorporated before later waves go live.

    What it includes and excludes

    • Includes: Coordinated deployment of a defined solution or standard across multiple locations, with a structured plan, shared architecture, and repeatable implementation approach.
    • Includes: Both greenfield deployments and migrations from legacy systems when they are executed as part of a cross-site program.
    • Excludes: One-off, isolated implementations at separate sites that are not managed as part of a common rollout program.
    • Excludes: Simple license expansion or user provisioning without accompanying process, configuration, or integration work at additional locations.

    Common confusion

    Multi-site rollout is often mentioned alongside terms such as:

    • Global template: The standardized configuration or process design that is reused across sites. A multi-site rollout is the program that applies that template.
    • Pilot or proof of concept: A pilot usually occurs at a single site to validate the approach. Multi-site rollout refers to the subsequent scaling phase to additional locations.
    • Enterprise deployment: Sometimes used interchangeably, but enterprise deployment can refer more broadly to organization-wide adoption, while multi-site rollout emphasizes the site-by-site implementation pattern.

    Operational considerations

    In practice, multi-site rollouts often use phased waves, with a limited number of plants going live at a time. Key considerations include data harmonization (such as part numbers and routings), integration consistency with ERP and PLM systems, version control for work instructions and recipes, and how to manage deviations or local extensions without fragmenting the overall standard.

  • Which plants or programs should I select for the first pilot?

    Select a plant or program that is representative enough to prove value, but contained enough to control risk.

    In practice, the best first pilot is usually not your flagship site, not your worst-performing site, and not the most regulated or qualification-sensitive program unless you already have strong validation discipline, integration readiness, and local leadership support.

    What a good first pilot looks like

    • Clear operational pain: The site has a visible problem worth solving, such as rework, routing confusion, paper delays, traceability gaps, training inconsistency, or poor handoffs between ERP, MES, QMS, or PLM.
    • Stable local leadership: Plant and program leaders will make decisions, remove blockers, and hold the line on process changes.
    • Manageable process scope: The workflow is important but narrow enough to implement without touching every product family, every shift, and every downstream system at once.
    • Reasonable data quality: Core routings, part masters, revision control, and work instruction ownership are good enough to support a pilot. Perfect data is not required, but unmanaged master data problems will derail early results.
    • Measurable baseline: You can compare before and after using lead time, rework, scrap, queue time, training time, execution errors, or traceability completeness.
    • Some local credibility: The site is respected internally, so a successful pilot can influence other plants without looking like a special case.

    What to avoid first

    • Your highest-risk production program: If any downtime or workflow instability would create major delivery, customer, or qualification risk, it is a poor first pilot.
    • The most customized plant in the network: If the site depends on years of local workarounds, undocumented tribal knowledge, and heavy legacy integration debt, it may teach the wrong lessons.
    • A crisis site: Plants already dealing with leadership turnover, poor schedule stability, major quality events, or ERP/MES transitions often cannot absorb another change.
    • A politically symbolic site: If the pilot is chosen mainly for visibility, the organization may optimize for appearances instead of learning.

    How to choose between plants and programs

    If your processes are mostly standardized across sites, choose a single plant where adoption is likely and results can be repeated elsewhere.

    If variation between plants is high, choose a single program or value stream with a contained workflow that crosses fewer organizational boundaries. In many brownfield environments, program-level pilots are safer because they reduce the number of interfaces, exceptions, and approval paths that must be managed at once.

    Either way, keep the first pilot small enough that you can validate process changes, train users, handle deviations, and maintain traceability without creating uncontrolled parallel processes.

    Selection criteria that matter more than enthusiasm

    1. Business impact: Is the problem real and costly?
    2. Execution feasibility: Can the team implement with limited downtime and limited custom integration?
    3. Validation burden: How much formal testing, document revision, and change control will the pilot trigger?
    4. System coexistence: Can the new workflow coexist with current ERP, MES, PLM, QMS, and paper records during transition?
    5. Replication potential: Will what you learn transfer to at least several other plants or programs?

    A simple scoring model across those criteria is usually better than selecting the loudest site or the most senior sponsor’s preferred plant.

    Brownfield reality

    Do not pick the first pilot as if you are starting with a clean slate. Most plants have legacy transactions, local spreadsheets, partial interfaces, and long-established approval paths. Your pilot should be designed to coexist with those conditions, not pretend they are gone.

    Full replacement strategies often fail in regulated, long-lifecycle environments because the qualification burden is high, downtime is hard to justify, integrations are deeply embedded, and traceability and change control obligations do not disappear during cutover. A pilot that works alongside existing systems is usually more credible than one that assumes a wholesale reset.

    Practical rule of thumb

    If you are choosing among several candidates, prefer the one that has:

    • a painful but bounded use case,
    • strong site leadership,
    • acceptable data readiness,
    • limited integration complexity,
    • and metrics you can defend under scrutiny.

    If you cannot identify those conditions, the issue may not be pilot-site selection. It may be weak process ownership, poor master data, unclear scope, or unrealistic rollout expectations.

  • capacity

    In industrial and manufacturing contexts, capacity commonly refers to the maximum sustainable output that a resource, production line, or plant can deliver under defined conditions. It is usually expressed as a quantity over time, such as units per hour, batches per shift, or operating hours available.

    What capacity includes

    Capacity typically considers:

    • Available time: The time a machine or line is scheduled and technically able to run (for example, staffed and not in planned shutdown).
    • Technical limits: Rated speeds, load limits, or throughput constraints of equipment and supporting utilities.
    • Defined operating conditions: Assumptions such as product mix, shift patterns, changeover rules, and quality standards.

    Capacity can be defined at different levels, such as a single piece of equipment, a production cell, an entire line, or a full site. It is also used in planning and MRP to align demand with what the operation can realistically support.

    What capacity does not include by default

    Capacity, by itself, does not automatically account for actual performance losses like unplanned downtime, minor stops, or yield loss. Those losses are typically reflected in metrics like OEE, availability, or throughput. Capacity sets an upper bound or planning assumption; performance metrics show how effectively that capacity is used.

    Operational use of capacity

    In day-to-day operations, capacity appears in:

    • Capacity planning and leveling: Comparing required workload to available machine and labor hours to identify overloads or underutilization.
    • Scheduling: Allocating orders or batches across lines and shifts based on available capacity windows.
    • KPI interpretation: Providing context for metrics such as OEE, NPT, and utilization by defining the number of hours or units considered as the “denominator.”
    • Program and portfolio management: Assessing whether new product introductions or volume increases fit within existing or planned capacity.

    Relationship to equipment states and KPIs

    Capacity in KPI definitions often depends on how equipment time is classified. For example, capacity may be based on:

    • Gross calendar time (all 24/7 hours), or
    • Planned production time (excluding planned shutdowns, maintenance, or holidays), or
    • Only specific equipment states considered “available for production.”

    Clear and consistent equipment state models are therefore important for defensible capacity and KPI calculations. If one site treats certain standby or changeover periods as part of capacity and another does not, metrics like OEE, availability, and NPT can become non-comparable.

    Types of capacity in manufacturing

    • Installed or nameplate capacity: The theoretical maximum output based on design or rated speeds, often assuming continuous operation.
    • Available capacity: Installed capacity adjusted for planned constraints such as shift patterns, preventive maintenance, or validated operating envelopes.
    • Effective capacity: A more conservative view of capacity that accounts for typical, recurring losses (for example, routine changeovers or standard quality checks), used for realistic planning.

    Common confusion

    • Capacity vs. utilization: Capacity is the potential or planned maximum; utilization is how much of that capacity is actually used over a period.
    • Capacity vs. throughput: Capacity is the planned or theoretical limit under defined conditions; throughput is the actual achieved output.
    • Capacity vs. availability: Availability is the proportion of planned production time that equipment is running; capacity is the amount of work that could be done, given the available time and technical constraints.

    Discipline-specific views

    Different functions may use the term slightly differently:

    • Operations and production focus on machine hours, line speeds, and staffing.
    • Planning and MRP model capacity as buckets of available work centers or resources for loading orders.
    • Engineering define capacity based on equipment design, validation limits, and utilities.
    • IT/OT and MES embed capacity assumptions into routings, production calendars, and equipment models used by the system.

    When using capacity in cross-functional discussions or KPI definitions, it is important to state clearly which definition and assumptions are being used.

  • Program view

    A program view commonly refers to a consolidated representation of activities, status, dependencies, risks, and performance across a defined program. In manufacturing and regulated operations, it is typically used to see multiple workstreams together rather than looking at a single work order, machine, line, or project in isolation.

    The term usually describes a way of organizing and presenting information, not a specific system by itself. A program view may exist inside MES, ERP, PLM, project management, quality, or analytics tools, or it may combine data from several of them. It can include schedules, milestones, material readiness, production progress, nonconformances, capacity constraints, and supplier status when those items affect overall program execution.

    What it includes and excludes

    A program view generally includes cross-functional visibility for a defined program, such as product family delivery, aircraft modification activity, launch readiness, or a major customer contract. It is broader than a single operational screen and narrower than an enterprise-wide executive dashboard.

    It does not necessarily mean a formal reporting standard, a digital thread, or a complete source of record. It is often a summarized or federated view assembled from underlying operational systems.

    How it appears in operations

    In practice, a program view may show:

    • planned versus actual progress across lots, builds, or work packages
    • material shortages or late supplier commitments affecting milestones
    • quality events, deviations, or rework influencing schedule risk
    • capacity or bottleneck signals across cells, lines, or outsourced steps
    • document, configuration, or approval status tied to program execution

    This makes the term relevant to both operational control and management reporting, especially where multiple systems contribute part of the picture.

    Common confusion

    Program view is often confused with project view. A project view is usually centered on tasks, dates, and deliverables for a single project, while a program view commonly rolls up several related projects, workstreams, or operational areas under one program.

    It can also be confused with a dashboard. A dashboard is a presentation format, while a program view is the scope and organization of the information being presented. A dashboard may provide a program view, but the terms are not identical.

    In software applications, program may also refer to a software program. That meaning is usually not intended in manufacturing operations discussions unless the context is clearly about software.