From the outside, implementing InDoc EDGE may look like a technical project: choose a system, transfer the data and go live. In practice, it is different.

Implementation is mainly a conversation about processes, habits, limitations and expectations. The contract is only the beginning. The project continues long after the solution goes into production. What happens between these two points often determines whether the solution will truly work in practice.

This work is carried out by the InDoc EDGE Business Solutions team: project managers, analysts and process architects who translate the needs of organizations into working processes every day.

In a conversation with them, we looked behind the scenes of implementation projects: how they work, where the biggest challenges appear and why clients often describe the experience more as a partnership than as a delivery.

Implementation is not just about fulfilling an offer

“Implementation is not just a technical project for us,” explains Tatjana Jaklič, Head of the Business Solutions team. “It starts with understanding the client: how they work today, where documents create a burden and what they want to achieve with the change.”

This perspective changes the way a project is managed. The offer defines the framework, but in practice, every step requires an assessment of what will work in the client’s specific environment in the long term.

“Our goal is not to follow the offer word for word, but to build a solution that will work in their environment in the long run,” Tatjana adds.

That is why implementation is not simply about completing a list of requirements. It is a process in which requirements and solutions meet, align and often need to be redefined until something is created that truly works in practice.

We show the solution early, because that is when the conversation changes

Many things become clear only when the client sees the solution. As long as the system is abstract, expectations are also abstract. When users start clicking through the interface, requirements become more concrete, and so does the feedback.

“We show the basic solution very early. When the client starts clicking and using the system, the conversation moves from theory to practice. That is when you really see what works for them and what does not,” explains Sebastjan Zemljak.

"When the client starts clicking and using the system, the conversation moves from theory to practice."
Sebastjan Zemljak

That is why an early demonstration is not just a presentation. It is a tool for timely alignment. Without it, misunderstandings may only appear shortly before go-live, when changes are more expensive and delays are almost unavoidable.

Standard solution or customization: when to choose one or the other

The approach to standard solutions depends strongly on the area of use. For system documents, where ISO standards and other regulations apply, the team usually relies on proven solutions. In such cases, stability, traceability and compliance are more important than customization.

In areas such as invoice approval or internal rules, the situation is different. Customizations are more common because the system often needs to connect with other environments and existing processes.

“With system documents, we practically do not change the solution. In other areas, we know from the beginning that customizations will be necessary,” explains Tatjana Jaklič.

In time-limited projects, the decision is even clearer.

“If we started changing a proven solution in time-limited projects, we would risk the deadline and stability,” adds Andreja Vehar.

In such situations, the team deliberately chooses a proven path. Improvements are then introduced in phases — not as a compromise, but as a well-thought-out strategy.

Development is involved when the solution has broader value. In other cases, the best possible path is found within the existing functionalities.

The goal is not a perfect standard or full customization. The goal is a solution that is stable, understandable for users and sustainable in the long term.

You can read more about how the development team thinks about the technical decisions behind this in the blog How we develop InDoc EDGE and why this means long-term stability.

Migrations are the most sensitive phase, and also the most instructive

Migrations are among the most sensitive phases of a project. They are not only about transferring documents. They also involve transferring structure, metadata, permissions, integrations and often a way of working that users have been used to for years.

A specific challenge of migration projects is the client’s starting point. Data is not always ideally prepared. Some information needs to be added manually, some metadata needs to be reconstructed, and sometimes it is necessary to accept that not everything can be obtained, either because of limited access or additional costs.

The team’s role is to make a realistic assessment: what can be solved immediately, what can be solved in phases and where an alternative path needs to be found. A migration is therefore always adapted to the actual situation, not to an ideal scenario.

The other side of migration is human. A system change means entering the unknown for users, especially for those who have built their habits in the previous environment over many years.

That is why key users are included in the project very early. They get to know the solution before go-live, take part in shaping the processes and gradually get used to the new system. In this way, migration is not a sudden cut, but a gradual transition.

Who on the client’s side determines the success of the project

Technology and methodology are important. But in practice, the success of a project often depends most on who is involved on the client’s side.

The ideal team is clear: someone who understands the content and processes well, someone with the mandate and support of management, and someone with basic technical understanding who can connect business requirements with the system.

In practice, ideal conditions are not always in place. In larger organizations, several departments may be involved without a unified overview. In smaller organizations, IT support may be limited.

The Business Solutions team understands these differences and leads projects based on the real situation, not ideal assumptions. Missing roles are supported with additional explanations, guidance and clear agreements.

“The key is that there is someone on the client’s side who truly wants the new solution and is motivated to make it work.”
Tatjana Jaklič

Such a person often becomes the internal connector: between departments, between management and operations, and between business requirements and technical implementation.

They give the project momentum that formal roles alone cannot replace. This internal motivation is often decisive in whether the solution is not only implemented, but also truly adopted in practice.

After go-live, the cooperation really begins

Go-live is an important milestone, but it is not the end of the project. In fact, this is when the most honest part of the cooperation begins - when the system is no longer in a test environment, but in everyday use, supporting real decisions, deadlines and responsibilities.

“After go-live, we are practically in stand-by mode for the first few weeks. That is when real needs and expectations become visible,” explains Sebastjan Zemljak.

Only through actual use does the system show how it behaves in the hands of different users and in contact with real processes.

Once the system stabilizes, communication moves into established channels. Content-related questions, process adjustments, upgrades and phased improvements remain in the hands of the Business Solutions team.

Solutions are not “set and forget”. They develop over time, based on client feedback.

You can read more about how the reliability of these solutions is checked before go-live in Klavdija Blatnik’s blog How we ensure the reliability of a document system in practice

Technology is the tool. The way of working makes the difference.

The implementation of InDoc EDGE is not a linear project. It is a process that begins before the contract is signed and continues long after go-live.

In this process, success is not determined only by functionalities, but by the way of working: how we cooperate with the client, when we rely on a standard solution, when we customize, how we handle migrations and how trust is built through every phase.

That is why clients often describe the cooperation as a partnership. Because partnership is built throughout the project. It does not begin simply with a signed contract.

Source: This blog was created based on a conversation with the InDoc EDGE Business Solutions team. You can read the full interview on Mikrocop’s anniversary page.