The State of FMEA in 2026: Why 80% of FMEAs Are Still Done in Excel

Most FMEAs in 2026 are still created and maintained in Excel. Despite decades of FMEA software, specialized tools, and industry standards, the majority of failure mode analyses remain manual spreadsheet exercises. They are often done to satisfy audits rather than to drive real reliability improvements. This post examines why Excel persists, what it costs organizations, and how the technology landscape is finally shifting toward AI-powered, data-driven FMEA.

The Uncomfortable Truth About FMEA Today

FMEA (Failure Mode and Effects Analysis) has been a core quality tool for decades. It is required in automotive, aerospace, medical devices, and many manufacturing sectors. Yet the way most organizations execute FMEA has not fundamentally changed. The dominant tool is still Microsoft Excel. Templates are passed from project to project. Engineers fill in rows based on experience, standards, and sometimes guesswork. The output is a document that satisfies auditors but rarely connects to how the organization actually manages risk and maintenance.

This is not a criticism of the engineers doing the work. They are following the process they were given. The issue is structural: FMEA has become a compliance deliverable rather than a living risk management tool. The result is shelf-ware. Documents are created, reviewed, signed off, and filed. They are updated only when an audit demands it or a major design change forces a revision. In the meantime, real failure data from the field, work orders, and maintenance systems flows elsewhere. The FMEA does not see it.

The Excel Problem: Version Control, Copy-Paste, and Disconnection

Excel is flexible and familiar. It is also the source of many FMEA headaches.

Version control nightmares. Multiple people edit the same FMEA. Files are emailed, saved to shared drives, and copied for new projects. No one is sure which version is current. “FMEA_v3_final_REVISED.xlsx” and “FMEA_v3_final_JSmith_edits.xlsx” sit side by side. Merging changes is manual and error-prone. Audit trails are weak or nonexistent.

No data reuse. Each new FMEA often starts from a blank template or a copy of a similar product. Failure modes, causes, and controls are re-typed. There is no structured database of failure modes to draw from. Knowledge lives in individual spreadsheets and in people’s heads. When engineers leave, that knowledge goes with them.

Copy-paste FMEAs. To save time, teams copy FMEAs from similar products and change the product name. The failure modes may not match the new design. Scores are carried over without re-evaluation. The result is a document that looks complete but does not reflect actual risk.

Disconnected from operational data. Work orders, warranty claims, and maintenance records contain real failure information. Excel FMEAs rarely connect to these systems. When a new failure pattern emerges in the field, the FMEA is not updated automatically. The gap between documented risk and actual risk grows over time.

Survey-Style Insights: Pain Points and Time Investment

Industry analysis and practitioner feedback point to consistent themes. These are not formal survey results but patterns observed across automotive, aerospace, pharma, and general manufacturing.

Common pain points:

• Time-consuming. FMEA is one of the most labor-intensive quality activities. A single DFMEA or PFMEA for a critical system can take 100 to 300 engineer hours. Teams report spending weeks or months on a single FMEA.
• Inconsistent quality. Without shared criteria and calibration, scores vary by author. One engineer’s “moderate” Severity is another’s “high.” RPN or Action Priority results are hard to compare across projects.
• Tribal knowledge dependency. FMEA quality depends heavily on who is in the room. Experienced engineers know the failure modes; new hires do not. Knowledge transfer is informal. When key people leave, FMEA quality drops.
• Stale documents. Most FMEAs are updated only when forced. Design changes, process changes, and field failures accumulate. The FMEA on file may be months or years out of date. Industry estimates suggest that a majority of FMEAs are shelf-ware: completed for compliance but not actively used for decision-making.

Average time to complete an FMEA. Estimates vary by system complexity and standard. A simple component might take 20 to 40 hours. A complex subsystem or process can take 100 to 200 hours. Full vehicle or system-level FMEAs can exceed 300 hours. Multiplied across many products and processes, FMEA represents a massive investment. Yet the return – in terms of risk reduction and maintenance optimization – is often unclear.

Living documents vs shelf-ware. A “living” FMEA is one that is updated when designs change, when new failures are discovered, or when controls are improved. In practice, most FMEAs are created once, approved, and then rarely touched. They live on a server or in a quality management system. They are pulled out for audits. They are not used to drive maintenance strategies, spare parts planning, or design improvements. The gap between intent and reality is wide.

The Compliance Trap: Checking the Box

FMEA is required. Customers demand it. Standards require it. Auditors check for it. So organizations produce FMEAs. The goal becomes “pass the audit” rather than “reduce risk.”

