How we implemented business processes and why we need it at all

When a company is small and everyone knows everyone (up to about 30 people), no formalized business processes are needed, in theory. When a company is large, geographically divided, or the tasks are non-trivial, the amount of mess begins to rapidly increase. We must fight this. For example, we decided to implement business processes at the moment when we no longer recognize some of our own employees.

The first reasonable question that I want to ask is why this “bureaucracy” is needed at all. The answer is simple: in principle, it looks like refactoring. Outside, everything is the same, but inside it is already logical, it works well and you can quickly develop further.

An example of a staged process from the 1900s

Workers at the Ford plant assemble parts on the conveyor. The worker receives 5 bucks a day and collects 30 units of production. Henry Ford looks at the worker for an hour and realizes that he does a lot of unnecessary actions. He tries to assemble the part himself using the new scheme, and he understands that, in theory, this can be done faster, but you need to slightly change the conveyor, move the equipment, and, most importantly, teach the worker to perform other movements. Through "I do not want," he teaches this person to do what is necessary - and, voila! - it still continues to receive 5 bucks a day, but already produces 42 units of production.
')
Habitually? Not. Intuitive? Not. Profitable? Yes, if the cost of re-equipping and re-training workers is less than the estimated profit.

And the introduction of business processes: you need to understand what is at the entrance, what should be the result of the output and how to achieve it optimally. If the cost of the work of researching and changing the company is less than the expected profit from it, you need to do it.

Chronology of struggle with the mess

We went through these stages:

1. We are four people, everyone understands everything.
2. Two different stores appear: the rules for receiving mail and the rules for mandatory responses to it are already needed.
3. Representations in the cities appear. A systematic collection of information begins for internal instructions, advice and other pieces designed to help in different situations: in fact, positive experience and hereditary collections of the rake.
4. Complicated site interaction. Developers raise tracker and ticket system.
5. There are so many of us that the same questions are asked more than three times. A closed corporate blog is being established to be able to keep abreast of everything, quickly report problems, and change process mechanics.
6. A team of specialists is hired who plan business processes within the company, compile accurate instructions and orgschema. In fact, there is a process of describing existing processes and optimizing them where necessary.
7. All this joy is pondered under the situation.

Are processes needed if a team of 10 people?

Yes, but not to understand “what and where”, but to stabilize the work process and limit liability. I will give an example from the life of my former company.

Example 1: a simple but familiar to the pain - a feature from the client.

1. Meeting the client and the manager to set the task.
2. Coordination of job acceptance criteria.
3. The head of the department is a technical task developer.
4. Terms of reference or test points are agreed with the client.
5. Development in progress.
6. The head of the department conducts acceptance.
7. The manager conducts the delivery of the project to the client.

If you are a developer, with this process it means the following things:

• No one except your manager can set tasks for you (even the general director).
• You never work without a clear terms of reference.
• You do not see the client. You do not even see the manager, if you really want to.
• A client who suddenly changed his mind with a new idea on the last day of development is a manager's problem.
• You are responsible for the shoals only in front of your manager (and he is in front of the client).
• You do not work for "fatigue", but for the result. That is, if the development was completed in an hour, it does not mean that you will receive less than if it were done in a month.

Everything is simple, logical and understandable, but causes costs associated with the need to comply with the protocol.

Example 2, now from the practice of Mosigra
Introductory: there is a crazy office for 50 people and clearly structured retail stores. Suppose a retailer in retail needs a new shelf in return for a newly broken one. This is what it does in the old scheme:

1. Appeals to the senior point and reports the problem.
2. The senior of points refers to the regional coordinator and reports about a problem.
3. The coordinator knocks on the head of the AXO department and reports the problem.
4. The head of the AXO department sets the task for the laborer.
5. The handyman approves the budget of his supervisor for a new regiment.
6. The financial director is on the table under the signature.
7. The next day comes.
8. Work finally puts a new shelf.

If in the process something is interrupted, the regiment will arrive only after the seller tells the elder once again about it and the whole scheme is passed through again. It is clear that it is described quite exaggerated and in real life everything is simpler, but 10-15% of the processes without a clear scheme can still fail, for example, if the manager is ill.

Now the same situation looks like this:

1. The seller calls the AXO and reports the problem.
2. An employee of the Operations Department decides whether to use the funds.
3. Worker puts a new shelf.

