Pesquisa e Descoberta · Etapa 01 · Como Trabalhamos
Cada projeto do OpenQCore começa com uma investigação estruturada. Antes de propor soluções em inteligência artificial, automação, software ou infraestrutura, estudamos o problema como um sistema: seus objetivos, partes interessadas, fluxos de trabalho, decisões, dados, tecnologias, dependências, restrições, riscos e resultados mensuráveis.
Nosso processo de descoberta combina pesquisa, pensamento sistêmico, análise de engenharia e raciocínio de negócios para avançar de um desafio observado até uma definição de problema defensável.
Porque a primeira pergunta não deve ser:
Não esta questão
"Que tecnologia devemos implementar?"
Em vez disso, esta pergunta
"Qual problema estamos realmente resolvendo — quais evidências o sustentam, quais são as causas e qual resultado precisa mudar?"
Pesquisa · Evidência · Análise de Sistemas · Análise de Negócios · Medição
Por que a descoberta vem primeiro
Experimentar com inteligência artificial tornou‑se muito mais fácil. Converter essa experimentação em valor organizacional mensurável continua sendo muito mais difícil.
74%
das empresas ainda não tinham demonstrado e escalado valor tangível com IA.
BCG, Where's the Value in AI?, 2024 · n=1.000 executivos seniores.
A pesquisa da BCG de 2024, baseada em 1.000 CxOs e executivos seniores em mais de 20 setores e 59 países, mostrou que apenas 26% das empresas haviam desenvolvido as capacidades necessárias para ir além de provas de conceito e gerar valor tangível com IA.
Isso não significa que a tecnologia seja ineficaz. Significa que a tecnologia, por si só, é insuficiente.
As organizações podem começar por adotar um modelo, uma plataforma ou uma tecnologia de automação e só depois descobrir que a limitação subjacente está em outro lugar: processos fragmentados, dados inacessíveis, responsabilidade pouco clara, limitações de integração, controles inadequados, objetivos mal definidos ou um problema que nunca foi medido.
Portanto, a OpenQCore inverte a sequência: a tecnologia deve ser escolhida como consequência de compreender o problema — não como substituta dessa compreensão.
Uma abordagem multidisciplinar
Problemas organizacionais complexos raramente pertencem a uma única disciplina. A OpenQCore analisa‑os por meio de três perspectivas complementares.
Observar · Questionar · Formular hipóteses · Testar · Validar
O raciocínio científico ajuda a distinguir observações de suposições, formular questões, examinar explicações concorrentes e determinar quais evidências apoiariam ou contradiziam uma hipótese. Não presumimos que a primeira explicação seja a correta.
Sistemas · Interfaces · Dados · Dependências · Restrições · Confiabilidade
A análise de engenharia examina como os componentes interagem dentro do sistema mais amplo — software, infraestrutura, dados, pessoas, processos, interfaces, sistemas externos e dependências operacionais.
Essa perspectiva está alinhada com o pensamento moderno de engenharia de sistemas. A ISO/IEC/IEEE 15288:2023 define processos do ciclo de vida de sistemas aplicáveis a elementos individuais e a sistemas‑de‑sistemas, com envolvimento das partes interessadas ao longo de todo o ciclo de vida.
Objetivos · Economia · Processos · Risco · Valor · Medição
A análise de negócios determina por que o problema importa. Examinamos o resultado desejado, as partes interessadas afetadas, o impacto operacional, considerações econômicas, restrições organizacionais e como a melhoria seria medida.
A transformação por IA costuma ser discutida principalmente em termos de modelos e algoritmos. As evidências de implementação apontam para um quadro mais amplo: a pesquisa da BCG de 2024 indicou que cerca de 70% dos desafios enfrentados pelas empresas em iniciativas de IA estavam relacionados a pessoas e processos, cerca de 20% à tecnologia e apenas 10% aos algoritmos.
10%
Algoritmos
BCG Build for the Future 2024 · Estudo Global · n=1.000.
20%
Tecnologia e Dados
BCG Build for the Future 2024 · Estudo Global · n=1.000.
70%
Pessoas e Processos
BCG Build for the Future 2024 · Estudo Global · n=1.000.
Estas percentagens fazem parte do quadro de pesquisa da BCG, não de uma lei universal. Ainda assim reforçam um princípio importante de engenharia: o modelo é apenas um componente de um sistema sociotécnico mais amplo. Na OpenQCore, a fase de descoberta analisa, portanto, não só a camada de inteligência, mas também o ambiente operacional em que essa inteligência será inserida.
A Metodologia de Pesquisa da OpenQCore
A fase de descoberta é conduzida como uma sequência estruturada de investigação. A profundidade varia conforme o projeto, mas a estrutura analítica mantém-se consistente.
Qual resultado importa — e para quem?
Começamos por identificar as pessoas, funções e sistemas afetados pelo problema. O pedido declarado pela organização não é automaticamente tratado como o objetivo subjacente — "precisamos de um agente de IA" descreve uma possível implementação, não necessariamente o problema de negócio ou de engenharia.
Analisamos
Partes interessadas · Responsáveis pelas decisões · Usuários · Objetivos de negócio · Objetivos operacionais · Incentivos · Dependências · Requisitos conflitantes
Resultados
Modelo de partes interessadas e objetivos
Como o sistema opera na prática hoje?
Reconstruímos o processo operacional atual em vez de depender exclusivamente da forma como ele está documentado. Quando apropriado, estabelecemos linhas de base quantitativas para o fluxo de trabalho existente.
A análise pode incluir
Processos · Tarefas · Decisões · Transferências · Filas · Exceções · Intervenção humana · Gargalos · Retrabalho · Fluxo de informação
Resultados
Modelo operacional do estado atual
Em que ambiente técnico estamos a trabalhar?
Examinamos a arquitetura relacionada ao problema e investigamos o ambiente de dados separadamente. Isso é importante porque uma capacidade de IA que funciona experimentalmente pode não ser adequada para produção se as informações necessárias não puderem ser acedidas de forma fiável, segura ou com qualidade suficiente.
Analisamos
Aplicações · Serviços · APIs · Bancos de dados · Infraestrutura · Integrações · Identidade · Segurança · Dependências externas — e disponibilidade, acessibilidade, estrutura, qualidade, linhagem, propriedade, cobertura, atualidade e sensibilidade dos dados
Resultados
Panorama de sistemas e dados
Que ambiente externo molda o problema?
Uma solução tecnicamente válida pode ainda ser inadequada do ponto de vista operacional ou comercial. O escopo depende do projeto — um sistema de saúde regulado, uma plataforma financeira e uma ferramenta interna de produtividade não exigem o mesmo tipo de investigação contextual.
Quando relevante, analisamos
Condições de Mercado · Estrutura do Setor · Regulamentação · Normas Técnicas · Ambiente Competitivo · Panorama Tecnológico · Expectativas dos Clientes · Dependências Externas
Resultados
Modelo de Contexto e Ambiente Externo
O que limita o espaço de soluções?
Consideramos as restrições como entradas de projeto, e não como surpresas descobertas durante a implementação. Também separamoѕ explicitamente fatos conhecidos, pressupostos, incógnitas conhecidas, dependências e riscos — porque a incerteza deve ser documentada, não transformada silenciosamente em certeza.
Identificamos as relevantes
Restrições Técnicas, Operacionais, Orçamentárias e de Prazo · Requisitos regulatórios, de segurança e de privacidade · Restrições Organizacionais · Riscos de Adoção · Dependências de Integração · Limitações de Dados
Resultados
Registro de Restrições, Pressupostos e Riscos
O que exatamente precisa mudar?
A fase de descoberta converge para uma definição precisa do problema, cobrindo a condição observada, evidências, causas raiz, sistema afetado, linha de base, estado alvo, critérios de sucesso, restrições e objetivos explicitamente excluídos.
A definição inclui
Condição Observada · Evidências · Causas Raiz · Sistema Afetado · Linha de Base · Estado Alvo · Critérios de Sucesso · Restrições · Objetivos Excluídos
Resultados
Definição do Problema Validada
O Ciclo da Descoberta
A descoberta não é apenas uma lista de verificação a ser completada uma única vez, do início ao fim.
Observar
Analisar
Mapear
Hipotetizar
Validar
Definir
Uma vez alcançada confiança suficiente: Problema Validado → Estratégia e Arquitetura.
Aplicando a Metodologia
Um problema observado e sua causa subjacente nem sempre coincidem. Considere um exemplo operacional simplificado.
Condição observada: As solicitações dos clientes demoram 48 horas para serem processadas.
Evidência do fluxo de trabalho: As solicitações passam por várias aprovações manuais.
Evidência do sistema: Informações relevantes estão em aplicações desconectadas.
Evidência de dados: As mesmas informações são recuperadas e verificadas repetidamente.
Hipótese da causa raiz: Fluxos de trabalho fragmentados e informação inacessível geram retrabalho manual repetido.
Nesse ponto, simplesmente adicionar uma interface conversacional pode melhorar a experiência do cliente sem resolver a restrição de processamento subjacente. A questão de engenharia, portanto, deixa de ser "How do we add AI?" e passa a ser "Which intervention changes the causal mechanism producing the undesirable outcome?" — essa distinção é central para Research & Discovery.
Observação: A verificação manual de documentos está associada a um gargalo significativo no processamento.
Hipótese: Um fluxo de trabalho de inteligência documental controlado pode reduzir a revisão manual mantendo os controles de verificação necessários.
Evidências necessárias: Documentos representativos · Taxas de erro existentes · Padrões de exceção · Requisitos de revisão · Tempos de processamento
Avaliação: Qualidade da extração · Taxa de exceções · Taxa de revisão humana · Tempo de processamento · Modos de falha
Decisão: Apoiar · Modificar · Rejeitar a hipótese
O objetivo não é provar que uma tecnologia proposta funciona. O objetivo é determinar se as evidências justificam sua utilização.
Defina o sucesso antes da implementação
Se o sucesso for definido apenas após a implementação, quase qualquer resultado pode ser interpretado como sucesso. Por isso, a OpenQCore estabelece linhas de base e critérios de avaliação relevantes já na fase de descoberta.
Tempo de Ciclo
Quanto tempo demora o processo?
Custo por Operação
Quais recursos cada transação consome?
Taxa de erro
Com que frequência o processo gera um resultado incorreto?
Taxa de processamento
Quanto trabalho o sistema consegue processar?
Esforço humano
Quanta intervenção manual é necessária?
Confiabilidade
Com que consistência o sistema funciona?
Qualidade das decisões
Com que precisão ou consistência as decisões são tomadas?
Taxa de automação
Quais operações podem ser concluídas sem intervenção manual?
Exposição ao risco
Que riscos operacionais, de segurança ou de conformidade existem?
Métricas de experiência
Como o processo afeta clientes, colaboradores ou outros usuários?
A estrutura é simples: Linha de base → Intervenção → Meta → Medição → Avaliação.
Se a mudança desejada não puder ser descrita, não é possível avaliar de forma significativa o sucesso da solução.
A IA exige análise contextual de riscos
Em iniciativas envolvendo IA, a fase de discovery também avalia se o uso proposto de IA é adequado ao contexto em que será aplicado. O AI Risk Management Framework do NIST organiza as atividades de gestão de risco em torno de quatro funções e descreve a gestão de risco como um processo contínuo ao longo do ciclo de vida da IA, e não como um exercício pontual de conformidade.
O framework também aponta características associadas a uma IA confiável, incluindo validade e confiabilidade; segurança, proteção e resiliência; responsabilização e transparência; explicabilidade e interpretabilidade; proteção da privacidade; e gestão de vieses prejudiciais.
Uso pretendido
Modos potenciais de falha
Supervisão humana
Sensibilidade dos Dados
Consequências da Decisão
Segurança
Confiabilidade
Requisitos de Avaliação
Controles Operacionais
Requisitos de Governança
Isso não significa que todos os projetos exijam a mesma arquitetura de governança. Os controles de risco devem ser proporcionais ao sistema, ao seu contexto e às consequências de uma falha.
Evidências Antes da Recomendação
Procuramos a intervenção respaldada pelas evidências. Pesquisas recentes reforçam a importância de redesenhar o trabalho em vez de simplesmente sobrepor IA aos processos existentes.
~2/3
das organizações ainda não haviam começado a escalar o uso de IA em toda a empresa.
McKinsey, The State of AI: Global Survey 2025.
39%
relataram impacto no EBIT relacionado à IA em nível empresarial.
McKinsey, The State of AI: Global Survey 2025.
A mesma pesquisa aponta o redesenho de fluxos de trabalho como característica central das organizações que obtêm mais valor com IA — uma das razões pelas quais a OpenQCore investiga o modelo operacional em torno da tecnologia, em vez de tratar a implantação como objetivo em si.
A OpenQCore não inicia a fase de discovery com uma solução técnica já definida. As evidências podem apontar que a intervenção adequada é o redesenho de processos, integração de sistemas, engenharia de software convencional, arquitetura de dados, automação de fluxos de trabalho, analytics, inteligência artificial ou uma combinação dessas. Em alguns casos, as evidências podem indicar que não há justificativa para desenvolver nova tecnologia.
A OpenQCore não recomenda inteligência artificial por modismo. Recomendamos seu uso quando o problema, as evidências, a viabilidade econômica e as restrições operacionais o justificarem — e deixamos claro quando não o fazem.
Problema → Evidência → Requisitos → Restrições → Intervenções Candidatas → Avaliação → Abordagem Mais Adequada — não: IA → Encontrar algum lugar para usá-la.
A escolha da tecnologia vem após a investigação.
Pressupostos são identificados, não apresentados como fatos.
Conclusões importantes devem estar vinculadas às evidências que as sustentam.
Quando houver incerteza, devem ser consideradas explicações concorrentes.
Critérios de sucesso são definidos, quando possível, antes da implementação.
Aspectos desconhecidos e limitações permanecem visíveis.
O nível de análise deve refletir o custo, a complexidade e o risco da decisão.
Resultados da descoberta
Pesquisa e descoberta não têm por objetivo terminar apenas com uma apresentação cheia de observações. Devem gerar artefatos que possam orientar uma decisão de engenharia. Conforme o escopo do trabalho, esses artefatos podem incluir:
Contexto do problema, evidências, observações e principais achados.
Quem é afetado, quem toma as decisões e quais resultados importam.
Como o trabalho e a informação circulam atualmente na organização.
Aplicações, interfaces, fontes de dados, dependências e restrições técnicas.
Explicações fundamentadas em evidências para a condição observada.
Desempenho atual segundo indicadores operacionais ou técnicos relevantes.
Requisitos funcionais, técnicos, operacionais e de governança identificados durante a descoberta.
Viabilidade técnica, de dados, de integração e operacional, quando aplicável.
Intervenções potenciais priorizadas conforme evidências, valor, viabilidade e risco.
Limitações conhecidas, premissas, dependências e riscos materiais.
Metas, métricas e abordagem de avaliação.
O ponto de decisão da descoberta
O objetivo da descoberta não é garantir que um projeto avance, mas sim determinar se ele deve avançar. Assim, um engajamento de discovery pode concluir com um dos seguintes desfechos:
O problema está suficientemente definido, as evidências justificam a intervenção e existe um caminho de engenharia viável.
Persistem incertezas relevantes e são necessárias mais evidências.
O problema original ou a intervenção proposta não correspondem ao que a investigação revelou.
O objetivo continua válido, mas uma intervenção técnica ou operacional diferente é mais adequada.
O valor esperado, a viabilidade ou o risco não justificam a implementação.
Não construir o sistema errado pode ser tão valioso quanto construir o certo.
Da Pesquisa para a Arquitetura
Pesquisa e descoberta não existem separadas do ciclo de vida de engenharia. Seus resultados tornam-se entradas para a etapa seguinte: Evidência → Definição de problema validada → Requisitos → Restrições e riscos → Critérios de sucesso → Estratégia e Arquitetura.
A arquitetura não deve começar como uma coleção de tecnologias preferidas. Deve emergir de uma compreensão defensável do que o sistema precisa realizar, dentro de quais restrições, para quais partes interessadas, com que nível aceitável de risco e em relação a quais resultados mensuráveis.
Etapa 02
Converter um problema validado em uma orientação técnica para o sistema.
Você não precisa chegar com uma estratégia de IA. Traga o desafio operacional, a restrição técnica, a questão de pesquisa ou o objetivo de negócio. Começamos por determinar o que realmente está acontecendo — e o que as evidências indicam que deve acontecer a seguir.
Referências de pesquisa e metodologia
Referenciamos essas fontes diretamente em vez de ocultá-las, porque nossa metodologia se baseia em princípios consagrados da investigação científica, engenharia de sistemas, engenharia de requisitos, análise de negócios e gestão de riscos.
Boston Consulting Group — Onde está o valor na IA? (2024)
Com base em uma pesquisa com 1.000 CxOs e executivos seniores em mais de 20 setores e 59 países; é a fonte das proporções 74% / 26% e do princípio 10–20–70 mencionados acima.
McKinsey & Company — O Estado da IA: Pesquisa Global 2025
Fonte dos dados sobre escalabilidade e impacto no EBIT em nível empresarial, e do achado sobre a importância do redesenho de fluxos de trabalho entre organizações de melhor desempenho.
ISO/IEC/IEEE 15288:2023 — Engenharia de Sistemas e Software — Processos do Ciclo de Vida do Sistema
A principal referência de engenharia para abordar sistemas — seus elementos, ciclo de vida e partes interessadas — de forma estruturada.
ISO/IEC/IEEE 29148:2018 — Engenharia de Requisitos
Define processos e itens de informação para a engenharia de requisitos ao longo dos ciclos de vida de sistemas e software; a ISO confirmou esta edição como vigente após a revisão de 2024.
NIST — Estrutura de Gestão de Riscos de Inteligência Artificial (AI RMF 1.0)
Apoia o raciocínio sobre riscos de IA no contexto por meio de Govern, Map, Measure e Manage, com gestão contínua de riscos ao longo do ciclo de vida da IA. A AI RMF 1.0 do NIST está em revisão ativa — por isso indicamos a versão explicitamente em vez de dar a entender que seja sempre a última versão final.
