Hábil MDW

Your systems, finally in agreement.

Your core system, your ERP and your channels connected without replacing them, with an audit trail of every operation.

The platform that connects your systems.

Let's talk about your case

Prefer email? Write to us at hola@habil.mx

What is Hábil MDW?

Hábil MDW, Hábil's Enterprise Middleware Platform, is the layer that sits between the systems you already have. Every order, every payment, every policy and every notice goes through it, with the response from whoever received it and the reason if something failed.

Your systems work; what gets lost is in between them. A payment that left the channel and didn't reach accounting. An issued policy the CRM doesn't know about. An order the store charged for and the warehouse didn't see. Each system says everything is fine, and your people absorb the difference, with spreadsheets and phone calls, at month-end. When connections grow without a map, manual work becomes part of operations, and changing a system becomes unthinkable, because nobody knows what will break.

Hábil MDW brings order to that space. It connects to your core system —the central system of your business—, to your ERP and to your channels through the means each one already has, converts what comes in into a single language, takes each operation through the steps your business defines and keeps a record of what happened, when and who did it. Your systems keep doing their job; Hábil MDW makes sure they understand each other.

It is a platform of your own: your operations do not share an installation with anyone else's. It runs on your infrastructure or on ours, with Hábil in charge of operations. And it is engaged separately from Hábil AI and Hábil Lake: you can use one without the others.

Three levels, depending on what you need

Hábil MDW is a product and a service. The product is the platform. The service is what we do with you so your systems work as one. It is engaged by level, and each level builds on the previous one.

The platform

Your systems connected, with a trail

What you get with the product:

  • An installation just for you, on your infrastructure or on ours, operated by Hábil.
  • A connection to what you already have. Your core system, your ERP, your online store, your customer service channels and your partners, through the means each system already offers.
  • A single language for all of them. Each system comes in with its own format, and the platform translates it into a common model: an order is an order, wherever it comes from.
  • Your business steps, in configuration. What happens after a payment is collected, who gets notified, what gets invoiced: it is defined in configuration, not in code.
  • A guarded gateway for your partners. Banks, stores, agents and distributors connect with their own identity and their own permissions.
  • An audit trail of every operation. What was sent, what each system answered, at what time and, if it failed, why.
  • No paid enterprise licenses. We use open or freely usable components.

To get started

Your first flow, end to end

We connect the systems of a first complete flow —for example, from the order to the payment and the invoice—, define the steps and rules with you, and leave it working with the audit trail visible to your team.

At this level we choose together the flow that gets stuck the most today or costs the most manual work. For that flow we put in writing which system does each step, what it is sent, what it should answer and what happens if it doesn't answer. When we finish, that flow runs through the platform, and the old connection is switched off only once the new one has shown that it reconciles.

To grow

More flows, channels and partners

We add flows, channels and partners, with alerts, operations dashboards and staged coexistence with the systems that are going to be replaced.

This level is for when the platform is already the path operations run through and more areas want to use it. We open the gateway to new partners, add customer service channels, bring the old connections nobody wants to touch into the same path and, if you decide to, connect your operations with Hábil Lake and with Hábil AI.

Find your area

Management and Finance"Each system reconciles on its own; together, they don't. At month-end, someone reconciles by hand what the core system says against what the bank collected."Every operation goes through the same path, with its response and its time, and what didn't arrive is visible the day it happens, not at month-end
Operations"We don't know whether that operation arrived. It gets retried by hand, and sometimes it gets duplicated."Every submission is kept with its response or its failure reason, and retries are designed not to repeat the effect
Sales"Our partners want to sell from their own system, and we send them files by email."A gateway for your partners, with their identity, their permissions and their own audit trail, so they can quote, issue or collect from their side
Technology (CIO / CTO)"If we change that system, everything else breaks, and only one person knows how they're connected."Connections stop living inside each system and move to a layer with a map and an audit trail; the detail is further down
Compliance"The auditor asks for evidence, and we go looking for it in emails and scattered logs."Every operation recorded with its response, its time and who did it, and personal data masked in the logs

Where Hábil MDW adds value

Eight scenarios. They are scenarios, not clients: they show the kind of problem Hábil MDW solves, how it does it and which capabilities it uses.

Scenario: rates that change without an IT project · Auto and property insurance

Before: the premium changes by coverage, area, deductible, sum insured, age, term and channel. With a custom-built system, every rate or rule adjustment is an IT project, and the agent channel waits for weeks.

