Skip to content

SAP · Managed Services

A go-live is the start of the system’s life, not the end of the project.

Noble runs SAP landscapes after they are live: application management for the questions and changes a business raises every week, a release cycle that keeps the system on SAP’s cadence without surprising anyone, interface monitoring that catches a failed document before a period-end does, and hypercare after every go-live — the first weeks in which the difference between a system that works and one that is trusted is decided.

What a managed service is for

An SAP system is configured to the organisation as it was on the day it went live, and the organisation does not stay that way. A new plant opens, a tax rule changes, a product line is added, a supplier moves country. Each of those is a change to the system, and a managed service exists so that the change is made properly — configured, tested, transported and documented — rather than worked around by the people who needed it yesterday.

The service is also where the system’s knowledge lives after the project team has gone. The reason a posting rule was set the way it was, the interface that has to run before another, the month-end sequence that nobody wrote down — a managed service keeps those in a register with an owner, so that the organisation is not dependent on the memory of whoever was in the room.

What the service covers

01

Application management

The questions, incidents and small changes a business raises against a live system: a posting that will not clear, a report that shows the wrong figure, a new cost centre, a user who needs a role. Each is logged, owned and closed through the same transport path a project change uses — because a change made in production without a record is how a landscape drifts.

  • Incident, request and small-change management for live systems
  • Functional support across finance, logistics, procurement and HR processes
  • Every change through the transport path, with a record
  • A knowledge register that outlives the people who wrote it
02

The release cycle

SAP ships on a cadence, and a landscape either keeps up with it deliberately or falls behind it by accident. The service plans each release against the organisation’s calendar — never across a period-end — assesses what it changes in the configured process, the custom code and the interfaces, regression-tests the processes that matter, and lands it in a window the business agreed to.

  • Release planning against the business calendar
  • Impact assessment on configuration, custom code and interfaces
  • Regression testing of the processes that matter
  • Feature activation reviewed release by release
03

Interface monitoring and support

Every interface into and out of the landscape watched for the document that did not arrive: queues, failed messages, missing acknowledgements and late files, each with a threshold and a person who is told. A failed interface is reprocessed with its context intact, and the reason it failed goes into the register so the next occurrence is shorter.

  • Queue, message and file monitoring with owners
  • Reprocessing that keeps the document and its context
  • Period-end interface sequence rehearsed and documented
  • Root causes registered so repeats are shorter
04

Hypercare after a go-live

The weeks after a go-live, run as a distinct phase with its own team, its own daily rhythm and its own exit criteria. The first month-end is the real acceptance test of an SAP system; hypercare exists so that it is watched by the people who built the configuration, and so that what they learn is written into the register before they hand the system to the steady-state service.

  • A distinct phase with a daily rhythm and exit criteria
  • The first period-end watched by the people who configured it
  • Handover to steady state on evidence, not on a date
05

Landscape and environment management

The systems around production: development and quality kept in step, client copies and refreshes on a schedule, a project landscape stood up beside the maintenance one when a programme needs it, and the sandbox that lets the business try something without a transport. Where SAP operates the infrastructure under RISE, the service manages the customer’s side of that boundary.

  • Development and quality kept in step with production
  • Client refreshes and project landscapes on a schedule
  • The customer side of the RISE boundary managed
06

Service governance

The service reviewed as a service: a register of open items and their owners, a regular review with the organisation’s SAP owner, a change calendar the business can see, and a record of what was done and why that an auditor can follow. The terms — coverage, response, escalation — are written into the contract, and the review measures the service against them.

  • Open-item register with owners, reviewed on a rhythm
  • A change calendar the business can see
  • Terms written into the contract and measured against

The service year

A loop, because a managed service is a calendar rather than a project. Each release passes the same stages, and the period-end is the attended stage — the point at which nothing is imported and everything is watched.

  1. 01Plan the releaseAgainst the business calendar
  2. 02Assess impactConfiguration, code, interfaces
  3. 03Regression testThe processes that matter
  4. 04Land in a windowAgreed with the business
  5. 05Period-endFreeze; watch everything
  6. 06Review the serviceRegister, owners, terms

SAP, S/4HANA and RISE with SAP are products and offerings of SAP SE, named to identify what the service runs. All marks belong to their owners.

Tell us what the last month-end was like.

How the last period-end went — what failed, what was done by hand, who stayed late — describes a landscape more precisely than any system inventory. Start there.