Analyst’s Perspective
3 Questions for the Expert. Mikołaj Polak
Which banking process is the hardest to automate?
There isn’t one universal answer. While banking processes are broadly similar, every bank has its own operational and organizational specifics. In theory, most processes can be automated—but in practice, limitations such as API availability or how data are stored often stand in the way. Missing APIs obviously create challenges when integrating new systems with existing ones.
Storing and processing data in formats such as spreadsheets causes a different kind of problem. Many institutions still keep data in spreadsheets, often in Excel format. In most organizations, there is probably a saying that “Excel rules!” because it is popular, well-known, and users feel comfortable working with it. However, as an input data source for a workflow system, spreadsheets are inefficient from a system integration perspective. Therefore, in such cases, the first step is not automation but data preparation.
Take the KYC (Know Your Customer) onboarding process as an example.
One requirement for automating KYC is verifying an entity across internal and external databases to identify and eliminate potential risks. It sounds straightforward—until you realize the data live in spreadsheets. Excel is not a database!
This means more work: you must build a proper database, migrate existing data, and create tools for adding, deleting, and managing that data—usually a new application. Only then can the KYC process be integrated with the new data repository.
In reality, the hardest part of automation is rarely the process itself. It’s usually the technological environment or the quality of the data. Before automating, you need to identify data sources and ensure consistency across departments. Different teams often process the same data in different ways, leading to discrepancies. There should be “one source of truth.” The technological environment and organizational procedures must also be standardized. That’s often the hardest and most crucial part of the work.
What are the most common mistakes clients make and could easily avoid?
One of the most common mistakes is the lack of process thinking.
Clients often focus on a single outcome instead of expressing the actual problem or need. Yet every outcome stems from an underlying process, which may involve multiple stakeholders, system interactions, and sub-processes. Ignoring that context leads to fragmented and inefficient solutions. Fortunately, a responsible vendor can usually help clients see the bigger picture through workshops and requirement sessions. That’s why we recommend creating an “as-is” process inventory, using methods like Event Storming, to help the organization truly understand how it operates.
The second common mistake is the lack of a precisely defined business need.
Here, too, the problem often lies in “thinking in terms of a ready-made solution.” For example, instead of a message like “I need the application to aggregate client data from various internal and external sources and present it clearly so the user can quickly make a decision without searching through multiple systems,” we get the message: “Please recreate in the system the table I currently have in Excel.” If such a defined need is treated as a finished requirement, the result is wasted hours of work by the development team and, worst of all, an unhappy client. After all, the client didn’t just want the table copied into the system—they wanted to solve a specific problem they couldn’t clearly articulate.
That’s why workshops and ongoing communication with stakeholders who are also end users are so important. On the one hand, they help to resolve any doubts. On the other hand, they accustom people to defining business and project needs in a way that truly reflects what their organization requires and what they expect from an effective process.
Scrum works particularly well here. Short, two-week sprints deliver tangible business value fast. End users test the product in real conditions, providing immediate feedback that drives continuous improvemen
The third frequent mistake is starting IT projects without involving domain experts.
It is not uncommon that project teams consist of technical staff, product owners, and business process owners. However, they lack people working with the process daily—the so-called end users. Yet, these are precisely the individuals for whom the IT solution is ultimately intended.
Imagine a project being carried out in a large logistics company planning to implement a Transportation and Warehouse Management System (TMS/WMS). The project’s goal is to automate delivery scheduling, goods reception, and optimize drivers’ routes.
In the project team, there are representatives from IT, finance, and the procurement team responsible for managing relationships with carriers. Yet, it’s missing those with hands-on, operational experience—dispatchers, warehouse staff, and drivers—those who will actually use the new system.
As a result, the solution technically meets business requirements but proves unintuitive in practice. Planning routes demands too many clicks, while the goods reception module fails to account for differences between warehouses with varying ramp capacity. Although the system operates as designed, it fails to support operational work efficiently—leading to user frustration and costly corrections after rollout.
That’s why it’s so important that, in addition to technical specialists and process owners, project teams include operational representatives. They best understand everyday constraints and the real needs of users. Their involvement from the start of the IT project helps prevent discrepancies between the system concept and its actual use. This is a classic example of a lack of “as-is” knowledge in the project team. Domain experts could have pointed out during the analysis phase which data were truly needed and how best to present them. Including them from the start helps avoid situations where a technically correct solution proves impractical for everyday use.
A fourth, equally common mistake involves choosing the wrong project methodology.
Clients want to run projects using agile methodology, which is more flexible, responds faster to changing conditions, and delivers tangible business value more quickly. At the same time, they often operate within organizations that impose rigid schedules and budgets. Furthermore, if a client defines business needs imprecisely, does not involve domain experts, and does not view the process holistically, the result can be escalating project requirements. These requirements often look very different (and harmless) during the RFP stage but later reveal a multitude of new, constantly emerging demands.
I frequently encounter situations where the IT project sponsor sets a fixed implementation deadline upfront, yet the requirements remain "fluid" and must fit within the confirmed budget for that year. In this way, what could be addressed flexibly in an agile methodology becomes a problem in a world of non-negotiable deadlines, budgets, and scopes. Naturally, the client ends up dissatisfied—the project fails to meet their unspoken expectations.
When deciding on IT project methodology, it is critical to understand its strengths as well as its demands and limitations. It is also crucial to consider the constraints and requirements of one’s own organizational structure. A realistic and detailed examination of business needs, the needs of stakeholders involved in daily processes, and boundary conditions imposed by the organization—all this helps select the appropriate project methodology for the environment in which the project will be conducted.
What do clients most often ask about when considering a process automation platform (such as Flowee)?
Banking clients most often ask about integrations—especially with databases like KRS, REGON, or BIK, which are key for daily operations. They also want to know whether Flowee has a built-in decision engine, or if it automatically pulls financial data from KRS to calculate creditworthiness and produce loan offers.
Although the initial answer to all these questions is “no, this is not included in the package,” Flowee achieves all functionalities through integration with already existing solutions on the client’s side. It is also possible to customize Flowee to the client’s needs during implementation. This includes building new modules specifically designed for the client to work optimally within the environment directly established at the client’s premises.
Clients are increasingly inquiring about the availability of a mobile version. In the next stages of Flowee’s development, we plan to work on solutions that will provide convenient and secure access to the system from mobile devices. Responsible product design also means being aware that not all solutions will function smoothly or be equally ergonomic and well-secured in a mobile environment.