What changes: your insurer or your agent channel quotes, issues, collects and invoices policies with its own rules and rates. A rate adjustment is configuration, and it reaches every channel you connect in the same way: the web, the agents and the partners.

Why it is hard: the rate lives in the core system, the payment collection in another system and the invoice in a third, and all three have to tell the same story about the policy.

How Hábil MDW solves it: the rules and steps of the policy are defined in configuration, and the platform takes each policy from the core system to payment collection and to the invoice, with each system's response in view.

Capabilities: Connect your systems · Your business steps · Guarded gateway.

Scenario: the agreement with a partner, without running it by hand · Group, affinity and warranty insurance

Before: an agreement with a partner or an extended warranty is a plan with rules, cut-offs, collection and claims that is run by hand or in a development built just for that partner.

What changes: batch issuance, direct-debit collection, the file, the claim and the report to the partner follow the same path. The partner checks what concerns it from its own system, with its own identity.

Why it is hard: each partner sends its files with its own format and its own cut-offs, and the report sent back has to reconcile with what was collected.

How Hábil MDW solves it: each partner's files are translated into the same language, each batch leaves its audit trail, and the partner comes in through the guarded gateway, with permissions only over what is its own.

Capabilities: Connect your systems · Your business steps · Guarded gateway · 24/7 operation with a trail.

Scenario: the health network, on a single path · Health: group plans and networks

Before: catalogs, clinics, digital member cards, scheduling and consent live between spreadsheets and systems that don't talk to each other. An appointment gets double-booked and a consent gets lost.

What changes: the quote, the member card, a schedule that avoids double-booking, payment collection and the evidence of consent go through the same platform. Each clinic in the network sees what is its own.

Why it is hard: health data requires special care, and each clinic uses its own system, or none.

How Hábil MDW solves it: the platform connects each clinic through whatever means it has, keeps the evidence of each consent and leaves personal data masked in the logs.

Capabilities: Connect your systems · Your business steps · 24/7 operation with a trail.

Scenario: from the simulator to collections · Lending, finance companies and pensions

Before: the monthly payment changes with the down payment, the term, the risk profile, the included insurance and the campaign; the retirement calculation is a complex formula. Then the loan has to be approved and collected, in other systems.

What changes: the simulator, the approval and collections follow a single flow, and the formula is configuration. A campaign change is configured once for all connected channels.

Why it is hard: the credit bureau check, the decision, the signature and the payment live in different systems, and a loan halfway through cannot be left without an owner.

How Hábil MDW solves it: each application carries its status and its steps; your team sees which step it is at and who it depends on, so that no loan is left without an owner.

Capabilities: Connect your systems · Your business steps · 24/7 operation with a trail.

Scenario: price, inventory and shipping with your distribution network · Retail and e-commerce

Before: the price depends on the input cost, the variants, the volume, the channel and the coupon. Inventory has to be reserved and shipments coordinated with several carriers, across several systems that don't talk to each other.

What changes: the catalog, the price, the cart, inventory with reservations and shipments go through the same platform. Each shipment carries its tracking number and its status.

Why it is hard: inventory changes in the store, in the warehouse and across the network at the same time, and each carrier answers in its own way.

How Hábil MDW solves it: inventory is reserved at the moment of purchase, designed not to sell the same item twice; each carrier connects through its own means and its response is translated into the same language, and your ERP receives each sale with its confirmation.

Capabilities: Connect your systems · Your business steps · Guarded gateway.

Scenario: the filing that doesn't expire · Environmental and regulatory compliance

Before: sites, permits, evidence and reminders live in folders and spreadsheets. A missed deadline costs a fine, or a shutdown.

What changes: each obligation has its file, its documentary evidence and its notice before it expires. You can see which site has which filing pending and who is handling it.

Why it is hard: obligations come from several authorities, each with its own deadlines, and the evidence is in the hands of different people.

How Hábil MDW solves it: each filing is a process with its statuses and its deadlines; the platform notifies whoever is responsible, keeps the evidence with its date and leaves the audit trail ready for the auditor.

Capabilities: Your business steps · 24/7 operation with a trail.

Scenario: where each order stands, on a single page · Order traceability

Before: an online order goes through the channel, payment, inventory, the location that fulfills it, the carrier and invoicing. Each system knows its part and none knows the whole story. When something gets stuck, each area says "it went fine on my side", and nobody answers the customer.

