Is it possible to omit soft variables?
Posted: Mon Apr 16, 2001 5:03 pm
At last some sense from Jay on soft variables.
Much of the significant SD work my company (Cognitus) does for clients is
focussed on the identification and significance testing of strategic
variables for which little hard data exists, or where the impact of such
variables is imperfectly understood. The great value of SD, as opposed to
most other forms of modelling, is that it is an open method that enables
real managers to engage in discussion and debate around a structure - and,
in particular, to develop understanding of the real significance of soft
variables. Many SD practitioners, however, seem to be more concerned with
how many angels fit on a pin-head, than in using the methods and tools to
help real managers make decisions in an imperfect world.
There is thus a tendency for managers to think of SD in terms of old style
OR (and hence to compare/confuse it with detailed analytic tools such as
econometrics}, rather than as a powerful and structured method to develop
better shared understanding (however imperfect) of how things really work
in order to improve decision-taking. Another real problem is that SD
practitioners are often perceived - and portray themselves - as modellers.
Nobody disputes the need for competent modelling skills but good SD
practitioners need a wider range of skills, not least the skills to
facilitate diverse management groups and to communicate with them using the
language of SD. This implies that practitioners need to develop the
authority and presence to work at more senior levels, and they need the
confidence and skills to keep things simple. Few, in my experience, have
done so.
Simple SD models that address specific issues often yield much greater
insights (and therefore have more influence) than large, opaque models that
include rigorously defined data structures. Indeed I suggest that a good
objective for any SD practitioner should be to build small models - the
smaller the better, consistent with the perceived needs and realities of the
sponsoring management group.
A particularly good example of this in our consulting work, concerned
helping the managers of a huge North Sea oilfield understand how to add
value to the field over its remaining life through interdependent operating
and capital expenditure policies. A major uncertainty concerned the future
behaviour of the oil reservoir - although the engineers had hugely complex
models and vast amounts of data. In the context of future value, the
management team thought it adequate and appropriate to condense all this
data into one single graphical function in an SD model, and to test the
impact of minor variations on the value outcomes. Having thus identified
where the main sensitivities lay, the team were then able to focus the
detailed reservoir simulators at critical uncertainties. The SD model was
used interactively by the management team as an 80/20 calculator - to
develop shared understanding of the issues, and not as a replacement for
more detailed tool sets.
From: "Richard" <richard@cognitus.co.uk>
Much of the significant SD work my company (Cognitus) does for clients is
focussed on the identification and significance testing of strategic
variables for which little hard data exists, or where the impact of such
variables is imperfectly understood. The great value of SD, as opposed to
most other forms of modelling, is that it is an open method that enables
real managers to engage in discussion and debate around a structure - and,
in particular, to develop understanding of the real significance of soft
variables. Many SD practitioners, however, seem to be more concerned with
how many angels fit on a pin-head, than in using the methods and tools to
help real managers make decisions in an imperfect world.
There is thus a tendency for managers to think of SD in terms of old style
OR (and hence to compare/confuse it with detailed analytic tools such as
econometrics}, rather than as a powerful and structured method to develop
better shared understanding (however imperfect) of how things really work
in order to improve decision-taking. Another real problem is that SD
practitioners are often perceived - and portray themselves - as modellers.
Nobody disputes the need for competent modelling skills but good SD
practitioners need a wider range of skills, not least the skills to
facilitate diverse management groups and to communicate with them using the
language of SD. This implies that practitioners need to develop the
authority and presence to work at more senior levels, and they need the
confidence and skills to keep things simple. Few, in my experience, have
done so.
Simple SD models that address specific issues often yield much greater
insights (and therefore have more influence) than large, opaque models that
include rigorously defined data structures. Indeed I suggest that a good
objective for any SD practitioner should be to build small models - the
smaller the better, consistent with the perceived needs and realities of the
sponsoring management group.
A particularly good example of this in our consulting work, concerned
helping the managers of a huge North Sea oilfield understand how to add
value to the field over its remaining life through interdependent operating
and capital expenditure policies. A major uncertainty concerned the future
behaviour of the oil reservoir - although the engineers had hugely complex
models and vast amounts of data. In the context of future value, the
management team thought it adequate and appropriate to condense all this
data into one single graphical function in an SD model, and to test the
impact of minor variations on the value outcomes. Having thus identified
where the main sensitivities lay, the team were then able to focus the
detailed reservoir simulators at critical uncertainties. The SD model was
used interactively by the management team as an 80/20 calculator - to
develop shared understanding of the issues, and not as a replacement for
more detailed tool sets.
From: "Richard" <richard@cognitus.co.uk>