It's nearly midnight. Engineer Wang drains his third americano at the Hongqiao office floor-to-ceiling window. The DOORS requirements matrix on screen sprawls to row 387, while a German customer quality engineer pings him on WeChat: "Why isn't HW14.3.2's CAN bus wake-up logic traced to test cases?"

This is the third time he's been called out by a customer this month. Just yesterday morning he demoed an "Agile kanban" in Jira to a new EV maker client, then spent the afternoon filling in 158 test cases in ZenTao for an OEM—the same infotainment system, three requirement pools, five document templates maintained by one department.

This isn't an anomaly—it's the current reality: every production project has two R&D universes. When auditors arrive, the conference room plays a textbook-perfect ASPICE flow animation. The real world on engineers' laptops? Legacy code scattered across Jira, DOORS, WeChat File Transfer, DingTalk Drive, and "New Folder (3)" on the desktop.

Process Performance Art

A leading Tier 1's E/E department customizes three sets of requirement documents monthly: Excel matrix tables for Japanese clients, DOORS traceability files for German clients, and Confluence pages for internal collaboration. More absurdly, when requirements change, engineers must update all three systems simultaneously. One emergency change took 16 hours—14 of those were spent syncing documents.

This high-wire document juggling consumes 30% of R&D resources and forces companies to maintain multiple ALM systems: IBM DOORS for ASPICE certification projects, Jira for Agile iterations, ZenTao for test case management. Toolchain fragmentation means requirements close after flowing through 3-5 systems; time actually spent thinking about business logic and coding is under 35%.

Misunderstanding and Misuse of ASPICE

ASPICE is a widely recognized software process improvement model in the automotive industry. Its underlying V-model is a rigorous process. But in practice, some assessors and quality managers lack deep understanding of actual R&D processes, rigidly applying the standard and blindly requiring documentation—leading to cumbersome, inefficient processes.

For example, a Tier 1 mandated "must use SVN to lock documents for baselines" during ASPICE certification. But in actual development, baseline management tools and requirements tools were disconnected—after pulling a baseline, everyone kept developing based on the constantly changing requirements, rendering the baseline meaningless. To satisfy audits, the team had to reverse-engineer baseline documents, even fabricating review meeting records.

Another time, an assessor required a detailed test strategy document. The team spent massive effort writing it, only to find it nearly useless when actual testing began—the assessor only cared about document form, not whether the document actually fit project management.

The Dangers of Horizontal Tailoring

Faced with ASPICE-induced efficiency problems, some companies adopt horizontal tailoring: only ASPICE-certified projects follow ASPICE, while other projects use a lightweight process.

This seems to save time locally, but plants a time bomb for the entire team. When does it explode?

First, team members must adapt to two different project management styles and tool ecosystems—the learning cost is huge. A new engineer just got familiar with the lightweight process, then gets assigned to an ASPICE project and is completely lost.

Second, teams get used to lightweight processes and resist ASPICE when it's needed. When a "lightweight project" suddenly gets audited by a customer, the team—unfamiliar with DOORS—faces 3 months of rework.

Finally, reverse-engineering to satisfy ASPICE certification kills team morale. Smarter people refuse to do this ceremonial work, leading to a "bad money drives out good" effect.

Implement Vertical Tailoring

Vertical tailoring is the more effective, long-term correct improvement strategy: all projects—customer-facing or internal—use the same R&D process and toolchain. But for projects with lower audit requirements, appropriately simplify the complex ASPICE process to respond faster to market demands. For example:

Requirements, architecture, design, and test case documents can be written more concisely—e.g., using mind maps to lay out thinking

Use face-to-face meetings for requirements and architecture reviews—fix issues on the spot, foster a pragmatic expert culture

Reduce strategy documents like test strategy and project management strategy—these are already agreed at company level

Vertical tailoring reduces tool procurement and maintenance costs, gives teams a consistent process across projects, and lets the team refine one system to its best state—whether facing strict or simple customer audit requirements.