# Software Skills Across 203 U.S. Professional Occupations: O*NET 31.0 Evidence

> O*NET 31.0 evidence across 203 occupations reveals universal productivity, process-and-data and specialist software layers for career and curriculum decisions.

- Canonical page: https://mtfinstitute.com/insights/software-skills-203-professional-occupations-onet-31/
- Content type: Article
- Editorial category: Research &amp; Reports
- Publisher: MTF Institute of Management, Technology and Finance
- Author: MTF Institute Editorial Team- Published: 2026-09-22
- Updated: 2026-09-22
- Language: English
- Topics: Professional Development, Process Optimization, O*NET, Occupational Research, Software Skills

Software capability is not one skill. Across 203 detailed U.S. professional occupations in five major groups, the August 2026 O*NET 31.0 Software Skills file contains 15,833 occupation–software records, 4,736 distinct software examples and 121 software categories. The evidence shows a near-universal productivity layer, a broad process-and-data layer, and deep role-specific systems. The practical implication is clear: learners and employers should build software capability as a stack, not as a random list of applications.

This MTF Institute Research Report answers a concrete question: **Which software categories form the common and differentiating capability layers across management, business and financial operations, computer and mathematical, architecture and engineering, and legal occupations?** It provides category prevalence, group comparisons and a decision model for curriculum and career planning.

## Key findings

Office-suite and spreadsheet software each appear in 202 of 203 included occupations. Presentation software appears in 196, database user-interface and query software in 194, word processing in 194 and electronic mail in 185. This common layer is widespread, but product familiarity alone does not distinguish a professional.

The process-and-data layer is also substantial. Enterprise resource planning software appears in 155 occupations, project management software in 148, analytical or scientific software in 147, document management in 130 and process mapping and design software in 103. Business intelligence and data analysis software appears in 80 occupations.

Depth differs sharply by group. The median Computer and Mathematical occupation has 134.5 software examples across 37.5 categories. Median counts are 52 examples and 18 categories for Architecture and Engineering, 48.5 and 20.5 for Management, 41 and 19 for Business and Financial Operations, and 23 and 14 for Legal.

Every included occupation has at least one O*NET example marked Hot Technology. The share with at least one In Demand example is 100 percent in Legal, 97.2 percent in Computer and Mathematical, 93.8 percent in Business and Financial Operations, 85.7 percent in Management and 83.9 percent in Architecture and Engineering. These labels belong to O*NET&#039;s data and should not be interpreted as vacancy forecasts.

## Why this question matters

Career advice often alternates between two weak extremes: master one famous product or learn everything. Employers face the same problem when job descriptions list a long mixture of commodity, platform and specialist tools. A prevalence map helps separate baseline fluency from differentiating depth.

The analysis does not claim that every worker uses every listed example, that more software is always better or that a named product causes higher pay. It identifies the software categories associated with occupations in a standardized public source. The practical decision is how to allocate limited learning time and how to request credible evidence.

## Methodology

### Source and release

The study uses the official O*NET 31.0 Database, released in August 2026. The source tables are Occupation Data and Software Skills. O*NET describes Software Skills as software used on the job, with a category, example and Hot Technology or In Demand indicators. The archived bundle includes the exact text source used, deterministic analysis code and result files.

### Inclusion rule

We included every detailed occupation in five two-digit major groups that had at least one Software Skills record: 11 Management, 13 Business and Financial Operations, 15 Computer and Mathematical, 17 Architecture and Engineering, and 23 Legal. The resulting denominator is 203 occupations: 56 Management, 48 Business and Financial Operations, 36 Computer and Mathematical, 56 Architecture and Engineering and 7 Legal.

This differs from earlier MTF reports with 199 occupations because the present inclusion is driven by the current O*NET Software Skills table and current detailed occupation rows. We report the observed denominator rather than forcing comparability.

### Unit and measures

The source record is an occupation–category–example row. We counted distinct occupations, examples and categories after trimming text. Category prevalence is the number and share of included occupations with at least one example in that category. Group medians use each occupation&#039;s distinct example and category counts. Hot Technology and In Demand coverage indicate whether an occupation has at least one corresponding flagged example.

We did not weight occupations by employment, vacancies, wages or usage frequency. We did not infer proficiency level. Product names can occur in multiple contexts, and the source reflects O*NET&#039;s collection and taxonomy processes.

### Quality checks

The analysis verifies that every included occupation has records, deduplicates category and example counts within occupation, preserves the O*NET-SOC code, and reconciles group totals to the overall denominator. All calculations can be rerun with the included Python script. The public CSV files provide record-level and summarized results.

## The universal productivity layer