Please note: the head of the store employee is not involved in the process. And one more thing: if an employee of the AHO, the new regiment can cost twice as much as the normal price for such situations, an alert is generated for the financial director.

If the AXO issues an invoice that goes beyond the plan of their department, an alert is generated for the management, where there are two buttons: “give lyuly” and “allow”. If desired, you can click both. The essence of mechanics: the path is shorter and faster, but full control is preserved. No extra action.

Metrics

When you know exactly who and what is doing, there is one more thing that is indispensable for large projects: the ability to assess the performance of specific people and predict the speed of certain things.

For example, it is relatively easy to consider the efficiency of an online store operator: the percentage of calls received, the average check for orders and other easily formalized parameters make it clear what and how.

It is already more difficult to evaluate the work of the purchaser: but the construction of the business process makes it possible to understand what happened next with the product, how it became and how effective it was.

Shoals

All of the above would be just a theory if it were not integrated into the management and accounting system (in our case, in 1C). Now, for example, if someone calls the store and orders a product that is not available right now, this information either immediately reaches the purchaser, or it folds into the collector of the jambs. As a result, the head of the procurement department clearly sees the problem and has the opportunity to take action.

When sectoids parachute

They say that the military has instructions for all occasions: even if a UFO arrives with plasma tanks, they have an exact plan of action in this case. So with the processes: ideally, they are for all occasions of the employee. When an employee does not have a contingency plan, two things happen:

• He refers to the one who is responsible for this question (most likely, without distracting his leader).
• If the situation repeats, a process rule is created to handle such cases.

How is it all being introduced to the company?

1. First, the analyst talks to the manager and understands the task. It so happens that the processes are introduced for a tick so that it is more profitable to sell the business to a foreigner, it happens that for Ponts, and sometimes for business. The last case is the most interesting and difficult.
2. An invoice that induces an ohu cognitive dissonance is billed. At this point, you need to agree on such conditions that the payment is made with an increase in specific indicators. Roughly speaking, they began to receive 20% more profit as a result of the introduction - pay.
3. Then the analyst goes around the whole company and asks many, many questions about how it works.
4. Then, each employee receives a questionnaire with a request to indicate their tasks to be performed (half an hour is filled).
5. The analyst tensely thinks and draws up a block diagram of the interaction from which the processes and the organic scheme of the company grow.
6. The company is reorganized into new processes.
7. Employees hear the essence of change. If employees are aged, they understand tight, but they do right away. If the young - understand perfectly, but change slowly.
8. Corrected bugs. The structure changes as the company and its processes change.

Timing

Our process took about a month to collect data with analytics (working under the Lunokhod-1 program) and analytics in the state, another month went to collecting and checking the questionnaires, after a lot of time the orgschema and processes appeared, then it was all implemented. In total, everything took about six months.

Why else do you need to implement such things?

• To control the workflow, do not lose the task and see who and what specifically does.
• For each thing in the company there is a specific responsible person (each problem has a surname).
• Not to explain each time to a new person, for example, how to arrange departure, etc.
• It is more efficient to scale without explaining the whole essence of life to each employee in another city.
• Quickly accept new people.

Summary: Pros and Cons

Pros:

• Less chaos, more order
• Clear job descriptions appear.
• There is an orgschema that optimizes processes.
• IT processes are closely associated with the real, it becomes possible to automate a pile of things.

Minuses:

• The procedure takes a lot of time and requires a lot of money: for example, starting it at the seasonal peak of sales is not the best idea.
• The consultant is not a wizard. He does not solve problems, but offers typical solutions (which are also in books) and helps to grind them into the company. These typical solutions are implemented with the direct participation of the leadership.
• We will have to work a lot and hard ourselves both in the construction of processes and in the implementation.
• In the end, it is expensive for the company, so you need to very clearly understand what exactly all this will give.

I will continue the comparison with refactoring: it is expensive, complicated, you should not start doing it a week before the big release, but it’s very useful if the project has grown into a big, heavy one and a lot of different people are working on it. And the completion of refactoring (but not the process itself) is very calming the nerves of all those who used to fall into a rage, seeing the Chinese code.

UPD . In a personal reminded that in order to build business processes, it is necessary to formulate strategic goals and even a mission (in the good sense of the word). Yes, otherwise it will be unclear what to do, where to do and how to do: you need a kind of DNA or the modus operandi of the company.