Processkartläggning för bättre systemstöd

It is a way to map and understand how work is actually done. Not how it should be done according to the routine description. Not how the systems were intended to be used when they were introduced. But how tasks, decisions, data, exceptions and responsibilities move through the organization in everyday reality.

What is process mapping?

Process mapping means that you describe a process visually, from start to finish. It could be a customer case, an order, an internal application, an invoice process, onboarding, a planning process or something else entirely.

A good mapping not only shows the steps in the flow, it also shows which roles are involved, what information is required, what systems are used, what decisions are made, and where the process tends to get stuck.

In its simplest form, a process map shows what starts the process, what happens next, and what counts as a finished result. It also shows who does what, what decisions are made along the way, and what systems or data sources are used.

The important thing is not that the map looks good. The important thing is that it is useful. A process map that everyone recognizes is often more valuable than a perfect diagram model that no one uses.

IBM describes process mapping as a method for creating a better understanding of processes and finding areas for improvement. It’s a good starting point, but in practice it’s also about creating a common language between business, IT and management. When the process becomes visible and clear, it becomes easier to decide what to standardize, automate, rebuild or leave as is.

Why process mapping is important for business

Process mapping is rarely an end in itself. You do it because something needs to be improved. Maybe the process takes too long. Maybe too many errors occur. Maybe the work is too dependent on individuals. Maybe there is no system support that really fits.

McKinsey highlights that many organizations try to change structure and responsibilities, but miss the fact that the underlying processes and behaviors are unchanged. They also write that two-thirds of managers experience their organizations as too complex and inefficient. This is an important point: if the process is not truly understood, both organizational changes and systems risk solving the wrong problems.

In many larger businesses, it's not a single process that's the problem. It's the handovers: Between departments. Between systems. Between central and local teams. Between operations and IT. That's often where process mapping becomes most valuable.

It shows where the friction is

Friction is rarely seen in a regular report. It is noticeable in everyday life. Someone is waiting for a response. Someone is double-registering data. Someone is asking in a chat what applies. Someone is exporting a file from one system, adjusting it in Excel, and uploading it into another.

When you map the process, such moments become visible. It also allows you to distinguish between steps that are no longer needed, steps that are needed but should be automated, and steps that require human judgment but need better support.

That distinction is important. Not everything should be automated. But what recurs frequently, follows clear rules, and creates administration is often a good candidate.

It reduces personal dependence

Many processes work because a few people are very good at holding them together. That can be impressive, but it can also be risky. If the knowledge is in the heads of individual employees, the process becomes difficult to scale, monitor, and improve.

Process mapping helps you move knowledge from the individual level to the organizational level, making it easier to use employee experience in the right way. Instead of key people having to save the process every week, they can be involved in improving it.

Process mapping before automation

Process mapping and process automation go hand in hand. It's hard to automate smartly if you don't first know how the process works.

A common mistake is to start with the technology. You find an automation tool , an AI support , a case management system or an integration solution and then try to make the process fit. This may work for simpler flows, but in complex operations it often backfires.

According to McKinsey, 88 percent say their organization regularly uses AI in at least one business function. Meanwhile, only about a third say AI programs have begun to scale. McKinsey points out that high-performing organizations are more likely to fundamentally redesign their workflows, rather than simply layering technology on top of existing ways of working.

This doesn't just apply to AI. It applies to automation in general. If the process is unclear, the technology risks amplifying the problems instead of solving them.

Start by understanding the current situation

A good process mapping starts with the present: how the work actually happens today, rather than how the process should work or what the future vision looks like.

It may feel strange, as the current situation often contains shortcuts, special cases and manual solutions that no one really wants to know about. But that is precisely why the mapping is needed.

When documenting the current state, you should capture both formal and informal work. What steps are done manually? What systems are used? What data is created, changed, or moved? What decisions require human judgment? What exceptions take the most time?

Once the current situation is clear, you can start discussing the ideal situation. Then the conversation will be much more concrete.

Separate process, system and organization

In many workshops, three things are mixed up: process, systems and organization. This is understandable, as they influence each other. But in process mapping, they need to be kept separate:

• The process describes what will happen.
• The systems describe what support is available.
• The organization describes who is responsible for what.

If you mix them together too early, you risk the solution becoming too narrow. You might build on a way of working that only exists because an old system requires it. Or you might shift responsibilities between roles without changing what actually creates lead times and errors.

