After go‑live: give support the context it needs

Gather enough information to route the request

Ask which activity was under way, what result was expected and what was observed. Add the impact on the team and the checks already performed. This makes it possible to assess the issue without jumping to the conclusion that there is a software defect or a rule that needs changing.

The handling process needs to distinguish usage questions, incidents and change requests. Depending on the site, the local team, central support, the integrator or the vendor may be involved at different levels. Quality events follow the applicable procedures.

Define Business System Owner and administration responsibilities

Where a site uses the title Business System Owner (BSO), the responsibilities attached to it need to be explicit. For the MES, define who represents production needs, who prioritises requests and who follows changes with IT and quality. Decisions and approvals need identified owners.

Administration covers authorised operations in the system, such as managing master data or preparing a configuration change. Business responsibilities and administration tasks may be shared between several people. The allocation needs to make clear who requests, who decides, who implements and who checks.

Reference: ISPE · GAMP: lifecycle approach and clear responsibilities

Plan on-call coverage around production

Shift-based on-site presence and on-call support are organised differently. For on-call support, define coverage hours, situations that warrant a call and the contact channel. Availability and response arrangements are agreed with the site.

The person contacted needs access to the operational context and diagnostic guidance. Their remit defines which actions they may take and which issues need escalation to IT, automation, the integrator or the vendor. Quality decisions remain within the site’s processes.

At the end of the intervention, record the diagnosis, actions and unresolved points for the team taking over. Recurring calls can then inform improvements to the system, documentation or training.

Make the handover usable in practice

A handover needs to be checked. Ask the support team to find a design decision, a data owner and a previously encountered issue. This is a practical way to check that the knowledge is accessible.

Useful documentation brings together the reasons for design choices, known limitations and contact routes. Each item needs an owner who keeps it current and consistent with the relevant system version. An answer that was correct before a change may become misleading afterwards.

Use the tools and channels approved by the site for sensitive information. A knowledge base is not a place to copy batch record data without control.

Connect recurring requests to system changes

Similar requests deserve to be examined together. They may point to incomplete training material, misunderstood data or a design difficulty. The response can then address their common cause.

Before agreeing a change, describe the need and the users concerned. A small screen change can affect a recipe, an interface or batch record review. Its impact on testing, validation and training material is assessed through the site’s change process.

Keep the link between the original request, the decision and the delivered version. The next person who picks up the issue will be able to understand what changed and why, without having to reconstruct the project’s conversations.