Fundamentals of Process Mapping – Introducing Subprocesses Part 4

From what we have seen so far, we’d have 3 separate, but related process models. One for each of the following:

  • Buy a Book
  • Choose a Book
  • Pay for Book

Numbering the processes

Some of that was getting difficult to describe. The fact that Pay for Book is a process step in one diagram and a whole process was causing some difficulties in describing the relationship. I’d recommend reading through it again, slower this time, checking that you are certain which process step is being to referred to at each point.

Some standards help understanding by providing a key to each process step. The most common method is to assign a unique number to each process. The benefit of this is that you can define the process once (e.g. say we define “check stock level”) and then we can use it elsewhere as a process step (e.g. in an ordering, logistics or auditing processes).

Some standards help you navigate the hierarchy by assigning and set of numbers, e.g. everything at the top level has one number (1, 2, 3, 99, 123, etc). The next level down would have another point number so that all the process steps in process 1 would have numbers of 1.1, 1.2, 1.3 and those in process 3 would have 3.1, 3.2. Down another level and we’d see labels such 1.1.1, 1.3.4 and 4.3.5. This does lean towards a parent-child relationship between processes. Not necessarily bad, but I prefer more freedom.

The more levels and the greater the complexity, the greater the need for a naming convention.

Reuse

By allowing processes to appear in other process maps, they can be reused. For instance, theScan Book process step above could be used elsewhere, e.g. to retrieve information about a book such as how many are in stock, price, different versions, etc. The process step would be the same in all processes.

Common Mistakes

  • The Process Start in a subprocess doesn’t relate to any process step in any other process map. So you’d never actually use this process.
  • The process overlaps with the previous or next process in the chain – as we saw earlier with the Scan Book process step.
  • The Process Ends (i.e. the outcomes of a process) for the subprocesses aren’t reflected in the higher-level processes.
  • Change in process mapping methods – giving a process step to a different analyst can result in that process step being described using different methods or no standards. This isn’t necessarily a mistake, but should be considered before responsibility for process mapping is delegated.

Why 3 Levels?

You don’t have to have 3 levels, they suited the early part of this article. It’s a common concept in a lot of domains. In Data-modelling, the hierarchy of Conceptual, Logical and Physical data models has long proved beneficial. Closer to the process domain, Alistair Cockburn was promoting multiple levels of Use Cases almost a decade ago.

When do you stop going smaller?

When everyone understands the process step without having to ask any questions.

For many clients, two levels is sufficient for the process analysts to be involved in; a high-level mapping of all the processes, then a more detailed view of each process. a 3rd level may be created for the more complex processes that require more analysis. Developers are likely to look for further detail, so either another level or different diagramming technique can be used.

Recap

  1. A process step can be described in more detail in its own process map
  2. Processes can be re-used in more than one process
  3. Process maps should contain sufficient information to relate to each other – using the Process Starts and Process Ends
  4. Different readers will have different ideas of how much detail they want to see
  5. The different levels of process maps can be used for different audiences
  6. As the number of processes and levels increases, the greater the need for a naming convention

Next Article

Notice that Buy a Book was written from the buyer’s perspective whereas Pay For Book was written from the Bookseller’s perspective. We’ll discuss how to handle that in the next article.

Which Diagram type?

All the diagrams above could be process maps. In some cases, especially with mapping the flow of user-interfaces, then UML Sequence Diagrams can be more useful than Activity Diagrams. I’ll explain why in a later article.

This is an article in the Fundamentals of Process Mapping online book provided by Alan Ward

Fundamentals of Process Mapping – Introducing Subprocesses Part 3

In the previous diagram, I’ve put two crosses, not part of any standard. I’ve used them to highlight what’s wrong with the Choose Book process as depicted above. The second of the crosses is easiest to explain.

The process step of Scan Book more properly belongs in the Pay for Book process. We can see it in the Pay For Book process, so let’s keep it there. If it’s also in the Choose Book process, then we’re duplicating actions. Someone following the overall process in the diagram above would end up scanning books twice. That’s not right.

The cross on Take to Pay Desk is more awkward and shows where we cross the boundary between science and art. Does Take to Pay Desk belong more to selecting a book or paying for it? My view is that it should be in Pay for Book. Since the book is chosen at the point that the customer picks up the book. Anything after that (apart from putting it back in the bookrack again) is beyond the scope of choosing a book. Two other scenarios come to mind that reinforce the fact that it’s in the wrong process above:

  • if they were going to steal the book, they wouldn’t take it to Pay Desk.
  • if they were going to read the book in the store, as is getting a lot more common-place in the UK, they wouldn’t need to take it to the Pay Desk.

