It’s beneficial to state and have vendors understand your fundamental project objective and procurement goals:
Provide an understanding of all in-scope, start-to-finish business workflows (the “As Is” or “Future State” business processes to be supported by your new software solution) and to what extent current or re-engineered processes have been documented. Provide any documentation that lists process descriptions and business rules or, in the event this is unknown, describe your organization’s willingness and expected process to define these important system design and configuration elements.
Whether your organization chooses to undertake a business process re-engineering (BPR) exercise as part of its business transformation or simply stays the course with its business “as is,” process and business rule documentation can be presented in the form of data models, object models, process workflow charts, or step-by-step grids or tables. A listing of all the distinct and unique workflows to be implemented, including the names of the different business processes, process types and/or workflows, is desired to enable accurate costing.
“Use Case methodology” is a recognized process definition/documentation best practice that lends itself especially well to a regulatory environment, and which will result in documentation that could be readily interpreted by COTS and/or Custom Application Development software vendors as they seek to understand system requirements described in a subsequent RFP.
The Use Case approach is primarily workflow-centric and, therefore, valuable to regulatory agencies undergoing transformation. Ultimately, when the time arrives, up-to-date documentation of your Use Cases will allow software vendors to understand your capability-oriented system requirements in the context of the in-scope business processes that will remain “as is” and those that have been improved through re-engineering.
NEXT WEEK: Your reasons for software system change and your critical success factors.