For years, enterprise software was evaluated mainly on features and business outcomes. In the AI era, another question is becoming just as important: where does the software actually run, and how does it fit an organization's data and AI architecture?
In Part 3 of our CEO Interview Series, QPR Software CEO Matti Erkheikki explains why architecture has become a business decision, why QPR chose early to build process mining that runs natively in Snowflake, and what this means for organizations bringing AI into their operations.
His message is simple: instead of moving business data to another analytics platform, bring the intelligence to the data.
The Interview
For a long time, companies evaluated enterprise software mainly by what it could do. Features, dashboards, user experience. Those things still matter.
But AI changes the picture. AI agents need access to reliable business data and operational context, and they need it within the organization's security and governance rules.
So where your software runs is no longer just a technical detail for IT. It affects how quickly you can use AI, how well you can control your data and what the solution costs as usage grows.
That is why I believe every technology buyer should now ask one more question: does this software actually fit our data and AI architecture?
It means that the process mining runs inside Snowflake, where the customer's data already is.
With our Snowflake Native App, QPR ProcessAnalyzer is installed directly in the customer's own Snowflake account. The analysis happens there. The process data does not need to be exported to a separate process mining environment.
The difference is simple. In a connected architecture, the data travels to the software. In a native architecture, the software comes to the data.
I often put it this way: move the intelligence, not the data.
Because we saw where our customers' data was going.
More and more large organizations were building their data foundation in Snowflake. They had invested heavily in getting their data governed, secured and in one place. It did not make sense to ask them to copy that data into yet another platform just to analyze their processes.
So we decided to build process mining to run where the data lives. We became the first process mining software to run natively in Snowflake back in 2022, and in 2024 we brought the first process mining Native App to Snowflake Marketplace.
At the time, it was an architectural decision. Today, with AI agents entering business operations, it has turned out to be a strategic one.
Quite a lot, and most of it shows up in day-to-day operations.
First, there is less infrastructure to manage. You do not need separate pipelines to continuously copy and synchronize process data into another vendor environment.
Second, governance stays with the customer. The Native App runs inside their Snowflake account, under their existing security and access controls. That makes it easier to manage who can access the data and how it is used.
Third, scaling becomes simpler. Snowflake's compute can be scaled as workloads grow, so customers can expand their process intelligence capabilities without building a separate analytics infrastructure.
And then there is cost. When you avoid unnecessary data replication, you also avoid the additional storage, data movement and infrastructure costs that come with it.
And the one that changes the conversation most is time to value. Because there is nothing to extract and no new environment to secure, a first analysis can be delivered in hours and real value within days. The conventional route – building the integrations, replicating the data, and then taking a new environment through a security review – is easily measured in months.
For me, the real benefit is that process intelligence becomes part of the customer's existing data architecture rather than another system they have to maintain.
That it is the wrong tool for the job.
Every process mining project stands or falls on getting the event data into shape, and most process mining products ship their own ETL capabilities to do it. Those capabilities exist because the work had to happen somewhere and the vendor had nowhere else to put it. They are not where any process mining vendor's best engineering goes, ours included.
A data platform like Snowflake has spent years building exactly this capability, and it keeps extending it. Snowflake CoCo, their data-native AI coding agent, now builds pipelines and transformation logic from a plain-language description, inside the platform where the data already sits. No process mining vendor is going to out-build that, and none should try.
This is the part of native architecture that people underestimate. It is not only that the data stays where it is. It is that the customer gets to use the best available tool for each job — the data platform and its ecosystem for the transformation work, our engine for the process mining — instead of accepting whatever one vendor happened to build in.
They are two sides of the same idea. Snowflake-native brings the intelligence to the data. MCP (Model Context Protocol) brings the intelligence to the people.
For years, process intelligence has been a tool for specialists. AI changes that. With our QPR MCP Server, a finance manager can simply ask, "Where is our order-to-cash process slowing down?" in an AI tool they already use – any client that supports MCP, including ChatGPT and Microsoft Copilot - and get an answer based on actual process data. No process mining dashboard needed.
And when more people and AI agents can access these insights, governance becomes even more important. Our Snowflake Native App keeps the analysis within the customer's governed data environment.
The next breakthrough in process intelligence will not be a better dashboard. It will be making the dashboard optional.
Yes, very clearly. The conversation has changed.
A few years ago, the first questions were about process mining features and what the software could do.
Today, more and more organizations contacting us already use Snowflake. They know what process mining is. And they ask a very direct question: can we do this without moving our data out of Snowflake?
That is a different starting point. They are not just evaluating another analytics tool. They are looking at how process intelligence fits into their existing data environment and their plans for AI.
We also see what this architecture makes possible at enterprise scale. Ericsson, for example, uses QPR ProcessAnalyzer for global trade compliance analytics in a Snowflake environment, with more than 1.2 TB of data and 10–20 million new transactions every month.
What I find interesting is that customers are increasingly thinking beyond the immediate use case. They want an architecture that will still make sense as their data volumes, analytics needs and AI usage grow.
Of course they should look at capabilities. But I would add a set of architecture questions to every evaluation.
Where does our process data actually live?
Where is the process mining computation performed?
Do we need to replicate data into a separate vendor environment?
Who controls access, governance and data residency?
What are the full costs, including infrastructure and data movement?
Can our AI agents access governed process insights?
What happens when we add more processes, users and AI workloads?
These questions are not about any one vendor. They help companies understand what they are really committing to.
A platform may meet today's functional requirements, but companies also need to understand how it will fit into their architecture three or five years from now.
My advice is simple: evaluate the architecture as carefully as you evaluate the features.
Yes and no, and the distinction is worth making precisely.
QPR ProcessAnalyzer uses Snowflake as its underlying data and analytics engine in both deployment models. So an organization that does not use Snowflake still gets what the platform itself brings: the performance, the elastic scalability, the security model, and access to the best transformation tooling available for the data work every process mining project depends on.
If an organization already uses Snowflake, our Native App runs directly in its own Snowflake account. The process data stays there, and the customer controls the environment.
f an organization does not use Snowflake, QPR ProcessAnalyzer is also available as a managed solution. In that case, it runs on a Snowflake environment managed by QPR, and the customer does not need to purchase or maintain its own Snowflake subscription.
So customers can benefit from the same underlying technology, scalability and process intelligence capabilities without having to adopt Snowflake themselves.
The difference is where the environment is managed and who controls the Snowflake account.
What I would say to every organization is this: make the architecture part of the decision. Do not let it be something you discover after you have signed.
As enterprises bring AI into everyday operations, the architecture behind their software matters more than ever.
Process intelligence should work with an organization's existing data and AI environment, not create another isolated data platform.
QPR pioneered Snowflake-native process mining to make that possible: bringing process intelligence to the data, and making operational insights accessible to both people and AI.
Your data is already in Snowflake. Your process intelligence can run there, too.
Explore Snowflake-native process intelligence →
See QPR ProcessAnalyzer on Snowflake Marketplace →