Synthis - Process Modeling Software

Why business leaders need to ask their IT organisations about process

2010-02-12T15:03:11Z

The Financial Times just posted a great new article on process improvement programs in IT organizations. The article specifically calls out ITIL and COBIT. It is a great read for any business owner, process jock, or IT manager who wants a quick introduction into the value standards like ITIL and COBIT bring to an IT organization and to the business as a whole.

The article had a number of great points, including:

Without a strong process based program in IT, it is very difficult to quantify how money is being spent.
Process improvement efforts often take a backseat when resources are scarce, sacrificing efficiency.
A top down push for blind adoption of any standard can lead to backlash.

Read Full Article: FT.com - Why business leaders need to ask their IT organisations about process.

Process Mapping 101 – Introductory Tutorial

Process Mapping 101 – Introductory Tutorial

2010-02-09T22:16:07Z

Process Mapping is one of the quickest and most intuitive ways to document all sorts of different activities that go on inside your business every day. For initiatives like regulatory compliance to process improvement to education and training, you may find that Process Maps are the quickest and most effective way to document and communicate how your business works. With just a few clicks of the mouse, you can illustrate what otherwise would be complicated to write as well as tedious and time consuming to read in narrative form.

Before getting started, it is a good idea to familiarize yourself with the Process Modeler Environment and check out the Process Modeler Quick Start. These two articles will give you a basic understanding of what the Process Modeler can do. The following articles in Process Mapping 101 will teach you the fundamentals of process mapping and how to use the Process Modeler to create highly effective maps quickly and easily.

When reading through these lessons remember that above all else, consistency is the key to a successful initiative. Why? Because when you are consistent you don’t have to do everything else “exactly right.” When you are consistent in the way you document your processes, your process maps don’t have to be works of art; you don’t have to use the perfect diagramming shape each time; and you even can get away with doing things that some people might consider “incorrect”. The reason for this is that with consistency, your audience will have an easier time following and understanding your work. Remember, with consistency your audience can understand your work, and if they can understand it, you have done a good job!

This tutorial is compilation of articles or “lessons” broken down into the following sections:

Lessons 1-3: Getting Started With Your First Maps
Lessons 4-9: Making Great Looking Process Maps
Examples: Learning from a Bad Example

After you master these concepts, Process Mapping 102 (Coming soon) teaches you how to break down large processes, work with different shapes, and layer additional information onto your map.

Lessons 1-3: Getting Started With Your First Maps

Start Your Map Using Basic Shapes – The Synthis Process Modeler contains hundreds of “shapes” that you can place onto diagrams. This article shows you how quickly and simply to start using the six basic shapes that you will use more than 90% of the time. Read Article »
Simple Element Naming Conventions – Following a few simple conventions that will help you improve the readability of your Process Maps. Read Article »
“Show it” on Process Map and “Say it” in the Comments – Avoid cluttering your diagrams with “too many words”. Instead use Element forms to capture rich process detail. Read Article »

Lessons 4-8 Making Great Looking Process Maps

How to Use the Grid – Consistent Element spacing is one of the simplest ways to improve the visual appeal of your Process Map. Read Article »
Right Angles Look Better than Diagonal Lines – Using right angles instead of diagonal lines to connect Elements instead will make your map look more organized and help your reader follow the flow. Read Article »
Design Your Process Map from Left to Right. Unless you live in a right to left culture, you should try to start your process on the top left with sequential steps following to the right. Choosing to work top down is not a bad option either but be consistent with the direction you choose. Changing directions arbitrarily on your map will confuse your reader. (Coming soon.)
How to Make a U-Turn to Avoid a Run-on Process Map – An exception to the working left to right guideline pops up when you have a diagram that seems to run on forever. Without wrapping your diagram somehow, you can end up with a diagram that is very wide and not very tall. (Coming soon.)
Avoid Excessive Decoration on Your Process Maps (Coming soon.)

Learning from a Bad Example

So far, Process Mapping 101 has given you a bunch of tips that cover many different topics. We are going to “put it all together” by starting with an example that really can use some improvement! Simply applying the lessons of Process Mapping 101 above will result in a much more consistent, visually appealing, and understandable Process Map.

