What is IDEF0?

I’ve refered to IDEF0 in a number of posts.  Its time to explain what I mean.

IDEF stands for Integrated  DEFinition and the zero is there to distinguish this functional process modelling from the other tools in that tool kit.  It was originally intended to define manufacturing processes but it works for human work too.

Why do I talk about IDEF0 so much? It is very useful to get a quick diagram that explains a process like  a black box rather than a narrative of how to do it. You see what is done, what is changed and what is used to do it. It frees people from historic methods of doing things because you can focus on what happens and why those actions are needed (leaving the how to be resolved at another time). Outcome: I simplify and improve organisations using it.

People understand IDEF0 very quickly and it is so simple to explain – here’s my script:

Imagine this part of your job as a magic box that gets it done {draw a rectangle in the middle of a piece of paper}

What comes out of it? {for each answer draw a horizontal labeled arrow coming out of the right hand side of the box}

What do you need to come to you from other processes to get it done {for each answer draw a horizontal labeled arrow coming into the left hand side of the box}

What mechanisms, resources and tools do you need? {for each answer draw a vertical labeled arrow going into the bottom of the box}

What measures and controls do we have at the start of the process? {add a vertical labeled arrow going into the top left of the box}

What measures and controls do we have at the end of the process? {add a vertical labeled arrow going into the top right of the box}

Are there any measures and controls in the middle of the process? {add a vertical labeled arrow going into the top middle of the box}

With a few notes on the back of the sheet about business constraints, business rules or decision guides and data requirements you have a one page description of a process. It is concise and easily understood – the ideal process description.

These steps also help to:

  • find things that are produced for no reason
  • identify processes that might not be needed
  • discuss quality of the inputs to the process
  • consider missing controls or measures
  • identify over-engineering in other processes or from suppliers

More information IDEF can be found at http://www.idef.com/


About 3triangles
Helping organisations make change happen in 3 key areas: strategic change, deliver tactical impacts, efficient and effective processes. All blog content (c) 2009 - 2012 Carol Long and Three Triangles Performance Ltd

4 Responses to What is IDEF0?

  1. steve h says:

    I have just spent a couple of evenings reading INTEGRATION DEFINITION FOR FUNCTION
    MODELING (IDEF0) 1993. I am intrigued. A small set of simple elements rigorously applied can result in a simple picture of a complex things. RIGOR seems to be a big part the IDEF0 publication. I am not clear that the approach you define aligns with the method of the IDEF0 publication or will produce the fascinating results I have seen in a couple of examples I found on line. I am also struggling to understand nuances of the semantics e.g. what distinguishes an input from a control? is the activation of a function found in the input or in the control or possibly in both? The publication clearly states that a function requires a control and an output as a minimum so I am not sure if some examples I have seen adhere to the letter of IDEF0. I am also a bit puzzled that there appears to have been some user group energy around this a few years ago but I see little or nothing in the way of current activity. Why hasn’t this become a bigger item? Do you have any suggestions as to how a person (quaintly referred to as a “non-automated system” in the publication) might get some guidance today?

    • 3triangles says:

      IDEF0 did have quite a bit of momentum behind it in the 1990s and, from my perspective, this seemed to have been diverted when the companies promoting it either ran into difficulties or got distracted into other things, including Agile and Use Cases.

      The approach I use is a variation. My motivation is not to abandon rigour but to facilitate communication.

      To clarify (I hope):

    • an input is something that goes into the process and is either transformed, consumed or used as a catalyst.
    • a control can be approximated to a “test” or “measurement” applied as part of the process
  • Tom Creighton says:

    The rigor associated with IDEF0, along with its simplicity is, as you have seen, the real strength in the technique. Of course, it is sometimes useful to put together a model that is quickly expressive, even if it lacks the rigor one would like. To your questions of control vs. input, this is a common question. In order for an activity (function) to fire, one must have an enabling trigger. This is the required control. Inputs are typically distinguished from controls by observing that the former are transformed into outputs, or possibly consumed in the activity. Thus, if “Create Fire” is the activity, an input might be fuel, a mechanism might be a match or other ignition device, the output is light and heat, and the control is oxygen. Of course one can view it slightly differently, but this is an example I like to use.

    • 3triangles says:

      Thanks for your comment Tom.
      I’m not sure I’d see oxygen as a control because it is used/ chemically transformed as part of “create fire”.
      I agree with your explaination of the test of hat is an input and what is a control.

  • Leave a Reply

    Fill in your details below or click an icon to log in:

    WordPress.com Logo

    You are commenting using your WordPress.com account. Log Out /  Change )

    Twitter picture

    You are commenting using your Twitter account. Log Out /  Change )

    Facebook photo

    You are commenting using your Facebook account. Log Out /  Change )

    Connecting to %s

    %d bloggers like this: