Hábil MDW

Os sistemas da empresa, enfim de acordo.

O sistema central, o ERP e os canais da empresa conectados sem substituí-los, com o rastro de cada operação.

A plataforma que conecta os sistemas da empresa.

O que é o Hábil MDW?

O Hábil MDW, a Enterprise Middleware Platform da Hábil, é a camada que fica entre os sistemas que a empresa já tem. Por ela passa cada pedido, cada cobrança, cada apólice e cada aviso, com a resposta de quem o recebeu e o motivo, se algo falhou.

Os sistemas da empresa funcionam; o que se perde está entre eles. Um pagamento que saiu do canal e não chegou à contabilidade. Uma apólice emitida que o CRM não conhece. Um pedido que a loja cobrou e que o armazém não viu. Cada sistema diz que está tudo bem, e a diferença fica com as pessoas da empresa, com planilhas e telefonemas, no fechamento do mês. Quando as conexões crescem sem um mapa, o trabalho manual vira parte da operação, e trocar um sistema fica impensável, porque ninguém sabe o que vai quebrar.

O Hábil MDW põe ordem nesse espaço. Ele se conecta ao sistema central, ao ERP e aos canais da empresa pelas vias que cada um já tem, converte o que chega a uma mesma linguagem, conduz cada operação pelas etapas que o negócio define e deixa registrado o que aconteceu, quando e quem fez. Os sistemas continuam fazendo o que lhes cabe; o Hábil MDW cuida de que eles se entendam.

É uma plataforma própria para cada cliente: as operações da empresa não compartilham instalação com as de mais ninguém. Roda na infraestrutura da empresa ou na nossa, com a Hábil à frente da operação. E é contratado separadamente da Hábil AI e do Hábil Lake: é possível usar uma plataforma sem as outras.

Três níveis, conforme a necessidade

O Hábil MDW é um produto e um serviço. O produto é a plataforma. O serviço é o que fazemos junto com a empresa para que os sistemas dela trabalhem como um só. É contratado por níveis, e cada um se apoia no anterior.

A plataforma

Os sistemas conectados, com rastro

O que se obtém com o produto:

  • Uma instalação exclusiva para a empresa, na infraestrutura dela ou na nossa, operada pela Hábil.
  • Conexão com o que a empresa já tem. O sistema central, o ERP, a loja virtual, os canais de atendimento e os parceiros, pelas vias que cada sistema já oferece.
  • Uma mesma linguagem para todos. Cada sistema entra com o próprio formato, e a plataforma o traduz para um modelo comum: um pedido é um pedido, venha de onde vier.
  • As etapas do negócio, em configuração. O que acontece depois de cobrar, quem é avisado, o que se fatura: isso é definido em configuração, não em código.
  • Uma porta com guarda para os parceiros. Bancos, lojas, corretores e distribuidores se conectam com identidade e permissões próprias.
  • O rastro de cada operação. O que foi enviado, o que cada sistema respondeu, a que horas e, se falhou, por quê.
  • Sem licenças empresariais pagas. Usamos componentes abertos ou de uso livre.

Para começar

O primeiro fluxo, de ponta a ponta

Conectamos os sistemas de um primeiro fluxo completo —por exemplo, do pedido à cobrança e à nota fiscal—, definimos com a empresa as etapas e as regras, e o deixamos funcionando com o rastro à vista da equipe.

Neste nível escolhemos juntos o fluxo que hoje mais trava ou que mais custa em trabalho manual. Para esse fluxo, deixamos por escrito qual sistema faz cada etapa, o que é enviado a ele, o que ele deve responder e o que acontece se não responder. Ao terminar, esse fluxo passa pela plataforma, e a conexão anterior só é desligada quando a nova demonstrou que bate.

Para crescer

Mais fluxos, canais e parceiros

Somamos fluxos, canais e parceiros, com alertas, painéis de operação e a convivência por etapas com os sistemas que serão substituídos.

Este nível é para quando a plataforma já é o caminho por onde passa a operação e mais áreas querem usá-la. Abrimos a porta a novos parceiros, acrescentamos canais de atendimento, levamos para o mesmo caminho as conexões antigas que ninguém quer tocar e, se a empresa decidir, conectamos as operações dela ao Hábil Lake e à Hábil AI.

