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?
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.
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).
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).
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.
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.
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.
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?
Yes, you probably won't get it perfect at once, that's why there are 4 more letters besides D in the model.
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.
It is important to aggregate all the information in files in order to refer to them at the next stage.
So, the business process cycle or cycles are complete, the feedback has been collected. It's time for analysis for future process refactoring.
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.
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:
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:
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.
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.
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.