In a company with 50–250 employees, there comes a point when the business is no longer what it was a few years earlier. More people, more customers, more suppliers, more approvals, more administration, more exceptions. Yet operations often still rely on the same tools used when the company was half its current size: email, Excel, phone calls, face-to-face discussions, “ask Judit,” and “we have always done it this way.”
For a while, this works. From the outside, it may even look flexible. Colleagues get things done: they make follow-up calls, forward messages, pass things on, search, and investigate. The invoice is not where it should be, but someone finds it. The quote is awaiting approval, but someone forwards it. The customer complaint reaches the wrong place, but someone will notify the right person.
But this is not a system. It is an operating model built on people's memory, goodwill, and capacity to absorb excessive workloads.
And this is fundamentally where the leader's problem begins. They sense that something is wrong, but it is difficult to pinpoint. Approvals are slow. There are too many follow-up questions. Decision-making authority is unclear. The same task is being handled in several places. The only way to find out the status of a case is to call someone. Finance, HR, procurement, and customer service are functioning, but they cannot be managed with clarity.
This is usually when someone says: we need to digitalize.
That is a sound realization in itself, but it can easily lead in the wrong direction. Digitalization does not begin with buying new software. It does not begin with deciding that you need CRM, ERP, workflow, or AI. Digitalization begins with examining how the company actually operates.
In Hungary, digital infrastructure is already adequate in many places, but that does not mean companies have completed the digitalization of their operations. What is missing is not an internet connection, a laptop, or online meetings. It is the ability to make operations transparent, measurable, transferable, and open to improvement.
And now AI enters the picture.
Everyone is hearing that AI will take care of administration, reporting, customer communication, document management, and decision support. There is real potential here—and plenty of it. But there is an uncomfortable reality: AI will not bring order to a company that cannot clearly explain how it works.
If we do not know who approves what, under which rules, by what deadline, with which exceptions, and with what accountability, AI will not create order. It will simply move the disorder along faster.
That is why, as a leader, your first question should not be which software to buy. Nor should it be which AI tool to try. The first question is simpler, but far more important:
Do we really know how our company operates?
Start with an operational overview, not software
Most digitalization projects go wrong because they start with tools. We need CRM. We need ERP. We need a project management system. We need workflow. We need automation. We need AI.
Perhaps you really do. But that is not the first step.
First, clarify what kind of operation you want to see. Where do you want management control? Where does the lack of visibility hurt most? Where is there too much email? Where do cases stall? Where does the company depend on knowledge held in one person's head? Where can we not say how long a process takes?
Leaders often believe they know their own company. And they are partly right. They know the key figures, customers, key people, and problems. But in a growing company, the details of day-to-day operations quickly move beyond their direct visibility.
They cannot see exactly how many emails a purchase requires. They cannot see how many sources finance draws on to assemble an approval. They cannot see where an HR process gets stuck. They cannot see how many people handle a customer complaint before someone finally takes responsibility for it.
This is not a leadership failure. It is a natural condition of growing companies.
As the company grows, operations develop layers. At first, everyone knew everything. Then came department heads. Then specialists. Then policies. Then Excel spreadsheets. Then exceptions. Then the people who “have been here for ten years—they know.”
Eventually, the company stops operating as a system with centralized visibility and becomes a network of local habits.
This is where process assessment becomes a management tool.
We are not talking about placing a few attractive process diagrams in a shared folder. Nor about writing a policy that nobody reads afterward. This is about helping management regain visibility into operations.
The purpose of process assessment is not to document every minor action. It is to make clear:
- who does what,
- when they do it,
- what their decisions are based on,
- who they depend on,
- where they hand work over,
- where work gets stuck,
- what happens when an error occurs,
- and which parts can be automated.
Once this is clear, digitalization becomes operational improvement rather than a software project. That is a major difference.
AI does not replace process assessment
There is too much noise around AI right now, and leaders need to see through it. The problem is not that companies want to work with AI. The problem is wanting to work with AI while their own operations remain disorganized.
AI does not become useful simply because we introduce it into the company. It becomes useful when we know where it fits.
Consider a simple example. An invoice arrives by email. Someone forwards it to a manager. The manager asks a follow-up question. Finance searches for the contract. The confirmation of completion is missing. Three days later, it turns out that the whole transaction was assigned to the wrong cost center.
You can apply AI to this. It can summarize the email, extract data from the invoice, and suggest a reply. But the process remains disorganized.
AI can add value once we have clarified when the process starts, what inputs are mandatory, who is responsible first, which rules determine the next step, who can make decisions, what value threshold requires management approval, what happens when data is incomplete, and where the case closes.
Do not start with an AI project. Start by understanding the processes.
This does not slow down digitalization. Quite the opposite: it prevents it from heading in the wrong direction.
Of course, AI can and does play an important role in assessing, mapping, and analyzing processes and identifying industry best practices. But in an established, operating company, an internal assessment is difficult to avoid. You simply need to consider: how do we do this today? xFLOWer.ai can be a great help in assessing a process and drawing process diagrams. Enter a prompt—as detailed as you like—and your process diagram will be ready. Free to use: xFLOWer.ai
Is digitalizing a flawed process a mistake? Yes and no
We often hear that flawed processes should not be digitalized. There is truth in that, but the reality is more nuanced.
If there are unnecessary approval rounds, no clear owner, poorly assigned roles, or exceptions in every other case, these flaws will remain in a digital system. Sometimes they become even more visible.
But there is another side to this.
A flawed but digitalized process is at least visible. It runs consistently. It can be measured. Its history can be retrieved. You can see where it gets stuck. You can see who fails to act on time. You can see which field is always missing. You can see how many days a case spends awaiting approval.
That is still better than a process that is flawed, invisible, and handled differently by everyone.
The worst operational situation is not an imperfect process. It is a process that is imperfect, dependent on individuals, invisible, and impossible to improve.
So there is no need to be alarmed if the first process assessment reveals an unflattering picture. In fact, that is normal. If actual operations differ from the policy, it is not a scandal. Policies often describe how the company should operate. Process assessment reveals how it actually operates.
The gap between the two is not a source of shame. It is the opportunity for improvement.
What should leaders aim to achieve?
Before assessing processes, you need to decide on objectives, not tools. In a company with 50–250 employees, the most important objective is usually not to “automate everything.” That is too broad, too technology-focused, and too easily misleading.
The first objective is transparency.
Transparency delivers most of the business benefits: faster decisions, fewer errors, less dependence on key people, better management control, more accurate reporting, easier training, and more stable operations.
Management control is not micromanagement. It does not mean the managing director intervenes in every small task. Quite the opposite. Good control means they do not need to intervene in everything because they can see that the system is working.
With a well-designed workflow, leaders receive information not because someone prepares a separate report for them, but because information is generated automatically through operations.
They can see how many cases are in progress. Where they stand. Who they are assigned to. Which step has a bottleneck. Where a decision is needed. What is falling behind schedule.
This is an entirely different management position from seeing what is happening in the company only once something has gone wrong.
The second objective is ease of handover.
A company can be handed over when its operations do not exist solely in a few people's heads. The knowledge of the owner, managing director, finance director, office manager, or a long-serving key employee is valuable. But unless that knowledge is translated into processes, systems, and responsibilities, it is also a risk.
The third objective is scalability.
A company does not grow effectively by hiring another person for every new problem. It grows effectively when its operations become less dependent on ad hoc manual solutions.
The fourth objective is to clarify decision points.
In many companies, it is not operational work that is slow, but decision-making. It is unclear who approves what, above which value threshold, based on which document, and by what deadline.
The fifth objective is measurability.
You do not need to build a complex KPI framework immediately, but improvement requires a few basic metrics. Lead time, approval time, number of stalled cases, percentage of overdue tasks, number of manual steps. Without these, we are managing by intuition alone.
The fundamental management principle is simple:
What we cannot see, we cannot manage. What we do not measure, we cannot improve.
Where should we start?
You do not need to assess everything at once. In fact, you should not.
A good process assessment does not begin with a comprehensive scan of the entire company. It begins with management choosing a focus. First, identify where the lack of visibility hurts most.
The most strategically significant area is not necessarily the best starting point. A complete contract management system, for example, may be very important, but too ambitious for a first project: many exceptions, legal variations, decision points, and stakeholders. It can easily drag on, causing the organization to lose momentum.
A simpler but frequently used approval process can be a much better starting point. Purchase requests, invoice approvals, leave approvals, internal requests, customer complaint escalation. Not because these are more important, but because they make better learning projects.
The first process should have a significant impact, recur frequently, be relatively easy to standardize, and currently involve a great deal of email or Excel.
Processes with too many exceptions, heavy dependence on individuals, or internal political sensitivities should not be forgotten. They simply should not be your starting point.
xFLOWer.ai offers a variety of solutions for process mapping. Try starting with the basic building blocks in the xFLOWer.ai periodic table. Your process diagram is ready in one click.
Start with a process inventory, not a process diagram
Many people assume that drawing a process diagram is the first step in process assessment. It is not.
The first step is a process inventory.
This is a simple list of the company's main operational processes. It does not need to be perfect. It does not need to include every detail. Its purpose is to give management and key departments a shared view of the operational building blocks that make up the company.
These processes might include:
- financial approvals,
- invoice management,
- purchase requests,
- contract preparation,
- HR administration,
- employee onboarding and offboarding,
- customer complaint handling,
- internal support tickets,
- management reporting,
- document management,
- equipment requests,
- leave and absence management.
The purpose of a process inventory is not immediate automation. It is to create a map.
How often does the process run? Who is involved? Who owns it? Where does it start? Where does it end? Which systems are involved? How much email or Excel does it require? Where does it typically get stuck? How dependent is it on management? How suitable would it be for workflow?
These questions alone reveal where management has lost the most control.
Which tools should you use?
For process assessment, choose the tool that fits your organization's maturity—not the trendiest one.
For a medium-sized Hungarian company, introducing a complex modeling methodology is generally not the right starting point. A better sequence is:
- first, understand the reality,
- then structure it,
- then model it,
- and automate where it makes sense.
Management interviews reveal what leadership expects. Interviews with key employees uncover undocumented practices. Workshops create a shared language. Excel or another spreadsheet can work well for a process inventory. Miro, DRAW.IO, or FigJam support visual thinking. A swimlane diagram shows who does what and where work is handed over. BPMN is useful for more complex processes connected to IT, but it may not be the best place to start. Process mining and process intelligence are powerful approaches, but they work well only where meaningful system data already exists.
The key point: do not start by trying to showcase a methodology. Start by understanding operations.
Assessing a process is not the same as running it
As a leader, it is essential to distinguish between the two.
Assessment tools help you understand and describe operations. These include interviews, workshops, process diagrams, Excel lists, and BPMN models.
An automation tool, on the other hand, actually runs the process. It assigns tasks. Manages deadlines. Sends notifications. Requests approvals. Links documents. Creates decision branches. Logs activity. Produces reports. Integrates with other systems.
This is where the journey stops at many companies.
The process assessment is completed. There are attractive diagrams. Management approves them. The document goes into a folder. The next day, the company continues operating through email, Excel, and phone calls, just as before.
That is why, from the start of the assessment, you need to think about turning the mapped process into an operational reality. You do not have to automate everything immediately, but it is worth designing the process logic so it can be executed later.
This is where a workflow platform such as xFLOWer comes in.
Not because every process assessment must end with a system implementation. But because, beyond a certain level of maturity, leaders want not only to see the process, but to run it as well.
A process is not a drawing. A process delivers value when it runs.
How should you involve colleagues?
The most sensitive aspect of process assessment is human, not technological.
If we communicate it as “finding out who is doing what wrong,” people will become defensive. If it sounds like “identifying where people can be replaced,” it will create fear. If management develops something behind closed doors and then imposes a finished system on the organization, it will create resistance.
The right leadership message is simple:
We are not examining people. We are making work easier.
Saying it once is not enough. Your actions must reflect it.
Colleagues need to feel that the assessment is being carried out with them, not against them. They know where day-to-day operations hurt. They know which Excel file has three versions. They know where unnecessary follow-up questions are needed. They know which approval is quick only on paper.
Leadership explains why the project is starting. Process owners show how it should work. The people doing the work explain how it actually works.
Together, these three perspectives provide a realistic picture.
Before a workshop, it is worth stating clearly:
We are not asking how the policy says you should work. We are asking how you actually work. It is fine if there is a difference. That is exactly why we are here.
This is a liberating statement. In most organizations, there is a gap between operations on paper and reality. That is not the problem. The problem is when people cannot talk about it.
Key people represent both value and risk
Every medium-sized company has key people. They are the ones who “know everything.” They know how to speak to each customer. They know what to watch out for with each supplier. They know where the latest Excel file is. They know which manager wants information in which format.
They represent tremendous value.
But leaders also need to recognize the other side: if operations depend too heavily on them, the company is vulnerable.
Not because they have bad intentions. But because human knowledge cannot scale indefinitely. A person goes on leave, becomes ill, burns out, leaves, gets promoted, or simply has too much passing through their hands.
The goal of process assessment is not to reduce the value of key people. It is to turn some of their knowledge into organizational knowledge.
That is an important distinction.
We are not taking knowledge out of their heads. We are protecting both the company and those employees from having everything depend on them.
A well-assessed process organized into a workflow does not weaken a capable colleague. It removes some of the repetitive administration, searching, and follow-up work, giving them more room for meaningful professional work.
How to run an effective workshop
A process assessment workshop does not need to be overly complicated. It needs a clear objective, the right participants, and a disciplined structure.
At the start, the leader should explain why everyone is there:
We are here to see how the process works. We are not looking for someone to blame. We want to understand where we can make work simpler, more transparent, and less dependent on individuals.
Next, clarify the start and end points. When does the process begin? What is the first event? What counts as completion? What falls within the process, and what falls outside it?
Then identify the participants. List roles, not just departments: requester, reviewer, approver, finance administrator, completion certifier, manager, administrator, external partner.
Then record what happens, step by step. A request arrives. Someone checks it. A piece of information is missing. It goes back to the requester. An email arrives. Someone forwards it. The manager approves it. Finance records it. A document is saved. The relevant person is notified.
Throughout the workshop, the most important question is:
Does it always happen this way?
If not, identify the exceptions. They do not need to be resolved immediately, but they must be recorded.
Finally, identify bottlenecks. Where does a case spend the most time waiting? Where are follow-up questions most frequent? Where is data missing? Where is responsibility unclear? Where is email being used for something that should be handled in a system? What happens when someone is on leave?
The outcome of the workshop should not be a perfect process diagram, but a shared understanding of operations.
When reality differs from policy, it is not a scandal
It differs in almost every company.
Policies often lag behind actual operations. The company has grown, new customers and managers have arrived, new systems have been introduced, and responsibilities have changed—but the paperwork has not kept up. Or the paperwork has been updated, but daily practice has not followed.
This should not be approached punitively. If colleagues feel they will be called to account for deviating from policy, they will not tell you the truth. And then the assessment loses its purpose.
The right leadership response is:
I understand that it is different on paper. Right now, I want to see how it actually works.
Then ask:
Why did it develop this way?
Perhaps the policy is too complicated. Perhaps there is not enough information to make a decision. Perhaps the approver is overloaded. Perhaps an old exception has become a habit. Perhaps the system does not support the actual work.
The gap between reality and policy is not an inconvenient by-product. It is one of the most valuable inputs for improvement.
Leadership mistakes worth avoiding
The first mistake is launching a project that is too large. “Let's map the entire company.” It sounds good, but it can easily paralyze the organization. Many interviews, many workshops, many documents, few quick results. Momentum fades.
It is better to start with a focused area.
The second mistake is speaking only to managers. Managers explain how a process should work. The people doing the work explain how it actually works. You need both.
The third mistake is allowing the assessment to become a fault-finding exercise. Process assessment is not an audit, preparation for disciplinary action, or a redundancy plan. If it looks like one, it has been communicated poorly.
The fourth mistake is choosing software too early. Software can be purchased quickly; operational structure cannot. If the process logic is unclear, every unresolved question will emerge during implementation. That makes it more expensive, slower, and more contentious.
The fifth mistake is trying to make every diagram perfect. A process diagram is not a work of art. It is good when it is usable.
The sixth mistake is failing to decide how to handle exceptions. Every process has exceptions, but if every other case is an exception, there is effectively no process.
The seventh mistake is ending the project with documentation rather than operational change. If the only outcome of process assessment is a document, we have gained little real control. The goal is to turn the identified process into operational rules, responsibilities, measurement, and, where justified, an automated workflow.
A leadership action plan for the first 30 days
Process assessment does not require months of preparation. You can reach your first realistic operational overview in thirty days, provided you do not try to solve everything at once.
In the first few days, management needs to clarify why the project is starting. “We want to digitalize” is not enough. You need a specific objective: more transparent back-office operations, fewer email approvals, faster decision paths, reduced dependence on key people, easier operational handovers, or identifying automation opportunities.
Then create a simple process inventory. Process name, department, process owner, roles involved, frequency, main problem, tools used, extent of email/Excel use, level of management control, automation potential.
The next step is to involve key employees and the people doing the work. Each selected area should be represented by at least one manager and one person involved in daily execution. The manager knows the expectations. The person doing the work knows the reality.
Then hold one or two process workshops. No more. Clarify the start point, end point, participants, steps, decision points, bottlenecks, and exceptions.
Finally, prioritize. What will deliver a significant business impact and be relatively easy to implement? Start there.
When should you consider workflow?
Workflow is worth considering when a process repeats, involves identifiable roles, contains decision points, has deadlines, and currently requires too much manual coordination.
Not every process is a good workflow candidate. Some activities are creative, unique, or highly specialized and should not be confined within an overly rigid system. But much of back-office administration does not fall into this category.
- Invoice approval does not gain value from hunting for information in emails.
- Purchase requests do not become flexible because everyone submits them differently.
- Onboarding does not become more human because three departments work from separate lists.
- Contract preparation does not become secure because someone remembers the latest version.
In these processes, workflow brings predictability, not rigidity.
The xFLOWer perspective: from assessment to execution
In this approach, xFLOWer is not a system for its own sake. It is a tool for turning process assessment into working business practices, not just documentation.
At many companies, digitalization stalls because there is no bridge between assessment and daily operations. The process is mapped, diagrams are created, problems are identified, and everyone agrees that something should change. Then everyday work resumes, and everything continues to run through email as before.
With a workflow-based approach, the operations uncovered during assessment can become a process that connects roles, accountable owners, deadlines, decision branches, notifications, documents, and reports.
From a leadership perspective, this is not about convenience. It is about control.
In a workflow, the same activity starts with a standardized form, mandatory fields, value-based approval thresholds, financial checks, deadlines, status tracking, reporting, and a retrievable history.
This is no longer drawing diagrams. This is execution.
Leadership checklist
- Do I know exactly how a typical back-office process runs from start to finish in the company?
- Do I know where cases most often get stuck?
- Do I know how many approval points an average decision involves?
- Do I know who can make decisions and up to what value limit?
- Do I know which processes still run through email or Excel?
- Do I know whose absence would bring an important operational area to a halt?
- Do I know where daily operations differ from policy?
- Do I know which process could be converted into a workflow most quickly?
- Do I know which data would show whether operations have become faster or better?
- Do I know what could be handed over to a new manager if they had to take over the area tomorrow?
Key takeaway
A well-managed company is not modern because it has a lot of software. It is modern because its operations are visible, measurable, and easy to hand over.
For a company with 50–250 employees, process assessment is no longer an administrative luxury. It is a management necessity.
This is precisely the company size where there is the most to gain.
- Leaders regain visibility.
- Colleagues spend less time on unnecessary administration.
- Key employees' knowledge becomes organizational knowledge.
- Approvals become easier to track.
- Processes become measurable.
- The company becomes easier to hand over and scale.
And the sequence is simple:
- first, process assessment,
- then simplification,
- then workflow,
- then automation,
- and AI support where it genuinely makes sense.
Do not start with software. Do not start with an AI project. Start by understanding operations.
This is not a slower route. It is the only sensible route if you want to build a manageable company rather than digital chaos.
