How-to... Create a process

• A process is made up of interconnected TaskPacks.

TaskPack is the basic building block of the process.

In order to construct the process, we will place TaskPacks in the process and connect them to each other in a successive series with the aim of creating value for the customer, delivering it, and charging for it at the end.

Before that, we need to find out which TaskPacks are there and how they are connected.

We call this process mapping.

Process Mapping

Now we will focus on core processes mapping. We have already listed the core processes in the Organizational Model of the company (see Strategers > Org Modeler). 

In the beginning, there were no TaskPacks. We have to create them. We should familiarize ourselves with the method of constructing TaskPacks. See documentation:  How to... TaskPack.

We should also be familiar with the principle of process construction. See the document:  How to... Principle of process construction.

1. Choose a scope

The mapping of all processes can be a time-consuming task. To expedite the implementation of Workanizers, it is advisable to initially select a specific subset of processes to map. This subset is referred to as the chosen scope. By focusing on a particular work segment where organizational issues are perceived, we can effectively address and improve those areas.

To establish the boundaries of the mapped process, we need to define its scope. This involves answering two questions:

• What is the main result of the process being mapped?
• What inputs does the process receive?

This step is crucial because it allows us to isolate the mapped process and prevent interference from other processes that have not yet been mapped.

See this example ... >

2. Collect information

Initially, we collect information about any activities that occur in the process. We consider them unsystematized.

We get unsystematized information:

• Based on personal knowledge and experience,
• By interviewing employees,
• By reviewing existing process records (e.g. ISO standards)
• By analyzing software usage,
• Etc.

Collecting unsystematized information about activities in a process is usually random. Among this information, we will identify, select, classify and highlight those that will help us in process creation.

See this example ... >

3. Classify information

Unsystematized information becomes usable only after we classify it. Classification of information is relatively simple. We should group them under these questions:

3.1 What is done?

The information that answers this question tells us about the results that are produced in the mapped process. This is what is done in the process. 

To identify these results, we can track the production and service increments.

See the documents: Increments of products and services in the process and How to... Principle of process construction.

• We need to determine what is the final result (increment) of the mapped process. We already did this at the beginning when we defined the scope of the mapping. We are now confirming and refining it.
• Then we determine which results need to be received as input to start the mapped part of the process. During choosing a scope mapping, we dealt with this issue, and now we are confirming and clarifying it.
• In addition, we need to identify the other results (increments) that occur between the start and final increment. These smaller results are essential for delivering the final result as their value progressively increases within the process.

3.2 How is it done?

We previously recognized results (increments) between the start and final (result) increment. Now we need to find out how they came about. Which activities produce which result?

• We need to supplement the information about "what is done" with information about "how it is done". Our goal is to get to more detailed activities that produce a certain result. 

Collecting unsystematized information about how work is currently done in the company usually leads us to a long list of activities that employees currently remember. This information has a different level of detail. Sometimes they are reduced to a general and incomplete list of activities, and sometimes the activities are described in too much detail.

This is the information we use to create TaskPacks respectively tasks later.

3.3 Why is it done that way?

We will often need answers to an additional question "Why is something done that way?". We need this information to understand the logic and evaluate the suitability of the activities that give the result. This information will not be an integral part of the process, but it can be very important for the optimization of the process. That's why we should record them and use them as needed. Using them:

• We avoid formalizing poorly designed processes.
• We may perform certain optimizations on the fly.
• Core processes can be more easily "cleaned" from the distraction of tasks that do not belong to them.
• It is easier to avoid process distortion due to creating processes and tasks for a specific person.

See this example ... >

4. Drafting a process

4.1 Draft TaskPacks

We have previously classified information about the activities in the process we are mapping. This information is the material for creating TaskPacks.

That means we don't have TaskPacks yet.

Before we create TaskPacks, we will create and use a "draft TaskPack" version of them. Draft TaskPacks are not finished TaskPacks. They only have a name, and their result is known. They don't have any other content e.g. tasks.

We can see what name to give TaskPack in the following document: How-to... General information about TaskPack.

4.2 Draft process