What changes: with an order number you can see its journey on a single page: what stage it is at, what was sent to each system, what each one answered, what is missing and who it depends on for it to move forward.

Why it is hard: the trail is spread across each system's logs, with different identifiers, and some failures don't show up as errors: the submission went out, but the response didn't arrive.

How Hábil MDW solves it: since every operation goes through the platform, its journey is already recorded; the platform rebuilds it, separates what failed from what is still waiting, and says whose court the ball is in.

Capabilities: 24/7 operation with a trail · Connect your systems · Coexist with legacy.

Scenario: one order, many channels and a single truth · Omnichannel sales and service

Before: the customer buys on the web, asks on WhatsApp and picks up in store. Each channel has its own version of the order, and the notice the customer receives sometimes doesn't match what happened.

What changes: each channel comes in with its own format and the platform converts it into a single order model, with the status of each item. Notices to the customer —by WhatsApp, email, SMS, push notification or inside your app— come from the same status, and the invoice is issued in the same flow.

Why it is hard: each channel has its own pace and its own rules, and a notice that goes out too early says something that isn't true yet.

How Hábil MDW solves it: the statuses of the order, its items and what happens at each step are defined in configuration. Each notice to the customer is designed to go out once what it announces has already happened.

Capabilities: Connect your systems · Your business steps · 24/7 operation with a trail.

Where order 10482 stands, on a single page

Example · illustrative data

The same order: looked up system by system, or rebuilt by the platform. Switch the view to see the difference.

Where order 10482 stands, on a single page
Today: asking area by area
StepSystemStatus
PurchaseOnline store"it went fine on my side"
PaymentPayment gateway"it went fine on my side"
ReservationInventoryno data
SaleERPno data
InvoiceInvoicingno data

Each area says it went fine on its side, and nobody knows where the order stands.

What the platform does

Five capabilities, told in three parts: the problem, what changes and why it is hard.

1. Connect your core system, your ERP and your channels, without replacing them

The problem: the core system, the ERP, the online store, the contact center and the partners talk to each other through custom-built connections, one by one. Each one lives inside a different system, and nobody has the full map.

What changes: we connect to your core system and your ERP through the means they already have —services, database, files— and to your channels through theirs. Each system comes in with its own format and the platform converts it into a single language: an order, a policy or a payment are described the same way, wherever they come from. Your systems keep doing their job; what changes is that now they understand each other.

Why it is hard: each system names things its own way, and what one calls "customer" another calls "account" or "policyholder". The equivalences are written with your team, once, and tested with every operation.

2. Your business steps, with evidence

The problem: when something happens in one system —a payment is collected, a policy is issued, an order is fulfilled—, the others find out late, partially or twice. And the steps that follow live in someone's head or in code nobody wants to touch.

What changes: each operation follows the steps your business defines: what happens after a payment is collected, who gets notified, what gets invoiced, what is done if a system doesn't answer. The steps and statuses are designed to be defined in configuration, not in code, so changing a rule doesn't have to be an IT project. When a system needs to know what happened in another, it receives a notice. If the notice arrives twice, it is designed so the effect on your business is applied only once. If a notice depends on data that another system hasn't returned yet, the platform waits for that data and retries, instead of sending an incomplete document.

Why it is hard: repeating a notice without repeating the charge has to be designed from the start, operation by operation. Adding it later, on connections already in use, costs much more.

3. A guarded gateway for your partners and your systems

The problem: your partners —banks, stores, agents, distributors— want to quote, issue or collect from their own system. Opening the door to them without control is a risk; not opening it means selling more slowly.

What changes: there is a single entry point, with a guard. Each partner and each system comes in with its own identity and can only do what its permissions allow. Usage limits —how many queries, at what times, on what— are configured per client and per partner. Every call is recorded, and if a credential is lost, only that one is revoked, without stopping the other partners.

Why it is hard: each partner needs something of its own, and the temptation is to put business rules in the gateway. They don't belong there: the gateway watches who comes in; the rules live in the processes, where they can be tested.

4. Designed to operate 24/7, with an audit trail of every operation

The problem: an integration that fails doesn't warn you: it leaves a gap that someone fills by hand. And when the customer asks where their order is, the answer is an investigation across areas.

What changes: the platform is designed to operate 24/7, with an audit trail of every operation: what was sent to each system, what it answered, at what time and, if it failed, why. Given an order or policy number, the platform rebuilds its journey and says what is missing and who it depends on: the platform, your core system or the channel. A submission that went wrong is retried by your operations team as a new submission, with a record of who did it and without touching the database by hand.

