Most process maps get built once, satisfy an audit, and die in a shared folder. The moment the org chart shifts or a system changes, the map is wrong — and everyone quietly stops trusting it. This page is our attempt to build something that stays true, because people are actually using it and correcting it.
Every process on this page starts as a SIPOC — Suppliers, Inputs, Process, Outputs, Customers — before it gets detailed. A SIPOC forces a team to agree on scope in five or six boxes before anyone argues about task-level mechanics. The useful trick is to fill it out backwards: Customers first, then Outputs, then Process, then Inputs, then Suppliers. Naming who the work is for and what they actually need, before mapping the steps, keeps the process honest to its purpose instead of just describing what people happen to do today.
A map only works if two people read it the same way. We're deliberately not using strict BPMN — Business Process Model and Notation, the ISO/IEC 19510 standard — here. BPMN uses formal pools and swimlanes, precise task/event shapes, and exact gateway logic (exclusive, parallel, inclusive) to spell out branching decisions without ambiguity. It's the right tool when a systems integrator needs to wire an actual workflow engine to it, but it reads like an engineering spec to everyone else. Instead we pair the SIPOC scope with GTC's stage-gate structure and plain process-owner, input/output, and measurement fields — closer to the spirit of ISO 9001's "process approach," which cares less about which shape you draw than about whether ownership, inputs/outputs, and KPIs are actually documented for every step.
A static map can describe a process. A live one can drive change — because most change efforts fail for the same reason: someone updates a policy without seeing what it touches upstream or downstream. A current map makes handoffs and dependencies visible before they become a rollout problem. It's also how you find real automation and AI candidates — you can't target a bottleneck, a manual re-entry step, or an RPA opportunity you can't see mapped out. And when a change does land, the map instantly scopes who and what systems are affected, which is most of the work of planning a rollout.
The Live Status panel above the SIPOC grid pulls real counts directly from our R&D project database — not a snapshot from the last time someone remembered to export it. The feedback flyout on the right edge lets anyone looking at a step flag that it's wrong, out of date, or missing something, and it lands in a tracked queue our team actually reviews — logged in automatically through Azure AD, no manual sign-off needed. That's the whole idea: the map corrects itself because the people doing the work are the ones maintaining it.
The near-term roadmap is to make each step clickable — click a high-level box here and drop straight into the detailed procedure, the system it runs in, and the metric that tracks it, rather than making someone go find a separate SOP. Combined with the feedback loop already live on this page, that turns this from a diagram you look at once into an operating reference the teams actually return to.
Loading…
Temporary — help us build the source of truth. Pick the page this is about, describe what you'd like changed, and hit submit. A Manager/Senior Manager, R&D reviews all submissions. This panel will be removed once the Future State revision ships.
Logged in via Azure AD — your name/email is attached automatically.
Feedback Received — thank you.
Green Tokai Co., Ltd. (GTC) — R&D Department, and Kick-Ass Innovations (KAI), an in-house business line incubated by R&D (not yet a separate legal entity — Current State). Built on a SIPOC + Stage-Gate framework, GTC's standard process-map format.
Covers how an idea becomes a GTC R&D project: intake via the R&D Project Proposal form, system-of-record tracking in Airtable, cross-functional ranking, and progression through the 5-gate stage-gate review used to judge concept, prototype, internal development, final development/marketing, and production release.
Full 14-KPI framework, targets, and data-readiness status below.
All 15 proposed KPIs below now have a home in Airtable. The Actual column pulls real, live numbers straight from Airtable wherever the data exists — not a status label. Where a KPI has no data logged yet, or needs a process/data-source decision before it can be tracked at all, that's stated plainly instead of a placeholder number.
| R&D KPI | How to Measure | Target | Actual |
|---|---|---|---|
| R&D Project On-Time Completion | Projects/milestones completed on time ÷ due | ≥ 90% | Loading… |
| Development Milestone Achievement | Milestones achieved ÷ planned milestones | ≥ 90% | Loading… |
| Trial Success Rate | Successful trials ÷ total trials | ≥ 85% | Loading… |
| First-Pass Validation Success | Developments passing validation first attempt ÷ total | ≥ 90% | Loading… |
| Customer Sample Approval Rate | Samples approved ÷ samples submitted | ≥ 95% | Loading… |
| Development Lead Time | Average days from request to completed development | ≤ 180 days | Loading… |
| Project Submission to 1st Action | Average days from project entry to first ACTION assigned | ≤ 7 days | Loading… |
| R&D Projects Completed | Number completed during period | Monitor/trend | Loading… |
| Open R&D Projects | Number currently active | Monitor | Loading… |
| Overdue R&D Projects | Number/% past planned completion | ≤ 5% | Loading… |
| Development-Related Customer Issues | Complaints attributed to development | Trend / 0 major | Not tracked in R&D Airtable — lives in Quality's complaint/CAPA system |
| Post-Launch Development Changes | Changes required after launch | Monitor | Loading… |
| Cost vs. Project Budget | Actual development cost vs. budget | Within ±10% | Loading… |
| Lessons Learned Implementation | Applicable lessons incorporated into new projects | ≥ 90% | Not tracked yet — needs a tracking design decision |
| Technical Risk Closure | Risks closed by planned date | ≥ 90% | Loading… |
| New Technology/Material Evaluation | Planned evaluations completed | ≥ 7/yr | Not tracked yet — needs a tracking design decision |
R&D Project On-Time Completion and Development Lead Time flipped to Live as soon as the team started logging Planned/Actual dates on completed projects — no schema change needed, just data entry. The KPI Dashboard above recalculates both straight from Airtable on every page load (the "n=" count shows how many projects that number is based on so far).
New Airtable fields added to the R&D Project table: Risk Status, Risk Planned/Actual Closure Date, Budget ($), Actual Cost ($), Trials Conducted/Successful, Customer Samples Submitted/Approved, Post-Launch Changes (#), Date of First Action — still awaiting data entry (except where noted below). First-Pass Validation Success becomes trackable once Gate decisions are logged as real per-project records (see Configuration & Change Control below) — same fix unlocks two KPIs at once. Development-Related Customer Issues lives in Quality's complaint/CAPA system, not R&D's Airtable — recommend a cross-reference rather than duplicating that data here. Lessons Learned and New Technology/Material Evaluation need a short design conversation before they're worth building — happy to scope those next. Project Submission to 1st Action is brand new: it compares Entry Date against the new Date of First Action field, which is empty on every existing record today, so it will read "No data logged yet" until staff start filling it in going forward.
GTC serves aerospace and other regulated OEM customers, so the R&D process is being reviewed against AS9100D's aerospace-specific additions on top of ISO 9001. Each card below maps an AS9100D requirement to where it already lives in this process — and calls out where the control exists on paper but isn't yet captured as structured, auditable data.
Risks & dependencies are captured at intake (Step 2), and every Gate Judge decision is itself a risk-based go/no-go control — HOLD/REVISE and REJECT exist specifically to stop a risky project before further investment. Risk Status and Planned/Actual Closure Date fields now exist on every project record, feeding the Technical Risk Closure KPI below.
Recommend: start setting Risk Status at Gates 1 and 3, where new-customer, new-technology, or supply-chain risk is most likely to surface — the fields are ready, they just need to be used.
The 5-gate structure (Concept → Prototype → Internal Development → Final Development → Production) requires an explicit Judge decision before a design or process can advance — the structural basis of configuration control.
Gap: gate decisions aren't logged as individual dated records in Airtable today (see the Data & Measurement note below) — the real audit trail currently lives in free-text Staff Notes/History fields, not structured revision records.
Most relevant at Gate 2 (prototype build) and production hand-off, where sourced materials and components first enter the process.
Recommend: require documented supplier/material qualification (approved source, certs of conformance where applicable) as a Gate 2 checklist item, especially on aerospace-designated projects.
Every project carries a unique Project # (RD00xx) from intake through closeout, with Gate records and task history attached to that number for the life of the project — the backbone of a traceability chain.
Recommend: explicitly tag aerospace-customer projects so they can be pulled as a filtered traceability set on request during an audit.
The Concerns field (severity + resolution) is designed for exactly this, and HOLD/REVISE/REJECT gate outcomes already function as an informal nonconformance/disposition path.
Gap: the dedicated Concerns table in Airtable is provisioned but not populated — concerns are currently tracked as free text on individual project records, not as structured, reportable records.
Gate 5 (Move to Production) is the natural checkpoint for a first-article inspection on any new part, process, or assembly before full-scale release to the owning department.
Recommend: add an explicit FAI sign-off field at Gate 5 for projects that produce a physical part or assembly, distinct from the general gate judgement.
Any associate or department identifies a cost-savings, quality, automation, new-model, or new-sales opportunity worth evaluating.
Standard intake channel: proposal title, application, value/objective, description, primary objective(s), rankings (new sales potential, cost savings, feasibility, investment requirement), estimated cost, funding source, staff/hours needed, risks & dependencies, strategic alignment, urgency, target timing, and supporting files.
Proposal is logged as a new record in the Airtable "R&D Project" table and issued a Project # (e.g., RD00xx). Alternate entry paths exist for phone, email, or support-ticket-originated ideas, but Jotform → Airtable is the standard, preferred path.
Are application, value/objective, and rankings sufficient to route the idea?
R&D staff, Senior Manager, or Manager, R&D assign Project Category & Sub-Department, designate Champion(s) and Support Team by discipline, and link any applicable Tax Benefit category for future R&D credit substantiation.
How should this project be prioritized?
Gate Judge reviews rankings, feasibility, and concept viability.
Champion and Support Team build tasks and milestones, develop the initial prototype, and document test results before returning to the Judge for a gate decision (Approve / Hold-Revise / Reject).
Findings and prototype are presented internally (Steering Committee / relevant department heads); feedback incorporated; Judge renders gate decision.
Design finalized; marketing/sales collateral prepared where relevant; cost, savings, and tax-benefit figures validated; Judge renders final pre-production decision.
Final gate judgement authorizes hand-off to GTC's owning department (Engineering, Production, Sales, or KAI) for full-scale production or implementation — the same concept → prototype → hand-off arc used across every GTC R&D project.
Concerns are logged with severity/resolution; milestones and tasks are tracked to plan vs. actual; staff notes and history maintain a full audit trail for every project.
ACTION set to COMPLETED; realized cost savings/revenue documented against the original Value/Objective; R&D tax-credit documentation finalized; project archived as a continuous-improvement reference.
How the two maps connect: KAI began as R&D Project RD0012 ("KAI-GTC uniforms in-house mfg / embroidery") — concept → prototype → hand-off from R&D to ongoing operation under GTC, the same arc every R&D project follows through the Gate process above. New product and Business Workflows & Intelligence ideas surfacing inside KAI today still re-enter the R&D pipeline (Step 2, Jotform) for formal evaluation before further investment; KAI's eventual move to full independence (Future State) will follow this same gated process.
KAI began as R&D Project RD0012 and today operates as a business unit inside GTC R&D — not yet a separate legal entity. It runs four customer-facing lines — Shirts, New Products/Services, Media Support/Services, and Business Workflows & Intelligence (consulting/sales of the apps, AI, and workflow systems GTC has built in-house) — plus internal digital signage support, produced in-house (embroidery, 3D printing, wide-format) or coordinated through an outsourced print portal. Current State: all KAI sales transactions are captured in KAI's online ecommerce systems and migrated into GTC's Plex (ERP); all KAI expense transactions are booked directly through Plex. KAI is still staffed and governed through R&D, and financially runs through GTC's books — see the Current/Future State note above; a Future State revision will reflect KAI as a fully independent legal and financial entity.
| Revenue Category | Year 1 % | Year 5 % |
|---|---|---|
| New Products (Garment Production + 3D Printing) | 21.3% | 46.8% |
| Design & Engineering Services | 35.7% | 14.4% |
| Consulting (incl. PLEX) | 21.2% | 7.3% |
| AI Services & App Development | 7.2% | 12.7% |
| Database & Digital Workflow Services | 9.2% | 9.8% |
| Print & Digital Marketing/Media | 5.3% | 9.0% |
KAI's production flow shares the same AS9100D scope as R&D wherever it touches purchased materials, outside vendors, or a physical hand-off to a customer. The controls below are written against KAI's current in-house/outsourced fulfillment flow.
New SKUs and Business Workflows & Intelligence engagements still originate as R&D proposals, where risk is formally captured. Day-to-day KAI risk shows up at the in-house-vs-vendor decision (Step 3) and the quality check (Step 5).
Recommend: log a simple risk flag on vendor-sourced jobs (single point of failure, lead time, quality history) rather than treating every outside vendor job the same.
The Pricing Strategy and margin sheets are the controlled documents that drive Step 4; the SOPs/quick-reference guides listed under Documentation are the process-configuration record.
Gap: no formal revision/version control is described for these documents today — recommend a simple version + owner + last-reviewed-date header on the Pricing Strategy and SOP files.
Directly relevant to KAI: blank apparel, thread, filament, and wide-format stock are purchased inputs, and outsourced vendor jobs (Step 3, "NO" branch) introduce externally-produced product.
Recommend: maintain an approved-vendor list with basic qualification criteria, and run outsourced jobs through the same quality-check gate (Step 5) used for in-house production.
Orders are traceable through the ecommerce platform and portal order numbers into Plex; production batches (embroidery run, print job) should carry that same order reference through fulfillment.
Recommend: confirm the order # survives from Step 1 intake through Step 6 fulfillment on every physical item, not just digital line items.
Step 5's quality check already has a real NO branch (rework in-house or return to vendor for correction) — that's a working nonconformance control.
Gap: results aren't logged anywhere structured today, so the "Order turnaround time & defect rate" KPI already listed in Measurements can't yet be reported from real data — the same data gap as R&D's Concerns table.
Step 3's "run a test/sample, then produce" language for in-house jobs is functionally a first-article check.
Recommend: apply the same test/sample step to new outsourced-vendor jobs and new Business Workflows & Intelligence deliverables before full release, and record the result rather than treating it as an informal habit.
Four intake channels: the public storefront (Shirts, New Products/Services), the internal outsourced-print/media portal (brochures, signage, personal orders), a direct internal request for digital signage/media content, or a direct engagement request for Business Workflows & Intelligence consulting (apps, AI, workflow automation).
Order/job is triaged against current queue, equipment availability, and KAI's revenue-line targets.
Embroidery, 3D printing, wide-format, and digital signage are KAI's in-house capabilities.
Quote/price is set using KAI's cost-plus model — direct expense ratio by line (Shirts ≈28.25%, New Products ≈33.3%, Media Support ≈75%) — referencing the internal Pricing Strategy and retail-vs-wholesale margin sheets; shipping is added at checkout, not embedded in the item price.
Does the produced or vendor-delivered item meet KAI/brand standards (layout, color, finish, resolution)?
Pick, pack, and label; ship via KAI's own FedEx account or deliver internally for signage/media requests.
Consumable/blank stock levels updated; storefront listings and availability adjusted as needed.
Sales are captured in KAI's ecommerce platform and migrated into GTC's Plex (ERP); all KAI expenses are booked directly in Plex. Current State: KAI is not yet a separately capitalized legal entity — all financial activity flows through GTC's books.
R&D Technician reports storefront traffic, conversion, top sellers, and margin by line to the Senior Manager, R&D (or Manager, R&D), against KAI's business plan targets.
Product or process ideas generated inside KAI (new SKUs, new equipment, new capabilities) are submitted back through the GTC R&D Project Proposal for formal evaluation before further investment — closing the loop with the R&D map above.
Direct links to the systems referenced throughout both process maps. Internal links require standard company sign-in / VPN access.
Jotform used by any associate/department to submit a new R&D idea.
R&D Project Proposal ↗Airtable base tracking every project, gate, task, milestone, and concern.
R&D Project Database ↗Internal-facing ordering portal for outsourced print & media jobs (production, admin, purchasing, sales, marketing, and personal staff orders).
Media / Print Portal ↗Manufacturing ERP referenced across R&D resourcing, engineering, and quality processes.
Plex ERP ↗GTC's growing practice for the consulting & sales side of the apps, AI, and workflow systems built in-house. Every engagement follows the same arc as an R&D project — concept, internal prototyping inside KAI/R&D, then hand-off to GTC for full-scale delivery — with examples already in production today: this process map, the R&D Airtable system, and KAI's ecommerce/production tooling.
ONLINE SHOWCASE COMING SOON — engagements available now