In IT, we used to be good in communicating, as long as we could do the techno-lingo and preferably between peers in our domain of expertise. However, these days IT is expected not only to talk to everybody in the IT organization, but also to the "other side", the business.

It is always a challenge to understand each other when explaining requirements so everybody perfectly understands them. If you have doubts, try the following test: say a relevant sentence of 15 words to a colleague. Have him or her repeat that sentence to another colleague and so on. The more colleagues involved, the more likely the final sentence will no longer express the initial message.

Everybody interprets what is heard and builds on this perception to give the sentence meaning and purpose. And, as we all know, IT involves many people. To complicate things even more, involved people don’t necessarily speak the same language or are IT agnostic (or worse).

But the human race has an instinct for survival. Inventive as we are, we create answers to questions. If the questions are profound, we translate them into something usable for everyone. ITIL and COBiT are examples. These frameworks introduce a unified language, a way of understanding unambiguously. However, there still are challenges developing concise and supportive documentation.

Let’s take the example of process documentation. One of the challenges faced is to put talking on paper without creating a massive 100-plus page document of activity descriptions and procedures. This result makes the documents hard to maintain, difficult to use and even more difficult to distribute. They also lose the communication value and become another piece of shelf ware.

BPMN

During the 2006 itSMF conference in the Netherlands, HP’s Jeroen Bronkhorst announced the usage of business process modeling notation (BPMN) to visualize and describe the processes in ITIL v3. As it was new to me, I dived into the BPMN as it appealed very much to me. Why? Because:

• It is easy to use.
• It is a simple graphical notation format. 
• It is an open OMG standard and widely supported. 
• It evolves―currently version 1.1 is out, and version 2.0 is almost there.
• There are many tools which use BPMN as a representation layer of processes, both freeware and payable.

Without going into theoretical details, BPMN can be used in three distinctive ways. They are:

• Descriptive modeling―focusing on the documentation aspect of modeling.
• Analytical modeling―focusing on the process performance analysis. 
• Executable modeling―focusing on the application code creation.

Descriptive modeling is ideal for the creation of process documentation, because it uses the basic functionalities of BPMN, yet is rich enough to provide a complete notation set for modeling any process.

Obviously, a supporting tool is needed, but you don’t need to search long to find something that fits your needs. But before you go surfing the web, some ideas to consider. Think of the challenges experienced managing your current processes documentation:

• Do you have difficulties distributing the material?
• Do you need a layered approach to structure your processes?
• Do you find the purchase of tools too expensive in these harsh economical days?
• Are you fed up consolidating information from numerous sources into one tool, which is time consuming to create and difficult to maintain?
• Is there a need to simulate processes?

In IT, we used to be good in communicating, as long as we could do the techno-lingo and preferably between peers in our domain of expertise. However, these days IT is expected not only to talk to everybody in the IT organization, but also to the "other side", the business.

It is always a challenge to understand each other when explaining requirements so everybody perfectly understands them. If you have doubts, try the following test: say a relevant sentence of 15 words to a colleague. Have him or her repeat that sentence to another colleague and so on. The more colleagues involved, the more likely the final sentence will no longer express the initial message.

Everybody interprets what is heard and builds on this perception to give the sentence meaning and purpose. And, as we all know, IT involves many people. To complicate things even more, involved people don’t necessarily speak the same language or are IT agnostic (or worse).

But the human race has an instinct for survival. Inventive as we are, we create answers to questions. If the questions are profound, we translate them into something usable for everyone. ITIL and COBiT are examples. These frameworks introduce a unified language, a way of understanding unambiguously. However, there still are challenges developing concise and supportive documentation.

Let’s take the example of process documentation. One of the challenges faced is to put talking on paper without creating a massive 100-plus page document of activity descriptions and procedures. This result makes the documents hard to maintain, difficult to use and even more difficult to distribute. They also lose the communication value and become another piece of shelf ware.

BPMN

During the 2006 itSMF conference in the Netherlands, HP’s Jeroen Bronkhorst announced the usage of business process modeling notation (BPMN) to visualize and describe the processes in ITIL v3. As it was new to me, I dived into the BPMN as it appealed very much to me. Why? Because:

• It is easy to use.
• It is a simple graphical notation format. 
• It is an open OMG standard and widely supported. 
• It evolves―currently version 1.1 is out, and version 2.0 is almost there.
• There are many tools which use BPMN as a representation layer of processes, both freeware and payable.

Without going into theoretical details, BPMN can be used in three distinctive ways. They are:

• Descriptive modeling―focusing on the documentation aspect of modeling.
• Analytical modeling―focusing on the process performance analysis. 
• Executable modeling―focusing on the application code creation.