Reconheça a área

Diretoria e Finanças«Cada sistema bate sozinho; juntos, não. No fechamento, alguém concilia à mão o que diz o sistema central com o que o banco recebeu.»Cada operação passa por um mesmo caminho, com a resposta e a hora, e o que não chegou é visto no dia em que acontece, não no fechamento
Operações«Não sabemos se essa operação chegou. Tentamos de novo à mão, e às vezes ela se duplica.»Cada envio fica com a resposta ou com o motivo da falha, e as novas tentativas são desenhadas para não repetir o efeito
Comercial«Os parceiros querem vender a partir do próprio sistema, e mandamos arquivos por e-mail para eles.»Uma porta para os parceiros, com identidade, permissões e rastro próprios, para que cotem, emitam ou cobrem do lado deles
Tecnologia (CIO / CTO)«Se trocarmos esse sistema, todo o resto cai, e só uma pessoa sabe como eles se conectam.»As conexões deixam de viver dentro de cada sistema e passam para uma camada com mapa e com rastro; o detalhe está mais abaixo
Compliance«O auditor pede evidência, e a procuramos em e-mails e em registros soltos.»Cada operação registrada com a resposta, a hora e quem a fez, e os dados pessoais mascarados nos registros técnicos

Onde o Hábil MDW gera valor

Oito cenários. São cenários, não clientes: mostram o tipo de problema que o Hábil MDW resolve, como resolve e quais capacidades usa.

Cenário: tarifas que mudam sem um projeto de TI · Seguros de automóvel e de danos

Antes: o prêmio muda conforme a cobertura, a região, a franquia, a importância segurada, a idade, a vigência e o canal. Com um sistema sob medida, cada ajuste de tarifa ou de regra é um projeto de TI, e o canal de corretores espera semanas.

O que muda: a seguradora ou o canal de corretores cota, emite, cobra e fatura apólices com as próprias regras e tarifas. Um ajuste de tarifa é configuração, e chega igual a todos os canais conectados: o site, os corretores e os parceiros.

Por que é difícil: a tarifa vive no sistema central, a cobrança em outro sistema e a nota fiscal em um terceiro, e os três precisam contar a mesma apólice.

Como o Hábil MDW resolve: as regras e as etapas da apólice são definidas em configuração, e a plataforma leva cada apólice do sistema central à cobrança e à nota fiscal, com a resposta de cada sistema à vista.

Capacidades: Conectar os sistemas · As etapas do negócio · Porta com guarda.

Cenário: o convênio com um parceiro, sem operá-lo à mão · Seguros coletivos, afinidade e garantia estendida

Antes: um convênio com um parceiro ou uma garantia estendida é um plano com regras, cortes, cobrança e reclamação que se opera à mão ou em um desenvolvimento dedicado a esse parceiro.

O que muda: a emissão em lote, o débito automático, o dossiê, a reclamação e o relatório ao parceiro seguem um mesmo caminho. O parceiro consulta a partir do próprio sistema o que lhe cabe, com identidade própria.

Por que é difícil: cada parceiro manda os arquivos com o próprio formato e os próprios cortes, e o relatório de volta precisa bater com o que foi cobrado.

Como o Hábil MDW resolve: os arquivos de cada parceiro são traduzidos para a mesma linguagem, cada lote deixa o próprio rastro e o parceiro entra pela porta com guarda, com permissões apenas sobre o que é dele.

Capacidades: Conectar os sistemas · As etapas do negócio · Porta com guarda · Operar 24/7 com rastro.

Cenário: a rede de saúde, em um mesmo caminho · Saúde: planos coletivos e redes

Antes: catálogos, consultórios, carteirinha digital, agenda e consentimento vivem entre planilhas e sistemas que não conversam entre si. Uma consulta é marcada em cima de outra e um consentimento se perde.

O que muda: a cotação, a carteirinha, uma agenda que evita conflitos de horário, a cobrança e a evidência do consentimento passam pela mesma plataforma. Cada consultório da rede vê o que lhe cabe.

Por que é difícil: os dados de saúde exigem um cuidado especial, e cada consultório usa um sistema próprio, ou nenhum.

Como o Hábil MDW resolve: a plataforma conecta cada consultório pela via que ele tiver, guarda a evidência de cada consentimento e deixa os dados pessoais mascarados nos registros técnicos.

