Throughout my professional career, I have observed that the rigor of my functional analyses has consistently been reinforced, regardless of the methodological frameworks used, whether it be the traditional V-cycle or an iterative Agile approach.
This evolution is not accidental; the gathering of requirements constitutes, from the very first steps of an ERP project, the indispensable foundation that clearly defines the functional scope and guarantees the consistency of all deliverables.
Beyond its functional role, the analysis represents genuine expertise. It mandates a common, precise, and unambiguous understanding of the client's expectations, in order to avoid any divergent interpretation that could compromise the success of the deployment.
This article, therefore, is not limited to improving the quality of the deliverable; it also aims to be an invitation to transparency with our clients and an emphasis on the mastery of our profession.
By clearly setting out the methodology and the tools we employ, we seek not only to secure every phase of the project but also to establish a lasting relationship of trust, built on clarity, accountability, and the sharing of a common vision.
The usefulness of the document
The functional analysis is the reference document that translates business needs into concrete solutions within the ERP.
- For the business functions: it validates that their needs are understood and transcribed unambiguously.
- For functional consultants: it provides the basis for correctly configuring the system.
- For developers: it distinguishes what falls under the standard, an add
- on, or a specific development.
- For project management: it secures the scope, limits scope creep, and serves as a guiding thread throughout the project.
This document must be shared with the client, who is its primary critical reader and validator. This validation is essential: it confirms that the integrator has correctly understood the current operation of the company or of a specific flow, and that they are proposing an adapted and realistic improvement solution.
It is therefore not just a formal deliverable, even if the nature, quantity, and quality of the information it contains make it an expertise; it is a tool for communication, steering/management, and joint validation between the business functions and the integrator.
Expertise
Expertise is the combination of in-depth knowledge, practical experience, and a capacity to analyze a specific domain with discernment.
When it materializes in an official document, it becomes a reflection of the company that employs us: this document carries its standards, its methodology, and its professional identity. But it also embodies the intellectual signature of its author; the way in which requirements are formulated, arguments are chosen, and recommendations are proposed reveal the skills, style, and vision of the person who wrote it.
Thus, every analysis document is both an ambassador for the organization and the personal testimony of its creator.
The structure of the analysis
The functional analysis follows a logical and clear framework. It begins with an introduction that sets the context, then describes the current procedures and the target procedures. It then details the response to the business needs within the ERP, distinguishing between standard functionalities, add-on functionalities, and specific developments. It specifies the configuration (paramétrage), the business rules, the screens, the reports (états), and concludes on the added value for the company.
Finally, it formalizes the requirements that guarantee the overall quality of the system.
The analysis begins with the presentation of the company: its sector of activity, its specific characteristics, and the subject covered by the study.
It then describes the current problems hindering productivity: duplications (or duplicates), sluggishness (or slowness), errors, lack of reporting.
This section explains why an evolution is necessary and what concrete improvements are expected.
Procedures
The existing process is described using the present tense: completed steps, involved stakeholders, blocking points. The objective is to provide a factual and objective view of how the company operates as of today.
The process is projected as it will be in the future ERP, using the future tense: more integrated, automated, and controlled. This phrasing highlights the expected transformation and improvement.
Writing rule: in a functional analysis, the conditional tense is never used. Only the existing (present) and the target (future) are described, to eliminate all ambiguity.
In order for the client to easily envision the proposed solution, one should not hesitate to include sketches or images of the future pages or windows of the system. These visuals, even if simple, allow for the following:
- For the client to concretely visualize their future work environment, thus helping them validate the proposed solution well before any development.
- For developers to have a visual reference of what they need to develop.
- To save time during the preparation of mock
- up materials in the phase subsequent to the analysis validation.
The diagrams illustrate these flows and make the stakes/issues clear to everyone.
Functionalities in the new ERP
Each need is translated into a response in the future system.
- Standard ERP: the functionality already exists; it will be available after configuration (paramétrage).
- Add
- on: an extension validated by the editor covers the need.
- Specific: a development will be created to meet a unique requirement.
Setup
This section describes the necessary settings: business rules, workflows, user profiles, nomenclature.
The configuration (paramétrage) adapts the standard to the company's practices and constitutes the first step of customization.
Detailed description of the functionalities
- Business rules: calculations, controls, validations.
- Screens and forms: mandatory fields, ergonomics, ease of data entry.
- Reports and reporting: indicators, dashboards, regulatory documents.
These descriptions ensure that users know how to work tomorrow and that the teams have all the elements required for configuration and development.
Business Conclusion
The end of each sub-process explicitly states the expected added value for the company. This section highlights the tangible benefits that will transform users' daily work and contribute to strategic objectives:
- Productivity gains,
- Increased data reliability,
- Better decision
- making,
- Improved customer satisfaction.
Non-functional Requirements
In addition to business processes, the analysis formalizes the system's quality requirements, guaranteeing its robustness and sustainability (pérennité). These points have a direct impact on user satisfaction and business performance:
- Performance: Measures the system's responsiveness (response time) and availability, as well as its capacity to handle peak loads.
- Security: Defines the rules for user authentication and authorization. It also covers data protection (encryption, backups) and regulatory compliance (GDPR).
- Volumes: Analyzes current data and integrates growth forecasts to correctly size the infrastructure and anticipate future needs.
- Ergonomics: Ensures that the system is intuitive and easy to use. Good ergonomics reduce errors and promote user adoption.
Formalizing these requirements from the outset allows them to be integrated into the technical specifications (or technical statement of work) and avoids surprises at the end of the project. They constitute the technical backbone that supports the business functionalities.
The value of the standard / add-on / specific distinction
This distinction is essential.
- The standard ensures stability, scalability, and lower cost.
- The add
- on provides a proven response to needs already encountered elsewhere.
- The specific offers strong differentiation but creates technical debt that must be monitored.
By making this breakdown explicit, the functional analysis allows the project management to make decisions with full transparency.
The document's function according to the project method
- V
- Cycle: the functional analysis is frozen before the technical design and serves as a contractual reference for configuration (paramétrage), developments, tests, and acceptance (recette). Each validation step relies on it.
- Agile: the analysis defines the "high
- level" (grosse maille) scope, expressed in business language and thus functional. It constitutes the starting point for identifying and writing user stories. The document is not frozen but evolves and is enriched sprint after sprint, in line with the priorities defined by the product owner.
The functional analysis is the cornerstone of an ERP project. It describes the context, formalizes the target processes, distinguishes between standard, add-on, and specific (developments), details the business rules, and sets the non-functional requirements.
It is useful to everyone: business functions, consultants, developers, and project management.
In a V-Cycle, it constitutes the stable and contractual reference. In an Agile project, it defines the initial business scope and serves as the basis for creating user stories.
In both cases, it secures understanding, structures dialogue, and guarantees that the implemented ERP will bring tangible value to the company.