Business process transformation

I'll start with some questions. Do you think regular office work needs inspiration? Can an employee burrow into a task and do it incredibly well, but miss out on the other two? Or does he have to do all three tasks in an average way, because the plan, KPIs, OKRs, business processes, regulations?

I will leave my opinion for an article, but for now I will say that in the corporate environment there is a whole layer of process slaves: managers and employees who are willing to do anything to comply with regulations, formalities. And it, as it seems to me, is infinitely bad, infinitely boring, partly stupid, and most importantly, very dangerous for the whole company. Because there is nothing worse than indifferent formalism. Have you encountered it?

Am I against business processes?

No! Business processes are cool. In any company, from a small sole proprietorship to a giant corporation, having business processes is the pledge of order and the absence of a variety of management headaches. Perfect: a routine task is transformed into an algorithm with input conditions, triggers, branches and so on. Only instead of the machine, the algorithm is executed by people, for whom deadlines and responsibilities are set. You do not have to worry about such a task, it is performed automatically, and it is even better if it is automated within the framework of ACS, in particular CRM or ERP.

What is important for business processes?

Steps (stages)-it should consist of clear, as simple discrete steps as possible, each of which is a clear, achievable task (not necessarily simple).Consistency - the whole set of business processes in the company should be coordinated and regulated in terms of overlaps.Changeability - business processes need to be reviewed and improved. If the processes do not evolve, your company will stagnate (i.e. it is behind the times and competitors).

What's bad for business processes?

Turning them into a cargo cult

It happens that an immature manager will see that the process approach and business processes have worked for one group of tasks and immediately drag them to other groups and tasks. In this case the team gets discouraged because they are forced to act according to certain schemes even if they don't make sense (indeed, not everything in the company fits into the coherent logic of a business process).

Chasing metrics

If you are not a defence plant, a pharmaceutical factory, a hospital, a special service etc., i.e. your work does not directly affect the lives and safety of people here and now, work tasks - oh, surprise! - can be postponed. And yes, do one qualitatively and in depth and then take on the rest, even if you get out of the plan. In such cases, quality work and in-depth approach should not be condemned, but rather celebrated. In the end, both you and clients will appreciate what is done thoughtfully and conveniently, not on the knees in a hurry (first of all, of course, it concerns development, but the situation is similar in other areas as well).

Pointlessness of business processes

Development of algorithms to perform tasks when the tasks are not homogeneous, not repetitive, vary greatly from start to start, have a high level of creative component, etc. Starting a one-off task by drafting a business process for it is bureaucracy and imitation of work. There are agile management models, ad hoc approaches and many other ways to take on and complete a task for such situations.

Business processes as a punishment tool

Team members who make a mistake within the process or take the initiative for positive change during a neglected process are punished verbally, in writing, by being depressed and universally despised. It should not be like this: while we are in the world of working people, the human being is more primary than the process and must be listened to. All the more so because very often the performers within a business process are much more aware of the real state of affairs than the architects of the business process.

All these factors taken together and one by one turn a company into a slave of business processes. Here it is, the great algorithm as a totem and an idol, but the executives and managers believe that the totem will work in any situation, should it be applied to any corporate sore point. But it doesn't!

To avoid some of the problems, you have to design business processes correctly. The right thing to do is not in BPMN notation, not in CRM, not on a piece of paper but with your head - a good, working, thinking head. This is a very important nuance because a single illiterate, inefficient or ineptly assembled business process can strike a blow to product, team, customers and profit. And business process inefficiencies are also more often than not costly - and this is not a metaphor, but "costly" in terms of resources used and money wasted.

"So why don't we just forget about business processes? If you didn't live an automated life, don't start one", some readers of this article will probably think so at some point. Many people think this way, especially in small business. And it's the wrong approach, because you can't live with bad business processes, and you can fail everything without them. If you have a routine and/or repetitive tasks, you need processes.

And I'm going to tell you point by point what to do to not become a slave to processes, but to master them and use them for the betterment of the present company and team.

How do you work with business processes?

Generally to manage the life cycle of business processes in a company there is a well-established and reliable model DMAIC (define, measure, analyze, improve, control, aka OIASC - define, measure, analyze, improve, control), which leads the team through the steps and almost never leaves without a positive effect on the output (unless your team is a swan, crab and pike). I will rely on it, but I will describe some points in more detail because, working with RegionSoft CRM and our clients, I see that small companies rarely approach modeling and using business processes, and newcomers to enter the management paradise on DMAIC model is quite difficult at once.

Defining business processes