Capacidades: Conectar os sistemas · As etapas do negócio · Operar 24/7 com rastro.

Cenário: do simulador à cobrança · Crédito, financeiras e previdência

Antes: a parcela muda conforme a entrada, o prazo, o perfil de risco, o seguro incluído e a campanha; o cálculo da aposentadoria é uma fórmula complexa. Depois é preciso aprovar e cobrar, em outros sistemas.

O que muda: o simulador, a aprovação e a cobrança seguem um mesmo fluxo, e a fórmula é configuração. Uma mudança de campanha é configurada uma vez para todos os canais conectados.

Por que é difícil: a consulta ao bureau de crédito, a decisão, a assinatura e a cobrança vivem em sistemas diferentes, e um crédito no meio do caminho não pode ficar sem dono.

Como o Hábil MDW resolve: cada solicitação leva o próprio estado e as próprias etapas; a equipe vê em que etapa ela está e de quem depende, para que nenhum crédito fique sem dono.

Capacidades: Conectar os sistemas · As etapas do negócio · Operar 24/7 com rastro.

Cenário: preço, estoque e envios com a rede de distribuição · Varejo e comércio eletrônico

Antes: o preço depende do insumo, das variantes, do volume, do canal e do cupom. É preciso reservar estoque e coordenar envios com várias transportadoras, entre vários sistemas que não conversam entre si.

O que muda: o catálogo, o preço, o carrinho, o estoque com reservas e os envios passam pela mesma plataforma. Cada envio leva o próprio código de rastreio e o próprio estado.

Por que é difícil: o estoque muda na loja, no armazém e na rede ao mesmo tempo, e cada transportadora responde do próprio jeito.

Como o Hábil MDW resolve: o estoque é reservado no momento da compra, com um desenho pensado para não vender duas vezes a mesma peça; cada transportadora se conecta pela própria via e a resposta dela é traduzida para a mesma linguagem, e o ERP recebe cada venda com a confirmação.

Capacidades: Conectar os sistemas · As etapas do negócio · Porta com guarda.

Cenário: a obrigação que não vence · Conformidade ambiental e regulatória

Antes: unidades, autorizações, evidências e lembretes vivem em pastas e planilhas. Um vencimento que passa custa uma multa, ou uma interdição.

O que muda: cada obrigação tem o próprio dossiê, a evidência documental e o aviso antes de vencer. Dá para ver qual unidade tem qual obrigação pendente e quem cuida dela.

Por que é difícil: as obrigações vêm de várias autoridades, cada uma com os próprios prazos, e as evidências ficam nas mãos de pessoas diferentes.

Como o Hábil MDW resolve: cada obrigação é um processo com estados e prazos próprios; a plataforma avisa quem precisa agir, guarda a evidência com a data e deixa o rastro pronto para o auditor.

Capacidades: As etapas do negócio · Operar 24/7 com rastro.

Cenário: em que pé está cada pedido, em uma única tela · Rastreabilidade de pedidos

Antes: um pedido on-line passa pelo canal, pela cobrança, pelo estoque, pelo ponto que o atende, pela transportadora e pelo faturamento. Cada sistema conhece a própria parte e nenhum conhece a história completa. Quando algo trava, cada área diz «do meu lado saiu certo», e ninguém responde ao cliente.

O que muda: com o número de um pedido, vê-se em uma única tela o percurso dele: em que etapa está, o que foi enviado a cada sistema, o que cada um respondeu, o que falta e de quem depende que avance.

Por que é difícil: o rastro está espalhado pelos registros de cada sistema, com identificadores diferentes, e há falhas que não aparecem como erro: o envio saiu, mas a resposta não chegou.

Como o Hábil MDW resolve: como cada operação passa pela plataforma, o percurso já está registrado; a plataforma o reconstrói, separa o que falhou do que ainda está esperando e diz com quem está a bola.

Capacidades: Operar 24/7 com rastro · Conectar os sistemas · Conviver com o legado.

Cenário: um pedido, muitos canais e uma única verdade · Venda e atendimento omnicanal

Antes: o cliente compra no site, pergunta pelo WhatsApp e retira na loja. Cada canal tem a própria versão do pedido, e o aviso que chega ao cliente às vezes não coincide com o que aconteceu.

