Entenda como processos ponta a ponta reduzem perdas em handoffs entre Engenharia, Suprimentos, Qualidade, fornecedores e operação, com ownership, métricas e critérios de interface.
Confira!
Processos ponta a ponta em Engenharia são fluxos gerenciados pelo resultado completo, desde o evento que inicia uma demanda até a entrega aceita pelo cliente interno ou externo, mesmo quando o trabalho atravessa diferentes departamentos, disciplinas, empresas e sistemas. A abordagem procura eliminar uma falha recorrente em organizações técnicas: cada área otimiza sua própria etapa, mas ninguém responde pelo desempenho do fluxo completo.
Em Engenharia, esse problema aparece em processos como desenvolvimento e revisão de projetos, gestão de mudanças, procurement técnico, controle documental, tratamento de RFIs, inspeções, não conformidades, medições, comissionamento e handover. A demanda passa por vários responsáveis e, em cada transição, pode perder informação, prioridade, contexto ou critérios de aceite. O resultado são filas invisíveis, retrabalho, decisões repetidas, documentos devolvidos e prazos maiores do que a soma dos tempos efetivos de execução.
A gestão ponta a ponta não elimina as áreas funcionais nem cria uma organização paralela. Ela estabelece uma visão transversal para que objetivos, fronteiras, interfaces, responsabilidades, indicadores e decisões sejam geridos como um sistema único. Na prática, o foco deixa de ser “minha etapa foi concluída” e passa a ser “o resultado esperado foi produzido com qualidade, rastreabilidade e prazo adequados”.
O que é um processo ponta a ponta?
Um processo ponta a ponta, também chamado de end-to-end ou E2E, é um processo transversal que conecta todas as etapas necessárias para alcançar um resultado específico. Seu início e término são definidos por eventos de negócio ou de gestão, e não pelas fronteiras do organograma.
A abordagem de processos da ISO 9001 trata os processos como componentes inter-relacionados de um sistema. Essa visão é especialmente relevante para Engenharia porque muitas entregas dependem de interações entre funções com objetivos locais distintos. Um desenho técnico pode depender de requisitos da operação, dados de campo, premissas de planejamento, informações de fornecedores, controles de qualidade e aprovações contratuais antes de ser considerado utilizável.
A APQC também caracteriza processos end-to-end como fluxos cross-functional orientados a um objetivo comum. O ponto central não é o nome do método, mas a mudança de unidade de gestão: o objeto passa a ser o resultado integral.
Um processo ponta a ponta precisa responder, no mínimo, a cinco perguntas:
- qual evento inicia o fluxo;
- qual resultado encerra o processo;
- quem recebe esse resultado e quais requisitos precisa atender;
- quais funções, disciplinas, fornecedores ou sistemas participam do caminho;
- quem responde pelo desempenho do processo completo.
Quando essas respostas não são claras, a organização tende a gerenciar departamentos e atividades, mas não o fluxo que realmente gera valor.
Por que a visão funcional não é suficiente para processos de Engenharia?
Estruturas funcionais são necessárias. Engenharia Elétrica precisa desenvolver competências próprias; Suprimentos precisa dominar sourcing, contratação e logística; Qualidade precisa manter critérios de inspeção e evidência; Document Control precisa assegurar emissão, revisão e distribuição controlada. O problema começa quando a eficiência de cada função é confundida com eficiência do processo completo.
Uma área pode cumprir seu SLA e ainda contribuir para um lead time excessivo. A Engenharia pode liberar um documento rapidamente, mas com premissas incompletas que gerarão devolução em Procurement. Suprimentos pode emitir uma consulta dentro do prazo, mas sem esclarecer dúvidas técnicas que atrasarão a equalização. Qualidade pode concluir uma inspeção pontualmente, mas a documentação necessária ao aceite pode continuar incompleta.
Esses exemplos mostram um fenômeno comum: otimização local com degradação sistêmica.
A visão ponta a ponta procura enxergar o que acontece entre as áreas. A maior parte das perdas de tempo em processos administrativos e técnicos não está necessariamente na execução da tarefa principal, mas em espera, fila, reentrada de informação, validação duplicada, priorização conflitante e tratamento de exceções.
Por isso, o processo precisa ser observado desde a demanda até o resultado final. A arquitetura de processos de Engenharia ajuda a identificar quais fluxos merecem essa visão transversal e onde as interfaces críticas estão concentradas.
Handoffs: onde os processos mais perdem informação e tempo
Handoff é a transferência de trabalho, informação ou responsabilidade entre duas pessoas, funções, disciplinas, empresas ou sistemas. Em processos de Engenharia, os handoffs são inevitáveis. O problema não é a existência da transferência, mas a ausência de critérios claros para que ela ocorra sem perda.
Uma transição Engenharia → Procurement, por exemplo, deveria definir qual pacote mínimo permite iniciar uma contratação. Se a especificação técnica está incompleta, se os quantitativos ainda são provisórios ou se critérios de equivalência não foram definidos, o handoff acontece formalmente, mas o processo seguinte recebe uma entrada incapaz de produzir uma saída confiável.
O mesmo ocorre em transições como:
- Operação → Engenharia, na formalização de uma necessidade;
- disciplina → coordenação multidisciplinar, na consolidação de interfaces;
- Engenharia → Document Control, na emissão controlada;
- Engenharia → fornecedor, na liberação de requisitos;
- fornecedor → inspeção, na apresentação de documentação e produto;
- obra → comissionamento, na transferência de sistemas completos;
- comissionamento → operação, na entrega de ativos e evidências;
- contratada → fiscalização, em medições, inspeções e solicitações de aceite.
Cada handoff deveria possuir critérios mínimos de entrada e saída. Isso pode incluir documentos obrigatórios, revisão válida, aprovação necessária, dados estruturados, responsáveis, prazo, classificação de criticidade e evidência de recebimento.
Quando esses critérios não existem, a etapa seguinte precisa descobrir o que falta. A fila deixa de ser apenas uma fila de trabalho e passa a conter itens com diferentes níveis de completude, aumentando variação e retrabalho.
A gestão de interfaces em projetos de Engenharia trata das interfaces técnicas dentro do projeto. No processo ponta a ponta, o foco é mais amplo: como a organização preserva informação, responsabilidade e critérios ao longo de um fluxo recorrente.
Quando o atraso nasce entre áreas, cobrar produtividade local raramente resolve. O diagnóstico precisa medir handoffs, espera, qualidade das entradas e responsabilidade pelo fluxo completo.
Conheça o Diagnóstico e Otimização de Processos de Engenharia
O custo oculto das filas entre áreas
Quando uma atividade termina em uma área e aguarda a próxima, o trabalho continua consumindo prazo mesmo sem consumir esforço. Esse tempo de espera costuma ser pouco visível porque cada departamento mede principalmente o tempo em que o item está sob sua responsabilidade direta.
Imagine um documento que leva quatro horas para ser preparado, duas horas para ser verificado e uma hora para ser aprovado. O tempo efetivo de processamento é de sete horas. Porém, se houver três dias de espera entre preparação e verificação e mais dois dias antes da aprovação, o lead time do processo pode superar uma semana.
O gestor que observa apenas horas trabalhadas conclui que o processo é rápido. O cliente do processo percebe exatamente o contrário.
Em Engenharia, as filas podem surgir por motivos diferentes:
- prioridades não alinhadas entre áreas;
- excesso de trabalho em andamento;
- recursos especializados compartilhados por muitos projetos;
- lotes grandes de documentos encaminhados de uma vez;
- aprovações concentradas em poucos gestores;
- entradas incompletas que aguardam complementação;
- ausência de prazo para análise de exceções;
- retrabalho que retorna para etapas anteriores;
- dependência de fornecedor ou terceiro sem SLA definido.
A visão ponta a ponta torna essas esperas mensuráveis. Isso é essencial porque muitas iniciativas de melhoria fracassam ao tentar reduzir apenas o tempo de execução de uma atividade que representa pequena parcela do lead time total.
Como mapear um processo ponta a ponta sem transformá-lo em um fluxograma gigante
O mapeamento deve começar pelo resultado, não pelas tarefas. Antes de desenhar qualquer fluxo, a equipe precisa estabelecer qual problema será analisado, qual evento dispara o processo, qual saída encerra o ciclo e quais requisitos definem sucesso.
O mapeamento AS-IS e TO-BE continua sendo a técnica central para compreender o estado atual e desenhar o estado futuro. A diferença é que, em um processo ponta a ponta, a fronteira precisa atravessar todas as funções necessárias para produzir o resultado.
Uma sequência prática é:
- definir resultado, cliente e fronteiras;
- identificar participantes e sistemas;
- levantar o fluxo real, incluindo exceções;
- registrar handoffs e critérios de passagem;
- medir tempos de processamento e espera;
- identificar devoluções, retrabalho e reentrada;
- localizar decisões e alçadas;
- avaliar riscos nas interfaces;
- definir indicadores ponta a ponta;
- desenhar o TO-BE e o modelo de governança.
O desenho não precisa detalhar todas as microatividades. O nível adequado é aquele que permite compreender onde o trabalho muda de estado, quem assume responsabilidade, qual informação é necessária e por que o item pode parar ou retornar.
O diagrama serve para mostrar o princípio: o processo não termina quando uma área conclui sua parte. Ele termina quando o resultado definido é aceito.
Como definir fronteiras corretas para o processo
Uma fronteira mal definida cria métricas enganosas. Se o processo de “revisão de documentos” começa quando o revisor recebe o arquivo e termina quando devolve comentários, ele pode parecer eficiente mesmo que o documento tenha passado dias aguardando triagem antes da revisão e volte repetidamente por problemas de entrada.
A fronteira deveria refletir a necessidade do cliente do processo. Em alguns casos, o processo começa no registro da demanda e termina na emissão aprovada. Em outros, pode incluir a distribuição controlada ou o aceite formal.
Critérios úteis para definir fronteiras incluem:
- evento que representa uma necessidade real;
- resultado que tem utilidade independente;
- cliente ou parte interessada claramente identificável;
- owner capaz de responder pelo desempenho;
- possibilidade de medir prazo e qualidade;
- interfaces relevantes para o resultado.
A fronteira não precisa coincidir com contrato, departamento, sistema ou fase de projeto. Ela deve coincidir com o resultado que precisa ser gerenciado.
Process owner e responsabilidade pelo fluxo completo
Um processo ponta a ponta precisa de alguém que responda por sua integridade e desempenho. Esse papel é normalmente chamado de process owner. Ele não executa todas as atividades nem substitui gestores funcionais, mas mantém a visão transversal e coordena decisões que afetam o processo completo.
O artigo sobre Governança de Processos de Engenharia aprofunda esse papel, as alçadas e a relação entre owner e gestores funcionais.
No contexto ponta a ponta, o owner precisa acompanhar pelo menos quatro dimensões:
- resultado: a saída atende ao requisito do cliente do processo;
- fluxo: o trabalho atravessa as etapas sem espera excessiva e retornos evitáveis;
- interfaces: entradas e saídas entre funções possuem qualidade e critérios claros;
- melhoria: problemas recorrentes geram mudanças no processo, não apenas cobranças individuais.
Sem ownership, problemas entre áreas tendem a ficar sem dono. Cada gestor pode explicar por que sua equipe cumpriu o procedimento e, ainda assim, o processo completo continuar lento ou instável.
Critérios de entrada e saída: o contrato operacional entre etapas
Uma forma eficaz de reduzir perdas nos handoffs é explicitar critérios de entrada e saída. Esses critérios funcionam como um contrato operacional entre etapas.
Para uma atividade de análise técnica, por exemplo, a entrada pode exigir:
- documento na revisão correta;
- requisitos de referência identificados;
- comentários anteriores tratados;
- anexos obrigatórios disponíveis;
- responsável e prazo definidos;
- classificação de criticidade registrada.
A saída pode exigir:
- decisão registrada;
- comentários classificados;
- pendências identificadas;
- aprovação ou rejeição formal;
- próxima ação atribuída;
- evidência preservada.
O objetivo não é criar burocracia adicional. É impedir que a etapa seguinte descubra repetidamente que recebeu algo que ainda não estava pronto para avançar.
Em ambientes com elevado volume documental, esse princípio pode ser aplicado a GRDs, submittals, RFIs, RNCs, vendor documents, relatórios de inspeção, datasheets e pacotes de comissionamento.
Rework loops: quando o processo parece avançar, mas volta para trás
Retrabalho em processos de conhecimento muitas vezes não aparece como sucata física. Ele surge na forma de documento devolvido, análise refeita, reunião repetida, decisão reaberta ou informação digitada novamente.
Esses loops precisam ser tratados como parte do processo real. Um mapa que mostra apenas o caminho ideal esconde justamente o que mais consome prazo.
Os retornos podem ser classificados por causa:
- entrada incompleta;
- requisito ambíguo;
- falha de coordenação;
- erro técnico;
- mudança legítima de escopo;
- decisão não documentada;
- critério de aceite divergente;
- versão incorreta;
- fornecedor sem informação suficiente;
- aprovação sem autoridade adequada.
Essa classificação ajuda a separar retrabalho evitável de mudança necessária. Nem todo retorno é desperdício. Uma revisão técnica pode legitimamente identificar um risco novo. O problema é quando a mesma categoria de falha se repete e o processo não aprende.
Processos ponta a ponta em Procurement de Engenharia
Procurement é um dos exemplos mais claros de fluxo transversal. A contratação de um equipamento ou serviço técnico pode envolver Engenharia, Planejamento, Suprimentos, Jurídico, Contratos, Qualidade, fornecedor e gestão do projeto.
Se cada área trabalhar isoladamente, problemas típicos incluem:
- especificação liberada sem maturidade suficiente;
- RFQ emitida sem critérios de equalização;
- propostas tecnicamente incomparáveis;
- dúvidas respondidas fora do fluxo oficial;
- mudanças após contratação sem controle de impacto;
- inspeções sem PIT/ITP adequado;
- documentação de fornecedor incompleta no recebimento;
- aceite comercial antes do aceite técnico.
O artigo de Procurement em Projetos de Engenharia detalha as etapas da contratação. A visão ponta a ponta complementa essa abordagem ao observar como as interfaces entre as funções afetam o resultado final.
Processos ponta a ponta em gestão documental
Gestão documental também não deve ser tratada apenas como atividade de protocolo. O valor está em assegurar que informação correta, aprovada e rastreável esteja disponível para quem precisa decidir, projetar, comprar, executar, inspecionar ou operar.
Um processo documental ponta a ponta pode começar na necessidade de produzir ou revisar uma informação e terminar quando a versão válida foi emitida, distribuída e incorporada ao contexto de uso.
Isso muda o foco de métricas como “quantidade de documentos processados” para questões mais relevantes:
- qual o lead time da revisão até a emissão;
- quantos documentos retornam por problemas de entrada;
- quantas revisões ficam aguardando decisão;
- qual percentual é aprovado na primeira passagem;
- quantas vezes uma informação obsoleta foi utilizada;
- onde estão os maiores handoffs e filas.
Processos ponta a ponta em qualidade e não conformidades
O tratamento de uma não conformidade também atravessa funções. Identificar a RNC é apenas o início. Um fluxo completo pode incluir registro, contenção, análise de causa, disposição, ação corretiva, verificação de eficácia e encerramento.
Se a área de Qualidade medir apenas tempo de registro ou quantidade de RNCs encerradas, pode perder a visão do problema real: quanto tempo a organização leva para eliminar a causa e impedir recorrência.
Esse princípio conecta o subcluster de processos ao cluster de QA/QC. A gestão da qualidade fornece controles e critérios; a gestão de processos organiza como as decisões e ações percorrem a organização.
Processos ponta a ponta e PMO
Um PMO pode ser um importante patrocinador da visão transversal, especialmente em processos que se repetem em vários projetos. Gestão de mudanças, riscos, documentos, status reporting, aprovações, lições aprendidas e encerramento podem possuir padrões corporativos comuns.
O PMO, porém, não deve necessariamente se tornar owner de todos os processos. Sua função pode ser definir governança, manter padrões, consolidar indicadores e facilitar melhorias, enquanto owners de negócio continuam responsáveis pelos fluxos.
Isso evita transformar o escritório de projetos em um concentrador de aprovações. A boa governança distribui autoridade com critérios claros.
Como medir um processo ponta a ponta
O indicador principal deve refletir o resultado do processo completo. Métricas locais continuam úteis, mas precisam explicar o desempenho sistêmico, não substituí-lo.
Indicadores frequentes incluem:
- lead time total;
- tempo efetivo de processamento;
- tempo de espera entre etapas;
- taxa de retrabalho;
- first pass yield;
- aging dos itens em andamento;
- percentual dentro do SLA;
- taxa de exceções;
- throughput;
- quantidade de handoffs;
- percentual de entradas rejeitadas;
- cumprimento de requisitos de saída.
Uma relação especialmente útil é comparar tempo de processamento com lead time. Quando o processamento representa pequena parcela do prazo total, o maior potencial de melhoria tende a estar em filas, prioridades, transferências e decisões.
O artigo de Indicadores de Processos de Engenharia aprofundará essa camada sem competir com métricas ágeis ou EVM, que possuem objetos de medição diferentes.
O que muda quando o processo é digitalizado
Workflow pode reduzir perda de informação, tornar alçadas executáveis, gerar notificações e preservar trilha de auditoria. Entretanto, tecnologia não corrige uma fronteira mal definida nem decide quais aprovações realmente agregam valor.
Automatizar antes de compreender o processo pode cristalizar:
- etapas redundantes;
- handoffs desnecessários;
- critérios inconsistentes;
- campos que ninguém utiliza;
- aprovação centralizada sem necessidade;
- exceções tratadas fora do sistema;
- métricas de volume sem visão do resultado.
Por isso, a Gestão de Processos, Workflows e Aprovações Técnicas deve entrar depois que o processo foi compreendido e governado. O sistema materializa regras; não substitui o trabalho de definir regras adequadas.
Workflow deve executar um processo já compreendido. Automatizar antes de revisar fronteiras, alçadas e critérios de entrada pode apenas digitalizar filas e retrabalho.
Como redesenhar o processo TO-BE
O desenho futuro deve atacar causas, não apenas reorganizar caixas no fluxograma. Cada mudança precisa responder qual problema elimina, qual risco reduz ou qual resultado melhora.
Um TO-BE pode combinar ações como:
- eliminar uma aprovação que não altera decisões;
- definir critério mínimo de entrada para reduzir devoluções;
- redistribuir alçadas para remover filas executivas;
- reduzir tamanho de lotes de documentos;
- limitar trabalho em andamento;
- criar priorização por criticidade e prazo;
- padronizar dados necessários no handoff;
- integrar sistemas ou eliminar redigitação;
- definir owner e indicadores ponta a ponta;
- automatizar somente etapas já estabilizadas.
É importante testar o desenho com casos reais e exceções. Um processo que funciona apenas para o caso padrão pode deslocar toda a complexidade para canais informais.
Quando o problema é processo e quando é capacidade?
Nem todo atraso se resolve redesenhando o fluxo. Se a demanda supera estruturalmente a capacidade de um recurso especializado, haverá fila mesmo com um processo bem desenhado.
O diagnóstico precisa distinguir pelo menos quatro situações:
| Situação | Sintoma | Resposta provável |
| Processo mal desenhado | retornos, duplicidade, decisões confusas | redesenho e padronização |
| Capacidade insuficiente | fila persistente em recurso crítico | redistribuição, capacidade ou priorização |
| Entrada instável | grande variação de qualidade e completude | critérios de entrada e prevenção |
| Governança fraca | escalonamentos e decisões sem owner | alçadas, ownership e fóruns |
Essa distinção evita uma solução simplista. Adicionar pessoas a um processo com alto retrabalho pode apenas aumentar o volume de retrabalho. Automatizar uma fila causada por aprovação centralizada pode fazê-la chegar mais rapidamente ao mesmo gargalo.
Sinais de que a organização precisa de visão ponta a ponta
Alguns sinais aparecem repetidamente em empresas de Engenharia:
- cada área afirma que cumpriu o prazo, mas a entrega final continua atrasada;
- documentos ou solicitações passam por muitas devoluções;
- ninguém sabe onde um item está parado;
- diferentes projetos executam o mesmo processo de formas incompatíveis;
- decisões precisam ser refeitas porque o contexto se perdeu na transferência;
- fornecedores recebem informações diferentes de áreas distintas;
- indicadores departamentais estão verdes, mas o cliente reclama de prazo ou qualidade;
- reuniões são usadas para reconstruir status que deveria estar no processo;
- exceções são tratadas por mensagens e planilhas paralelas;
- a mesma falha reaparece em vários projetos.
Esses sintomas indicam que o problema pode estar nas interfaces e na gestão do fluxo, não apenas na competência de uma equipe específica.
Como funciona um diagnóstico de processos ponta a ponta
Um diagnóstico consultivo deve começar pelos sintomas e pelas evidências. Entrevistas são importantes, mas precisam ser confrontadas com documentos, registros, tempos, volumes, filas, devoluções e exemplos reais.
O trabalho pode incluir:
- definição do processo e de suas fronteiras;
- mapeamento AS-IS;
- análise de documentos e sistemas;
- levantamento de handoffs;
- medição de tempos de processamento e espera;
- análise de retrabalho e exceções;
- identificação de gargalos e riscos;
- revisão de ownership e alçadas;
- definição de indicadores;
- desenho TO-BE;
- priorização de ações e roadmap.
O serviço de Diagnóstico e Otimização de Processos de Engenharia foi estruturado para esse tipo de problema: quando o desempenho depende da interação entre áreas e o simples ajuste de uma etapa isolada não é suficiente.
Processos ponta a ponta ganham valor quando o problema atravessa funções e se repete em diferentes projetos. Nesses casos, a Engenharia Consultiva pode separar sintomas locais de causas sistêmicas e estruturar um roadmap de melhoria mensurável.
Considerações finais
Processos ponta a ponta tornam visível o que estruturas funcionais tendem a fragmentar. Em Engenharia, isso significa acompanhar a demanda através de disciplinas, áreas, fornecedores, sistemas, aprovações e controles até que o resultado seja efetivamente aceito.
A principal mudança é gerencial: o fluxo passa a ter fronteira, owner, critérios de entrada e saída, indicadores e mecanismos de melhoria próprios. Handoffs deixam de ser apenas transferências administrativas e passam a ser tratados como pontos críticos de qualidade e continuidade da informação.
Quando a organização mede apenas atividades locais, pode melhorar produtividade e ainda piorar o lead time total. Quando mede e governa o processo completo, consegue distinguir execução, espera, capacidade, retrabalho e decisão — e direcionar a melhoria para onde ela realmente produz resultado.
Referências técnicas
[1] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO). The process approach in ISO 9001:2015. Geneva: ISO, 2015. Disponível em: https://www.iso.org/files/live/sites/isoorg/files/archive/pdf/en/iso9001_2015_process_approach.pdf
[2] APQC. End-to-End Processes. Houston: APQC. Disponível em: https://www.apqc.org/expertise/end-to-end-processes
[3] APQC. Applying Governance and Roles to End-to-End Processes. Houston: APQC, 2023. Disponível em: https://www.apqc.org/resource-library/resource-listing/applying-governance-and-roles-end-end-processes
Perguntas frequentes
É um fluxo transversal gerenciado desde o evento que inicia uma demanda até o resultado final aceito, mesmo quando atravessa diferentes departamentos, disciplinas, fornecedores e sistemas.
O processo departamental observa atividades dentro de uma função. O processo ponta a ponta acompanha o resultado completo através das fronteiras funcionais e mede as interfaces, esperas e retornos entre as etapas.
É a transferência de trabalho, informação ou responsabilidade entre pessoas, áreas, disciplinas, empresas ou sistemas. Handoffs mal definidos são fontes frequentes de perda de contexto, espera e retrabalho.
Não. O process owner responde pela integridade e desempenho do processo completo e articula decisões entre funções dentro de um mandato definido, sem necessariamente possuir autoridade hierárquica sobre todos os participantes.
Comparando o tempo efetivo de processamento com o lead time total e medindo períodos de espera entre etapas. Quando o tempo de execução é pequeno diante do prazo completo, a maior oportunidade costuma estar em filas, handoffs, prioridades ou decisões.
Quando atrasos, retrabalho, perda de informação e conflitos se repetem entre áreas ou projetos e as melhorias locais não resolvem o desempenho do fluxo completo.
Materiais técnicos complementares
Conteúdos principais sobre o tema
- Gestão de Processos e BPM: o que é, etapas e aplicação na Engenharia
- Arquitetura de Processos de Engenharia: cadeia de valor, macroprocessos e interfaces
- Governança de Processos de Engenharia: process owner, alçadas e responsabilização
Conteúdos técnicos correlatos
- Mapeamento de processos: como fazer AS-IS e TO-BE em empresas de engenharia
- Gestão de Interfaces em Projetos de Engenharia
- Procurement em Projetos de Engenharia