Descriptive modeling is ideal for the creation of process documentation, because it uses the basic functionalities of BPMN, yet is rich enough to provide a complete notation set for modeling any process.

Obviously, a supporting tool is needed, but you don’t need to search long to find something that fits your needs. But before you go surfing the web, some ideas to consider. Think of the challenges experienced managing your current processes documentation:

• Do you have difficulties distributing the material?
• Do you need a layered approach to structure your processes?
• Do you find the purchase of tools too expensive in these harsh economical days?
• Are you fed up consolidating information from numerous sources into one tool, which is time consuming to create and difficult to maintain?
• Is there a need to simulate processes?

In IT, we used to be good in communicating, as long as we could do the techno-lingo and preferably between peers in our domain of expertise. However, these days IT is expected not only to talk to everybody in the IT organization, but also to the "other side", the business.

It is always a challenge to understand each other when explaining requirements so everybody perfectly understands them. If you have doubts, try the following test: say a relevant sentence of 15 words to a colleague. Have him or her repeat that sentence to another colleague and so on. The more colleagues involved, the more likely the final sentence will no longer express the initial message.

Everybody interprets what is heard and builds on this perception to give the sentence meaning and purpose. And, as we all know, IT involves many people. To complicate things even more, involved people don’t necessarily speak the same language or are IT agnostic (or worse).

But the human race has an instinct for survival. Inventive as we are, we create answers to questions. If the questions are profound, we translate them into something usable for everyone. ITIL and COBiT are examples. These frameworks introduce a unified language, a way of understanding unambiguously. However, there still are challenges developing concise and supportive documentation.

Let’s take the example of process documentation. One of the challenges faced is to put talking on paper without creating a massive 100-plus page document of activity descriptions and procedures. This result makes the documents hard to maintain, difficult to use and even more difficult to distribute. They also lose the communication value and become another piece of shelf ware.

BPMN

During the 2006 itSMF conference in the Netherlands, HP’s Jeroen Bronkhorst announced the usage of business process modeling notation (BPMN) to visualize and describe the processes in ITIL v3. As it was new to me, I dived into the BPMN as it appealed very much to me. Why? Because:

• It is easy to use.
• It is a simple graphical notation format. 
• It is an open OMG standard and widely supported. 
• It evolves―currently version 1.1 is out, and version 2.0 is almost there.
• There are many tools which use BPMN as a representation layer of processes, both freeware and payable.

Without going into theoretical details, BPMN can be used in three distinctive ways. They are:

• Descriptive modeling―focusing on the documentation aspect of modeling.
• Analytical modeling―focusing on the process performance analysis. 
• Executable modeling―focusing on the application code creation.

Descriptive modeling is ideal for the creation of process documentation, because it uses the basic functionalities of BPMN, yet is rich enough to provide a complete notation set for modeling any process.

Obviously, a supporting tool is needed, but you don’t need to search long to find something that fits your needs. But before you go surfing the web, some ideas to consider. Think of the challenges experienced managing your current processes documentation:

• Do you have difficulties distributing the material?
• Do you need a layered approach to structure your processes?
• Do you find the purchase of tools too expensive in these harsh economical days?
• Are you fed up consolidating information from numerous sources into one tool, which is time consuming to create and difficult to maintain?
• Is there a need to simulate processes?

Layer 1: Graphical BPMN representation covering the high level process overview. This level answers questions like: How do we do what we do? What are the generic steps involved?

Layer 2: Graphical BPMN representation covering the procedures for each previous step including the role responsible to execute. This answers questions like: Who does what? How do we interact with each other to make it work?

Layer 3: Textual representation including the details of the previous step. This is known as work instructions, answering questions like: What is expected from the person executing this procedure? How is the supporting tooling used to support this procedure?

This layering is a very convenient guiding element when walking through the process documentation. You can see layer one and two as your table of contents. It allows you to drill down to the information. Modeling is usable for streamlining all types of communication: in projects, in development, in operational situations. So, the most important question remains: Is it usable for you?

If you understand your business completely, your business is totally in sync with the IT service offering, and all of this is formalized in easy-to-use and updated documentation, don’t bother. If there are gray zones or even fundamental gaps, you should give descriptive modeling using BPMN a closer look. For many, it is a gem waiting to be discovered. You will be surprised how it will improve the communication capabilities in your organization. Want to find out more? Here is a first step: http://www.bpmn.org/.

Eddy Peters is a senior ITSM consultant as CTG, an international information technology (IT) solutions and services company, he has been active in IT for almost 20 years, acquiring experience in both support and delivery capabilities. He had the opportunity to dig into the ITIL v3 framework early on, being beta reviewer, and to understand its potential. As ITIL Service Manager and COBiT Foundations certified, he currently develops solutions and provides guidance to customers, integrating their operational capabilities and service development requirements.