During SAP realization or build, project teams configure the agreed business processes, develop approved extensions, interfaces, forms and reports, prepare data and security objects, execute unit-level verification, resolve defects and keep the working solution aligned with approved design decisions. In SAP Activate terminology, the Realize phase uses iterative build and test cycles before the solution moves toward deployment and production readiness.
Realization starts from decisions, not a blank system
The build team should enter realization with a usable baseline: process scope, fit-to-standard outcomes, requirements, solution decisions, integration expectations, data scope, security needs and acceptance criteria. Design sign-off gives the project a controlled point of reference, while open items and approved changes continue through governance.
SAP Learning's SAP Activate material describes Realize as the phase where the solution is built and tested in iterations. The exact mechanics vary by SAP product, deployment model and project method, but the principle is stable: convert agreed requirements into working capability and create evidence that it behaves as intended.
Configuration implements the agreed process
Functional teams configure organizational structures, process controls, determination rules, workflow settings and other application behavior within the product's supported configuration model. Configuration should trace back to an approved requirement or standard-process decision rather than personal preference.
Teams also document why important settings exist. That rationale becomes valuable during testing, support and later changes because a configuration value without business context is difficult to govern.
Development handles approved extensions
Not every requirement can or should be solved through standard configuration. Approved developments may include extensions, interfaces, reports, forms, workflows or application enhancements. The project should keep these tied to the design decision that justified them and to technical standards such as security, maintainability and clean-core principles where applicable.
Integration design becomes executable during build: interfaces are configured or developed, mappings are implemented, error handling is defined, and technical teams verify connectivity and message behavior.
Data, security and testing progress alongside build
Realization is not only configuration and code. Data teams refine extraction, cleansing, mapping and load routines. Security teams build roles and authorizations against approved responsibilities. Test teams prepare scenarios and data while functional and technical teams perform unit-level checks on their own deliverables.
This parallel work matters because integration problems often appear at boundaries. A configured process may work with manually entered data but fail with migrated master data; an interface may technically send a message but violate a business validation; a role may permit the transaction but not the reporting action required by the job.
Defects and changes are normal—but controlled
Unit tests reveal defects. Business clarification may expose a missing requirement. Technical constraints may require a design adjustment. These are normal project events. The control question is whether the team distinguishes a defect from a new scope request and routes each through the appropriate decision process.
Without that discipline, realization becomes uncontrolled redesign. Teams should preserve traceability from requirement to design to build object to test evidence, and use change governance when the approved baseline must move.
What realization should produce
- configured process increments aligned to approved design;
- approved developments and integrations with technical evidence;
- data migration routines and progressively cleaner test data;
- security roles and authorization behavior ready for broader validation;
- unit-test evidence and resolved or controlled defects;
- updated documentation and traceability;
- a solution stable enough for system integration testing and later user acceptance.
Consultant thinking: “built” is not the same as “ready”
A developer saying an interface is coded or a consultant saying configuration is saved does not prove the business outcome. Ask whether the object is traceable, unit-tested, integrated with its dependencies, documented, transportable, secure and ready for the next test level. Build completion is an evidence statement, not an activity statement.
Key takeaway
SAP realization is the disciplined conversion of approved design into working solution increments. Configuration, development, integration, data, security, testing and defect resolution move together until the solution is ready for broader end-to-end verification and deployment preparation.