In both the above scenarios, the process of Choose Book would still be relevant. In the second scenario, the customer would still have followed the Choose Book process.

I’ve simplified the diagram by removing the Take to Pay Desk and Scan Book process steps and inserting the Take to Pay Desk process step in the Pay for Book process.

Remember: you won’t see the processes on the same page. That’s just so I can present the relationships between them.

Process Mapping Fundamentals – Introducing Subprocesses Part 2

If you look at the Pay for Book process-step in the top row of the above image, you’ll notice I’ve included a small image of the Pay for Book process. The use of colours is just to help me show how the processes fit together here. It’s incredibly rare to have the process and the more detailed process on the same page. In fact, I can’t ever remember doing that apart from when I’m showing the relationships between processes in articles such as this one.

I mentioned that the Process Starts and Process Ends are the glue because the detailed process (the lower one in the above diagram) should be able to fit into the main process (the upper one in the above diagram). It should do this without overlapping into any other process steps. Choose Book will also have its own detailed process map.

Here’s an incorrect example highlighting Choose Book and Pay For Book.

That Choose Book process relates to the Choose Book process step. Actually, maybe I should state that the Choose Book process is the Choose Book process step. It’s the same thing, just different views of it. One view shows more detail than the other.

Process Mapping Fundamentals – Introducing Subprocesses Part 1

Introduction

Processes can be broken down into more detailed processes. In this article, I’ll take one of the process steps from the previous article and look in more detail about how it connects to the other components of the process.

Some Perspective

A key feature of any workflow system is that you should be able to look at the system from different levels, e.g. a director’s view of the system may only show 5 or so process steps and cover what it takes 10-200 people or more to perform. A user’s workflow will probably require several process maps, each relating to the different processes that they perform on a daily basis and some that are less frequent. The solution’s workflow could feature many process maps, perhaps describing the user interfaces and the core system’s interfaces with external solutions.

Each map communicates to its intended audience. That means that we, as analysts, have to write for that audience. Fortunately they all follow the same basic principles. They should all relate to each other, if they don’t, then there’s a gap that needs to be addressed.

Using the 3 levels above, we should be able to look at the director’s level process model and delve into the process steps. Say we look at the process step 1 in that model, we should be able to find a user-level process model that shows us the detail of that step. Similary when looking at the user-level process model, we should be able to look any process step and see more detail in the process described in the solution workflow.

So how do the processes fit together?

The first point to understand is that most process steps can be a processes in their own right, usually with more detail. Rather than have all that detail on every diagram, it’s more common to display a box for the process step and that refers to a more detailed process map for that step.

Let’s take the Buy a Book process from the previous example and work through that.

The Pay For Book process step includes a number of its own steps when it’s viewed as a process. We’ll take a very simple concept of paying by cash. The same principles apply to paying by credit card, just that there’s more involved in that process.


Like all of these processes, real-life is more complex. For instance, scanning the book would display the price on the till. There’s also more happening with process cash payment, e.g. what about giving change back? I’ve changed to yellow just so it’s easier to show the different levels in the following diagram.

The glue is the Process Start and Process End points. These connect to other processes.

Note the name of the Process Start? It’s the same text as the process step in the original Buy A Book process. When reading Buy a Book, you may want more detail about Pay for Book, so look for the process model entitled Pay For Book and it should have one Process Start with the same name. The End point again assumes that the process has been completed. If we were looking at more detail, it could be that the buyer couldn’t pay and so didn’t purchase a book. For the moment, we’ll leave that outcome.

Process Mapping – Introducing Decision Points

In the previous article, I introduced a basic process map consisting of a process start point, a process end point, two process steps and connectors.

It’s rare that a process map is a straight line like that simplified process. There are usually options which can take the process down different paths.

In the case of our book-buying process, we may want to ask the customer if they want the book gift-wrapped as part of free promotion.

Decision Points
The most common symbol for a decision point is a diamond (or a rhombus for the pedants out there). Similar to the process steps, the decision point is linked by a connector into the diamond. The difference is that the decision point should have at least two connectors coming out. It’s generally best to label each connectors with the outcome that it represents, otherwise the reader is guessing which outcome they’re looking at.

So back to the gift-wrap example.

As you can see, I’ve added the following items to the previous diagram:

  • Decision point of Gift-wrap
  • Outcome of Yes
  • Outcome of No
  • Gift-wrap Book process step