A good process map makes it easier to ask the question: If we had designed this from scratch today, how would we have done it?

How to do a process mapping in practice

Process mapping doesn't have to start as a big project. It's often enough to choose a specific but important process and gather the right people.

The most important task at the beginning is to create the right framework. You don't need to know all the details from the start, but the mapping needs to be linked to a clear business goal. Otherwise, there is a risk that the work will become documentation rather than change.

1. Choose the right process

Don't start with the entire business. Choose a process where the potential for improvement is clear and where the result matters.

A good first process often has high volumes, many manual steps, long lead times or many handovers. It can also be difficult to follow up, dependent on Excel or have many local variations of the same way of working.

The most important thing is that the process is important enough to create an impact, but limited enough to be understandable.

2. Gather people who know the reality

Process mapping works best when it includes people who actually work in the process. Not just managers, system owners and project managers.

You need people who know what happens when the process doesn't follow the standard flow. That's often where the real complexity lies.

At the same time, IT or system-related expertise should be involved early on. Not to take over the work, but to create understanding around dependencies, integrations, data flows and technical limitations.

3. Draw the process from start to finish

Start with a simple map. What starts the process? What is the end result? What steps occur in between?

Don't try to capture everything at once. Instead, build the map in layers:

• Start with the main flow.
• Fill in roles and responsibilities.
• Add systems and data.
• Highlight decision points.
• Describe important exceptions.
• Complete with measurement points.

BPMN (Business Process Model and Notation) is an established standard for modeling business processes and is intended to be understandable to business users while still being capable of carrying more technical precision. However, not all process maps need to start at the full BPMN level. In early workshops, a simpler visualization can often be better.

4. Highlight issues and improvements directly

As the map grows, problems often arise naturally. Someone says that a step always takes too long. Someone else says that the information is never complete. A third person knows that the same task is recorded in two systems.

Capture this directly in the mapping. Otherwise, the work can easily become a documentation exercise instead of an improvement effort.

Common markings can be, for example:

• Wait.
• Duplication of work.
• Manual control.
• Poor data quality.
• Unclear responsibility.
• Unnecessary approvals.
• System changes.
• Steps that lack measurement.

This makes the map much more useful when you later need to prioritize actions.

5. Put the map to good use

A process map that does not lead to decisions is worthless. Therefore, every mapping should be linked to what you want to improve. The more (measurable) benefit the change brings to the organization, the more likely it is that the process problems you are struggling with will be solved (automated).

This can include shorter lead times, lower administrative costs, higher data quality, better customer experience, better regulatory compliance, less dependence on people or simpler governance between units.

And remember: tie the process change to one or more business or operational goals. Otherwise, there is a good chance that the process mapping will not only fall by the wayside, but will be deliberately put there.

When the benefit is clear, it becomes easier to prioritize between the improvement proposals, which are usually many. Not everything that is annoying is important. Not everything that is important needs to be rebuilt immediately.

Process mapping and process mining

Process mapping is often done through workshops, interviews and document analysis. Process mining is a more data-driven way of understanding processes, where system logs are used to show how flows actually work.

Gartner describes process mining platforms as tools that provide visibility into business processes and application landscapes, allowing leaders to make smarter decisions based on organizational priorities. This is particularly relevant in businesses where processes already leave clear digital footprints across multiple systems.

Deloitte believes that process mining has evolved from a niche technology to a strategic enabler for transparency, efficiency and compliance. They also highlight that organizations need to address barriers such as data quality, collaboration between departments and the ability to translate insights into measurable results.

For many businesses, the combination is strong. Workshops show why the process looks the way it does. Process mining can show how often different variations/deviations from the process actually occur.

When is manual mapping enough?

Manual process mapping is often sufficient when the process is limited, when few systems are involved, or when you are in the early stages. It is also a good way to gain consensus between people.

It is particularly useful when you need to understand responsibilities, decisions, exceptions, perceived problems, improvement ideas, and organizational dependencies. It is also a good format when you want to capture things that are not visible in system data, such as why employees take shortcuts or why certain exceptions always require extra effort.

When can process mining be relevant?

Process mining becomes more interesting when the process has large volumes, many system events, or large variations between units.

This can be useful when you want to see actual flow variations, bottlenecks, lead times, deviations from the standard process or differences between teams, regions and business areas.

But even then, business understanding is needed. Data can show that a step takes a long time. It can't always explain why it's reasonable, unnecessary, or risky.

