Operating Model

Product Development, Transfer, Repeat Orders, and Supply Chain Execution

1. Core Principle

The organization is vertical. The work is horizontal.

Departments define accountability. Processes define how work moves across those departments. All product development, transfer, repeat, turnkey, and tolling workflows are inherently cross-functional.

2. Functional Structure Clarification (R&D vs Product Development)

Separation of Roles:

The operating model is divided into two coordinated contexts: Grow and Run. Product Development operates within Grow, where cross-functional work is focused on defining new products, closing technical gaps, and preparing opportunities for execution. PETS operates within Run, where cross-functional work is focused on execution readiness, repeatability, sustainment, and controlled change.

Both contexts perform R&D, but with different intent: Grow R&D is focused on define; Run R&D, through PETS, is focused on sustain.

PETS (Process Execution & Technical Support): PETS is the system owner of repeatable execution, including BOM control, master data, execution readiness, in-spec sustainment within approved boundaries (v1.x), and authorship of the Master Manufacturing Record (MMR) using approved technical inputs.
R&D (Technical Authority — Define)
  • Responsible for formulation development
  • Executes bench and pilot work for new or undefined products
  • Responsible for technical feasibility and problem-solving
  • Defines initial specifications (v0.x → v1.0)
  • Defines the validated process and provides the technical inputs required for execution
  • Owns material changes requiring revalidation (v2.0)
Product Development (Program / Commercial Execution)
  • Responsible for project execution after qualification
  • Owns customer interface post-qualification
  • Coordinates the cross-functional workflow
  • Owns timelines, scope alignment, and handoffs
  • Drives transition into repeatable execution
PETS / Run R&D (Sustain)
  • Authors the Master Manufacturing Record (MMR)
  • Translates R&D-defined process inputs into execution-ready records, BOMs, and master data
  • Maintains specifications and master data in execution
  • Executes repeat and minor technical changes within v1.x boundaries
  • Supports validated transfers and repeatable execution
  • Maintains BOM readiness and execution controls
  • Escalates out-of-bound changes to R&D

3. Order Qualification and Routing

Qualified Order Gate:

Entry into Product Development or Transfer workflows requires defined scope, a high-level estimate, and a confirmed technical path.

Commercial Ownership: Commercial owns opportunity intake, initial screening, and order classification.
Product Development Ownership: Product Development owns cross-functional execution after qualification.
Order Type Entry Criteria
Product Development No existing validated product; new formulation or technical development required
Transfer – Validated Existing product, validated process, complete specifications (v1.0), and known materials/suppliers
Transfer – Requires Work Any gap in formulation, specifications, process, sourcing, or execution readiness
Repeat Order No change to specification, BOM, supplier, or process
Repeat Order w/ Changes Any proposed change to specification, BOM, supplier, or process

Transfer – Validated (No Technical Work Required)

4. Cross-Functional Process Paths

Commercial Intake → Qualification → Routing → Define (R&D) → Validate (Quality) → Enable (Procurement) → Execute (Operations) → Sustain (PETS)
Order Type Cross-Functional Flow
Product Development Commercial → Product Development → R&D → Quality → Procurement → Operations → PETS
Transfer – Validated Commercial → PETS → Quality → Procurement → Operations
Transfer – Requires Work Commercial → Product Development → R&D → Quality → Procurement → Operations → PETS
Repeat Order Commercial → PETS → Procurement → Operations
Repeat Order w/ Changes PETS (v1.x) or R&D (v2.0) → Quality → Procurement → Operations

5. Specification Lifecycle (Control Backbone)

v0.x
Draft / development stage
v1.0
Locked specification for execution
v1.x
Minor controlled changes within PETS scope
v2.0
Material change requiring R&D redefinition and revalidation
Execution Rule:

No purchasing, production, or system transaction may occur without an approved specification version (v1.0+) and the corresponding released execution data.

6. Business Model Overlay

Model Ownership / Process Implication
Turnkey Full internal control across formulation, sourcing, specifications, and manufacturing
Tolling Customer may own formulation, but internal validation, supplier approval, and execution controls still apply before manufacturing
Hybrid Shared ownership model; interface points and decision rights must be explicitly defined before execution

7. Execution Control Rules (Non-Negotiable)

8. Critical Cutovers

9. Org Chart RACI Model (Accountability Across Functions)