O que muda: cada canal entra com o próprio formato e a plataforma o converte para um mesmo modelo de pedido, com o estado de cada item. Os avisos ao cliente —por WhatsApp, e-mail, SMS, notificação ou dentro do aplicativo da empresa— saem do mesmo estado, e a nota fiscal é emitida no mesmo fluxo.

Por que é difícil: cada canal tem o próprio ritmo e as próprias regras, e um aviso que sai antes da hora diz algo que ainda não é verdade.

Como o Hábil MDW resolve: os estados do pedido, os itens e o que acontece em cada etapa são definidos em configuração. Cada aviso ao cliente é desenhado para sair quando o que ele anuncia já aconteceu.

Capacidades: Conectar os sistemas · As etapas do negócio · Operar 24/7 com rastro.

Em que pé está o pedido 10482, em uma única tela

Exemplo · dados ilustrativos

O mesmo pedido: procurado sistema por sistema, ou reconstruído pela plataforma. Mude o estado para ver a diferença.

Em que pé está o pedido 10482, em uma única tela
Hoje: perguntar área por área
EtapaSistemaEstado
CompraLoja virtual«do meu lado saiu certo»
CobrançaGateway de pagamento«do meu lado saiu certo»
ReservaEstoquesem dado
VendaERPsem dado
Nota fiscalFaturamentosem dado

Cada área diz que do lado dela saiu certo, e ninguém sabe em que pé está o pedido.

O que a plataforma faz

Cinco capacidades, contadas em três partes: o problema, o que muda e por que é difícil.

1. Conectar o sistema central, o ERP e os canais da empresa, sem substituí-los

O problema: o sistema central, o ERP, a loja virtual, a central de atendimento e os parceiros conversam por conexões feitas sob medida, uma a uma. Cada uma vive dentro de um sistema diferente, e ninguém tem o mapa completo.

O que muda: nós nos conectamos ao sistema central e ao ERP da empresa pelas vias que eles já têm —serviços, banco de dados, arquivos— e aos canais pelas vias deles. Cada sistema entra com o próprio formato e a plataforma o converte para uma mesma linguagem: um pedido, uma apólice ou uma cobrança são descritos da mesma forma, venham de onde vierem. Os sistemas continuam fazendo o que lhes cabe; o que muda é que agora eles se entendem.

Por que é difícil: cada sistema dá às coisas os próprios nomes, e o que um chama de «cliente» outro chama de «conta» ou de «segurado». As equivalências são escritas com a equipe da empresa, uma vez, e testadas a cada operação.

2. As etapas do negócio, com evidência

O problema: quando algo acontece em um sistema —cobrou-se, emitiu-se, atendeu-se—, os outros ficam sabendo tarde, pela metade ou duas vezes. E as etapas seguintes vivem na cabeça de alguém ou em um código que ninguém quer tocar.

O que muda: cada operação segue as etapas que o negócio define: o que acontece depois de cobrar, quem é avisado, o que se fatura, o que se faz se um sistema não responde. As etapas e os estados são desenhados para ser definidos em configuração, não em código, de modo que mudar uma regra não precisa ser um projeto de TI. Quando um sistema precisa saber o que aconteceu em outro, recebe um aviso. Se o aviso chegar duas vezes, ele é desenhado para que o efeito no negócio seja aplicado uma única vez. Se um aviso depende de um dado que outro sistema ainda não devolveu, a plataforma espera esse dado e tenta de novo, em vez de mandar um documento incompleto.

Por que é difícil: repetir um aviso sem repetir a cobrança exige desenhá-lo desde o início, operação por operação. Acrescentar isso depois, sobre conexões que já estão em uso, custa muito mais.

3. Uma porta com guarda para os parceiros e os sistemas

O problema: os parceiros da empresa —bancos, lojas, corretores, distribuidores— querem cotar, emitir ou cobrar a partir do próprio sistema. Abrir a porta para eles sem controle é um risco; não abrir é vender mais devagar.

O que muda: há uma única porta de entrada, com guarda. Cada parceiro e cada sistema entra com identidade própria e só pode fazer o que as permissões dele deixam. Os limites de uso —quantas consultas, em que horários, sobre o quê— são configurados por cliente e por parceiro. Cada chamada fica registrada e, se uma credencial se perde, revoga-se só essa, sem parar os demais parceiros.

