How to match business and processes

Hi! I am Maksim Kataev, a senior business analyst in Tinkoff Mobile Core department. Our department develops common components (SDKs) for mobile applications: from authorization to design system. They are used in the applications of the Tinkoff ecosystem: Investments, Business, Mobile, and others.

I handle authorization: as soon as a client opens a Tinkoff application for the first time, he sees the screen that our team develops. But we are not limited to one screen: there are scenarios for a cross authorization, a partner authorization, an authorization of trusted people, and a dozen other mechanisms by which we grant access (or don’t) to a user into the application.

Analysts typically work with business processes and identify areas of concern, continuously striving to improve them. I am going to tell you about business process optimization: what to pay attention to when a stakeholder comes to you willing to change a process.

I tried to emphasize not on boring theory, but rather on the hacks that can be applied in real life. This text is basically for junior specialists, who start their career in the business analytics sphere. Let’s go!

A little bit of AS IS and TO BE

A business process creates a valuable result for the business, it has a decision maker, a start and an end points, time constraints, and it consumes resources.

The purpose of a business process is to make business solve its problem and ultimately make more money.

Business processes come in two states: AS IS and TO BE. AS IS — the current state by which the company lives now. TO BE — the desirable state by which you want the company to live in the future. Well, in case you didn’t know 🙂

The life cycle of a business process is usually organized into five stages. They are looped and form the Business Process Management Lifecycle.

These are the five steps that make up the cycle:

1. Design. As part of this stage, we need to understand why we are going to change a business process. This includes collecting business needs, describing the problem, and clarifying how this problem correlates with the business needs and how we will determine whether we have achieved success. It also describes the process in the AS IS state and highlights the problem areas that need to be fixed. The first step is to gather as much context as possible, which is going to be used to build the business process design.
2. Modeling. The stage where you need to figure out how to fix the problems of the AS IS process and model how the process will be in the future — TO BE.
3. Execution. It’s about approved process in TO BE notation. Here we need to get rid of the old process and teach all users how to act another way.
4. Monitoring. This stage is needed to monitor the business process to see if we have achieved the goal.
5. Optimization. After gathering enough data and feedback, we can start a new optimization cycle. This applies to minor tweaks: for example, if we see that there is a bottleneck in a business process, we can get rid of it and quickly implement it into an existing process. If, on the other hand, the process is outdated and requires renovation, we can start a new BPM cycle from the very beginning.

It should be taken into account that some companies may not have AS IS process in place. For example, there may not be a process for document management in a startup that has just started operating. Then there is no point in building an AS IS. The only way to design a process is from scratch and then immediately teach all users how to do things in a new way.

There is also no point in collecting the current state when there is no established AS IS. This happens when all users act chaotically and independently of each other. For example, accountant Anna can send documents for signing in Telegram (not in WhatsApp, for sure), accountant Alice can print and deliver them personally, and accountant Vera can send them by a carrier pigeon. Such a document flow can’t be described as a single AS IS process, because each accountant acts differently. It is better to make one common TO BE process for everyone and then teach the accountants how to act.

The theory is over, so let’s move on to the know-how. I will consider them in connection with the BPM cycle.

How to design or look for problems

This part is about a point where to start if you are asked by business to optimize the process.

Collect requirements. This is the ultimate baseline for business analysts that is sometimes forgotten. If colleagues come in with complaints about a process, it’s better to make sure that they are operating the process correctly. It may turn out that the they are just not, and then the problem is solved by instruction or conducting a presentation for the users. That’s why we say that the best task is the one you don’t have to do 🙂

Define the problem. If there really is a problem, we need to define it clearly. For example, we may aim to cheapen a process if it is costing the business too much and not generating commensurate benefits.

Determine how to measure the outcome. It’s important to define upfront how we will recognize that the problem has been solved and what we consider to be a good business process outcome. This is so that we can go back over improvements over time to see if we did everything well and correctly. This approach is useful for prioritizing tasks among themselves: the net profit from a task will help the product manager to sort tasks in the backlog correctly.

1. Incorrect result: Everybody should be better off
   Correct result: A business process is considered successful if costs decrease at least by 3% after the TO BE process is implemented
2. Incorrect result: We have to make a new process because our CEO wants us to do that
   Correct result: The time taken by users to go through all the steps of a business process should decrease. Let’s define the business process:

• excellent — if the time is reduced by more than 40% of the current median value;
• fair — if the time has been reduced by 20% of the current median value or more;
• poor — if the time has been reduced by less than 20% of the current median value.

A results focus is a must. If we had a good time when implementing a business process but did not create anything that was important for the business, this process is going nowhere. And no bonuses coming!

The design and problem-finding phase is the groundwork. If we perform it qualitatively, at the end we will understand why we undertook to optimize the process and how urgently we need to do it. Often it turns out that the task is not really that important and necessary — which means we can do anything else.

How to simulate or visualize the future

Now we can start preparing the process in the TO BE state.

Calculate the capacity of each step in the business process. People and machines have a limit to the number of operations they can perform per unit of time.

