Merlean vs RPA

What RPA does well

RPA earns its place where there is no other way in. Legacy systems with no API, desktop applications, terminal emulators, software from a vendor who will not expose anything: a bot that drives the interface is sometimes the only option, and for high-volume repetitive work on a stable screen it pays for itself quickly.

It is also genuinely good at spanning systems that have no relationship to each other, because the interface is the one thing every system has.

Where it becomes expensive

An RPA bot encodes a path, not a purpose. It knows that the third field on the second tab receives the policy number; it does not know what a policy is. So the maintenance cost is driven by the rate of change in the interface rather than by the rate of change in the business, and a purely cosmetic redesign can break a fleet of bots that were working perfectly.

The second cost is coverage. Each bot handles one path, so a process with meaningful branching needs a bot per branch, and the exceptions - the cases a human would handle by thinking - fall out of automation entirely.

The third is credentials. Bots typically run under a service account with wide permissions, because a narrow one cannot cover every path. That is a standing risk which is hard to reduce without reducing coverage.

What Merlean does instead

Merlean reads the application's source to build a model of its endpoints, fields, validation, permissions and workflows, and executes against that model through the same HTTP interface your own frontend uses. Nothing is clicked, so nothing breaks when the interface moves.

Because the unit is an outcome rather than a path, branching is handled at execution time. A request that could go two ways produces a question rather than a failure, and a request that falls outside what the application permits is refused rather than half-completed.

And because Merlean acts with the requesting user's own credentials, there is no privileged service account. It can do exactly what that person could do by hand.

Choose RPA when

• The target system has no API and no source you can connect - a vendor desktop application, a mainframe terminal, a scanned-document workflow.
• The process is high volume, entirely deterministic, and runs on a screen nobody is going to redesign.
• The work spans several unrelated systems and the interface really is the only common surface.

Choose Merlean when

• The application is yours, or its source is available to connect.
• The work varies: branching, judgement calls, requests that are not identical every time.
• End users - not an automation team - should be able to trigger the work, in their own words, with their own permissions.
• The interface changes often enough that maintaining recorded paths has become the real cost.

Frequently asked questions

Can we run both?

Yes, and it is a common arrangement. RPA reaches the legacy systems that have no other entry point, while Merlean handles the applications whose source you control. They are not competing for the same processes.

Is Merlean cheaper than RPA?

The licence is not the interesting number. RPA's dominant cost is maintaining bots against changing interfaces, and that is the cost Merlean removes, because it is not driving an interface.

Does Merlean need an API?

It needs an application whose code it can read, which in practice means a web application with HTTP endpoints - including the internal ones your own frontend calls. A public or documented API is not required.

Related