Por que é difícil: cada parceiro precisa de algo próprio, e a tentação é colocar regras de negócio na porta. Ali elas não entram: a porta cuida de quem entra; as regras vivem nos processos, onde podem ser testadas.

4. Desenhada para operar 24/7, com rastro de cada operação

O problema: uma integração que falha não avisa: deixa um buraco que alguém preenche à mão. E quando o cliente pergunta em que pé está o pedido, a resposta é uma investigação entre áreas.

O que muda: a plataforma é desenhada para operar 24/7, com rastro de cada operação: o que foi enviado a cada sistema, o que ele respondeu, a que horas e, se falhou, por quê. Dado um número de pedido ou de apólice, a plataforma reconstrói o percurso e diz o que falta e de quem depende: da plataforma, do sistema central da empresa ou do canal. Um envio que deu errado é refeito pela equipe de operação da empresa como um envio novo, com o rastro de quem o fez e sem mexer no banco de dados à mão.

Por que é difícil: o rastro precisa servir a dois públicos —a equipe de operação, que quer saber o que fazer, e o auditor, que quer evidência— sem expor os dados pessoais que viajam em cada operação.

5. Conviver com os sistemas antigos, e sair deles por etapas

O problema: o sistema central tem vinte anos, o barramento de integração ninguém mais quer tocar e a substituição do ERP é adiada ano após ano porque ninguém sabe o que vai quebrar.

O que muda: nós nos conectamos ao sistema central pelas vias que ele já tem —serviços, banco de dados, arquivos—, mesmo que seja um aplicativo de desktop, procurando não mexer na lógica nem nas telas dele; se uma extensão for inevitável, dizemos isso no diagnóstico. Quando a empresa decide substituir um sistema, desenhamos a convivência por etapas: os canais continuam alimentando o sistema certo, a migração é feita por trechos e a conexão anterior é desligada quando a nova demonstrou que bate.

Por que é difícil: enquanto dura a convivência, os dois sistemas precisam contar a mesma história. Isso exige comparar, trecho por trecho, o que diz o antigo com o que diz o novo.

Modernizar o core

Onde roda

Na infraestrutura da empresa —a nuvem que ela já paga ou os próprios servidores— ou na nossa, com a Hábil à frente da operação. Cada cliente tem uma instalação própria: as operações da empresa não se misturam com as de mais ninguém.

Se roda na nossa, a instalação tem conexões, credenciais e rastro próprios. Nos dois casos, nós instalamos, atualizamos, fazemos backup e monitoramos a plataforma, no horário que combinarmos, com um serviço mensal.

O que nunca fazemos

Mudar a lógica ou as telas dos sistemas da empresa sem avisar antes. Nós nos conectamos pelas vias que eles já têm e, se uma extensão for inevitável, isso é combinado no diagnóstico.

Colocar regras de negócio na porta de entrada, onde depois ninguém consegue testá-las.

Abrir para um parceiro mais do que as permissões dele deixam.

Misturar as operações da empresa com as de outro cliente, ou usar os dados dela para algo que ela não autorizou.

Desligar uma conexão antiga antes que a nova demonstre que bate.

Deixar a empresa presa: as regras e as etapas do negócio ficam escritas e são dela.

Os detalhes de controle e segurança vêm a seguir.

Controle, segurança e dados

Quem entra e o que pode fazer

Cada parceiro, cada sistema e cada pessoa entra com identidade própria, e só pode fazer o que as permissões deixam. Os limites de uso são configurados por cliente e por parceiro. Se uma credencial se perde, revoga-se só essa, sem afetar os demais.

O que aconteceu com cada operação

Cada operação fica registrada com o que foi enviado, o que cada sistema respondeu, a hora e, se falhou, o motivo. Quando alguém pergunta o que aconteceu com um pedido, uma apólice ou uma cobrança, a resposta está escrita, não na memória de uma pessoa.

Os dados pessoais, no caminho

Viajam criptografados entre os sistemas, saem mascarados nos registros técnicos e cada sistema recebe só o que precisa. As regras são definidas com a equipe da empresa, de acordo com as políticas dela.

Evidência para o auditor

