How to write an SAP discovery resource request in 2026

Most discovery resource requests still ask for volume. They specify headcount, a start date, and a rough duration. That approach made sense when discovery was a manual exercise requiring armies of consultants to interview stakeholders, map interfaces by hand, and produce slide decks over several weeks. The work has changed. However, the request has not caught up. For any organization serious about SAP IT Recruitment, getting the resource request right before a program starts is one of the highest-leverage decisions a project team can make.

This guide walks through exactly what to include in a modern SAP discovery resource request, which roles actually matter, how to structure the seniority mix, and what questions to put to any supplier still quoting the old shape.

Why the Old Discovery Request No Longer Works: SAP IT Recruitment

The traditional discovery resource request was built around time and bodies. A client would ask for three to five consultants over eight to twelve weeks to produce a current-state assessment. The assumption was that discovery was slow because the work was slow.

That assumption is no longer valid. AI-assisted analysis tools can now process a custom object inventory, generate an interface map, identify technical debt concentration, and flag modernization priorities in a fraction of the time those tasks once required. In a recent 2iSolutions engagement, AI produced an initial SAP environment analysis covering all four of those areas well ahead of the timeline a traditional team would have needed. A senior architect then validated every finding before anything entered the program plan. Significantly, speed and completeness came from the AI capability, while judgment and accountability came from the human expert.

What This Means for Your Headcount Request

The implication is direct. You no longer need a large team to produce volume. You need a smaller, more senior team to produce quality. A request that still asks for five mid-level consultants over ten weeks is asking for the wrong shape. The supplier reading that request will staff accordingly, and you will get exactly what you asked for.

Reframe the request around outcomes and validation, not around effort and hours. That single shift changes everything downstream.

The Roles That Actually Matter in 2026

A well-structured SAP discovery team in 2026 looks different from what most templates still describe. Here is the core composition that reflects how the work actually gets done.

Senior SAP Solution Architect

This is the non-negotiable role. The architect owns the technical narrative, validates AI-generated outputs, and makes the judgment calls that no automated tool can make. They understand which technical debt is genuinely blocking and which is cosmetic. They know when an interface map is complete and when it is missing a critical integration path.

Request this role at a minimum of 15 to 20 years of SAP experience, with direct S/4HANA migration or greenfield implementation history. In particular, a generalist with broad ERP exposure is not a substitute.

Functional Lead (Module-Specific)

Depending on your scope, you need at least one functional lead who owns the business process layer. This person translates technical findings into business impact. They can tell a finance director what a particular piece of technical debt means for period-end close, not just what it means in ABAP terms.

For large programs covering multiple modules, request one functional lead per major process area. Do not ask for one person to cover finance, supply chain, and HR simultaneously. That is how critical gaps get missed.

Technical Analyst or Configuration Specialist

This role supports the architect and handles the structured data collection that feeds AI-assisted analysis. In 2026, this is not a junior role doing manual documentation. It requires someone who understands what the tools are doing, can identify anomalies in the output, and can escalate intelligently.

Request this at a mid-to-senior level. A junior analyst without SAP system experience will slow the architect down rather than accelerate the work.

Program or Delivery Lead (Optional but Recommended)

For any discovery engagement running longer than four weeks or involving more than three stakeholder groups, a delivery lead keeps the workstream on track. This person manages the schedule, owns stakeholder communication, and ensures findings move from analysis into documented decisions. Without this role, architects spend time on coordination instead of analysis.

How to Structure the Seniority Mix

Most discovery requests get the seniority mix wrong in one of two directions. Either they over-index on senior resources and create a bottleneck where highly paid architects are doing work that a mid-level analyst should handle. Or they under-index on senior resources and produce a discovery output that a program steering committee cannot trust.

The right mix for a standard SAP discovery engagement in 2026 is roughly:

• 40 to 50 percent senior (architect and functional lead)
• 40 to 50 percent mid-level (technical analyst, configuration specialist)
• 10 to 20 percent coordination (delivery lead or project coordinator)

For a four-to-six week engagement, that typically means two to three people, not five to eight. The smaller team moves faster, communicates more clearly, and produces a tighter output. Furthermore, a smaller senior team is easier to brief, easier to manage, and easier to hold accountable. Funding models for discovery work in other domains, such as the Discovery Grants program structure, also emphasize targeted expertise over sheer headcount.

SAP Specialized Recruiters who understand program delivery will recognize this shape immediately. A supplier who pushes back with a larger headcount proposal without explaining why should be asked to justify the additional roles against specific deliverables.

What Duration to Request and Why

Duration is the second area where most requests are miscalibrated. Eight to twelve weeks was the standard because manual discovery took that long. With AI-assisted analysis handling the heavy lifting on object inventories and interface mapping, the timeline compresses significantly.

Realistic Duration Ranges by Scope

For a focused single-module or single-process discovery, four to six weeks is achievable with the right team. For a full environment assessment covering multiple modules, custom development, and integration architecture, six to eight weeks is more realistic. Beyond eight weeks, you are either dealing with an unusually complex environment or the engagement has scope creep that needs to be addressed before it starts.