When FMEA is a compliance exercise, several things happen. Teams focus on completeness. Every column is filled. Every failure mode has a score. The document looks thorough. But the analysis may be shallow. Failure modes are generic. Causes are vague. Controls are listed because they exist, not because they are effective. The FMEA satisfies the checklist. It does not necessarily improve reliability.

The compliance trap also affects timing. FMEAs are often completed late in the design or process development cycle. They are done because the gate requires them, not because the team needs them for decision-making. By the time the FMEA is finished, many design decisions are already locked in. The FMEA becomes a record of what was done, not a guide for what should be done.

Breaking out of the compliance trap requires a shift in mindset. FMEA should be a tool for risk reduction, not just a deliverable. That means connecting FMEA to operational data, updating it when conditions change, and using it to drive maintenance and design actions.

What Good FMEAs Look Like

Good FMEAs share several characteristics. They are not just documents; they are part of an active risk management process.

Connected to operational data. Failure modes are informed by real data: work orders, warranty claims, maintenance history. When new failures appear in the field, the FMEA is updated. The link between documented risk and actual risk is maintained.

Regularly updated. FMEAs are revised when designs change, processes change, or new failure information becomes available. They are not one-and-done. Ownership is clear. Review cycles are defined.

Driving maintenance actions. FMEA results inform preventive maintenance, inspection frequencies, and spare parts strategy. High-priority failure modes map to specific maintenance tasks. The FMEA is used, not filed.

Consistent and auditable. Scoring follows standard criteria. Changes are traceable. The FMEA can be defended in an audit because it reflects a real process, not a last-minute effort to produce a document.

Collaborative. Design, process, quality, and maintenance teams contribute. Knowledge is shared. The FMEA is a team artifact, not a single author’s output.

Achieving this state is difficult with Excel alone. It requires structure, integration, and a commitment to treating FMEA as a living process.

The Technology Landscape: Excel to AI

The FMEA technology landscape has evolved in stages.

Stage 1: Excel. Spreadsheets and templates. Flexible, cheap, familiar. The default for most organizations. Limited structure, no integration, version control problems.

Stage 2: Specialized FMEA software. Tools like IQS, APIS, and others. Better structure, version control, and reporting. Often tied to quality management systems. Still manual entry. The workflow is “better spreadsheet,” not “data-driven analysis.”

Stage 3: AI-powered platforms. New tools that ingest operational data – work orders, manuals, prior FMEAs – and generate FMEA drafts automatically. AI suggests failure modes, causes, and controls. Engineers review and refine. The first draft is produced in days instead of weeks. FMEAs can be updated as new data arrives.

Most organizations are still in Stage 1 or 2. Stage 3 is emerging. The shift is driven by the recognition that manual FMEA cannot scale and that operational data already contains much of the information FMEAs need.

Why Traditional FMEA Software Has Not Solved the Problem

Specialized FMEA software improved on Excel in important ways. It provided structured worksheets, version control, and integration with quality management systems. It did not, however, solve the core problem: FMEA creation and maintenance remain manual.

Engineers still type failure modes one by one. They still score each row. They still copy from prior projects when they can. The software is a better container, but the content is still created by hand. That limits how many FMEAs an organization can produce and how often they can be updated.

Traditional software also tends to be siloed. It lives in the quality department. Work orders live in the maintenance system. Warranty data lives elsewhere. The FMEA tool does not automatically pull in new failure information. The connection, if it exists, is manual.

The result: FMEA software reduced some pain (version control, formatting) but did not fundamentally change the economics of FMEA. Creating and maintaining FMEAs is still expensive. The gap between FMEA and operational reality remains.

The AI Opportunity: From Operational Data to FMEAs

AI changes the equation. Operational data – work orders, repair records, maintenance logs – already describes failures. It contains failure modes, causes, and sometimes the controls that were applied. AI can extract this information and structure it into FMEA format.

Instead of starting from a blank worksheet, teams start from a draft generated from their own data. The draft reflects real failures that have occurred. It includes failure modes that might have been missed in a purely experience-based analysis. Engineers review, correct, and add. The time to first draft drops from weeks to days.

AI can also keep FMEAs current. When new work orders are processed, the system can flag new failure patterns and suggest FMEA updates. The FMEA becomes a living document because it is connected to the data that drives it.

This does not replace engineering judgment. AI proposes; engineers decide. The value is in speed, coverage, and the link to operational reality. For more on this topic, see our post on AI-powered FMEA.

