Design scalable solutions
The right supply chain solution is rarely found on a shelf in a box which is purchased, installed and delivers your organisation the right results within budget. As each organisation has unique processes, specific financial reporting standards and a range of documentation requirements, reaching the final design involves a lengthy process and is reliant on a number of factors. Although the implementation phase is more prone to failure due to the visible impact on the business, the success rate of the project can be increased by managing the design phase closely to minimise or eliminate project specification creep. Following is a typical framework structure we adopt:
Business Requirements Document
The business requirements documentation set is developed and forms the baseline of what the business is seeking to achieve from a business solution perspective, it does not focus on how it will be designed from a technical perspective. We use this document to also ensure that there is clear allignment with the project scope, planned deliverables, timeline, project methodology and structure as outline in the project charter.
This requirements document should be compiled by business stakeholders, subject matter experts, external stakholders, PMO and any other relevant teams that can contribute to the formation of a clear and total business solution. The content needs to be at a level that is supported by business process mapping that details relevant inputs, outputs and metrics that are constantly monitored and measured by the business. These business process maps must capture the "Current state" and any "Future State" alternatives to complete the business requirements document pack. In summary, the core components of the business requirements documentation set include:
- Project charter(Alignment) - Project scope, Project deliverables, project methodology, structure and budget parameters
- Process mapping - Current state and future state alternatives
- Project risks, constraints, mitigation planning
- Reporting structure - Status reporting, Operations review
- Project plan - milestones, achievements, delays.
- Compliance - Sign off protocols and change requirements authorisation.
Functional Requirements Document
This is a detailed plan of what is required to be developed and how it is to be developed. The business requirements document is translated into a design brief that details the solution, the look, feel and operational aspects by a team of resources that include busness analysts, developers, project managers, test script developers and possibly trainers. Each field on a screen will be detailed, the steps taken to complete a transaction, data flow and interface mapped along with data management and report creation. The functional specification should be detailed enough to be converted into training materials for user acceptance testing. These can include:
- Screen display, look and layout
- Data sets, type and mode of capture
- Workflows to support the system
- Interfaces requirements
- Reporting requirements or other forms of output
- Regulatory and compliance requirements
- Security management and controls within groups to user level
In complex projects where a number of hardware and software vendors may be required, the overall process of vendor selection should be standardised and based on specificly defined vendor criteria, namely: product suitability, product fit, level of scalability, after sales support, company's financial state, project methodology and experience of the team.
The design environment will require management and coordination to establish the correct platform for designing the final product. This is typically set up at the vendors premises as all resources are readily available. In complex projects, a level of integration may be required between multi vendors systems where either transactions or documents are created and need to flow to the interfaced system.
Design standards are strict and are predetermined by the programming language used to create the customised solution. Forms or documents can vary as these are not usually part of the source code and require verification.