Why it is hard: the trail has to serve two audiences —your operations team, who wants to know what to do, and your auditor, who wants evidence— without exposing the personal data that travels in each operation.

5. Coexist with your legacy systems, and move off them in stages

The problem: the core system is twenty years old, nobody wants to touch the integration bus anymore and the ERP replacement is postponed year after year because nobody knows what will break.

What changes: we connect to your core system through the means it already has —services, database, files—, even if it is a desktop application, seeking not to touch its logic or its screens; if an extension is unavoidable, we tell you in the assessment. When you decide to replace a system, we design staged coexistence: your channels keep feeding the right system, the migration is done in stages and the old connection is switched off once the new one has shown that it reconciles.

Why it is hard: while coexistence lasts, both systems have to tell the same story. That requires comparing, stage by stage, what the old one says against what the new one says.

Modernize the core without slowing the business

Where it runs

On your infrastructure —the cloud you already pay for or your own servers— or on ours, with Hábil in charge of operations. Each client has its own installation: your operations are not mixed with anyone else's.

If it runs on ours, your installation has its own connections, credentials and audit trail. In both cases, we install, update, back up and monitor the platform, on the schedule we agree, with a monthly service.

What we never do

Change the logic or the screens of your systems without telling you first. We connect through the means they already have, and if an extension is unavoidable, it is agreed in the assessment.

Put business rules in the entry gateway, where nobody can test them afterwards.

Open up to a partner more than its permissions allow.

Mix your operations with another client's, or use your data for something you didn't authorize.

Switch off an old connection before the new one shows that it reconciles.

Leave you tied down: the rules and steps of your business are written down, and they are yours.

The details of control and security follow.

Control, security and your data

Who gets in and what they can do

Each partner, each system and each person comes in with their own identity, and can only do what their permissions allow. Usage limits are configured per client and per partner. If a credential is lost, only that one is revoked, without affecting the others.

What happened with each operation

Each operation is recorded with what was sent, what each system answered, the time and, if it failed, the reason. When someone asks what happened to an order, a policy or a payment, the answer is written down, not in one person's memory.

Your personal data, along the way

It travels encrypted between systems, is masked in the logs, and each system is sent only what it needs. The rules are defined with your team, against your policies.

Evidence for your auditor

Access by partners and systems, by credential and with a log; each operation, with its response and its time. Evidence your auditor can look up, without searching through emails.

Record and backup

The platform is backed up with a written restore order, and monitored with its own signals: which operations are waiting for a response, which failed and since when, which connection stopped answering.

For your technology team

How it is built. A platform of small pieces, each with one business responsibility —order, inventory, payment collection, invoicing, shipping, notifications, identity, among others—, that talk to each other through events and APIs.

By capability.

Connection.

Per-system adapters to your core system and your ERP through the interfaces they already expose: SOAP or REST services, stored procedures or staging tables, files. For ERPs we prioritize the interfaces the vendor supports —in SAP, for example, JCo, OData, IDoc or REST; also Oracle, Microsoft Dynamics 365, Odoo or CONTPAQi—, so we don't leave you custom developments that get in the way when you upgrade it. Databases such as Oracle, DB2 (including on IBM i), SQL Server, PostgreSQL, MySQL, MariaDB or MongoDB. Each adapter translates into the common model.

Orchestration and events.

The flow of each operation is a state machine described in configuration; adding a channel or an outcome doesn't require recompiling. Events follow the CloudEvents standard and travel over a bus using the Kafka protocol or over the queue your company already runs (IBM MQ, RabbitMQ or another). Each consumer is idempotent: it is designed so that a repeated event doesn't repeat the effect.

Guarded APIs.

A single gateway with identity (OAuth 2.0 / OpenID Connect), permissions per consumer, usage limits configurable per client and a record of every call. It can be the one you already have —Apigee, Azure API Management, Amazon API Gateway, Kong, WSO2, APISIX or another—. REST or GraphQL APIs, with a published and versioned contract.

Operations and audit trail.

Structured logging per operation, with an identifier that follows it across systems, metrics and traces with open standards (OpenTelemetry), and retries with backoff, designed not to repeat the effect. The reconstruction of an order's journey is built from that trail.

Coexistence with legacy.

Connection to IBM i (AS/400), with RPG programs exposed as services without rewriting them; with legacy buses such as WebSphere ESB, IBM Integration Bus, MuleSoft or WSO2, which stay up while the migration is done stage by stage.

