1. Start with the Most Common Questions from Practitioners

In the previous Configuration Management Series 1, we covered the basic concepts and importance of configuration management.
Many readers shared a common question:

"Now I understand the concept. So what do I actually do in real projects?"

In Series 2, we summarize a practical 5-step configuration management process that can be implemented immediately in engineering teams.
This includes key check points, checklists, and ready-to-use practical templates, all explained in one place.

2. Why Do Organizations Fail in Execution Even with Perfect Documents?

Even when companies possess configuration management documentation, execution often collapses due to the following reasons:

• Process procedures exist, but engineering work is not performed according to the defined process.

• Only the configuration manager understands the changes, while developers and test engineers are unaware of them.

• Documents and real workflows operate independently and never synchronize.

On the other hand, organizations that successfully build configuration management as an internal capability share these traits:

• Start small and improve rapidly.

• Maintain a structure that can be understood by all engineers after hearing it once.

• Keep documents aligned with real project workflows and ensure full traceability, including past history.

3. Practical 5-Step Configuration Management Framework for Real Engineering Work

Step 1 — Create the Configuration Management Plan (A Plan is More Than Documentation)

The configuration management plan is defined as a mandatory requirement in ISO 26262 Part 8.
However, writing the document alone is not planning. The real purpose of planning is team-level agreement on how configuration work will actually operate inside the project.

Core Elements of the Plan

Scope Definition
Clearly classify:

• Which projects apply configuration management

• Which work products must be managed

• Which artifacts are excluded from control

Configuration Management Organization & Role Structure
Define organizational boundaries, responsibilities, and authority for configuration activities.

Naming & Version Identification Rules
A practical and widely-used engineering pattern:

[ProjectCode][ArtifactType][ModuleName]v[Version][Date].Extension

Example:
CM01_SRS_BrakeModule_v1.0_20251127.xlsx

• Baseline Definition
  Specify baseline points through formal review and approval flows, marking a confirmed version as the reference baseline.
• Tools, Schedule, Status, and Change History Management Policies

• Ensure tools are defined and compatible with project needs

• Set policies for scheduling, history logging, version status, and archiving

Checklist for Step 1

• Has the artifact scope been shared with all project members?

• Are all teams applying the same naming & identification rules?

• Have document storage location, baselines, and approval rules been agreed upon?

Step 2 — Identify What to Manage

All major work products and engineering decision evidence created throughout the safety lifecycle must be configuration-managed.

Example Artifacts to Control

• Requirements specifications

• Design descriptions

• Test cases and results

• Safety plan & safety case

• Decision meeting records

• Manuals & guidelines

• Release versions

• Change history logs

Checklist for Step 2

• Are there missing artifacts?

• Is ownership assigned for each work product update responsibility?

• Are versions kept up-to-date regularly?

Step 3 — Control Change Flow

Change itself is natural. But uncontrolled change becomes safety risk, failure risk, and certification risk.

Typical Uncontrolled Change Failure Cases

• A developer modifies code, but the team is unaware, leading to system failure after release.

• Test teams repeat outdated test cases because they never received the update.

• A failure occurs after release, but root cause analysis is impossible due to lack of history tracking.

Safety Impact Analysis (Mandatory for Every Change)

• Does the failure mode change?

• Is the safety goal impacted?

• Are safety mechanisms affected?

• Are additional safety measures required?

Ready-to-Copy Change Request Template

Configuration work repeats the flow: Change Request → Review → Approval → Implementation → Re-verification → History Logging.

Step 4 — Build Traceability as a Core Capability

Audit and certification assessments always include the question:

"How was this requirement designed, implemented in code, and validated in test?"

Poor Responses When Traceability is Missing

• "It should exist somewhere…"

• "I think we tested it…"

• "Let me check again…"

Result: audit failure or assessment failure.

Strong Benchmark Response When Traceability Exists
REQ-001 was designed in DES-005 → implemented in MOD-010 → validated in TC-025/026.
(And traceability matrix is presented immediately.)

The ability to retrieve and explain evidence instantly proves configuration success.

Step 5 — Audit as a Maturity Gate

Configuration maturity splits at audit execution:

• Does the system satisfy safety requirements?

• Is audit frequency defined?

• Is audit ownership assigned?

• Is failure verification performed per module?

4. Three Core Operating Principles for Success

• Execution fails if attempting perfection too early.

• Configuration fails if owned by only one person.

• Documents must update when reality updates.

Following these principles automatically prepares teams for version history control → traceability → ISO audit readiness.

5. Why Organizations Trust Configuration Management from Hermes Solution

Expertise from Hermes Solution comes from over 10+ years and 100+ successful ISO consulting and project experiences across multiple industries.

Industry-specific configuration strategies for:

• Automotive (ISO 26262)

• Aviation

• Semiconductor

• Industrial embedded systems

What Makes This Approach Different

• Templates that can be applied instantly by practitioners

• CCB process and configuration culture design included

• Document-driven trigger architecture

• Execution and documentation remain synchronized

• Supports baseline and change control flow design for real engineering teams

Hermes Solution does not build document-only configuration.
It builds configuration where the document becomes the engineering trigger.

6. Conclusion — Real Configuration Feels Different for Practitioners

The 5-step method introduced here is not a theoretical document guide.
It is an execution-driven engineering reality guide.

• Change immediately triggers request → safety impact analysis → agreement → implementation → verification → history.

• Traceability originates from document architecture design.

• Audits evaluate execution more than documentation review.

Success can be defined as:

Configuration that anyone can understand, apply, and trace back through history.

7. Ready to Start?

Build configuration with a trigger-driven process structure together with Hermes Solution—not as separate document work and separate project execution work.

The next post will return with a document management process guide, following configuration management.