It could be that there are more outcomes from the decision point. Or that the decision point leads to another decision point, e.g. Red or Blue wrapping paper? More complex would be that some points are only available.

Notation
I’ve already mentioned the common use of a diamond for the decision point and that outcomes should be labelled. In addition, the text inside the Decision Point should be a question. And the outcome labels should be appropriate as answers to that question. Sometimes we have to abbreviate the responses due to space. Bear in mind it’s all about communication, so think whether the readers will understand the abbreviated labels.

Ideally I’d have had a longer label for the decision point in the above example. My excuse is that I’m creating the maps on desktop software, then having to export in a way that works for this website. That’s not the way I’d normally work, since I’d usually use the process modelling software that the client has bought into. I could still get a longer label but the process map suffices to show how decisions are depicted.

You may also see a decision point duplicated at the end of the options. i.e. the process would show a decision point, then the options/outcomes, then bring them all back to a further decision point (often empty). This just shows that the decisions have been resolved and that there’s only the one path forward from that point on. This depends on the modelling standard you subscribe to.


Here’s an example of that. I find that the additional decision point can confuse less-technical, more business-oriented readers. It also takes up more space on the screen or paper. So I tend not to use it that often or until a project is at a more technical stage.

The Most Common Mistake
The most common mistake I see in process mapping is that there aren’t enough outcomes in the process map. The analyst may have assumed that the answer is yes or no. Often there are other outcomes, e.g. don’t know, timed-out, incorrect response, didn’t understand the response. It becomes more of an art than a science as to how many of these outcomes are included. Bear in mind that as more time passes and the project moves forward, then more of those outcomes should be documented.

Note the Ending
In the case of the gift-wrap example, the Process End is the same ‘Book Bought’ whichever outcome is taken from the decision point. That suits us because the Process of Buying a Book is still completed, regardless of whether the customer wants the giftwrap or not. It is possible to have different endings depending on the outcomes inside the process, we’ll get to that later.

Is that sufficient?
In short, no. It’s a start. Some of the first few steps in the process mapping journey. There is more to learn. For instance, we’re not depicting who does what, what else they do, the details of paying for a book, or even what happens if we charge for the gift-wrapping. I stated it was a free promotion earlier since it allows us to focus on the decision point itself. I also want to go into more detail about how process steps relate to processes.

Checklist for decision points

  • Is the symbol noticeably different from process steps or other items? (actually not necessary, but very worthwhile if the process modelling tool allows it and most diagramming tools do).
  • Do the decision point have enough outcomes?
  • Is there a label on each outcome?
  • Does every decision point have a question as its label?
  • Do the outcome labels relate the decision point question?
  • Do all the outcomes connect to other items? (e.g. process step, process end, decision point)

Modelling Standards
I mentioned Modelling Standard above. I refer to standards such as BPMN or UML, specifically UML activity diagrams. In this series, we are starting with basic examples, moving towards depicting models conforming to those standards. The main thrust is to get the basics right and point out some of the common mistakes along the way. Watch out for different terminology, in BPMN the decision points are referred to as Gateways.

Process Mapping Basics

Introduction

This is the first article in the Fundamentals of Process Mapping series. In the series, I want to discuss the areas that most process mapping tutorials miss.

In this bite-sized article, I’ll introduce the idea of a basic process map.

Let’s get some background about process mapping first.

What is a process map?
A process map is a tool. It is not an end in its own right. They are often used in software development lifecycle or within Business Process Re-engineering (BPR). If the methodology you’re working in states that one is required, you’re not writing a map just to fulfill that aim, but because the creators of that methodology realised that a process map would be a useful tool to have.

I see a process as one component of a process description, not necessarily the only component. That’s worth remembering.

What are the purposes of a process map?

I have at least four aims when I’m process mapping:

  1. To describe a process in pictorial form
  2. To provide a quick way of understanding how the main steps in a process fit together
  3. To provide documentation for agreeing what happens in a process
  4. To provide documentation for what could happen in a process, e.g. process improvement

There are other aims depending on the need, e.g. for collaborative working, facilitating workshops. Whatever the discrete aims are, they all boil down to communication.

What are the components of a process map?
Every process has at least one process step, at least one starting point and at least one ending point. The process step is an action that is performed by an actor (either a person, a system or an organisation).

Our initial basic process will have the following:

  • one starting point
  • two process steps
  • one end point
  • connectors showing the direction of flow