The first step is to define everything possible: goals, objectives, requirements, roles, business processes. You have to start with understanding what is important for the company and the team (sometimes it's just different "important"), what risks the manager bears, what has already been worked on and why it is bad or good. All of this can be done formally and according to methodologies, or you can have a quiet brainstorming session within the team, discuss its results and make sure all of the ideas and conclusions are written down. The approach to the methodology and format depends on the size of the team, its cohesion, ability to negotiate and willingness to work without a "stick" from above. As a rule, the democratic approach of generating ideas and plans out of chaos works well in small and medium-sized businesses. So what should be done at this stage?

Understand if there are processes in the company: what is routine, what is repetitive on an ad hoc basis, where failures occur, what slows things down, what proportion and what resources are taken up by major projects and whether they include routine (usually yes).Gather requirements from staff and departments: understand who does what and when, who intersects with whom, etc. The easiest way is to draw all connections and chains on paper in the form of a classic flowchart to collect a ready algorithm of actions afterwards.Identify process chains among all tasks and actions and fix something like MVP - ready scheme with details of deadlines, responsible persons, transitions, events-triggers.At a minimum we may combine processes into algorithms described in the visual editor. But it is better to use XXI century achievements and "plug" business processes into special software - for instance into CRM-system module. There are several advantages: Process Wizard (you are led "by the hand" while creating an instance of the process), operating triggers (you don't have to remember a call or a letter, when you move from one stage to another everything will happen automatically), logging (you can immediately see where the process has stalled, who broke the deadline, where the problem is), well, analytics (which you will need a little later).To run the processes is to work with them for some time, to see how the team's work has changed, to identify objective and subjective findings and shortcomings, to record ideas.

Yes, you probably won't get it perfect at once, that's why there are 4 more letters besides D in the model.

Business processes measurement

This is the main tool to analyze the effectiveness of the work done. The goal of business process automation is the speed of the process from start to finish. Therefore the first measurement should be done even before automation. Collect data on the average time taken to complete the process and record this value. Repeat these measurements after automation is implemented. You should see an acceleration. If you do not, you have not configured the automation correctly. But if you see acceleration, then you have achieved the main primary objective and can now continue to accumulate statistical data in order to improve it again or even several times in the future.

Sometimes measurement is paired with process testing - i.e. the process seems to be being tested, but the data about it is already indicative of future real work. It doesn't matter - what matters is what you collect and how you collect it.

Subjective feedback from everyone who works with the business process every day: the process owner, employees, performers, customers, anyone else in the chain of activities. This is the most valuable information, because it is extracted in a real work environment.Quantitative indicators: time to execute, number of steps, duration of each step, measurable result, etc.Technical indicators: whether all steps have been taken into account, whether the process is redundant, whether triggers work, whether the work of the business process is embedded in the automation loop or exists as a formality in and of itself, etc.

It is important to aggregate all the information in files in order to refer to them at the next stage.

Analysis

So, the business process cycle or cycles are complete, the feedback has been collected. It's time for analysis for future process refactoring.

Determine which processes work, which don't, and which are zombies (hang, unnecessary, time-consuming without significant results).Identify weaknesses in all processes. Identify successes for each process.Find the causes of failures in the processes, describe them.Break down the processes into relatedness groups - this is needed to combine some processes into one.Take the time to decompose poorly performing and zombie processes.

Make temporary changes to the process maps (if you have them, they are sometimes described after the business process redesign) and to the process diagrams.

Get ready to change.

Improve

This stage is as important as the definition stage. If you like, this is the redefinition stage - global refactoring and process redesign takes place. And it's not all straightforward here either: it doesn't just happen the first time after the business processes have been created and implemented in the company, but actually continuously:

when a new process is created and tested;when existing business processes become obsolete;when input data and process objectives are changed;when the company's goals change;when significant changes occur in the external environment affecting the business processes.

Since process debugging is a permanent thing, it … also needs to be turned into a business process, i.e. made as quick as possible at the start, efficient and operational even in the face of new conditions and risks. Basically, there are three basic conditions for this:

Collect feedback on a continuous basis (you can do it without analysis, but it is more convenient to do it with analysis);Automate everything that can be automated - this will free the hands and heads of the team for intensive problem solving and not the company in routine, showdowns and memories of who did what wrong;do not be afraid to kill processes: if you see that even after the next iteration of redesign the process is ineffective or does not work - exclude it from the system, so it is not needed (for example, the process of publishing an article on the Hubr is a valuable, convenient and necessary essence, but the formal process of writing an article is a waste of time, because it is a discrete semi-creative process, which often also lies above the work tasks).

So, how do you do business process transformation?

You have already collected and analysed the feedback, all the problematic process nodes have been found - most of the work is done. During business process reengineering (another synonym, they are all found in the core literature and used in practice) it is important to take a few steps to consolidate success and get what it was all about.

Simplify all procedures, make them unambiguous, clear and logical.Eliminate unnecessary tasks and subtasks - they interfere with processes, waste time and resources.Take into account all changes designed on the basis of feedback and analytics.Overcome resistance from employees who may be too lazy to change processes and deliberately distort information to avoid diving into refactoring.

Once you have done all of the above, you are back in the cycle of definition - measurement - analysis - improvement.

Everyone should be involved in working on business processes: both employees and management. Whether or not to involve external mentors is up to everyone, but usually when properly organised, the team does quite well on its own. A process definition working group is a desirable group of people who are able to collect, analyze requirements and outline MVP processes. The advantage of such a group is that the rest of the staff is less busy with processes and gets a ready, professional schematic, draft and process maps.

Control

The simplest but nonetheless mandatory process: collecting reports, checking deadlines and process logs, analysing results, preparing for feedback collection. Sometimes it is missed but this is fundamentally wrong: you may miss the factual information that will trigger a change (e.g. the process is perfect but the result is totally different from what was expected and it turns out that the business process exists for its own sake.

Business processes are sometimes referred to as the user interface of work tasks. And this is a really cool definition: well-designed business processes really do make life easier for the team, more integrated into the work flow. Yes, it's easy to get rid of business processes because developing an effective system of processes in a company is time-consuming and resource-intensive. But it often leads to chaos. What's more, the flexibility and success of an entire team depends on streamlining processes and continuously improving them. But if you show a little healthy stubbornness and work on business processes, the result can be downright cosmic: literally through the thorns of process development and automation to the stars of team achievement. And this is not pathos for a long time; it is business as usual for an intelligent team, not slaves to processes.