With draft TaskPacks, we will outline the draft version of the entire process. Draft TaskPacks should be successively arranged in a process. For the order of TaskPacks, we will be guided by the product and service increments. See Increments of products and services in the process.

With draft TaskPacks, we draft processes faster. We use the draft process to check the correct order of TaskPacks and their increments.

When drafting the process, we consider the fact that between 2 results, there is always a TaskPack. In those places, we will create draft versions of TaskPacks. In doing so, we can encounter three situations:

1. Between the two results, we have recorded only one activity. With further insight, we should discover whether it contains more detailed activities that correspond to the criteria of the tasks within the TaskPack.
2. Between the two results, we have recorded more activities. Here you should check how well these activities correspond to the criteria of the tasks that make up one TaskPack. Or we can recognize that these activities should make not one but two or more TaskPacks.
3. We have no recorded activity between the two results. In such a case, the activities that led to the result were overlooked for some reason or the existence of the result is questionable.

By observing these three situations, we take a critical look at how the process should look. Have the results been recognized as increments at the appropriate places in the process and have we properly named the draft versions of the TaskPacks between every 2 results?

See this example ... >

Drafting of the process is completed by determining the exact order of the draft TaskPacks that make it up.

5. Finalizing a process

To finalize the process, we need to convert the draft TaskPack versions into valid TaskPack versions.

5.1 Creating tasks in TaskPack

To complete TaskPacks with tasks and other content, follow the documentation:  How to... TaskPack.

5.2 Grouping into Sequences

The final version of the process consists of TaskPacks grouped into Sequences.

TaskPack can participate in the process only as part of a sequence. We will follow the process structure rules and group TaskPacks into sequences.

See the document:  How to... Process structure.

TaskPacks must be in a sequence to be used. They are linked logically, and the final TaskPack provides the key result of the sequence.

Sequences offer several benefits that make them a useful tool in process management:

• Firstly, they make it easier and quicker to manage a large number of TaskPacks for a process.
• When individual TaskPacks don't produce recognizable increments, grouping them into a sequence can help identify the output of the last TaskPack in the sequence as an increment.
• Sequences can also be used to classify TaskPacks that contribute to the creation of a milestone increment.
• It helps to easily mark and manipulate parts of the process that can run in parallel.

It should be noted that:

• A sequence cannot be split between 2 different processes.
• TaskPacks within a sequence must be executed successively.
• Sequences of the same process can occur in parallel, i.e., simultaneously.
• It's also worth mentioning that there may be significant time gaps (days and months) between the execution of consecutive TaskPacks in a sequence, depending on the nature of the work being performed.
• In rare cases where a TaskPack is "lonely," because it has no logical connection to any other TaskPacks, it can be added to a "lonely" sequence with that single TaskPack for the sake of formality required by the software.
• The software automatically establishes and visually presents TaskPacks connections when they are in the same sequence.

See this example ... >

5.3 Grouping into bundles

A bundle is a type of sequence that is specific.

• It is not possible to predict the execution time of the TaskPacks that are in the bundle. Their execution time depends on the combination of daily circumstances.
• The order of execution of the TaskPacks in the bundle does not have to be consecutive, as is the case with the sequence. The TaskPacks can be executed in the selected order that suits the circumstances.

That is why in the process the bundles should be recognizably marked. Even if bundles seem unusual, they are common in the daily business of many industries.

Example: TaskPacks to be executed daily in the store.

It's a whole bunch of different TaskPacks in retail business. Receiving and displaying goods, cleaning and arranging the sales area, of course also selling to the customer, working at the cash register, and much more. Many of these TaskPacks are completed while the store is open for customers. However, TaskPacks serving a customer always take priority over other TaskPacks. That's why every customer entry means that you will interrupt another TaskPack and give the customer your full attention.

Such TaskPacks are suitable to be grouped into bundles.

It makes sense for a Bundle to assign the execution in a wider time frame (eg work shift) and it is up to the Doer or Process Manager to find a suitable time to execute such TaskPacks.

Bundles are controlled by a special TaskPack located after the bundle. With it, for example, the retail manager evaluates whether and how well the TaskPacks from the bundle has been executed.