Tax.

CFDI invoicing with payment complements and cancellations, orchestrated toward your stamping provider.

Installation. One installation per client, in containers, on your infrastructure or ours. Each integration has its own identity and encryption, and only what is essential is exposed externally. No paid enterprise licenses: open or freely usable components, designed to be replaced without rebuilding the integrations.

Hábil MDW with Hábil AI and Hábil Lake

Hábil's three major solutions split the work: Hábil MDW connects your systems, Hábil Lake organizes your data and Hábil AI answers and serves with it. They are three independent platforms: they are engaged separately and none requires the others. When you have more than one, they feed each other like this:

What happens reaches the Lake.

Each operation that goes through Hábil MDW —an order, a payment, a policy— can reach Hábil Lake as it happens, with its history. The Lake organizes it and reconciles it against the source system.

Your AI acts through the same gateway.

When an agent from Hábil AI looks up an order or prepares a refund, it does so through Hábil MDW's guarded gateway, with its own identity, its permissions and an audit trail of every call. Anything that moves money or data is carried out with a person approving.

Nova knows where the order stands.

When a customer asks on WhatsApp where their order is, Nova answers with the status Hábil MDW keeps, not with a guess.

The AI reads the trail.

Every morning an agent reviews stalled operations, finds the reason for each one in the platform's audit trail and leaves them to your team.

Forecasts go back into operations.

What Hábil AI's forecasting estimates —for example, restocking— reaches your systems through Hábil MDW, as a proposal a person approves.

Discover Hábil Lake: a single version of your numbers, reconciled against your system.

Discover Hábil AI: AI that works with your systems, with a person approving anything that moves money or data.

How we start

In a first conversation, at no cost, we choose the flow in your operations that gets stuck the most today.

1

You write to us on WhatsApp with your industry, your role and your main systems.

2

We schedule 45 minutes with a Hábil architect.

3

We ask which systems you use, how they connect today and where the trail gets lost. We don't ask for access or for your customers' data.

4

You leave with a map of your connections: which system talks to which, through what means, which ones fail without warning, which risks we see and whether it makes sense to go ahead.

5

If it does: we start with the To get started level, with scope, deliverables and cost agreed before starting, and a clear goal for closing that stage: that the first flow runs through the platform, with its audit trail in view.

The route is: assessment → proposal with scope, cost and risk → first connected flow → operation.

What we need from your team: a person who knows the flow and decides its rules, access to the systems being connected when we start, and sign-off on the flow before the old connection is switched off.

We work with a few clients at a time: the architect who reviews your assessment follows your project to the end.

We tell you no when your systems already talk to each other well and nobody reconciles by hand, when the flow lives in a single system, or when the cost of the platform is greater than the manual work it saves you.

Frequently asked questions

What people ask us before starting

  1. No. Hábil MDW connects to them through the means they already have —services, database, files—, seeking not to touch their logic or their screens. Your systems keep doing their job.

  2. That is one of the reasons for having the platform. We connect through whatever means it has, even if it is a twenty-year-old desktop application, and if one day you replace it, coexistence is designed in stages.

  3. The operation waits and retries, and your team sees which step it is at and who it depends on. Retries are designed not to repeat the effect, for example, so that a retried payment doesn't generate a second charge.

  4. Yes. They come in through a guarded gateway, each with its own identity, permissions and usage limits, which are configured per client and per partner. Every call is recorded.

  5. On your infrastructure or on ours, in an installation just for you. It travels encrypted, is masked in the logs, and each system is sent only what it needs.

  6. It doesn't have to be. The steps, statuses and rules of each flow are meant to be defined in configuration. Your team changes them with us, and they stay written down.

  7. No. They are engaged separately. If later on you want your operations to reach the Lake or your AI to act in your systems, they connect.

  8. The rules, the steps and the map of your connections are written down and are yours, as is the audit trail of your operations. The platform uses open standards, and it is designed so a piece can be changed without rebuilding the integrations.

  9. Scope and cost are agreed before starting. What moves them most: how many systems and partners are connected, how many flows, how many operations and how often, whether there is personal data to protect, the level you choose and whether it runs on your infrastructure or on ours.

Don't see your question?

Let's talk about your case. In 45 minutes we tell you whether it makes sense, what depends on your systems and what risk you must resolve before going ahead. First conversation, at no cost.

Let's talk about your case

Prefer email? Write to us at hola@habil.mx