A solution design document (SDD) is the master technical specification that translates approved business requirements into a precise, build-ready system design — covering application configuration, integration architecture, data migration approach, security model, environment strategy, and non-functional requirements fulfilment. It is the primary governance artefact for the build phase of an ERP or EPM implementation: everything that is built must be traceable to the SDD, and everything in the SDD must be built. Deviations from the SDD — configuration decisions made during build that differ from the approved design — must be formally change-controlled and the SDD updated, not silently implemented and subsequently discovered by a tester or an auditor.
SDD Structure for ERP and EPM Implementations
A solution design document for a finance system implementation covers the following sections:
- Solution overview: The design philosophy, the scope of what is being built, the systems in scope, and the key design decisions made during the design phase with their rationale
- Application design: For each module in scope — the configuration decisions, the business rule implementations, the calculation designs (for EPM applications), the workflow definitions, and the reporting outputs delivered by the module
- Integration design: The integration architecture, with interface specifications referenced for each interface in scope
- Data design: The data migration approach, the data mapping decisions, the master data design (dimension structures, hierarchies, account classifications), and the data governance model that will operate post-go-live
- Security design: The role model, access control configuration, audit logging design, and regulatory compliance attestation
- Environment and infrastructure design: The environment strategy, infrastructure sizing (based on NFRs), and backup and recovery design
- Testing approach: The testing strategy, the test types planned for each phase, and the acceptance criteria derived from the NFR document
Common Gaps and Failure Modes
The specific failure that undermines the SDD’s value as a governance artefact is an SDD produced at a design level that does not distinguish between design intent and configuration decision. A section that states “the account hierarchy will be configured to support management reporting” has described an intent. A section that states “the account dimension in PBCS will contain three rollup levels: Natural Account → Reporting Line → P&L Summary, with the specific hierarchy members defined in Appendix C” has documented a configuration decision. The former is unusable as a build specification and as a test baseline. Acceptance test cases cannot be written against an intent; they can be written against a defined hierarchy structure. An SDD that cannot be used to write test cases is not a design document; it is a requirements summary with a different name.
How Loop Wise Solutions Produces This
Loop Wise Solutions produces SDDs to a configuration-decision level of precision — every section is written so that the build team can implement directly from the document, and the test team can derive acceptance test cases from it. We conduct a formal SDD review with the client’s business and IT representatives before build begins, with a sign-off process that confirms both the technical accuracy of the design and the business alignment of the configuration decisions. The signed-off SDD becomes the contractual baseline for build scope; any change to the design after sign-off is subject to formal change control.
