|
There is a longstanding Lifecycle Unification problem relating to Bills of Material, known in Industrial Engineering circles as the multiple BOM reconciliation problem.
The difficulty is this: any reasonably complex system has not one, but several BOMs, each representing a distinct configuration of the system across its lifecycle (e.g. as-required, as-specified, as-designed, as-built, as-used, as-maintained etc.). These BOMs differ from each other both in structure and in the number and kinds of parts that comprise them.
Identifying and propagating the consequences of even a single modification to one feature of one component in one BOM, to its counterparts in other BOMs for the same system, requires the coordinated expertise of a team of people that span several speciality disciplines such as process, mechanical, instrumentation and software engineering, not to mention quality assurance.
Sound familiar?
|
|
In this message I want to introduce the concept of Quality by Design (QbD) arrays. Since I want to accentuate the positive here, I won’t dwell too long on ‘disarray’, other than to say that it’s a fair description of the current state. We’ve already introduced the concept of System & Component itemization, specification & verification; and if we call these dimensions X,Y&Z, then a basic but powerful calculus emerges, where
X = Σx, Y = Σy and Z = Σz
and
x = + xs + xr + xd + xi + xo + xp + xm + xc + …
y = + ys + yr + yd + yi + yo + yp + ym + yc + …
z = + zs + zr + zd + zi + zo + zp + zm + zc + …
Each of the subscripts corresponds with an episode in our lifecycle continuum, and these are extendable in both directions (you’ve guessed it, the ultimate continuum addresses all aspects of DDML in algebraic format). In the above example, the subscripts relate to specification, risk, design, installation, operation, performance, maintenance, change; but the array is configurable rather than compulsory. Sub-phases can also be accommodated by ‘bracketing’ as required e.g. [design = design_basic v design_detailed] and so on…..
What does all of this do on reality street? Very simply, it means that systems & components are subject of single point of data entry only, with multiple perspectives
(i.e. datasets and protocols) available at different stages of the macro or micro lifecycle. Get it?
|