Common mistakes when mapping processes

Process mapping works best when it is concrete, honest and linked to decisions. When it fails, it is often because the work becomes too abstract or too solution-driven.

You are mapping the ideal process instead of the reality

It's easy to draw the process as it should work. But then you often miss what actually needs to be solved.

Reality contains exceptions, shortcuts and special cases. They should not be hidden, but understood. Otherwise, the process map becomes a description of ambition, not reality.

You're making the map too detailed too soon

A process map can become so detailed that no one can or will use it anymore. Start at a level that can be discussed. Then delve deeper into the parts that need to be delved into at the right time and focus on where the delving is actually needed.

Control the level of detail based on the purpose. Will the map be used for improvement, requirements gathering, automation, internal control or system development? This requires different levels.

You're talking about systems too early

System support is important, but if the discussion starts there, you risk locking yourself into today's limitations.

Start with the process. Then consider what system support is required to make the process work better, and whether you should buy a standard system, build it yourself, or customize it for your business.

You forget the measurement points

If you want to improve your process, you need to know how to measure the improvement. Otherwise, it will be difficult to determine whether a new way of working or system support actually had an effect.

The metrics don't have to be complicated. They could be time from start to finish, number of manual steps, number of completions, percentage of cases following standard flow, number of errors, time on hold, or number of escalations.

The important thing is that the measurement connects to the benefit. Don't measure everything. Measure what helps you make better decisions.

From process map to requirements gathering

For Multisoft, process mapping is often closely linked to requirements gathering . This is because very few (no?) custom systems start with a ready-made list of features. They start with a business need.

When a process is mapped, it becomes easier to formulate requirements that are concrete. Instead of saying that the system should be user-friendly, you can describe what the user needs to be able to do at a certain step. Instead of saying that the process should be automated, you can point out which decisions, controls and handovers should be controlled by the system.

A process map can therefore become a bridge between the language of the business and the language of system development. Something that a solid requirements gathering should also be.

The process map helps you find the right type of requirements

Not all requirements are created equal. Some describe functionality. Others describe rules, roles, integrations, data models, permissions, reports, or non-functional needs.

When the process is clear, it becomes easier to see what requirements are needed. For example, a step in the process may indicate that a certain function is needed. A decision point may indicate that the system needs to handle a rule. A handover moment may indicate that integrations or permissions need to be investigated.

This makes requirements gathering more accurate. It also reduces the risk of important needs being discovered late.

When process mapping shows that standard systems are not enough

Sometimes the process mapping shows that the process is quite standardized. In that case, a ready-made system may be the right way to go. There is no point in customizing something that already works well in the market.

But sometimes the mapping shows something else. The process may be business-critical, industry-specific, or full of rules, integrations, and exceptions that don't fit into a standard system.

This often creates a choice. Either you adapt your business to a standard system, continue with manual solutions, build in-house, or develop customized system support on a proven platform.

The last option becomes relevant when the process is important enough to deserve better support, but where full in-house development feels too burdensome or risky.

For business managers, this is often the practical question. Not whether the process can be digitalized in theory, but which path provides the best balance between benefit, control, pace and long-term perspective.

What Multisoft can contribute

Multisoft develops customized business systems on the proprietary Softadmin® platform . This is relevant when the process mapping shows that there is no standard system that solves the need in the right way, or when several existing systems need to be tied together by a more business-oriented system support.

Multisoft's strength lies not only in building systems quickly. It lies in understanding the process, translating it into requirements, and creating system support that can be further developed as the business changes.

Questions to ask before you start

Process mapping is better when it starts with the right questions. Before you book the first workshop, it may be wise to gather business, IT and other key people around what you actually want to understand.

It's not about having all the answers right away. It's about pinpointing where the process is failing and why it's worth spending time on.

• Which process creates the most friction today?
• Where does waiting time, duplication of work or uncertainty arise?
• What manual steps are there just because the systems don't support the flow?
• Where are we most dependent on individuals?
• What decisions are made frequently, but in different ways?
• What data are we missing to be able to control the process better?
• Which parts could be automated without compromising quality?
• What systems does the process need to retrieve data from or send data to?
• What would it be worth if the process became faster, safer or more traceable?
• Is the process so unique or important that a standard system is unlikely to be enough?

When the answers start to become clear, you often have a good basis for the next step: a more structured mapping, a requirements gathering or a discussion about what system support the process actually needs.