For the process map here starts at Process Start, continues to Process Step 1. Once that is complete, continue to Process Step 2. Once that is complete, continue to Process End and the process is terminated.

To put that into context, imagine a simplified process for buying a book in a bookstore.

The customer wants to buy a book, so process start (Buy a Book), customer Chooses a Book, then Customer Pays for Book. Once that’s complete, the Book is bought. I’ve simplified it so we can discuss it in more detail later on.

Notation
Your software may have different notation for process start/initiators, process ends/terminators and process steps (often just called processes). That’s ok. As long as you can tell the difference between them.

What Next?
That’s the very basics covered. I’ll go into more detail about processes, process steps, decision points and common pitfalls in the following articles in the series.

Fundamentals of Process Mapping

I’ve written before about the elements involved in a process map. In this series of articles, I want to start at the basics and explain what a process map should contain. I’ve seen a fair few methodologies come and go. Fortunately, methodology seems to be settling down with a few interesting branches appearing. I’ve also seen and used a lot of different process mapping tools at different levels, some more like CASE tools, some more like business process management tools, some just diagramming tools.

The aims of this series
I want to work with better-written process descriptions. I want to pass on best-practice as I’ve seen it after working with a lot of process and business analysts. I’ll discuss why following the methodology is not enough on its own, nor is just creating process maps on their own.

I am not writing against any software lifecycle methodologies, any project frameworks nor am I saying one tool is better than another (although I may touch on that). What I will provide are tips for improving the process analyses that you create regardless of which tool, methodology or framework.

Why am I writing this series?
As part of my BPR activities, I’ve received a lot of process descriptions that are not detailed enough, not internally consistent, not wide enough in scope, have gaps in them…in short, not good enough. It doesn’t matter to me who did the analysis, what counts is that someone (maybe the same person) is going to have to do more work to get it up to scratch.

If the work isn’t improved, then it causes problems further down the line. Some examples of the problems caused:

  • increase in customer complaints because agents can’t handle their questions
  • having to hire in more people as process gaps are identified
  • having longer queuing times because the the time taken to complete the process was underestimated, based on too simple a view of the process.
  • delay to process implementation while the correct level of detail is captured
  • stakeholder conflict as the invalid process maps highlight distrust between the operational teams and the process improvement teams

I’d prefer it if the process descriptions were defined properly in the first place. So please, distribute this.

Issues with Process Mapping

I’ve been using process mapping for over a decade now. I’ve probably been the recipient of more process maps than I’ve created, as I’ve had to implement changes that have already been designed by others. I’ve also had to talk many business users through the intricacies of their redesigned processes, especially if they (wrongly) hadn’t been designed by them. The most common scenario for me is where I’m asked to review process maps and assess how easily they could be implemented, bringing together knowledge of people, processes and IT/ICT.

Over that time, I’ve seen many sides for and against process mapping. I’ll discuss some of the issues and some of the methods for mitigating the risks associated with mapping processes.

1. Takes too much time

Mapping a process takes a long time. If that’s the only method that’s being used, then it will take longer than you expect. The only exception is that if you’ve been through similar exercises before, then you should already have some idea of how long it can take. To get a high level map is easy, to get to sufficient detail that a reader can understand the process takes a lot more time. This is time is extended if there is interaction with IT systems and different locations.

2. No standards

Some people map processes for a living. Worth bearing that in mind if you’re new to it. You can generally tell how much relevant experience a person has by looking at their output and any comments they attach to it. Have they picked a standard notation? Do all the decision points have two or more outputs? Are decisions labelled differently to process steps? And so on. Whatever the standard, a process map should be internally consistent. If a decision is a shaped as a diamond in one part of a map, then all decisions should be diamonds.

3. Conflicting standards

Assuming that the process-map author used a standard, it often doesn’t conform to the standard that the rest of the team are meant to be working with. The level of rigour required – as driven by an evaluation of potential risk – determines how closely diagrams have to conform to the standard. Some deviation is often permissible, and may even introduce new ideas, just bear in mind that a process map is a communication tool. The more standards people have to learn, the less concise and the less effective the tool becomes in communicating.

4. Not enough detail

The most common issue I see is that I receive just a process map. There has to be more information. The process map is a diagram of the process, but it isn’t the process itself, nor is it a complete description of the process. It is one tool for communication, there are others and analysts should some of these should be used. For instance, there should be a process description supporting the process map. This would provide the detail of each process step, providing elements that couldn’t be included in the diagram. Remember that a process map is a diagram and you’ll often need words to describe the process more completely. Words or pictures alone are often not sufficient, the combination of the two together work really well.

