Interaction instead of cooperation
Cooperation has been preached as the antidote to the division of labour since the end of Fordism. Unfortunately, however, it remains bloodless and without content as long as the cooperation is not reflected in mutual task definitions. This is often not technically difficult to represent. It is not visible in the expert department’s objectives, the experts must be able to make themselves understood by people who think differently, and the verification of results has the potential to not run so smoothly. This is more convenient in one’s own garden of methods. This is what risks use to their advantage and slip through organisational interfaces.
Numbers-data-facts instead of confessions of faith
The analysis of failures helps one to learn that the border between knowledge and belief strongly depends on the expectation. Naturally, designers and developers expect that their technology functions. In extreme cases, they see its function as proven after a single successful test. Contrary information dissipates quite easily. Risks find it easy to propagate in this fog.
Deviations are detected and the correlated causes determined by a patented procedure.
In evolutionary design, if innovation can develop with in the scope of known paths, this trickle can be kept in the usual riverbed with established methods. One can (and should) think using experience.
Disruptive technology changes pull the rug away from under the feet of experience-based approaches. In such cases, it is unavoidable to think from first principles and to subsequently act radically. This is unconventional and uncomfortable as the results of thinking are often different to what one expected. But it is healthy, keeps us awake and is very efficient because risks and failure mechanisms introduce themselves much faster than they can be reproduced in practice.
When levels of confidence are low, one can still follow the stony path of experience and analyse a series of mishaps during test operation to determine how the system works in details and where its weak points are. This is, of course, unbeatable, but if time is limited, a large portion of the problems should be thought through and the tests used to answer questions concerning the unknown unknowns.
Failure-affinity instead of failure-aversion
Reliability problems and downtimes normally occur at multiple locations in the development chain. They are then gladly talked down, explained away, or ignored, which is easy to do as the tests are excessively tough, and prototypes have to be used as units under test, and the test bed probably had a problem, etc. Of course, this is all possible, and these things need to be considered in each activity, eliminated, and monitored. Otherwise the weak points wander with the development process into the next generation, and after SOP to the customer, where they appear as production fault.
These aspects are built into the software suite architecture of Uptime SOLUTIONS. They provide the organisational foundation that is necessary to attain the highest reliability achievable with the test results, system monitoring, and analytics.