Os acessos de parceiros e sistemas, por credencial e com registro; cada operação, com a resposta e a hora. Evidência consultável para o auditor, sem procurá-la em e-mails.

Registro e backup

A plataforma tem backup com uma ordem de restauração escrita, e é monitorada com sinais próprios: quais operações esperam resposta, quais falharam e desde quando, qual conexão deixou de responder.

Para a equipe de tecnologia

Como é feito. Uma plataforma de peças pequenas, cada uma com uma responsabilidade de negócio —pedido, estoque, cobrança, faturamento, envios, notificações, identidade, entre outras—, que conversam por eventos e por APIs.

Por capacidade.

Conexão.

Adaptadores por sistema para o sistema central e o ERP, pelas interfaces que eles já expõem: serviços SOAP ou REST, procedimentos armazenados ou tabelas de intercâmbio, arquivos. Nos ERP priorizamos as interfaces que o fabricante suporta —no SAP, por exemplo, JCo, OData, IDoc ou REST; também Oracle, Microsoft Dynamics 365, Odoo ou CONTPAQi—, para não deixar desenvolvimentos que atrapalhem a atualização. Bancos de dados como Oracle, DB2 (também em IBM i), SQL Server, PostgreSQL, MySQL, MariaDB ou MongoDB. Cada adaptador traduz para o modelo comum.

Orquestração e eventos.

O fluxo de cada operação é uma máquina de estados descrita em configuração; acrescentar um canal ou um desfecho não exige recompilar. Os eventos seguem o padrão CloudEvents e viajam por um barramento com o protocolo do Kafka ou pela fila que a empresa já usa (IBM MQ, RabbitMQ ou outra). Cada consumidor é idempotente: é desenhado para que um evento repetido não repita o efeito.

APIs com guarda.

Um gateway único com identidade (OAuth 2.0 / OpenID Connect), permissões por consumidor, limites de uso configuráveis por cliente e registro de cada chamada. Pode ser o que a empresa já tem —Apigee, Azure API Management, Amazon API Gateway, Kong, WSO2, APISIX ou outro—. APIs REST ou GraphQL, com contrato publicado e versionado.

Operação e rastro.

Log estruturado por operação, com um identificador que a acompanha entre os sistemas, métricas e traces com padrões abertos (OpenTelemetry), e novas tentativas com espera, desenhadas para não repetir o efeito. A reconstrução do percurso de um pedido é montada com esse rastro.

Convivência com o legado.

Conexão com IBM i (AS/400), com programas RPG expostos como serviços sem reescrevê-los; com barramentos legados como WebSphere ESB, IBM Integration Bus, MuleSoft ou WSO2, que continuam de pé enquanto a migração avança trecho por trecho.

Fiscal.

Faturamento CFDI com complemento de pagamento e cancelamentos, orquestrado até o provedor de timbrado da empresa.

Instalação. Uma instalação por cliente, em contêineres, na infraestrutura da empresa ou na nossa. Cada integração tem identidade e criptografia próprias, e para fora só se publica o indispensável. Sem licenças empresariais pagas: componentes abertos ou de uso livre, desenhados para ser substituídos sem refazer as integrações.

O Hábil MDW com a Hábil AI e o Hábil Lake

As três grandes soluções da Hábil dividem o trabalho: o Hábil MDW conecta os sistemas, o Hábil Lake organiza os dados e a Hábil AI responde e atende com eles. São três plataformas independentes: são contratadas separadamente e nenhuma exige as outras. Quando a empresa tem mais de uma, elas se alimentam assim:

O que acontece chega ao Lake.

Cada operação que passa pelo Hábil MDW —um pedido, uma cobrança, uma apólice— pode chegar ao Hábil Lake no momento em que acontece, com a história dela. O Lake a organiza e a concilia com o sistema de origem.

A IA da empresa age pela mesma porta.

Quando um agente da Hábil AI consulta um pedido ou prepara um reembolso, faz isso pela porta com guarda do Hábil MDW, com identidade e permissões próprias e o rastro de cada chamada. O que movimenta dinheiro ou dados é executado com uma pessoa aprovando.

A Nova sabe em que pé está o pedido.

Quando um cliente pergunta pelo WhatsApp em que pé está o pedido, a Nova responde com o estado que o Hábil MDW registra, não com uma suposição.

O rastro é lido pela IA.