The first layer contains office suites, spreadsheets, presentation, word processing, email and database user interfaces. Their prevalence means “Microsoft Office” or equivalent is usually too vague as a differentiator. Evidence should show what the person produced: a controlled forecasting workbook, an executive decision deck, a query with validated joins, or a document workflow with version and approval rules.

Microsoft Excel and Microsoft Office software each appear across 202 occupations in the source examples. Microsoft PowerPoint appears across 193 and Microsoft Word across 190. These figures show breadth in the taxonomy, not the intensity or sophistication of actual use.

Curricula should teach transferable operations: structured data, formulas, validation, clear visual hierarchy, collaboration, access, change control and reproducibility. A learner should be able to explain assumptions and detect errors, not merely navigate a ribbon.

## The process-and-data layer

ERP, project management, analytical software, document management, process mapping and business intelligence connect individual work to organizational systems. This layer is where process optimization becomes visible.

ERP software appears in 155 occupations, roughly three quarters of the included set. Project management appears in 148. Analytical or scientific software appears in 147. These categories are broad: a single count does not make different products interchangeable. The cross-occupation presence nevertheless supports teaching system concepts such as master data, workflow state, authorization, audit trail, integration and reporting.

Process mapping and design software appears in 103 occupations, just over half. Mapping is not valuable because of the drawing tool; it is valuable when the model captures triggers, decisions, handoffs, exceptions and ownership. Business intelligence and data analysis software appears in 80 occupations, supporting a distinct analytical layer rather than universal baseline status.

## The specialist layer

Computer and Mathematical occupations show the greatest median breadth. Their top categories include database query, development environments and object- or component-oriented development software in all 36 included occupations. Operating systems appear in 34, database management systems and enterprise application integration in 32, and analytical or scientific software in 31.

Architecture and Engineering occupations combine the common layer with CAD, analytical and discipline-specific tools. Legal occupations show a smaller median breadth but universal coverage across the seven included occupations for database query, document management, email, browsers, office suites, presentations, spreadsheets and word processing. Management and Business and Financial Operations combine the common layer with ERP, document and project systems.

The implication is not that every manager should become a developer or every developer should master ERP configuration. A credible plan chooses depth where the role creates or governs value and interface literacy where it collaborates with specialists.

## Group comparison

Management&#039;s median occupation contains 48.5 examples across 20.5 categories. All 56 Management occupations include email, office suite, spreadsheet and word processing categories; 55 include presentation, 52 database user-interface and query, 45 ERP and 44 project management.

Business and Financial Operations has a median of 41 examples and 19 categories. Database query, office suite and spreadsheet appear in all 48; email and word processing in 47; presentation in 46; ERP in 39 and document management in 37.

Computer and Mathematical has a median of 134.5 examples and 37.5 categories, reflecting deeper and more diverse technical ecosystems. Architecture and Engineering has a median of 52 and 18. Legal has 23 and 14. Medians describe the center of each group; individual occupations can differ substantially.

## The STACK-3 learning model

Use three layers when planning development.

**Layer one: portable productivity.** Build evidence in structured spreadsheets, decision communication, document quality, collaboration and basic query literacy. The artifact must include checks and explanation.

**Layer two: organizational process systems.** Learn how work moves through ERP, project, document, workflow, process-mapping and BI environments. Focus on data contracts, permissions, lifecycle state and exception handling rather than memorizing menus.

**Layer three: role-specific depth.** Select tools from the target occupation and domain. A software role may need development, version control, database and integration depth. An engineering role may need CAD and analytical systems. A legal role may need research, matter, document and evidence systems. Demonstrate a complete task with domain constraints.

Allocate learning time only after examining target vacancies, employer stack and accessible practice opportunities. O*NET supplies an occupational baseline; current local vacancies and employer documentation provide context.

## A worked career decision

Consider an operations manager moving into AI-enabled process optimization. The common layer is probably already present, so spending months on generic office navigation creates little differentiation. The research suggests a better sequence: strengthen spreadsheet and query evidence; understand ERP workflow and master data; learn process mapping; add BI for measurement; then build bounded automation and AI evaluation capability.

The portfolio might include an order-exception map, a validated baseline workbook, a read-only ERP data extract, a dashboard with metric definitions and a controlled classification pilot. Each artifact connects a widespread category to an outcome and control.

For a computer professional moving toward business transformation, the gap may be reversed. Technical breadth is high, but the portfolio should demonstrate process ownership, economics, stakeholder translation, governance and adoption rather than adding another programming language without a decision context.

## Implications for employers

Job descriptions should separate required capability from illustrative products. Ask for “build and validate a scenario model with controlled inputs” before listing a spreadsheet brand. Ask for “trace an exception across workflow state and master data” before listing an ERP suite. Use product requirements when the environment truly requires immediate operation.

Assess with work samples. Give candidates a small sanitized dataset, process narrative and exception case. Ask them to choose a tool, state assumptions, produce an artifact and explain validation. This reveals portable competence better than a checklist of names.