Request a phased structure rather than a flat timeline. Phase one covers AI-assisted data collection and initial analysis. Phase two covers architect validation and stakeholder review. Phase three covers the final report and program planning input. This structure gives you natural checkpoints and makes it easier to course-correct if the scope shifts.

Duration and Billing Structure

Ask your supplier whether they bill by milestone or by time and materials. For discovery, milestone billing aligns incentives better. A supplier billing by the hour has no structural reason to move quickly. A supplier billing by deliverable does. This is why this question is worth putting directly to any SAP Recruitment Agency in Canada that you are evaluating for program staffing.

Questions to Put to Any Supplier Still Quoting the Old Shape

If a supplier responds to your resource request with a proposal that looks like it was written in 2019, ask these questions directly. The answers will tell you quickly whether they understand how discovery work has changed.

1. How does your proposed team use AI-assisted analysis tools during discovery: and who validates the output?
2. Can you show us an example of a discovery deliverable your team has produced in the last 18 months:?
3. Why are you proposing this headcount rather than a smaller senior team:?
4. How do you structure milestone-based billing for a discovery engagement:?
5. What is your process when AI-generated findings conflict with stakeholder interviews:?

A supplier who cannot answer question one clearly is not operating at the current standard. Hiring Top SAP Talent in Canada means working with partners who have kept pace with how the tools and the work have evolved, not just partners with a long roster of available consultants.

Writing the Request Document Itself

The resource request document does not need to be long. It needs to be precise. Here is the structure that works.

Section 1: Scope and Objectives

State what the discovery must produce. Be specific. “A current-state assessment” is not specific. “A validated custom object inventory, an interface map covering all third-party integrations, a technical debt concentration analysis by module, and a prioritized modernization roadmap” is specific. The more precisely you define the output, the more accurately a supplier can staff and price the engagement.

Section 2: Roles and Seniority Requirements

List each role, the minimum experience level, and the specific skills required. Do not use generic job titles. “SAP Solution Architect with S/4HANA migration experience and ABAP custom development assessment capability” is more useful than “Senior SAP Consultant.”

Section 3: Duration and Milestones

Specify the total duration and the milestone structure. Include what you expect at each checkpoint. This protects both parties and creates a shared definition of progress.

Section 4: Evaluation Criteria

Tell the supplier how you will evaluate their proposal. Criteria might include team experience, example deliverables, approach to AI-assisted analysis, and billing structure. When suppliers know the criteria, better proposals come back.

Section 5: Questions for the Supplier

Include the five questions from the previous section. A supplier who answers them well in writing before the engagement starts is a supplier you can work with. SAP IT Recruitment at the program level is as much about evaluating partners as it is about filling roles.

Frequently Asked Questions

Q. What is an SAP discovery resource request?

A. An SAP discovery resource request is a formal document a client organization sends to a staffing supplier or consulting firm, specifying the roles, seniority levels, duration, and deliverables required for an SAP environment assessment. It sets the scope and expectations before any consultant is engaged. A well-written request produces better proposals and faster program starts.

Q. How many consultants do you typically need for SAP discovery in 2026?

A. Most SAP discovery engagements in 2026 require two to three consultants rather than the five to eight that older templates suggest. AI-assisted analysis handles much of the data collection and initial output, so the team’s job shifts toward validation, judgment, and stakeholder communication. A smaller, more senior team produces better results than a larger, more junior one.

Q. What should a discovery resource request include?

A. A strong request includes a precise scope statement with named deliverables, role descriptions with minimum experience requirements, a phased timeline with milestones, evaluation criteria, and specific questions for the supplier. Vague requests produce vague proposals. The more specific the request, the more useful the responses you receive.

Q. How does 2iSolutions approach SAP discovery staffing differently?

A. 2iSolutions focuses on matching senior architects and functional leads to discovery engagements rather than filling headcount. In a recent engagement, the team used AI-assisted analysis to accelerate the environment assessment, with a senior architect validating every finding before it entered the program plan. That combination of speed and expert validation is the standard 2iSolutions applies across discovery programs.

Q. What questions should I ask an SAP Recruitment Agency in Canada before signing a discovery contract?

A. Ask how the proposed team uses AI-assisted tools and who validates the output, whether the agency can provide recent discovery deliverable examples, and how they structure milestone-based billing. Also ask what happens when automated findings conflict with stakeholder input. Agencies that answer these questions clearly are operating at the current standard of SAP discovery delivery.

Conclusion

The gap between how SAP discovery actually works in 2026 and how most resource requests describe it is wide enough to cause real program damage. A request built around volume and weeks produces a team built around volume and weeks. The result is a discovery output that takes longer, costs more, and delivers less confidence than a well-structured smaller engagement would.

Getting the request right means specifying outcomes rather than effort, seniority rather than headcount, and milestones rather than open-ended time blocks. It also means asking suppliers the right questions before the engagement starts, not after the first invoice arrives. The organizations that do this well enter their SAP programs with a validated, trusted current-state picture. The ones that do not spend the first months of implementation correcting assumptions that a better discovery would have caught.

For any team preparing a discovery request right now, the practical starting point is the deliverable list. Write down exactly what you need the discovery to produce, then work backward to the team that can produce it. That sequence, rather than starting with headcount, is what separates a resource request that works from one that simply fills a template.