Requirements management is particularly important where complex products or systems are designed or where their development is in progress. The goal of requirements management is to achieve a common understanding of a system to be developed between the contractor and the client. At the same time, the resulting documents often serve as a contractual basis for further implementation. [See Wikipedia: Requirements management]
In the sense of a holistic approach, this article is about how the topic of requirements management can be treated in process4.biz on the basis of documented processes (the existing company documentation, defined target processes or e.g. process reference models).
Within the context of documented processes?
It is not without reason that process models have established themselves as an important tool for graphically documenting the structures and processes of a company, including their interdependencies and links between them.
Among other things, they serve to document the
- Organizational structure (positions/roles)
- IT landscape
of a company and thus make transparent how a process is handled, who is responsible for, involved in or affected by it and what is required for it in terms of IT resources, documents and information in general.
Reference processes as a starting point
Process reference models represent a special case of documented processes. They can be used to provide support, e.g. by providing the “red thread” through the respective process flows for an industry or ERP system. In this way, for example, you can create the basis for future target processes, or a basis for comparison (i.e. reference) to the actual processes of a company that have already been recorded or documented.
As for the reference models “Industry” and “Microsoft Dynamics” offered by process4.biz, there is a so-called “Business Process Master List” (BPML). The BPML arranges all processes in the respective functional area of a company and is also the central structure for planning, budgeting and controlling ERP projects, as e.g. at YAVEON AG.
Based on the end-to-end processes of the customers, the BPML defines those areas that should be considered in the project or in the solution architecture. The application of the BPML goes far beyond a table of contents, in that it forms the basis of all process validation in a regulated environment (e.g. pharmaceutical industry). For the analysis of business processes and organization, as well as the assessment of potential in the business requirements, the BPML is used integrated to ensure a direct transition from these requirements to their coverage with information technology.
Depending on the application and project, our reference models enable a simple, quick start with regard to the recording and analysis of requirements based on the documented reference processes.
Recording the requirements placed on a system in a process-based manner means that, for the respective process, the following information should be compiled:
- Should this process be covered by the system?
- What are the special requirements for the process?
- Who is responsible for the process, who carries it out?
- Importance of the process (e.g. frequency, costs)?
- Interfaces or dependencies to other processes?
Requirements for the respective process resulting from these questions should be methodically standardized and recorded and documented in a clearly defined form. process4.biz is an ideal tool for this, since the requirements are managed there in a flexibly adaptable database and directly linked to the respective (reference) processes.
Requirements themselves are maintained as independent database objects and described by individually adjustable attributes. Thanks to relational links, they can be put into context and linked not only with processes, but also, for example, with documents, the respective responsible roles, persons or the required IT resources.
A requirement with its attributes
There are many more options available - if required, our tool also calculates the effort (in terms of time and cost that would be required to implement the respective requirement) and aggregates this per assigned process to facilitate decisions based on it (especially individual development/adaptation vs. standard in the course of implementing a system).
Data exchange and tool interfaces
Even if it were perhaps easier and more efficient, the documentation of target processes and the recording of the associated requirements are not always carried out in one work step. Old habits and existing documents can help to create (or continue to exist) parallel worlds that are not very conducive to the process-based approach.
To counteract such tendencies, process4.biz provides easy-to-use standard interfaces for data exchange. Existing lists of requirements can be imported via Microsoft Excel, for example, which converts the information maintained in rows into database objects that can then be reused flexibly. Data export is also possible in this way and can be used, for example, to analyze requirements (including their dependencies within the process model) in the context of business intelligence and data science.
The optional interface to Microsoft SharePoint enables data exchange in both directions. The decisive added value of SharePoint as a “data hub” lies in the fact that even less IT-affine users can easily record and maintain requirements via their web browser without significant training effort, which are then available for further use in the process model. Requirements can thus be recorded by different people, but at the same time as the respective target processes. The corresponding attributes of the database objects (see above) are also available on the SharePoint side and are maintained at the same time.
Maintenance of requirements in SharePoint
SharePoint is particularly suitable as an ideal platform for data exchange when, for example, requirements are to be processed in coordination with external service providers. In addition, corresponding (standard) workflows (e.g. release), version management and comprehensive document management can also be shared in order to centralize project-internal communication in one place.
Graphical representation and modelling
process4.biz can also be used to graphically display the dependencies between requirements and processes (as well as other process model content, if applicable). A basic distinction can be made between two procedures, the automatic and the manual creation of diagrams.
For this purpose, our tool provides so-called dependency diagrams, which automatically generate a corresponding graphical representation according to the existing relationships between the objects (requirements, processes, roles, etc.).
If a particularly structured representation and/or one based on appropriate notations is desired, a suitable template for modelling can be created with little effort. If required, requirements can not only be displayed but also included in the course of the graphical modeling.
The consistency of the data is ensured in every case, i.e. regardless of whether or how they are going to be displayed graphically, by our database and the associated redundancy-free objects (exist only once, but can be reused/instantiated as required).
Publishing target processes
Once the target processes, including the corresponding requirements, have been recorded, the company has a process model at its disposal that is capable of answering all essential information about what, how and with which in the context of each individual process. As mentioned at the beginning, this way the “common understanding about a system to be developed between contractor and client” can be created along the documented processes.
In process4.biz, a variety of reports and evaluation options are available to make the documentation as accessible as possible and to enable further use of the content.
All data available in the process model (incl. interdependencies among each other) can be prepared (preprocessed) on the basis of dynamic queries and thus provide the necessary data basis for automatic document creation or further analysis (e.g. BI use cases).
The preparation of a target process as a compact document is based on different contents (queries, graphics, static texts, etc.) and could be structured like this, for example:
- process description
- process flow (graphically, e.g. as flow chart)
- input / output
- process steps
- roles & responsibilities
Once such a report has been defined, it can be published for each process as often as required (and always with the up-to-date data). The report structure is completely variable and can be easily adjusted in a wizard. The underlying Word template is also fully customizable and is usually based on the customer-specific CI specifications.
The publication of the process model as a website can bring particular added value. The (released) process model contents are published as a consistent, interactive model and are available to (project) employees or external service providers via web browser. Thanks to graphical navigation, search function and context-sensitive links, “the big picture” is made transparent and a central point of contact for obtaining relevant information is created.
If the process model has been enriched with jump functions into the ERP system (or a corresponding reference model has been used as a starting point), the web model is also an interesting training tool that not only provides process know-how but also the corresponding system functions. For a better understanding, user training courses that are purely oriented towards the ERP system can be extended to include the organizational and process context.
Continue using the documentation
The focus of this article so far has been on requirements management in the context of documented processes. However, the (project-related) process model represents - depending on the size and scope of the project - also the current (sub-) process model of the company.
Such a process model can and should be kept up to date as it is a valuable tool for various tasks in the context of the management of a company.
The further use of the process model can have positive effects and create added value in the following areas:
- Change Management
Supporting changes and optimizations of processes
- Roll-Out planning
New locations should understand and adopt the processes of the company
- Training of new employees
Processes and system functions can be understood faster and better by new employees thanks to the organizational-process-related context
- Quality Management
Processes as the basis for internal and external audits
- Process Execution
Workflows and process automation
We would be pleased to demonstrate the procedure described here or the reference models mentioned live in our tool and are available for questions, suggestions and feedback. We also offer consulting services for a concrete implementation in your process4.biz solution. Simply contact us here or via email.
Corporate documentation based on the Industry Reference Process Model
Published on 17.07.2019 | Read in about 7 min
A tool to quickly document the processes in your company based on established methos and best practices.
Integrating ISO 9001:2015 into process4.biz models
Published on 08.04.2019 | Read in about 5 min
ISO 9001:2015 defines requirements for a quality management system and can be mapped in process4.biz as a tool for implementation and certification.