[SystemSafety] The bomb again

Thu Oct 10 02:59:05 CEST 2013

As I’ve previously been exposed to the systems dynamics technique in a
‘soft systems context’ I didn't fall out of my chair when I saw it used by
Nancy in the first of her papers on STAMP. Nor was I surprised overly by
the use of a hierarchy of control, again that's drawing on a specific
dialect of general systems theory.

Nor was I trying to make a case for STAMP as a methodology for accident
analysis, though clearly you can use it for that.

To rephrase my question a little, if you accept the thesis that various
sociologists make that you can't divorce the safety of a 'hard system' from
it's organisational context then surely that implies that you should expend
some effort on designing the containing organisational system, or at least
critically reviewing it? And if you do so, then what are the system design
and analysis tools and methodologies that can support you?

Interesting you should mention the hierarchical nature of DB, Alfred
Chandler makes the point in The Visible Hand that the technology of the
railways drove a specific centralised, hierarchical organisational form,
which I imagine DB adheres to. Circling back to nuclear weapons safety
Langdon Winner pointed out in Do Artifacts Have Politics that likewise the
technology of 'the bomb' inherently demands a closed, centralised, rigid,
hierarchical (and profoundly authoritarian) organisation to deal with it.
which sounds suspiciously like the USAF's SAC. When the organisational form
(and politics) departs from that, as happened in the aftermath of the Cold
War you then end up with incidents such as the Doom 99 flight occurring.

I haven't read Perrin's work, I'll add it to my ‘read over summer’ list. :)

On Wed, Oct 9, 2013 at 10:52 PM, Peter Bernard Ladkin <
ladkin at rvs.uni-bielefeld.de> wrote:

> On 10/8/13 7:43 AM, Matthew Squair wrote:
>
>> Isn't the question of whether you trust their efforts really a variant of
>> the agency dilemma? And
>> isn't that what 'design' of the socio-technical system should address,
>> and what a methodology such
>> as STAMP can assist you in doing?
>>
>
> Well, I bet some System Safety List old hands are chuckling to themselves
> at this one. I'd hate to disappoint........
>
> Let's stick with accident analysis. We have our own method for causally
> analysing accidents, called WBA. It is used in certain large German
> companies, and of course Causalis uses it for clients who wish for causal
> analyses.
>
> WBA does not have an inbuilt method for classifying
> operator/organisational/**society/legal/governmental (OOSLG) factors as
> such. We use the PARDIA classification for pointy-end activities and use
> decision-theoretic analyses (Rational Cognitive Modelling) for multi-agent
> interactions. WBA does determine where any OOSLG factors are present and
> those that are not addressed by PARDIA and RCM I like to leave for the
> organisational scientists such as Downer and Perrow.
>
> Two hundred fifty years ago, David Hume proposed two characterisations of
> cause which have persisted. One is the constant-conjunction criterion
> (CCC), beloved of those who collect statistics on repeatable events, for
> example the superb recent work of Judea Pearl and colleagues. The other is
> the counterfactual criterion, which WBA uses in a form called the
> Counterfactual Test (CT). Almost all conceptions of causality in the
> scientific, engineering and philosophical literature are one or the other
> of these. CT is used in an intuitive fashion by more or less all aviation
> accident investigations, and it occurs explicitly in the USAF guidance for
> aviation accident investigation. It should be more or less obvious why this
> is so - commercial-aviation accidents are not events which repeat in a
> manner in which CCC can address. (In contrast, CCC *obviously* helps with
> road safety, because road accidents happen with appropriate frequencies for
> CCC techniques to be useful.)
>
> Ten years ago, Nancy announced that she had a new conception of causality,
> which was embodied in STAMP. I saw, and continue to see, a problem in
> redefining a concept which has had a good and productive run in science for
> three centuries (if not two and a half millenia). It could well be that
> this new concept is a very useful concept; it could be very helpful in
> identifying areas of interest in accident investigation; indeed, judging by
> the interest in STAMP I imagine many people think it is. But why not choose
> a different word for it?
>
> We had a discussion on the York list. It wasn't scientifically very
> fruitful (but I do remember fondly - and repeat - a particular piece of
> repartee).
>
> People who like STAMP could *obviously* use WBA for parts of what they do
> - the two methods are compatible. And they would see the same advantage as
> other WBA users. The only hindrance to such practice is use of the word
> "causal" for two different concepts.
>
> The other thing about using STAMP is you have to buy the model. Now, I'm
> sure it is helpful, because the people developing STAMP are very smart and
> very dedicated and have been at it for a decade. But is the model right?
> One might well be able to persuade engineers that the STAMP
> social/organisational model is the bee's knees, but it is a quite different
> matter to persuade the experts in those things, the organisational
> scientists.
>
> Constance Perrin wrote a book in which she investigated some incidents at
> nuclear power stations and came to the conclusion that there was a tension
> between the way the plant was conceived to work organisationally and the
> architecture of plant operations impregnated in the minds of the operators,
> who came mostly from the "nuclear navy", which had/has a modus operandi
> completely different from the intended plant-operations architecture. A
> crucial insight. It is not obvious to me how a STAMP analysis would lead
> you to the same conclusion. (Maybe a good project to try?) That is why I
> prefer to leave these matters to the organisational theorists (despite
> their insistence upon using a language whose syntax and vocabulary is
> identical with those of English but whose semantics appears to come from
> Alpha Centauri).
>
> Ten years ago, some colleagues in Braunschweig compared analyses of the
> same accident (the Brühl derailment) using WBA and using STAMP. STAMP
> identified a lot of organisational features of the Deutsch Bahn (German
> railways, as it then was; now it's DB). STAMP likes to see feedback, but
> the DB, like many German organisations, is hierarchical and STAMP wanted to
> see cycles where things were acyclic. It wouldn't have been helpful,
> because, well, I guess you could try to tell DB to change things, but they
> would say "we have been doing it like this for over a century; here are the
> reasons we do it this way (giving you the very thick history book); it has
> evolved so and it more or less works; and if we change it to something new
> we are likely to introduce weaknesses which we won't know about until we
> start having accidents because of them." And, you know, that's not a bad
> set of reasons: you don't change things that aren't really broken, even
> when a major scientist redefines "broken" for you. (In contrast, they are
> happily adopting WBA through third-party recommendation and training.)
>
> All of which is not to say that we indulge heavily in NIH round here.
> Indeed, there was a major STAMP workshop recently put on by colleague
> Schnieder in Braunschweig, which generated a lot of interest. That's very
> welcome - as Nancy says, the important thing is thinking hard about hazards
> and accidents and using whatever help you can get.
>
> PBL
>
> Prof. Peter Bernard Ladkin, Faculty of Technology, University of
> Bielefeld, 33594 Bielefeld, Germany
> Tel+msg +49 (0)521 880 7319  www.rvs.uni-bielefeld.de
>
>
>
>
>

-- 
*Matthew Squair*
MIEAust CPEng

Mob: +61 488770655
Email: MattSquair at gmail.com
Website: www.criticaluncertainties.com <http://criticaluncertainties.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20131010/48297f0b/attachment-0001.html>