Error management - Organization

Error management - Organization

Introduction

The ClassiX® system is developed with high demands on the quality of the applications. In principle, however, software development - apart from the expansion of functionality - unfortunately always involves the correction of errors.

The approach of an object-oriented architecture - the basis for the architecture of ClassiX® - has not least the quality and thus the reduction of errors in mind, for example when talking about the reusability of program code. (In the last consequence, the reusability of program code unfortunately also has the effect of "reusing" program errors).

Extensive quality assurance measures at ClassiX® are intended to prevent errors from interfering with working with ClassiX®. In spite of all care taken, error messages or even program crashes may make it difficult or even impossible to work with ClassiX®.

Support

Therefore, an error management was developed, which is part of the ClassiX®Support model.

Self-help

Some error messages, however, do not necessarily have to be errors that can only be corrected by ClassiX®. Therefore here are some tips on how to proceed:

1. Precise description and analysis of the "fault
2. Testing for reproducibility
3. Search for a workaround
4. Message to Support

1. precise description and analysis of the "fault

The first thing to do is to record exactly WHAT and WHEN something has happened. The WHAT can be done e.g. by making a hard copy, the WHEN by describing what has just been done.

The WHAT may be an error message from this machine, or an "unexpected" result of processing data by this machine. In both cases it is important to know how the situation came about. Therefore please always try to describe immediately what the steps were before the "malfunction".

This approach may help you to recognise that you have done something that has never been done before. A "new" concatenation of entries in the system can lead to the fact that the system does not (yet) know them and therefore cannot process them. Here it has to be checked whether this is desired at all from an organisational point of view or whether it is simply a lack of functionality of the system.

However, precise documentation of the "malfunction" is the best prerequisite for getting help quickly.

2. testing for reproducibility

Please also try to repeat the - exactly described (see above) - procedure at least a second time. Experience shows that a "suddenly it went" has already helped many people.

Without a continuous reproducibility of an error, it is very difficult to find and thus to eliminate it.

3. searching for a workaround

Every mistake is annoying. However, it does not mean that you cannot continue in your work. Please try to continue your work by "other" input steps.

4. message to support

A well-documented and reproducible error pleases every member of the support team, as help can be provided quickly. If you have even reported that you have found a workaround yourself, everyone is happy because there has not been a standstill in the use of the system.