For example, one accountant can sign N papers and make M payments in a day. By using a simple equation, we can determine the workload capacity of one accountant. When counting, we should take into account that the value may decrease because people take on additional tasks, get sick, go on vacation, quit, or simply get lazy.

Optimize capacity. If you have properly planned the throughput and realize in advance that a bottleneck is forming somewhere, you can:

1. Get the process to an optimal state, when each worker is not blocked by other workers and is not idle. However, keep in mind that employees whose workload is 100% usually perform poorer than staff with 70–90% workload — breaks and free time is a must.
2. Add server capacity and hire people when there is nowhere else to optimize.
3. Forget it and take it for granted — just take these constraints into account in the context of process development.

Keep track of the time costs, they should be proportionate and appropriate. For example, if we build a spaceship from scratch and manage to do it in a year, this is an excellent result and Elon Musk can be proud of us. But if we take 100 years to build the same ship, no one will praise us for this: the technology will be obsolete and the company will go bankrupt.

How to reduce the time:

Pair activities that are independent of each other. Then independent executors may not wait for each other

Get rid of loops with a lot of iterations. For example, introduce a rule that after N iterations the process automatically moves to the next logical block

Minimize bureaucracy. When there are a lot of manual approvals in the process, people make mistakes and fail to meet deadlines

Consider the risks. They are divided into four types: legal, financial, technological, and human.

1. Legal risks occur when a change in legislation directly or indirectly affects a process. For example, if foreign software is used in the document flow, and the government prohibits foreign vendors from working with companies in the country, the process will have to be redesigned. It makes sense to prepare for this risk in advance and switch to software from a vendor that will not be banned, or change jurisdiction. Also, because of legal risks, the apps can be removed from the app stores, but that’s a different story…
2. Financial risks may occur if, for example, a startup is backed by several large investors. In such a case, there is a risk that the investor will leave and the business will start cutting costs — then the most expensive process will be the first to go under the knife (but only if it does not generate a comparable profit).
3. Technological risks are software and hardware failures. Sometimes the servers respond with a 5XX error, the internet blinks, and the power goes out — these are situations you should be prepared for. What to do if an accountant spent six hours filling out a huge report, the power went out and the report was not saved?
4. There are human risks wherever there are people. It’s worth considering what happens if a person makes a mistake. Do you need the ability to roll back changes and correct the error? Should we be well prepared for unexpected sick days?

Watch the cost and don’t overengineer. IT specialists (usually junior ones) sometimes suffer from a professional deformation: they try to automate and optimize everything around them. Automation does not always bring profit — sometimes it makes the business lose money. In this case you might be asked to roll everything back.

Imagine that a company asks you to optimize the reference process.

This is what the process looks like at the start

Now the accountants’ department issues certificates manually: a dozen users per day write to a company by mail, the accountants read the mail, fill out a template in “MS Word”, sign and send it back. Business is asking to reduce accountants’ involvement in this process.

The first thing that comes to mind is: of course, we need to generate certificates automatically! Let’s attach a script that will parse the mail, the backend will start generating certificates, we will sign them with an EDS, and then send them back to the mail. Beautiful!

How the TO BE process might look like

As soon as we calculate the cost of a business process, we quickly realize that it takes more resources than brings in. We plan to use several systems and set the tasks for more than 1 team — IT guys alone with their Zoom meetings will spend more money than the original process brings us over a couple of years.

So we need to do things differently. For example, hire a couple of college students and ask them to do the accountants’ job. Voila — we’ve solved the problem and saved the company money!

The conclusion of the block is simple and straightforward: by calculating the resources and considering the risks, you can achieve a favorable outcome.

With this business process in place, we will achieve the goal and benefit the business — we can head to the bonus!

How to implement and measure success

It is dangerous to launch a new process on everyone at once. If you are sure of your decision, no one forbids it, but even professionals can make mistakes. It is impossible to get rid of mistakes forever, but you can reduce their cost.

One of the options is to gather a test group and let them test the process. You can collect feedback and, if there is a critical one, go back to the modeling stage and refine the process. Also, a good test in a small group will let the business know that you’ve done a cool thing — the chances to get a bonus will increase.

Sometimes newbie analysts after the implementation stage unfairly think that their task is complete. But the process is rolled out to all users and somehow it even works — so you can switch to another task. But gradually the context in which the process works may change.

For example, a company has grown ten times, hired new employees, opened new business lines, and changed related processes. If you leave the process, it will gradually become obsolete and you may miss a critical moment, after which large-scale and expensive changes will be required.

Observe and highlight the insights. Regular monitoring of metrics, user interviews, gathering insights, and ongoing feedback collection will help you understand what, where, and when you need to refine the new process before it’s too late.

My favourite idea that I want to share in farewell: you should not use all knowledge at random and just because it is written in theoretical materials. No one forbids you to change the approaches if your current situation requires it. But first make sure it really requires it. 😄

Thanks for the reading to this point! I will be pleased to read your feedback in the comments.