What 2026 and Beyond Looks Like

The direction of travel is clear. FMEA will move from manual, document-centric exercises to data-driven, continuously updated risk models.

AI-generated FMEAs. First drafts will come from operational data. Work orders, manuals, and prior FMEAs will feed AI models. Engineers will spend more time reviewing and refining, less time typing.

Real-time risk updates. As new failures are recorded, FMEAs will be updated automatically. High-priority items will trigger alerts. Risk scores will reflect current conditions, not a snapshot from months ago.

Closed-loop reliability. FMEA will connect to maintenance planning, spare parts, and design changes. When a failure mode is addressed, the FMEA will record it. When a new failure appears, the FMEA will capture it. The loop between analysis and action will close.

Reduced shelf-ware. FMEAs that are connected to data and used for decisions will not sit in drawers. They will be part of daily operations. Compliance will follow from good practice, not the other way around.

This transition will take time. Excel will not disappear overnight. But the organizations that adopt AI-powered, data-driven FMEA will gain a significant advantage: faster analysis, better coverage, and FMEAs that actually drive reliability improvements.

How Tacit AI Approaches This

Tacit AI is an AI-powered platform for industrial reliability engineering. We built our Dynamic FMEA capability to address the problems described in this post.

From work orders to FMEA drafts. The platform ingests work orders, engineering manuals, and knowledge bases. It extracts failure modes, causes, and effects from your operational data. Instead of starting from a blank Excel sheet, you start from a draft that reflects real failures. Over 1,000 FMEAs and 100,000+ FMEA rows have been generated across automotive, pharma, and manufacturing.

Standards-compliant output. We produce DFMEA, PFMEA, and FMECA in formats aligned with AIAG-VDA, IEC 60812, SAE J1739, and MIL-STD-1629A. Export to Excel or integrate with IQS and other FMEA tools. You keep your existing workflows; we accelerate the creation and maintenance of FMEAs.

Faster time to value. Manual FMEA can take 100 to 300 engineer hours per critical system. Pilots typically deliver first results in under 7 days. The platform processes up to 1,000 work orders per minute and apply 15+ data quality validators to ensure inputs are reliable.

Living, auditable FMEAs. The platform links FMEAs to work order data so they can be updated as new failures and repairs are recorded. This creates a traceable, audit-ready maintenance strategy. FMEAs stop being shelf-ware and start driving decisions.

Frequently Asked Questions

Why do most companies still use Excel for FMEA?

Excel is familiar, flexible, and cheap. It requires no new software or training. Many organizations have used Excel for FMEA for years and see no compelling reason to change. The pain of Excel – version control, no data reuse, disconnection from operational data – is often accepted as “how FMEA is done.” Change requires recognizing that the cost of Excel exceeds the cost of better tools.

How long does it take to complete an FMEA?

It varies by complexity. A simple component might take 20 to 40 hours. A complex subsystem or process can take 100 to 200 hours. Full system-level FMEAs can exceed 300 hours. Industry reports suggest that many organizations spend weeks to months on a single FMEA. AI-powered tools can reduce this to days for a first draft.

What is the difference between a living FMEA and shelf-ware?

A living FMEA is updated when designs change, when new failures are discovered, or when controls are improved. It is used to drive maintenance and design decisions. Shelf-ware is created for compliance, approved, and then rarely touched. It sits in a file until the next audit. Most FMEAs fall into the shelf-ware category.

Can AI replace manual FMEA?

AI cannot replace engineering judgment. It can accelerate FMEA creation by generating drafts from operational data. Engineers review, correct, and add. AI also helps keep FMEAs current by flagging new failure patterns. The result is faster, more comprehensive FMEAs that stay connected to real data.

What should I look for in FMEA software?

Look for tools that connect to your operational data (work orders, maintenance systems), support your standards (AIAG-VDA, IEC 60812, etc.), and reduce manual entry. The best tools generate drafts from data and support continuous updates. Avoid tools that are simply “Excel with better formatting” unless that is sufficient for your needs.

Next Steps

The state of FMEA in 2026 is a mix of legacy practice and emerging change. Excel remains dominant. Compliance often outweighs value. But the technology and the data exist to do better. AI-powered platforms can turn operational data into FMEAs, keep them current, and close the loop between analysis and action.

Ready to move from Excel to data-driven FMEA? Explore Tacit AI’s Dynamic FMEA capability or read our What Is FMEA guide to understand the full process.