Meeting standards even without development processes?
Since ISO 9001:2015, exclusions from standard requirements are no longer possible. But what to do if the standard requirement is not applicable after a development process in the company? It depends on the details.
With the revision of ISO 9001:2015, the requirement for a development process (chapter 8.3) has also been revised. While the sections "Planning", "Inputs ", "Results" and "Changes" - as previously contained in 9001:2008 - have been retained, the sections "Verification ", "Validation" and "Assessment" have been combined into one section "Development Control".
No more blanket exclusions
The general requirement for a development process still exists according to chapter 8.3.1. This is with the aim of ensuring that the subsequent provision of a product or service is fundamentally guaranteed. After the revision of the standard, however, with the essential difference that blanket exclusions are no longer permitted. Here it becomes visible how the risk-based approach is interwoven with the development process.
Whereas previously a company that did not have a development process - e.g. a typical trading company - could exclude the relevant section, this will no longer be permissible in future. In companies that do not carry out all processes themselves, this raises questions and leads to uncertainty.
What's the score?
The solution to these questions lies in the first chapters of the revised standard. In section 4.3, exclusions of entire requirements are excluded, but specific sections can be determined as "not applicable".
The difference between "exclusion" and the "not applicable" provision is:
- "Not applicable" applies to requirements that do not apply to an organization in the first place, z. e.g. a technology is not used for a component, then the requirements regarding this technology are also not applicable.
- exclusions (which are in any case no longer applicable after the revision of the standard), on the other hand, meant that the requirements were applicable and relevant, but that it was not possible for the organisation was free to exclude the requirement, i.e. not to fulfil it.
For the application of "not applicable " the standard also specifies the following condition: "Conformity applies only if the requirements determined not to apply,
- not affect the ability or responsibility of the organization,
- the conformity of their products and services, and
- ensure the increase of customer satisfaction.
Responsibility in the organization
With the above conditions, the standard thus intends that the company, which wants to apply this process as "not applicable", basically takes activities to maintain the capability of its products and/or services unimpaired nevertheless. That is, the responsibility over the above conditions remains with the organization. Accordingly, it must be ensured that the development work necessary for them actually takes place systematically (is specified, initiated, commissioned and operated). This is to counteract the risk or danger that the product or service is impaired and conformity with regulations, rules and laws is not ensured. This can also have a negative impact on customer satisfaction and stakeholder expectations in the medium and long term.
"The general requirement for a development process still exists as per section 8.3.1."
And, as you might expect, when applying "not applicable" cases, the standard requires that the above condition be is justified, documented and thus verifiable.
Conversely, the obligation to provide evidence also means that if the evidence cannot be provided despite the application of the "not applicable" classification, the standard requirement is not fulfilled. The consequences can then be: Elimination of the deviation through the introduction of a development process, the subsequent documentation/evidence of the requirement or, in the unlikely event, abandonment of the provision of the product or service.
Guiding questions for practice
If the decision to apply "not applicable" still seems too technocratic, you can alternatively be guided by the following two questions:
- – Is the requirement to establish, formulate, implement and maintain a development process relevant and applicable?
- – Does this requirement (or non-compliance) affect your ability or responsibility to ensure the conformity of your products and the enhancement of ongoing customer satisfaction?
Only if both questions are answered in the negativethe "not applicable" classification for the development process is justified. Even if only the second question is answered in the affirmative, a development process must be established. This is independent of how this norm criterion is assessed by the organisation itself.
With regard to the implementation of the obligation to provide evidence, the organization can, for example, request relevant evidence documents from business partners such as franchisors, suppliers or development partners. These can be, for example, development plans or results on preceding specifications, which are then also audited, for example, in the sense of monitoring and control (reports of supplier audits). Precise and extended descriptions of the intended purpose can also be worked out jointly. In addition to the risks/hazards of the product or service, this also results in a list of preventive measures to be implemented as proof.
The documents must be able to show that the organization is responsible for the specific products and services so that it has all the information, competencies and resources to fulfil its responsibilities and customer satisfaction remains unaffected. Especially in the manufacturing industry and relevant industry standards, this requirement is already common practice. So-called waterfall, V-models or agile process models are often used for this purpose.
Considering the changing environment
The longer the planning horizon for a product or service, the sooner a change in the products and services must be considered (continuous reassessment). This states another principle. The more likely it is that influencing factors will change, the more necessary it is to reassess the product or service and, if necessary, to align it with the new influencing factors. It is - this as a conclusion - good to weigh up whether the two leading questions should really be answered with no and proven accordingly.
Since developments in a changing environment not only prevent risks/hazards, but also represent a differentiating factor in the long term, their omission can mean the impairment of the organization's ability and responsibility. Accordingly, successful companies do not wait until this issue first arises. They invest in development at an early stage and together with partners or use this as an opportunity to do so now at the latest.