Um agente revisa toda manhã as operações paradas, encontra o motivo de cada uma no rastro da plataforma e as deixa para a equipe.

As previsões voltam para a operação.

O que a previsão da Hábil AI estima —por exemplo, a reposição— chega aos sistemas da empresa pelo Hábil MDW, como uma proposta que uma pessoa aprova.

Conheça o Hábil Lake: uma única versão dos números da empresa, conciliada com o sistema dela.

Conheça a Hábil AI: a IA que trabalha com os sistemas da empresa, com uma pessoa aprovando o que movimenta dinheiro ou dados.

Como começamos

Em uma primeira conversa, sem custo, escolhemos o fluxo da operação que hoje mais trava.

1

A empresa nos escreve por WhatsApp informando o setor, a função e os sistemas principais.

2

Agendamos 45 minutos com um arquiteto da Hábil.

3

Perguntamos quais sistemas a empresa usa, como eles se conectam hoje e onde o rastro se perde. Não pedimos acessos nem dados dos clientes.

4

A empresa sai com um mapa das conexões: qual sistema conversa com qual, por qual via, quais falham sem avisar, quais riscos vemos e se convém ou não avançar.

5

Se convém: começamos pelo nível Para começar, com escopo, entregáveis e custo acordados antes de começar, e uma meta clara para dar a etapa por concluída: que o primeiro fluxo passe pela plataforma, com o rastro à vista.

O caminho é: diagnóstico → proposta com escopo, custo e risco → primeiro fluxo conectado → operação.

O que precisamos da equipe da empresa: uma pessoa que conheça o fluxo e decida as regras dele, os acessos aos sistemas que serão conectados quando começarmos e a validação do fluxo antes de desligar a conexão anterior.

Trabalhamos com poucos clientes por vez: o arquiteto que revisa o diagnóstico acompanha o projeto até o fim.

Dizemos que não quando os sistemas da empresa já conversam bem entre si e ninguém concilia à mão, quando o fluxo vive em um só sistema, ou quando o custo da plataforma é maior do que o trabalho manual que ela poupa.

Perguntas frequentes

O que nos perguntam antes de começar

  1. Não. O Hábil MDW se conecta a eles pelas vias que já têm —serviços, banco de dados, arquivos—, procurando não mexer na lógica nem nas telas deles. Os sistemas continuam fazendo o que lhes cabe.

  2. Essa é uma das razões de ter a plataforma. Nós nos conectamos pelas vias que ele tiver, mesmo que seja um aplicativo de desktop de vinte anos atrás e, se um dia a empresa o substituir, a convivência é desenhada por etapas.

  3. A operação espera e tenta de novo, e a equipe vê em que etapa ela está e de quem depende. As novas tentativas são desenhadas para não repetir o efeito, por exemplo, para que uma cobrança refeita não gere uma segunda cobrança.

  4. Sim. Eles entram por uma porta com guarda, cada um com identidade, permissões e limites de uso próprios, que são configurados por cliente e por parceiro. Cada chamada fica registrada.

  5. Na infraestrutura da empresa ou na nossa, em uma instalação exclusiva. Viajam criptografados, saem mascarados nos registros técnicos e cada sistema recebe só o que precisa.

  6. Não precisa ser. As etapas, os estados e as regras de cada fluxo são pensados para ser definidos em configuração. A equipe da empresa os muda junto conosco, e eles ficam escritos.

  7. Não. São contratados separadamente. Se mais adiante a empresa quiser que as operações cheguem ao Lake ou que a IA dela aja nos sistemas, eles se conectam.

  8. As regras, as etapas e o mapa das conexões ficam escritos e são da empresa, assim como o rastro das operações. A plataforma usa padrões abertos, e é desenhada para trocar uma peça sem refazer as integrações.

  9. O escopo e o custo são acordados antes de começar. O que mais os altera: quantos sistemas e parceiros são conectados, quantos fluxos, quantas operações e com que frequência, se há dados pessoais a proteger, o nível escolhido e se roda na infraestrutura da empresa ou na nossa.

A pergunta não está aqui?

Vamos conversar sobre o seu caso. Em 45 minutos dizemos se convém, o que depende dos sistemas e qual risco deve ser resolvido antes de avançar. Primeira conversa, sem custo.