MELLORCATalk to Mellorca
Discovery

SaaS & Application Portfolio Management

Business capabilities that depend on tools nobody supports

Quoting, collections or payroll often rest on a tool with no named support owner. Budget cuts and vendor changes expose the gap. How to map capabilities to tools and assign support.

Mellorca Discovery2026-10-03

When a business is asked to cut software spend, the conversation usually starts with licences: which tools are expensive, which are under-used, which overlap. It is often only at the point of cancelling something that someone says, "wait, that is how we produce the monthly debtors pack" or "the warehouse labels come out of that". The tool turns out to underpin something the business cannot do without, and nobody is clearly responsible for keeping it working.

This article is about that condition: important business capabilities that depend on tools with no named support owner. It is a portfolio problem rather than a single-application problem, and it is most often discovered at an inconvenient moment.

The problem in plain language

A business capability is something the organisation must be able to do: issue quotes, collect payments, run payroll, schedule technicians, file VAT returns. Each capability depends on a chain of tools. Some are major systems with clear owners. Others are smaller: a reporting add-in, a scheduling plug-in, a browser extension, a free-tier SaaS tool, a spreadsheet template with macros, or a connector set up by a former employee.

The problem is not that these tools exist. It is that nobody has been assigned to keep them supported: to watch for vendor changes, apply updates, manage access, renew subscriptions and fix them when they break. When one fails, the capability fails with it, and the business has to work out who can help while the work piles up.

What the buyer is actually trying to solve

Leaders rarely search for "capability ownership". They ask how to find out what software the business depends on, which tools are safe to cancel, or who should support a system nobody owns. The underlying need is confidence that every capability the business relies on has supported tools behind it, and that cost reduction will not cut through something critical.

Evidence and system mechanism

Inventories and roles are baseline expectations

The NIST Cybersecurity Framework 2.0 sets out outcomes that apply well beyond security. It expects organisations to maintain inventories of software, services and systems (ID.AM-02) and of services provided by suppliers (ID.AM-04), to prioritise assets by classification, criticality and impact on the mission (ID.AM-05), and to establish, communicate and enforce roles, responsibilities and authorities (GV.RR-02). A tool with no support owner fails these expectations twice: it is often missing from the inventory, and no role covers it.

Vendor support is time-limited and varies by product

Microsoft's lifecycle FAQ explains that each product has its own support timeline, that older versions may differ from newer ones, and that support for add-ons and tools can be ended with a minimum of twelve months' notice. Other vendors have their own policies. Someone has to watch those timelines for every tool a capability depends on. If nobody owns the tool, the notice goes unread.

Platforms assume an administrative owner

Microsoft's Power Platform governance guidance lists designating an administrator as the first best practice, before environment strategy or other controls. The same assumption runs through most business software: governance starts with a named person.

Warning signs

  • The application list, if one exists, records cost but not which capability each tool supports.
  • Support requests for some tools go to "whoever set it up", who may have left.
  • Subscriptions are paid on personal or departmental cards.
  • Vendor notices about changes or end of support go to a shared mailbox nobody reads.
  • Planned cancellations are reversed at the last minute because a dependency is discovered.

If the business cannot yet list every tool in use, that is the place to start; see why businesses cannot list all the applications they use.

Problem owner and why-now trigger

The problem belongs jointly to the COO or head of operations, who owns the capabilities, and the IT manager, who usually inherits the support burden. Finance becomes involved because it holds the budget and is often the function asking for cuts.

The most common trigger is budget reduction. A licence review forces decisions about individual tools, and that exposes which capabilities depend on them. Other triggers include a vendor ending support for a product, a key person resigning, and an audit asking who is responsible for a system.

Economic consequence

The cost appears in three ways. First, outages: when an unsupported tool fails, the capability stops until someone works out how to fix it, and the business absorbs the delay in lost sales, late billing or idle staff. Second, false savings: cancelling a tool that turns out to be essential leads to emergency reinstatement, rushed replacements or manual workarounds that cost more than the licence. Third, risk: unsupported tools miss security updates and keep access for people who have left. The pattern is closely related to not knowing which services depend on which systems.

Root cause

  • Tool-first rather than capability-first thinking. Portfolios are managed as lists of products and costs, not as the capabilities those products enable.
  • Bottom-up adoption. Teams adopt small tools to solve immediate problems, and support is never formally assigned.
  • Ownership confused with purchase. Whoever bought or set up a tool is assumed to own it, until they change role or leave; see application owners who leave without transfer.
  • No criticality rating. Without a view of which capabilities matter most, there is no basis for deciding where support effort should go.

Practical intervention

  1. List the capabilities that matter. Start with fifteen to thirty core capabilities, such as quoting, invoicing, collections, payroll, procurement, stock control and customer service.
  2. Map each capability to its tools. For each one, record every tool in the chain, including add-ins, connectors, templates and free-tier services.
  3. Rate criticality. Agree which capabilities would stop the business, slow it, or merely inconvenience it if they failed for a day.
  4. Assign a support owner to each tool on a critical chain. The owner watches vendor notices, manages access and renewals, and is the first call when it fails. Owners can be internal or a managed service provider, but they must be named.
  5. Use the map in cost decisions. Before cancelling any tool, check which capabilities depend on it. Guidance on removal decisions is in how to decide which software to remove.
  6. Review twice a year. New tools appear constantly; the map only works if it is kept current.

Trade-offs

Assigning owners creates real work, and some tools will turn out not to be worth supporting. That is a useful result: it allows a deliberate decision to replace, consolidate or retire them. For low-criticality tools, a light-touch owner who only watches renewals and access may be enough.

An illustrative example

Illustrative: a Gqeberha automotive parts distributor with about 120 staff was asked to reduce software spend before year-end. A low-cost reporting add-in looked like an easy cut. Mapping capabilities first showed it produced the weekly overdue-accounts list the credit controllers worked from. It had been configured by a former finance analyst and had no owner. Instead of cancelling it, the business assigned it to the finance systems lead, documented the setup and scheduled a replacement inside the main accounting system.

Diagnostic questions

  • Can you name the tools behind each of your ten most important business capabilities?
  • Does every tool on those chains have a named support owner who is still with the business?
  • Who receives vendor end-of-support and change notices for each tool?
  • Before a cancellation, do you check which capabilities depend on the tool?
  • Which capability would stop first if a small, unowned tool failed tomorrow?

What good looks like

The business holds a short capability map linked to its application inventory. Each critical capability lists its supporting tools, and each tool has a named support owner, a criticality rating and a renewal date. Cost reviews start from the map, so savings are taken where they are safe. Vendor changes are picked up early because someone is responsible for watching them.

Where Mellorca fits

A digital systems audit can build the capability-to-tool map and identify unowned dependencies. Digital systems architecture and roadmap work then helps decide which tools to support, consolidate or replace, and in what order.

Method note

This article applies published framework outcomes and vendor lifecycle guidance to software portfolio management in smaller organisations. It does not estimate how common unowned tools are, as no reliable South African data was found. The example is illustrative and not based on a specific client.

Sources and further reading

Related Mellorca reading

Article summaryQuoting, collections or payroll often rest on a tool with no named support owner. Budget cuts and vendor changes expose the gap. How to map capabilities to tools and assign support.
Explore our solutionsStart a conversation