Figure 1 shows our fictitious example depicting how a company responds to customer or prospect inquiry. When you don’t start out with the Process Mapping 101 tips in mind, it is easy to end up with Process Maps that look just like this. There are certainly many things that can be improved about this example, but for starters we are going to tackle using the gird and right angles as well as working from left to right.

Use the grid for deliberate spacing. When you don’t start with a grid spacing in mind it is easy to “grow” a sloppy diagram. Here Elements appear at different horizontal and vertical spacings. Compounding the confusing effect, Elements are not in aligned rows or columns meaning that Edges are not automatically aligned.
Right Angles Look Better than Diagonal Lines. No big secret here. The diagonal lines look unfinished and interrupt the left-to-right flow.
Work left to right. In this example the user starts the process off going left AND right out of the Decision Element. Kind of visually confusing isn’t it? We will talk more about Decisions in a minute but clearly this violates the left-to-right principle. When you put your Start Point in the upper left corner, working the flow left to right is natural and easy. If your start turns out not to be the actual start and you need to add new preceding steps to an existing flow, don’t just squeeze them in anywhere you can find room on the canvas. It is incredibly easy to move everything to the left and/or down. Use the Select All toolbar button or the “Ctrl-A” shortcut, then drag all the shapes into a neat group. Make sure to drop them on an even grid spacing!

After applying these first three tips you can see a dramatic improvement! The Process Map is much more readable after just a few minutes of work. It still looks a little cluttered though. One thing you might notice is that many of the Element names are not following the naming conventions discussed above, and the map has a good bit of extra decoration. For instance, why is the “Sales Related Inquiry?” decision colored green? Is it because the author of this Process Map was thinking “sales equals money and money is green?” That is the problem with many of the “decorations” you put onto a map. More often than not, the reader will not appreciate your reasons for the bold/color/dashes/etc. Let’s fix the Element names, remove extra decorations, and move any other extra information off of the map and into the appropriate Element’s comment area.

Getting better! Let’s take a look at a few of the fixes. First of all, you might have noticed that the large yellow comment in the lower right is gone. The comment in that box really applied to the decision “Customer on version 1.2 of XYZ product?”, which we renamed to “Customer on Latest Version?”. The yellow highlight was drawing too much attention away from the rest of the process. Worse than that, since the text only appeared on the diagram and was not associated with the Decision Element, the information could not be generated into any of the documents that the Process Modeler produces. To fix it, simply move the text to the Decision’s comment area.

The last area that could use some improvement on the Process Map is the use of Decisions. In the example above: 1. the Decisions don’t have all of their exit arrows labeled 2. the Decisions use different directions for Yes/No 3. “Sales Related Inquiry?” has three exits.

There, all done! All of the Edges are labeled, the Yes Edges go to the right, and all the No arrows go down. Sometimes you cannot help but break this convention; still, overall the convention creates a nice flow. Also, the “Sales Related Inquiry?” decision was broken down into two Decisions, as it should have been all along.

I hope you will agree that the tips presented in Process Mapping 101 resulted in a Process Map that is clear and easy to understand. Remember, while we did take a good bit of the information off of the map, we put that information back into the various Elements’ comment areas. Now when users browse the Synthis Process Maps they are presented with a picture that is easy to follow, and at any point they can drill down on individual Elements for more information.

Repository Downloadable Help

2010-01-13T02:16:43Z

The majority of the Repository help documentation is available in downloadable form.

File: SynthisRepositoryHelp.pdf
Pages: 98
Size: 6.2 MB

Repository Installation Guide

Right Angles Look Better than Diagonal Lines

2010-02-14T22:33:11Z

Diagonal lines can become visually distracting to readers. Try to stick to horizontal lines with 90 degree bends. In small examples this may not appear to make a big difference, but as your Process Map grows the effect will be significant. Combine right angles with consistent grid spacing for great results.

Figure 1 - Using Right Angles Creates Neater Process Maps

Elements – Start Point

2010-02-14T22:33:44Z

A Start Point is used to represent the action that triggers or initiates a process. Generally a Start Point should represent an action, not simply a condition or state. For a Process Map documenting a customer support process flow, a Start Point may be “Customer Emails Support” or “Customer Phone Call Received.” It is a good idea to start your flow by thinking about what triggers your process, and add that as a Start Point to the upper left of your map.

