Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 3 of 5

Adopting innovation

8 min

Impact assessment asks "what will change whether we like it or not?" Adoption asks a different question: "of the new things SAP now offers, which do we want?" New apps, new scope items, new analytics and new automation arrive with every release. Some are worth a lot. Some solve problems you do not have. All of them cost something to adopt: configuration, testing, role changes, training and the attention of busy key users.

Process owners are the right people to make these calls because they own the business outcome. IT can tell you what a feature does. Only the owner of the process can say whether it is worth changing how people work.

Value against effort

Adopt nowHigh value, low effort. Example: a new filter in an app your team already uses that removes a manual export.
Plan itHigh value, high effort. Example: a new process capability that changes roles and needs training. Put it on the roadmap with a release slot.
Take it when freeLow value, low effort. Let it arrive with the release; mention it in release notes.
Decline for nowLow value, high effort. Record why, and look again when your needs change.
Sort each candidate innovation by value and effort.
The Sign-Off Table · thesignofftable.com/academy/sap-pow-304

Value should be stated in business terms you can check later: hours saved at month end, fewer manual journal entries, faster dispute resolution, a control that auditors asked for. Effort includes everything, not just configuration: test design and execution, role and authorization changes, training, documentation, and the change fatigue of users who just absorbed a go-live.

Now, later or not at all

  1. Does it fix a known pain point or control gap?Yes → candidate to adopt · No → continue
  2. Is it already on in your release, or will it be switched on automatically?Yes → treat as impact, not adoption; test and communicate · No → continue
  3. Can the key users absorb the change this quarter?Yes → schedule in the next release window · No → plan for a later window
  4. Does it depend on other scope you have not adopted?Yes → adopt the prerequisite first or wait · No → proceed
  5. Is the value large enough to justify a dedicated release?Yes → plan it as a small project · No → bundle with the next regular release
Deciding now, later or not at all for an optional innovation.
The Sign-Off Table · thesignofftable.com/academy/sap-pow-304
  1. SpotRoad Map Explorer, What's New items rated optional, user requests
  2. AssessValue and effort grid, prerequisites, team capacity
  3. DecideAdopt now, plan, take when free, or decline for now
  4. LogInnovation log entry with reason, owner and revisit date
  5. ScheduleChange request with a release slot on the calendar
  6. ProveTests added to the regression pack; value checked after one quarter
The innovation adoption cycle, from idea to proven value.
The Sign-Off Table · thesignofftable.com/academy/sap-pow-304

The second question matters more in Public Edition. Some new capabilities need explicit activation, while others become active with the upgrade for customers who use the related scope. SAP's documentation for each feature says which applies. Read it carefully: an innovation you did not choose is impact, and belongs in the previous lesson's process.

Change fatigue is a real cost

The first year after go-live is the worst time to stack innovations. Users are still building confidence in the new system, key users are fielding questions, and support teams are clearing the hypercare backlog. A good rule is to cap the number of user-facing changes per role per release. If the AP team is absorbing a new invoice approval process this quarter, the new payment app waits for the next window, even if it is valuable. Adoption that people cannot absorb turns into workarounds, and workarounds become the next round of defects.

Write the decision down

Keep a simple innovation log: feature, release, value statement, effort estimate, decision (adopt now, plan, take when free, decline), owner and the date to revisit declined items. The log keeps you honest. When someone asks in a year why Contoso never adopted a capability, the answer is there, along with the conditions that would change it.

Feature (example)ValueEffortDecision
New column and filter set in an AR line item appCollectors stop exporting to spreadsheetsLow: one role check, one noteAdopt now
Automated matching for incoming paymentsFewer manual clearings each dayMedium: rules, testing, trainingPlan for the next release window
New analytics app for a process Contoso outsourcesNone todayLowTake when free; no training
Process change requiring new organizational setupUnclearHighDecline for now; revisit next year

An extract from Contoso's innovation log. Feature names are illustrative.

What would you do?

A vendor sales presentation shows an impressive new SAP finance capability. The CFO forwards it to Dan asking, "Can we have this next month?" Contoso's next release window is in six weeks and the AP team is mid-way through training on a separate change. What should Dan do?

Key points
  • Adoption is a business decision owned by the process owner, informed by IT.
  • Sort candidates by value and effort: adopt now, plan, take when free, decline for now.
  • Features that switch on with the upgrade are impact, not adoption.
  • Count all of the effort: testing, roles, training and change fatigue.
  • Keep an innovation log with reasons and revisit dates.

Check your understanding · not graded

Lesson check

  1. 1. A new capability has high value and high effort. Where does it belong?

  2. 2. A new feature becomes active with the upgrade for customers using the related scope. How should it be handled?

  3. 3. Which item is part of the effort to adopt an innovation?

  4. 4. Why keep an innovation log?