Modeling and Simulation
December 28, 2013 1 Comment
A friend and colleague reached out yesterday to ask about modeling and simulation tools. Then went on to ask about consistent notations as a desire for the practice he supports. During the span of my career I’ve had to learn various methodologies and notations around BPR/M as both the discipline has matured as well as terminology. During BPR’s big push during the late 70s courtesy of the USAF’s Mantech program I was introduced and became a modeler for an Aerospace firm. Dennis Wisnosky -who led the program- gather a few of us at various prime vendors with the objective of creating a generic model of an Aircraft manufacturer. As part of the program Softech developed IDEF0 a modeling notation / methodology. Today there is more distinction between what is a notation and what is a methodology.
During that same year I had to create various diagrams for systems, IT applications, shop floor processes and manufacturing processes. This demand to learn the latest notation continued till I joined IBM, at which time my employer started sending me to various conference, consortiums and programs to develop methodologies and notations due to the years of build models. Two years ago at a Summit meeting I presented the topic of Accuracy and Precision. Topics that are closely related but as another of my mentors, Harrington pointed out these are different concepts and when building models one should understand a few things:
- The greater the level of detail the more complex and expensive it is to create
- Greater detail does not always translate to greater understanding or the ability to communicate that understanding
Since then when I’m asked about modeling and simulation engagements, the first question I have is what’s the point of the model or simulation? If its to communicate to executives or other people that requires one level of detail; If its a step by step procedure for people to follow that’s another level; and it is for automating a process that’s still another level.
The next question I typically asks is what is the target audience’s level of experience with models and various notations; show typical line of business executives UML just won’t cut it, show programmers BPMN may or may not be helpful as they are often wanting more technical detail than process –though in my opinion that’s a big flaw in logic, as the process gives a programmer context which will help drive better design decision (enter the latest trend to build scenarios and user personas).
Lastly on my top three scoping questions is usually how much time is planned for the activity and due date for the deliverables. With such questions notation and methodologies decisions become a little easier. The only big question left is whether the enterprise as chosen a one size fits all standard or has a taxonomy of notations to use for specific purposes and all those involved have the needed training to use.