quality

Quality Process

PSI’s quality tracking system centers on “Redbooks” - a homegrown issue tracking system used across all departments.

---

The Redbook System

What is a Redbook?

A Redbook is PSI’s internal term for a quality issue ticket. When someone discovers a problem during design, build, or field installation, they open a redbook.

Name Origin: The original system used physical red notebooks where issues were logged by hand. The digital system inherited the name.

Interfaces

Interface	URL	Description
Redbook Web	https://redbook.progressivesurface.com	Modern web app for RFC management
WPF App	Desktop (PSI.Redbook.View)	Legacy desktop application
Analytics Dashboard	https://ps-redbook-dashboard.azurewebsites.net	Analysis and reporting

See Redbook Web for the modern web interface documentation.

When to Open a Redbook

Open a redbook when you discover:

• Drawing errors (typos, missing dimensions, wrong tolerances)
• Design function issues (interference, undersized components)
• Vendor quality problems (parts don’t meet spec)
• Assembly errors (wiring mistakes, fitment issues)
• Field problems (issues found at customer site)

Redbook Lifecycle

┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│   Opened     │────▶│  In Progress │────▶│   Closed     │
│ (Issue found)│     │ (Being fixed)│     │  (Resolved)  │
└──────────────┘     └──────────────┘     └──────────────┘
      │                    │                    │
      ▼                    ▼                    ▼
   Opener           Dept assignments        Resolution
   records          track who's             documented
   details          working on it

Key Redbook Fields

Field	Description
ID	Unique ticket number
Project	Job number
Problem	Description of the issue
Drawing	Related drawing number
Priority	Urgency level (1-High to 4-None)
Dept flags	Which departments are assigned
ECN/NCN	Linked change documents
Account	Customer account (from ACCOUNT.1287)
Primary Resp	Responsible cost center (from COCE)
Activity	Activity log with timestamps
Solution	Solution description
Opportunity	Waste metrics (material $, labor hours)

---

Detection Timing

When an issue is found significantly impacts the cost to fix it. PSI categorizes detection timing as:

Stage	Days Before Ship	Multiplier	Typical Finding
Early	>90 days	1.0x	Design review, early build
Mid-Build	30-90 days	1.25x	Assembly, initial testing
Late Build	<30 days	1.5x	Crunch time fixes
Near/At Ship	~0 days	2.0x	Last-minute discoveries
Post-Ship	After ship	2.0x	Field escapes

Caveat: This uses planned ship dates. Projects that ship late may show issues as “Post-Ship” even if caught in-house.

---

Quality Metrics

Key Performance Indicators

Metric	Definition	Target
Quality %	Quality Cost / Project Value	<2%
Early Detection Rate	% issues found >90 days before ship	>50%
Field Escape Rate	% issues found post-ship	<3%

Severity Levels

Severity	Description	SLA Target
Critical	Safety risk or major customer impact	⇐3 days
Major	Significant rework or schedule impact	⇐14 days
Moderate	Noticeable issue requiring correction	⇐21 days
Minor	Small issue with minimal impact	⇐30 days

---

ECN Process

An Engineering Change Notice (ECN) is a formal document authorizing changes to engineering drawings.

When ECN is Required

• Design changes affecting fit, form, or function
• Dimension changes beyond tolerance adjustments
• Material substitutions
• Assembly method changes

ECN Workflow

1. Engineer identifies need for change
2. ECN document created with justification
3. Affected drawings/parts identified
4. Approvals obtained
5. Drawings updated
6. BOM updated if parts change

ECN Linkage to Redbooks

Redbooks may trigger ECNs when the fix requires drawing changes. The Has_ECN flag indicates when a redbook resulted in an ECN.

---

NCN Process

A Non-Conformance Notice (NCN) tracks quality issues with purchased or manufactured parts that don’t meet specifications.

NCN Workflow

1. Quality issue identified with incoming/manufactured part
2. NCN document created
3. Part quarantined
4. Disposition determined:
   • Return to vendor: Send back for credit/replacement
   • Rework: Fix in-house
   • Use as-is: Accept deviation
   • Scrap: Discard

NCN Linkage to Redbooks

Redbooks may link to NCNs when vendor quality is the root cause. The Has_NCN flag tracks this relationship.

---

Root Cause Categories

The Redbook Analysis system uses AI to classify root causes:

Root Cause	Description
Design Function	Design doesn’t work as intended
Drawing Error	Typos, missing dimensions, wrong tolerances
Vendor Quality	Purchased parts don’t meet spec
Wiring Error	Electrical connection mistakes
Assembly Error	Mechanical fitment/installation issues
Process Change	Customer or scope changes
Information Gap	Missing or unclear requirements

Systemic Issues

Root causes appearing on >50% of projects are flagged as systemic issues - indicating organizational patterns rather than project-specific problems.

---

Preventability Analysis

The Deep Dive analysis found that 94% of top Design Function issues were preventable through:

Prevention Method	Examples
Design Review	Checklists, peer review, interference checks
Supplier Management	Better specs, incoming inspection
Process Control	Work instructions, training
Communication	Customer requirements clarification

---

UniData Tables

The Redbook system uses these UniData tables:

Table	Purpose
REDBOOK.1287	Main redbook records
ACCOUNT.1287	Customer accounts
EMPLOYEE.PUBLIC.1287	Employee lookup
COCE	Cost centers (Primary Responsibility)
ENG.CHG.1287	Engineering Change Notices
NCN.CHG.1287	Non-Conformance Notices

See Redbook Web - Field Mapping for complete field documentation.

---

Related Pages

• Redbook Web - Modern web interface
• Redbook Analysis - Analytics dashboard
• UniData API - REST API for Redbook access
• Terminology - Quality-related terms
• Engineering Process - Design workflow
• Manufacturing Process - Build process

---

Last updated: February 2025