Wednesday, 19 September 2018

T34 Poznan (Posen-Ferstung) Poland. Military Capability

When looking at kit like this you start to think about capabilities in a different light. Military analogies and historical case studies help things make a lot more sense to "services" business people, steeped in process thinking, who often struggle with the capability modelling concept. The ability to tackle enemy heavy armour reliably on the Eastern Front WWII , cheaply and in quantity was what made the T34 a capability supporting asset; a war winning weapon for the soviets.  Looking at battle field examples in the field - Poznan Poland-  rather than prepared examples given to the west, (such as those specimens at Bovington (Dorset)) shows the fit for purpose finish in its true form.  The build speed for a T34 was many times faster than its German rivals and the cost many times lower than the iconic Tiger II. Simpler, easier to maintain, cheaper and faster to deploy the technology backed up by a superior production system won the day. T34 Poznan (Posen-Ferstung) Poland.

Thursday, 13 September 2018

Process mapping is not always universally a good thing.

Process management is promoted as the answer to most operational difficulties. Get stuff mapped, understand the measures that deliver what stakeholders required and reduce the variability. Tool vendors "lap this up" and provide repositories and mapping tools to do the job plus add-ons in some cases to create business architectures - great.

Like many things it all becomes, in some cases a bit too much, where the above approach is preached by some as the only way - basically if you don't do this you don't know what your are doing! It becomes simplistic with mantras like " if you can't measure it you can't measure it "," Your standards aren't standards" that doesn't comply with **BPMN 2.0 so it isn't professional process mapping. and so on.

The approach described is probably fine in high volume low variety environments where doing the same thing the same way makes measurement and outcomes consistent. Quality systems require compliance to documented processes and systems; this is all wrapped up in this *BPM paradigm.

However what about environments where the service provided is nearly always different every time a client pulls value? Does it then make sense to map processes and engage the BPM way of doing things. Process mapping implicit knowledge of professional knowledge workers is pretty hard - I have tried a few times over the years and it is a bit pointless as an exercise I can tell you!

So what is the message here?

The point I am making is that  methods and techniques have to be appropriate and just because you are an expert in one method or another don't get drawn into thinking that it is the only way and please stop,  reflect  on what you are saying because some of the evangelism we see in some methodologies today is highly counterproductive.

 AGILE, Six Sigma, Scrum, Prince 2 to name a few candidates for consideration- I am sure readers can think of others where it has all got a bit too much.

*BPM Business Process Management
** BPMN Business Process Mapping Notation Version 2.0.