Saltar para o conteúdo principal

Arquitetura

Uma camada de decisão sobre os sistemas que já utiliza.

A OODARIS lê os dados do seu ERP, do POS e do planeamento. Por predefinição, escreve de volta apenas o que uma pessoa identificada aprovou. Os seus sistemas de registo continuam a ser a fonte de verdade.

Pedir uma revisão de arquiteturaVer o sistema operativo agêntico

Registo da decisão

Entrada 4417Aprovado

CL-03 Suburbano: escalão de redução B

  1. LidoVenda efetiva, stock, tráfego, preço e plano de cada cluster14 fontes
  2. Verificado1.412 verificações noturnas levantaram 3 exceções, entre as quais o CL-03Durante a noite
  3. PropostoEscalão B: um primeiro corte mais suave, mantido durante duas semanas87% de confiança
  4. Verificação de políticasDentro do limite de margem definido pelas finanças de mercadoriaValidado
  5. AprovadoPlaneamento de mercadoria08:47
  6. Escrito de volta
    • Condições de preço, SAP S/4HANA, 214 SKUOK
    • Ordens de transferência, CL-04 para CL-03, 3 packsOK
    • Open-to-buy e plano de mercadoria reprojetadosOK
  7. ReversãoReversível durante 14 diasAberta
O rastreio 4417 liga cada linha aos seus dados de origem.Vista de produto ilustrativa

Ciclo de vida da decisão

Todas as decisões passam pelas mesmas cinco etapas.

Uma revisão de arquitetura trata dos contratos entre elas: o que cada etapa recebe, o que lhe é permitido fazer, onde uma pessoa assina e o que fica registado.

  1. 01

    Reunir o contexto

    Reunir o contexto relevante de produto, localização, calendário, inventário, plano e políticas.

    Contratos de dados canónicos
  2. 02

    Delimitar e encaminhar o trabalho

    Atribuir tarefas delimitadas ao agente, modelo, otimizador ou serviço empresarial adequado.

    Coordenador e contexto partilhado
  3. 03

    Gerar uma recomendação

    Combinar evidências e restrições numa ação proposta, com justificação e confiança declarada.

    Modelos, otimização e regras
  4. 04

    Rever e aprovar

    Por predefinição, uma pessoa revê cada recomendação antes de as encomendas ou as alterações serem escritas de volta.

    Controlo de políticas e aprovação humana
  5. 05

    Escrever e aprender

    Enviar ações aprovadas através de interfaces controladas e comparar depois os resultados com o efeito esperado.

    API, eventos e pista de auditoria

Um plano de controlo para todo o fluxo

Os controlos acompanham a decisão em vez de serem reconstruídos em cada transição.

  • Limites de políticas definidos pelas suas equipas
  • Limiares de confiança
  • Intervenções e aprovações humanas
  • Registos de decisão e linhagem

Integrações

Onde a OODARIS se encaixa no seu ambiente tecnológico

A OODARIS lê dos sistemas que já utiliza e escreve as alterações de volta no sistema a que pertencem. Nada é migrado e os seus sistemas de registo continuam a ser a autoridade.

Lê de

Merchandising e ERP
SAP ECC ou S/4HANA, Microsoft D365, Oracle Retail, NetSuite, APTOS
Lojas e comércio
POS, Shopify
Plataformas de dados
Armazéns de dados como o Redshift, armazenamento de objetos como o S3
Tudo o resto
Fontes personalizadas através de APIs, fluxos de eventos ou exportações de ficheiros
OODARIS
  1. 01Um modelo de dados de retalhoProdutos, localizações, calendários e medidas de todas as fontes, com linhagem até ao registo de origem.
  2. 02Cinco decisõesPlaneamento financeiro de mercadoria, open-to-buy, sortido, alocação, e preços e reduções de preço.
  3. 03Aprovação por pessoa identificadaPor predefinição, nada é escrito de volta até o responsável da decisão aprovar. Se o responsável escolher Autonomous, a OODARIS age dentro das salvaguardas que ele definir. Cada ação fica registada com o seu motivo e pode ser revertida.

Escreve de volta

  • Condições de preço e reduções, por exemplo no SAP S/4HANA
  • Ordens de transferência e alterações de packs
  • Atualizações de plano: o open-to-buy (OTB) e o plano financeiro de mercadoria (MFP) reprojetados

Cada escrita de volta usa as próprias APIs ou os caminhos de eventos do sistema de destino e fica registada com a decisão que a originou.

Para iniciar um piloto, precisamos de

  • Histórico de transações de vendas
  • Acesso ao POS ou ao ERP, através de uma API ou de uma exportação de ficheiros
  • Dados de inventário, idealmente ao nível de SKU

Segurança e dados

Como são tratados os dados, o acesso e as aprovações

Estas são as práticas com que a OODARIS é construída e operada. A revisão de arquitetura percorre cada uma delas face aos seus próprios requisitos.

Tratamento de dados
A OODARIS lê os dados de que cada decisão precisa e só altera os seus sistemas através da escrita de volta: aprovada por uma pessoa ou executada dentro dos limites definidos pelo responsável da decisão. Os seus sistemas de registo continuam a ser a fonte de verdade.
Tenants e ambientes
Os dados de cada cliente ficam dentro do limite do seu próprio tenant e os ambientes são mantidos separados.
Controlo de acesso
A identidade e o acesso baseado em funções determinam quem pode ver, propor, aprovar e executar cada decisão. Os dados são encriptados.
Pista de aprovação
Cada recomendação, aprovação e intervenção é registada com quem a fez, quando e porquê. As verificações de políticas e os limiares de confiança são executados antes de algo chegar a um aprovador.
Reversão
Cada escrita de volta tem um caminho de reversão e a reversão fica no mesmo registo da decisão.
Rastreabilidade
Um ID de rastreio liga as entradas de origem, as execuções dos agentes e dos modelos, a aprovação, a escrita de volta e o resultado.

Avaliação técnica

O que os responsáveis de tecnologia perguntam primeiro

As questões que os responsáveis por tecnologia, IA e dados levam a uma avaliação de um Agentic OS e o que rever em conjunto.

Integração empresarial

Como se encaixa na empresa que já gerimos?

Fica acima dos sistemas que mantém e pode substituir as ferramentas de planeamento de que já não precisa: no ALDO Group, a OODARIS substituiu um sistema de planeamento legado e mais de 20 folhas de cálculo. Lê os dados do seu ERP, do POS e do planeamento e, por predefinição, escreve de volta apenas ações aprovadas, através das interfaces desses sistemas. Um piloto chega ao primeiro ciclo operacional em 8–12 semanas.

O que avaliar em conjunto

  1. Integração com sistemas empresariais existentes
  2. Segurança, acesso e responsabilidade operacional
  3. Implementação faseada com critérios claros

Funções compostas a partir de projetos reais no retalho

Traga-nos as suas perguntas de arquitetura.

Na revisão, mapeamos a OODARIS no seu ambiente: limites dos sistemas, circulação dos dados, acesso e aprovações e quem opera o quê. Traga os seus arquitetos empresariais e a sua equipa de segurança.

Pedir uma revisão de arquiteturaAgendar uma demonstração

O que acontece a seguir

  1. Uma resposta no prazo de 24 horas

    Uma pessoa da equipa OODARIS lê a sua nota e responde para marcar uma primeira chamada.

  2. A primeira chamada

    Os seus arquitetos percorrem connosco a forma como a OODARIS lê os seus dados, regista aprovações, escreve alterações de volta e as reverte.

  3. Um piloto, se fizer sentido

    8–12 semanas até um primeiro ciclo operacional, executado com os seus dados e as suas aprovações.