If you like spending time in the kitchen, test your skills by translating something you’re familiar with into a process model. You’ll need to be objective and not rely on inside knowledge – just follow the instructions even if you can see better ways of doing things. That comes later.

If you don’t cook then completing the exercise will  demonstrate that even without being a subject matter expert you can use a methodology to accurately document a process. Again, your first job is to accurately interpret the process description.

You’ll be using data flow diagrams (DFDs),  the simplest of all diagramming languages. If you’re unfamiliar with DFDs, check out How To Draw Data Flow Diagrams. For those of you already comfortable with this modelling notation, parts B and C of the exercise test your skills in showing/hiding complexity through levelling. We’ve included example answers for all 3 parts if you get stuck. Bon appetit!

Click here to go to the exercise.

If you enjoyed this articles you might also like the following:

How To of Essential Modelling

Modelling and Your Next Interview

How To Draw Data Flow Diagrams

The post Process Modelling 101 appeared first on IRM Training.

Data Flow Diagram – a process modelling tool

• Data flow diagrams (DFD) show how the functions, or processes, of a system relate to each other via the data that flows between them. They are most valuable in showing ‘what’, (the logical view) but can also be used to show the ‘how’ (the physical view).
• Data flow diagrams can be used to model the processes in a current system and, separately, a proposed new system. In addition they can show either physical or logical views.
• Data flow diagrams are not concerned with control or sequence. As a tool they are of limited use to designers, but are of greater use to analysts in communicating to the client and to the designers.
• DFDs are levelled so as to reduce the complexity at any one level.

Rules for Drawing a Data Flow Diagram

The four elements used in data flow diagrams are:

Data Flow

• Show the movement of data between processes, into and out of data stores and to and from terminators
• An arrow head indicates the direction of the data flow
• The data must have a meaningful name
• They do not show control

Process

• Indicates a function, this should be a transformation of data
• A functional primitive is the lowest process level

Data Store

• Shows data at rest
• May be manual or automatic accumulation of data

Terminator

• Shows the originator and/or receiver of the overall system data
• Represents people, organisations and systems just beyond the scope of the system under study
• Marks the boundary of the model
• Only appear in the highest level DFD – usually the context diagram

Download the PDF version of this guide to DFDs: How To Draw Data Flow Diagrams

If you enjoyed this article, you may also like:

There’s More to Modelling than Runways and Catwalks

Event-Based Analysis & Modelling

Process Modelling 101

The post How to a Draw Data Flow Diagram appeared first on IRM Training.

In the fashion industry, models are used to communicate (to bring to life) a designer’s ideas and creations. But they also go one step further – helping us the consumer to imagine how the clothes might look like if we were wearing them.

Models in business analysis perform a similar role, they stimulate our imagination so that we can analyse problems, explore solutions. The case for modelling is neatly summed up in this quote from the book Business Analysis Techniques: 72 Essential Tools for Success:

Models reveal the inconsistencies, loops, delays and bottlenecks involved in a process. A systematic analysis of “as is” process models provides a business analyst with the opportunity to think analytically and creatively about what the organisation really needs to do to achieve a better “to be” solution.

Modelling is one of those timeless techniques that transcends business analysis and is used in virtually every discipline from Accounting to Zoology – in between there’s engineering, design, construction, research, etc. Incidentally, accountants use modelling techniques to analyse financial data, zoologists use modelling techniques to analyse, amongst other things, animal behaviour.

Just as accountants and engineers have specific modelling techniques which are used across their respective professions, so too business analysis. But this article is not about which technique should you use – there’s plenty to choose from – it’s more about what are you trying to achieve.

So what are we trying to achieve? It boils down to two things. First what’s the problem – what’s wrong with the “as is” system? To get to the bottom of this we need some dialogue with the stakeholder. If the problem is well documented and understood then great – but often as not the stakeholder will only see the problem from a particular perspective. It’s up to the analyst to dig below the surface and find out the real cause.

Here you’ve got two choices, write a step by step description of the process under investigation – or draw a process model. Which do you think is easier and more likely to draw out the inconsistencies, loops, delays and bottlenecks in the current process? And a (very important) by product of doing the latter is you get to work collaboratively with the stakeholder rather than them dictating and you taking notes. And you don’t have to be the artist – take every opportunity to hand the whiteboard marker to the stakeholder and say “can you draw that for me?”

The second of our objectives is to decide what the “to be” system will look like. Modelling again offers a rich choice of options. It might be as easy as modifying an existing “as is” diagram or as liberating as asking draw me a picture of what you’d really like to see happening. Very few people would say they can’t understand the following diagram:

A final world on models – they can also clarify the often confusing steps in the business analysis process. Whether your project is agile, iterative, waterfall or a mixture of all of these, they all have the same objective…

…to reach an end point and produce a deliverable.

If you liked this article, you may also enjoy these:

Event-Based Analysis & Modelling

Stakeholder Communications – Pictures not Words

Data Modelling & Object Oriented Development

The post There’s More to Modelling than Runways and Catwalks appeared first on IRM Training.