You should try to start all of the pathways through your process with a Start Point. If your Process Map represents a step in a larger process, then you may start your flow using the parent or preceding step Process Map Element instead of a Start Point.

Like End Points, you should try to keep the number of Start Points on an individual Process Map as low as possible. One Start Point and one End Point is ideal but very often not possible. In our example customer support process above, the process is triggered by email and by telephone. When the start points are closely related and enter close to the same point in the overall process, that is fine. If you have multiple Start Points that are not closely related, you might want to think about breaking up your Process Map into multiple smaller maps focused on narrower parts of the overall process.

Elements – Activity

2010-02-14T22:34:43Z

An Activity represents a step in a process. The majority of your Process Map will be made up of Activity Elements. A simple best practice for Activities is to name it with a verb+noun phrase. Instead of giving the Activity a title like “Open the mail with the letter opener,” use “Open Mail” instead. You would use the Element Property Editor and the Activity’s comment field to document how the letter is to be opened. Also try to avoid using descriptive metrics or requirements in the Activity title. Instead of naming an activity “Deliver Pizza within 30 Minutes,” you should name it “Deliver Pizza.” In this example, “within 30 Minutes” is a very important detail and should be captured in the Activity’s comments field or, even better, documented as a Requirement Element that gets attached to the Activity.

Elements – Edge

2010-02-14T22:35:13Z

Edges: An Edge, sometimes called an “arrow” or a “link,” is what connects each step in the process. Unlike the other Elements in this list, Edges do not appear in stencils. Instead there are two ways to create them:

Click the “Link Mode” button on the toolbar and then click your source Element and drag it to your destination Element. The destination element should highlight in yellow when your mouse is correctly positioned over it for a drop.
A faster and simpler way to create an Edge is to hold down the control key (Ctrl) on your keyboard, then click-drag-drop it from the source to the destination Element.

To reroute an Edge, simply click somewhere on the Edge and drag to create a new “elbow.” You can put a label on the edge by double clicking the edge or by giving it a “Name” in the Properties Editor.

Elements – Decision

2010-02-14T22:35:51Z

Almost every process involves making a decision. Decisions should be concisely phrased questions with two exit Edges, one labeled “Yes” and one labeled “No.” You can’t always follow this tip, but generally when you want multiple outcomes from a decision (such as “A,B,C” or “yes, no,maybe”) you can break that one decision down into multiple sequential decisions. Additionally, try to avoid putting metrics or other qualifying criteria in the Decision title. Save that for the Comments or Requirements area in the Decision’s Property Editor. As an example, “Bill Due?” is preferable to “Bill is due in the next 10 days?”.

Elements – End Point

2010-02-14T22:36:02Z

An End Point represents a terminal state of your process and can be thought of as the opposite of a Start Point. An End Point does not have to be an activity or action taken by a person or system; it can be just a place holder to represent the terminal state. If you are mapping the call flow of an automated phone system, an example End Point might be “Call Ended”. If you are mapping a customer support process, an example End Point might be “Issue Resolved.” If you are not sure what to call it, “Process Ended” can be a fine End Point. You should try to end all pathways through your process with an End Point. If your Process Map represents an intermediary step in a larger process, instead of ending with an End Point, you may end your flow by linking to the higher level Process Map, or the Process Map that represents the next phase of the process. Like Start Points, you should try to keep the number of End Points on single Process Map as low as possible. One Start Point and one End Point per Process Map is ideal, but very often not possible. Many times you will have two End Points, one to represent a successful process termination and one to represent a failure. That is great. If, however, you have multiple End Points and the ends states are not closely related, you may want to think about breaking up your Process Map into multiple smaller maps focused on narrower parts of the overall process.

Elements – Process Map

2010-02-14T22:36:12Z

The Process Map Element doesn’t just give you a pretty diagramming canvas to work on; its icon also can appear on its own and/or on other Process Map canvases. Place a Process Map icon on a diagram to represent a drill down into a sub process, an exit of one process to another, or an exit back up to the calling process. On a diagram, you can double click an any Process Map icon to open up that Process Map’s diagram canvas.