This section maps the enterprise structure to a clear RACI (Responsible, Accountable, Consulted, Informed) model to reinforce that while processes are cross-functional, accountability remains defined.

Process Area R (Responsible) A (Accountable) C (Consulted) I (Informed)
Formulation / Development R&D R&D Product Development, Quality Operations, PETS
Component Specifications R&D (define) / PETS (maintain in execution) Quality Procurement, Operations Product Development
Product Specifications Quality Quality R&D Product Development, Procurement, Operations
BOM & Master Data PETS PETS Operations, Procurement Finance
MMR Authoring PETS Quality R&D, Operations Product Development, Procurement
Supplier Qualification Quality Quality Procurement, Product Development Operations
Sourcing Procurement Procurement Quality, Product Development, PETS Operations, Finance
Purchasing Procurement Procurement Operations, Finance PETS
Production / Operations Operations Operations Quality, PETS Finance
Change Control Quality Quality R&D, Product Development, Procurement, PETS, Operations All Functions

Specification Ownership by Lifecycle Stage

Lifecycle Stage Spec Version Responsible (R) Accountable (A) Key Role
Product Development v0.x → v1.0 R&D Quality Define component requirements, formulation, and performance expectations
Transfer – Requires Work v0.x → v1.0 R&D Quality Close gaps and establish validated specifications and execution conditions
Transfer – Validated v1.0 PETS Quality Verify, adopt, and execute against existing approved specifications
Repeat Order v1.0 PETS Quality Maintain and execute against approved specifications without change
Repeat Order w/ Minor Changes v1.x PETS Quality Control approved in-boundary changes within execution limits
Repeat Order w/ Material Changes v2.0 R&D Quality Redefine and revalidate changes that affect formulation, performance, or process capability

MMR Ownership by Lifecycle Stage

Lifecycle Stage MMR Status Responsible (R) Accountable (A) Key Role
Product Development Not yet production-released R&D / PETS input planning Quality R&D defines process; PETS prepares for execution translation
Transfer – Requires Work Draft to approval PETS Quality Create MMR from validated technical inputs before production use
Transfer – Validated Approved PETS Quality Adopt and confirm execution-ready manufacturing record
Repeat Order Approved / maintained PETS Quality Maintain approved MMR for repeatable execution
Repeat Order w/ Minor Changes Revised within boundary PETS Quality Update execution record within approved change limits
Repeat Order w/ Material Changes Requires redefinition R&D inputs / PETS authors new record Quality R&D redefines process; PETS issues updated MMR for approval
Component Specification Principle:

R&D defines what a component must do. PETS maintains approved specifications during execution. Quality owns and approves all component specifications as the control authority.

MMR Principle: R&D defines the validated process, PETS authors the MMR, and Quality must sign off before the record is released for production.

Interpretation: Processes cut across all functions, but accountability does not. Each step has a defined owner and executor to prevent ambiguity in cross-functional work.

10. Sourcing Model (Distributed Execution, Centralized Control)

Core Principle:

Sourcing is distributed in execution but centralized in control. R&D and PETS may identify and evaluate materials, but no material or supplier may be used for production without Procurement ownership and Quality approval.

A. Types of Sourcing

Type Primary Owner Purpose Constraints
R&D Sourcing (Exploratory) R&D Identify and evaluate new materials for formulation and development Pre-approval not required; not production eligible
PETS Sourcing (Operational) PETS Support repeat orders, validated transfers, and alternates within approved boundaries Must remain within approved specification boundaries (v1.0 / v1.x)
Procurement Sourcing (Commercial) Procurement Select suppliers, negotiate terms, and own supplier relationships Required for all production materials

B. Sourcing Decision Logic

Scenario Who Can Source Constraint
New Product Development R&D Exploratory only; must transition to Procurement before production use
Transfer – Requires Work R&D Must transition to Procurement after validation
Transfer – Validated PETS Only within approved specifications and validated boundaries
Repeat Order PETS No new sourcing unless change is triggered
Repeat Order w/ Minor Changes PETS Must remain within approved specification boundaries
Repeat Order w/ Material Changes R&D Requires redefinition and revalidation
Production Supply Procurement Mandatory owner; requires Quality approval

C. Control Rules

Summary: This model separates organizational structure from operational execution. Order type determines the path, specifications control execution, and accountability remains fixed while cross-functional processes move the work. R&D defines the validated process, PETS authors the MMR and execution records, and Quality signs off before production release.