ASM Modelling

(Login)

This section describes how to build a model using the ASM approach

These hints and tips reflect ASM used as a graphical diagramming language. This is a precursor to applying the  ASM simulation.

1. Initial knowledge elicitation (preliminary stage)

We have found that the easiest way to construct a process model is to begin with pencil and paper, where it is easy to get an overview and very quick for multiple modellers to work together to create and connect elements.

A good method is to hold a mapping workshop with 2 or more domain experts (ie, people who participate in the process and have a reasonable overview of it). Ask them to identify key tasks and write them onto small post-it notes, then build up the model gradually by locating the tasks on a grid (swimlanes representing different business functions down the page, with time roughly increasing along the page - eg. in 6 week blocks). We use post-it notes cut into different shapes for the tasks and deliverables, and position them on a grid drawn on a large sheet of plotter paper - or on multiple flipchart sheets taped together. Draw lines onto the sheet with a pencil to represent dependencies, and either decide the scope in advance or let the swimlanes emerge as you go along and 'discover' the process. About 2-4 hours of this is usually sufficient to capture the main structure of the process.

Then, the model can be transcribed into CAM and later iterations performed in the software, where it is easier to make changes. If more workshops are required, we print the model on large sheets of plotter paper and annotate it using pencils in the next session. We try to get more people for second and subsequent sessions, to get a broader point of view. Or, ask people to critique the print-out individually. After each iteration, we transcribe the results back into CAM. While doing this, we sort out problems (such as missing connectors etc) that were introduced into the emerging model, where the model as represented on paper differs from the way it was discussed during the session.

Its usually possible to create a good picture of a process in only a few sessions. It is a good idea to get some preliminary estimates of numeric data in the second session, if you are planning to run simulations. (at the start of the second session, start by validating the structure as transcribed into the CAM model, then ask for estimates of the numeric data). Ask what the duration of the tasks are, and the probabilities of failure for decision gates - and whether these values would be different on second and subsequent iterations. When modelling iterations, try to identify which tasks would be repeated; this gives more information than just 'pointing an arrow back' and can be helpful for validating later.

2. Modelling in CAM (second and later stages)

  1. Create a 'conceptual structure' first. When creating a large model, it's helpful to hold a conceptual 'picture' in your mind of how it will be organised. Will there be key 'stage-gates' or other review points where iterations feed back from? Will the model be structured into swimlanes? This will help structure the knowledge elicitation and lay out the diagram as you go along. You may need several iterations before arriving at a suitable structure.
  2. Decide on naming conventions. When there are many tasks and deliverables, its useful to name them in a consistent way across the model.
  3. Don't be afraid of creating large models. The software will work reliably even with very large models; many hundreds of nodes on a single worksheet. Being able to create such models without the software slowing down significantly is one of the strengths of ASM in CAM.
  4. Use hierarchies appropriately. Appropriate use of hierarchies in process modelling depends on the structure of your model. If a model includes a clear flow but a lot of cross-talk between items, it might be best to use the 'view subprocesses in the same sheet' mode, so all the crosstralk can be easily visualised, In this case we recommend keeping the number of nested levels on a worksheet relatively small. Diagram elements can be used to help organise the model (rectangles, swimlanes and text boxes - which can be created using the tools on the bottom toolbar). On the other hand, other models may be easily decomposed (for instance into successive stages that do not interact with their predecessors, or into nested iteration loops). These cases might be better broken down into nested subprocesses, modelled using the 'view subprocesses in new sheets' mode. However, when using this mode it can be difficult to get an overview of a model if many nested levels of hierarchy are used, and many connections across subprocesses are difficult to model. You can switch between these modes using the toggle button on the top toolbar while viewing an ASM model. Note they only affect the display and can be interchanged seamlessly - but a model you have laid out for one mode is not likely to display well with the other. It may be best not to use sub-processes at all - just lay everything out on one sheet. We recommend you try this first, until the size of the sheet becomes unmanageable.
  5. Lay models out left-to-right. When you print out the model, it will be easy to lay out on the desk (laying out top-to-bottom creates a long vertical 'scroll' which is difficult to read!)
  6. Use the 'multi line' option in deliverables. When editing a deliverable's properties, clicking the multi-line button allows you to add multiple info/material items to one ellipse. Each item appears on a separate line in the deliverable - saving space on the diagram.
  7. Use the 'optional flow' option for dependencies. Right-click a dependency (arrow) and use the option to distinguish between flow and data dependencies (explained above). This can be used to highlight the important information and to indicate the main route through the process and is very useful for simplifying models for simulation, without impacting the description.
  8. Use compound tasks and iteration constructs correctly. Green diamonds should be used to represent tests that can lead to rework. The 'iterate again' scenario should only be used to branch backward. Red boxes, on the other hand, represent selection between two or more alternative routes forward.
  9. Use hyperlinks to simplify flow. Hyperlinks allow an edge to be 'broken' into two segments, linked by a bi-directional port (circle). This can be useful to simplify the diagram if a feedback (or feedforward) edge has to cross a long distance or cross a lot of other edges. Double-clicking a port 'flips' the display to the other end of the hyperlink. Each port is numbered, allowing the ends to be 'matched up' on a printout.