5. Too much detail

Better too much detail than too little. I’m always curious if there’s such a thing as too much detail in process maps since the aim is to capture everything so that it can be understood, replicated, changed and/or implemented.

My current answer to this is “yes”. Once you’re into the realm of mapping something that’s rarely done, has very little associated risk and you know you’re going to change it, then you don’t need much detail.

You also don’t need much detail if you’re just trying to scope out the activities of an organisation.

Another indication of too much detail is when an analyst has focussed on one area more than another such that most maps are high level and one is too detailed in comparison. So unless there’s reason to concentrate on that one area such as you know you’re going to be doing that in the following stage, I’d start to think that there’s too much relative detail.

6. Users don’t understand them

Process maps should be easy for users to understand. If they’re not, then question the standard; are you using the most appropriate standard? For instance, I noticed that early versions of UML Activity Diagrams confused users due to the diagonal lines making the sequence of events unclear. Many of those Activity Diagrams still included horizontal and vertical lines, but the standard permitted diagonals. Compare that to later versions of the Activity Diagrams. Now, I’ve no idea if it’s the standard or just best practice that means that most lines are horizontal or vertical, but either way, I’ve seen a change towards that practice.

It is also worth taking a key or legend with you or at least explaining it in person. Mention what a process step is, what a terminator is, what a gateway is and how to read them. Especially talk through the difference between parallel and sequential processes.

7. Users aren’t involved with them

This is stake-holder management. By and large, people resist change. Not involving users in the process mapping exercise increases the risk of resistance and increases inaccuracy. The fewer users, the greater the risk. Fortunately, it’s rarer nowadays to see the creation of process maps not involving any users. But take it a step further, instead of a review process, move some of the ownership or responsibility onto the users. That doesn’t mean that they should be responsible for creating the maps, but that they should be happy with their content and happy that they represent what they do.

8. Don’t have the tools

You can’t do process maps well in MS Powerpoint. You can get so far and do a very high-level sketch, but you can capture detail that way. Trying to results in a mess, a divergence from standards and a confused user.

At worst, use MS Visio. This should be the lowest level of IT tool you should use. Better still, find a purpose-built tool. Make sure you can export into a format that your audience can open and read. Test the export and read process a few times. Visio used to be a bit unpredictable in its export output, but that seems to have settled down a lot. All depends what version you’re using and what the diagram includes.

If you’re a bit old-school and use post-its on brown-paper. Tape the post-its down once the process is agreed.

9. Use PowerPoint

In contradiction to the previous point, PowerPoint has a very useful feature in that its main deficiency as a drawing tool can be thought of as an advantage; i.e. it constrains the complexity of the diagram. I use it to show value chains and simple process maps. The diagrams usually have 6-10 steps and little branching. For this brief, overview type of process map, PowerPoint is ideal.

What’s in a process?

I’ve had a view for a number of years now that a process cannot be described with just a process map.

Well, not in its entirety. A standard process map usually consists of rectangular boxes linked with arrows. Better process maps have some variety in the size and shape of boxes representing the variety of actions and decisions that occur at the process steps. When good, these process maps conform to BPMN, UML (Activity Diagrams) or other similar standards. When bad, there can be missing outcomes from decision points, missing references to other processes or references to missing processes and so on, the list goes on.

How Deep?

However, no matter how good the process map, they cannot completely describe the process. Take the instance of capturing an AS-IS process, perhaps during the check phase of lean systems. A process map would only give a brief description (1 to 20 words maximum usually) of the process step in question. Just as a process can be broken down into process steps, process steps can often be broken down to a further level. And then those steps can be broken down again. In practice, there’s a point of diminishing returns after which you decide that enough detail is enough and that to gather more detail, although useful, would not be cost-effective. So it follows that no matter at what level you stop when looking at business processes, there’s always a level of detail that you’re missing. There are exceptions to this, for example when designing circuits, then the process steps may well be atomic. In most cases with business processes, there are further, more granular levels.

BPMN and UML Activity Diagrams are good at showing relationships between steps, including the order and control flow of the process steps and how they link together. That’s useful and should be used. The process maps should be consistent with the standard that the author is using. So make sure that if follows the rules. Simplistically, any decision point has to have at least 2 outcomes. If it has only one, then there wasn’t a decision. How does the standard deal with branching, merging, delays, broken or disjointed processes? Find out and use it. But that’s not all.

