Why enterprise software stalls after the pilot

A purchase order can arrive before an organisation is ready to use the product. Identity, data ownership and implementation work often explain the gap.

Enterprise software3 min read

Participants at the Junction hackathon, 2015.Vmuru · CC BY-SA 4.0

A trial can succeed because a few committed people keep it moving. They correct records, answer questions and reconcile the output with another system. When those people return to their usual responsibilities, use of the product can fall away.

For a software company, this is a delivery and product problem with direct commercial consequences. Adoption is best measured through completed business tasks. Logins and purchased seats provide useful context, but neither establishes that the organisation has changed how the work gets done.

Follow the work outside the interface

An invoice review product depends on more than a reviewer approving a document. The file must arrive, the supplier must match a record, exceptions must reach an authorised person and the decision must return to the accounting system. A polished review screen may improve only a small portion of that sequence.

Map the handoffs with the employees who perform them. Identify what they can stop doing once the new product is in use. A second queue to monitor or a new spreadsheet to reconcile creates work even when the underlying feature is useful. The buyer, administrator and regular user may each experience a different balance of effort and benefit.

A login integration is only the beginning

OpenID Connect lets a client verify identity using authentication performed by an authorisation server. SCIM provides a protocol for managing identity resources across domains. They address different needs: establishing who a user is, and keeping accounts and related information in step with the organisation.

Three separate identity responsibilities

Scroll to view all columns

Comparison	Responsibility	Acceptance check
Authentication	Verify the person signing in	The customer's identity provider can authenticate the intended users.
Account lifecycle	Create, update and disable accounts	Joiners, team changes and departures reach the application correctly.
Authorisation	Decide which actions a user may take	Permissions reflect the customer's roles and access rules.

Supporting these standards does not answer every access question. During evaluation, follow an employee joining, changing teams and leaving. Check the effect on permissions, active sessions, shared records and administrator access. Clear responsibility matters when a customer's policy differs from the assumptions in the product's default configuration.

Define what a connector promises

An integration needs an operating agreement: which system owns a record, which changes move in each direction and how conflicts are resolved. Missing fields, deleted records and interrupted transfers are ordinary production conditions. If an update fails halfway through, the customer needs to know whether retrying will duplicate work.

The OpenAPI Specification describes HTTP interfaces, including operations, requests, responses and security requirements. It gives teams a common way to inspect an API. The working integration still needs tested behaviour for retries, timeouts and incompatible changes. Documentation can describe those obligations, but the customer's experience depends on their implementation.

Three DE-CIX equipment cabinets with Brocade networking hardware and yellow cables visible through their mesh doors. — DE-CIX network equipment, 2011.Stefan Funke (opens in a new tab) · CC BY-SA 2.0 (opens in a new tab)

Assign an owner for failures that cross system boundaries. Without one, a service ticket can circulate between suppliers while the business task remains unfinished. Expose enough diagnostic information to identify the failed handoff without giving operators unnecessary access to sensitive records.

Price the implementation as it actually happens

Track data preparation, configuration, training and continuing support through the trial. Separate work likely to recur for every customer from improvements that can be reused. Some valuable enterprise problems require substantial services. The commercial plan needs to account for the people, scheduling and margin involved in providing them.

Compare repeated use after the initial support period with use during it. Customer service objectives can measure successful completion or information freshness, following the approach to user experience described in Google's Site Reliability Workbook. Match the measurement frequency to the task. Daily activity is a poor measure of adoption for a quarterly process.

Before wider deployment, establish an exit path too: data export, revocation of connections and preservation of required records. These provisions make supplier risk easier for a buyer to assess. The adoption decision then rests on a clearer comparison between the recurring benefit and the full work of operating the product.