Create role-based learning maps. Universal tools deserve performance standards, not endless introductory training. Process-system learning should use cross-functional scenarios. Specialist learning should align with actual architecture and supervision.

## Implications for educators

Organize curricula around outcomes that require multiple software layers. A learner could diagnose a process, analyze its data, communicate a decision and design a controlled improvement. Product tutorials can support the task, but assessment should focus on evidence quality, reproducibility, governance and reflection.

State what a credential attests. Completion, knowledge tests, project assessment and observed workplace competence are different claims. Publish assessment rules and identity verification where applicable. Encourage learners to retain sanitized evidence of method and revision.

## Limitations

O*NET is a U.S. occupational information system. Results may not generalize to other labour markets, organizations or job levels. The Software Skills file identifies software associated with occupations; it does not measure frequency, mastery, criticality, market share or causal value. Categories vary in breadth. Hot Technology and In Demand indicators are source fields and are not independently validated here.

The five-group scope excludes other important occupations. Equal occupation weighting means a small occupation counts the same as a large one. Release updates can change occupations, examples and flags. Product names can become obsolete faster than underlying capabilities. This is descriptive research, not a forecast of hiring, salaries or displacement.

## Authorship, review and reproducibility

The MTF Institute Editorial Team conducted the analysis and wrote the report. The same team performed a structured editorial and reproducibility review on 22 September 2026, checking source attribution, inclusion rules, denominators, formulas, result tables, practical claims and limitations. This is an institutional research report, not a peer-reviewed journal article. O*NET and the U.S. Department of Labor did not approve or endorse the analysis.

The Zenodo archive contains the searchable PDF, source tables, analysis code, record-level and occupation-level CSV files, category, product and group summaries, the machine-readable analysis result, README and method note. The DOI and direct PDF link below identify the final archived version.

**DOI:** [10.5281/zenodo.22885872](https://doi.org/10.5281/zenodo.22885872)

**Archived PDF:** [MTF-RR-2026-09-22-01.pdf](https://zenodo.org/records/22885872/files/MTF-RR-2026-09-22-01.pdf?download=1)

## How to use this report responsibly

Begin with the category layer, then inspect the target occupation rows in the archived profiles. Compare them with current vacancies and the actual systems used by a prospective employer. Choose one portable capability and one specialist capability for the next learning cycle. Produce an inspectable artifact and request critique.

Do not claim competence because a product appears in the data. Do not infer that absent software is irrelevant. Do not convert the descriptive prevalence into a salary or automation prediction. Use the findings to ask better questions and allocate learning effort.

## Sources and evidence boundaries

This guide uses primary sources for governance and occupational evidence. The [NIST AI Risk Management Framework](https://airc.nist.gov/airmf-resources/airmf/5-sec-core/) organizes AI risk work around Govern, Map, Measure and Manage, and explicitly treats human oversight, documentation, testing and monitoring as lifecycle responsibilities. The [NIST AI RMF Playbook](https://airc.nist.gov/airmf-resources/playbook/) offers voluntary actions rather than a certification. The [OECD AI Principles](https://oecd.ai/en/ai-principles) emphasize human-centred values, transparency, robustness, security, safety and accountability. The [O*NET 31.0 database](https://www.onetcenter.org/database.html) supplies standardized U.S. occupational and software-skill information, but it is not a forecast of vacancies or a guarantee that a named product is required by every employer.

Treat vendor claims, demonstrations and certificates as inputs to evaluation, not proof of business impact. A tool that performs well on a clean demonstration may fail on incomplete records, policy exceptions, adversarial input or an inaccessible downstream system. A course can provide a structured practice environment; it cannot substitute for authorization, production testing, domain judgment or employer-specific controls.

## A practical next step

Choose one real but low-consequence workflow this week. Write its decision, owner, input boundary, current baseline, exception path and acceptance test on one page. Only then test an automation. Preserve the original evidence, record every change, compare the result with the baseline and ask an independent reviewer to challenge the failure cases. A small verified result is more valuable than a large untested promise.

&gt; ### Build a governed AI-automation portfolio
&gt; The [Professional Certificate: The AI Automation &amp; Process Optimization Expert](https://mtfinstitute.com/programs/ai-automation-process-optimization-expert/#enroll) is the most relevant MTF Institute programme for readers who want structured practice in workflow analysis, automation design and evidence-led process improvement. Review the curriculum and enrolment terms to decide whether it fits your objectives. A credential supports learning; your inspectable projects and responsible operating habits remain the evidence employers can evaluate.



## Citation

When citing or summarizing this material, link to the canonical HTML page: https://mtfinstitute.com/insights/software-skills-203-professional-occupations-onet-31/