So what is missing from a process definition?

Most often, I find that the underling rationale for the process is missing. A process or a process step exists for a reason, usually it’s do something. In reality, the process steps in a process map are representations of what something or someone does on a routine basis. More commonly, it’s an actor (a person or a system) doing an action to transform an object. This could be processing an application form, taking a payment, assessing eligibility, writing a letter, creating an account and so on. Let’s take one of those in more detail. A likely scenario of processing an application would have:

  1. a customer submitting an application form
  2. the organisation receiving the form,
  3. an agent checking the application for completeness
  4. the agent recording the application on the organisation’s system
  5. the agent assessing eligibility
  6. the agent giving a reply to the customer (by letter or email)
  7. if the application was accepted, then a new service or entitlement is started on behalf of the customer

Input and Output 

The common item throughout all the above is that there’s an application form being processed. The customer fills it out, the agent assesses it. It goes on a journey and the process steps cover that journey. The application form probably has a “for office use only” on it. Sound familiar? Well the agent would be filling out that part. What’s important is the each process step receives the application from the previous process step. So the application is an output from step (1) and an input to step (2). By noting these on a process map or in an accompanying text document, we’ve improved the quality of process map incredibly. So if a process step needs to receive something, list it as an input. Similarly for output. Often, any analyst who’s previously been a developer  will probably focus on data inputs and outputs to a process, e.g. parameters that have to be passed along the journey. Watch out though, paper, faxes and files are equally as important.

Transformations 

Back to the rationale, the process step will transform the input into the output. These transformations should be recorded. So if the agent adds something to the application, record that fact in the process description. Bear in mind that the process step can (so far) only achieve an output by transforming an input. By recording these, we’ve added more detail and more rigour to the process definition.

Record Data Usage 

In step (5), the agent assesses eligibility. Maybe they retrieve some customer details based on the information in the application form and perhaps also retrieve a sliding scale as a reference. These are pieces of data that the process step uses to change. Ignoring human emotion, the output can only come from a combination of input, retrieved data and an algorithm. From what we covered earlier, the algorithm could be broken down to more more granular steps. The process step could also update a retrieved form or create further data to be stored somewhere. This retrievals and updates should also be recorded as part of the process definition. At a high level, I’d expect to see which systems are being used per process step. At the next level down, we should cover data at the conceptual level (e.g. Customer, Car, Address). Another level down, I’d be looking to record usage of data at the logical level (customer first name, customer last name, address postcode, car registration number). To some extent, the old Data-Flow Diagrams handled the flow of data between process steps. The combination of ERD and DFD seems to be have been lost in today’s modelling skills.

Channels 

In step (6), I mentioned “by letter or by email” rather lazily not differentiating between how the process may differ for each channel. The process should be consistent with the channel that it applies to. If there’s a change in the channel or medium, these should be recorded. Coming from implementing multi-channel solutions, I like process maps to be applicable to all channels and only show the exceptions. In practice, this often requires a split, either due to the time nature of the interaction (synchronous or asynchronous) or whether it’s electronic or in person.

Where? 

Reading the steps in the list above, you’d expect steps (2)-(7) to be performed by an agent in the same place. If the geographic location changes, then record this. Same goes for teams, although using the swimlanes in BPMN and UML should already cater for these. Ideally, anything that changes about the environment in which the processes are conducted should be recorded. It’s best to describe what I mean by example here; if an analyst or group of analysts are mapping a group of processes, if all the processes are performed in one location, then that can be recorded in the text description of the process. If the location changes per process or process step, I’d expect to see each step have the location recorded. It’s better to be explicit rather than leave people guessing, especially where you have the opportunity to reduce ambiguity.

Summary 

To recap, a process definition should consist of at least:

a) a textual description of the process and each process step
b) a control flow of the process through each process step
c) zero or more inputs to the process and to each step
d) zero or more outputs from the process and each step
e) zero or more retrievals for each step
f) zero or more updates for each step
g) environmental variables

Any decent modelling tool should as a minimum allow the analyst to capture this information, be it diagrammatically or textual.

In my experience, the vast majority of analysts do (a) and (b) only. Some analysts make an effort at doing (c) and (d) with varying degrees of success. Get any analyst with a process background rather than full understanding of the systems development life-cycle and you’ll be struggling to get anything beyond (c). I’ve made some generalisations, but they are true from my experience.

Yet there’s still more to capturing an accurate description of a process. Each process has attributes (e.g. time taken, peak volume, average volume, etc.) that should also be recorded.