No chat você escolhe um papel para cada pedido. Um papel é ao mesmo tempo uma metodologia completa e uma fronteira de acesso: os papéis só de leitura recebem fisicamente apenas as ferramentas de leitura do SAP e não conseguem alterar nada. Todos os papéis de Support e Consulting são só de leitura; apenas os papéis de Development escrevem, e apenas num sistema de nível de desenvolvimento. Um administrador pode redefinir qualquer papel ou adicionar o seu próprio.
Implementa um requisito de ponta a ponta: compreender → explorar o estado atual → reutilizar o que existe → planear → lock + set source → syntax check + testes/ATC → ativar → relatório.
Uma alteração terminada e ativada segundo a sua abordagem, não um rascunho de código.
Entrega um desenho da solução, não escreve código.
Um plano ponderado antes de alguém tocar no sistema.
Revê contra as suas normas; resultados ordenados por prioridade (Critical / Major / Minor) com localizações e correções exatas.
Uma segunda passagem independente — sem o risco de o revisor «acidentalmente» reescrever algo.
Escreve/expande testes ABAP Unit; nunca altera a lógica de produção para «forçar» um teste a ficar verde.
Cobertura de testes sem distorcer a lógica de negócio.
Executa o ABAP Test Cockpit, devolve os resultados ordenados por prioridade; corrige apenas se você pedir explicitamente.
Qualidade ao nível da norma ATC, sob o seu controlo.
Executa o ATC e corrige as conclusões de forma metódica, categoria a categoria, preservando o comportamento.
Conclusões fechadas sem alterar o que o código faz.
Investiga e responde com provas, pode executar consultas SQL sobre os dados.
Respostas rápidas e fundamentadas sobre o sistema — sem risco para ele.
Transforma a especificação em bruto de um cliente no formato interno padronizado do Makion, cruzando com o sistema em produção.
Um requisito caótico torna-se uma especificação ordenada e testável.
Dimensiona um desenvolvimento a partir da sua especificação: cada objeto classificado S / M / L com um intervalo de horas, além dos pressupostos e das incógnitas por trás do número. Entrega um documento de estimativa.
Um número de esforço defensável antes de se comprometer, em vez de uma intuição.
Concebe e constrói modelos de dados CDS ao estilo VDM da SAP: entidades de vista de interface e de consumo, associações, anotações e controlo de acesso (DCL), criados e ativados no seu sistema.
Um modelo de dados limpo e em camadas sobre o qual assentam os seus relatórios e aplicações, em vez de um SELECT avulso.
Constrói objetos de negócio RESTful ABAP (RAP) de ponta a ponta: modelo CDS, definição de comportamento e classe de comportamento, projeção e vínculo de serviço OData — ativados e prontos a consumir.
Um serviço transacional real no seu sistema, não um diagrama dele.
Prepara um serviço para Fiori Elements: as anotações @UI e as extensões de metadados que alimentam um List Report / Object Page, além do vínculo de serviço OData — depois entrega honestamente o deploy do app-shell da UI ao seu tooling.
Os seus dados a um passo de uma aplicação Fiori — com toda a camada de anotações já feita para si.
Pega num objeto próprio, encontra o que quebra no S/4HANA (APIs obsoletas, acesso direto a tabelas, sintaxe antiga) e propõe uma correção mínima para cada um; você aprova, aplica e ativa, e para mudanças arriscadas escreve primeiro um teste de fixação.
ABAP próprio pronto para S/4HANA / Clean-Core, objeto a objeto — no seu próprio ECC.
A metade de análise da migração: lê o seu código próprio e o seu uso para mapear o esforço de S/4HANA — o que é usado, o que quebra, o que corrigir primeiro. Nunca se liga à produção.
Uma imagem de migração priorizada antes de alguém mudar uma linha.
Lê um SAP Adobe Form existente e aplica uma alteração estrutural (adicionar / remover / reordenar / religar uma coluna), devolvendo um XDP pronto a colar para o separador «XML Source» do SFP; a geometria e as ligações de dados são garantidas por um motor determinístico.
Edite Adobe Forms descrevendo a alteração, em vez de o fazer à mão no LiveCycle.
Audita a conformidade com o clean core: APIs libertadas, ausência de leituras de tabelas standard, extensibilidade. Só de leitura.
Um veredicto de clean core por objeto antes de escrever o plano de migração.
Faz a triagem de um incidente entre dumps ST22, jobs SM37, logs SLG1, atualizações SM13, IDocs e tRFC — e devolve causas-raiz ordenadas com uma única ação seguinte tipada.
De «está avariado» a uma causa ordenada e um passo seguinte — só de leitura.
Uma varredura matinal do sistema: IDocs bloqueados, jobs falhados, backlog de tRFC/qRFC e dumps recentes — o retrato de saúde antes de os utilizadores o reportarem.
Problemas encontrados antes de chegar o primeiro ticket.
Uma análise aprofundada das falhas de IDoc: registos de estado, dados de controlo e segmentos (EDIDC / EDIDS / EDID4), para explicar porque um falhou e o que fazer. O reprocessamento continua a ser uma entrega.
A verdadeira razão pela qual um IDoc falhou, não apenas um número de estado.
Análise do estado atual num formato fixo: conclusão → evidência → impacto → recomendação → esforço / risco. Lê o sistema e o código, não altera nada.
Um retrato honesto da situação atual, sustentado por evidências.
Deriva do código as autorizações que um programa realmente precisa, compara-as com as que estão concedidas e assinala lacunas e concessões excessivas.
Raciocínio de menor privilégio fundamentado no código real.
Inventaria o panorama de integração (RFC, ALE, IDoc, OData) a partir da configuração e do código (estático, não em tempo de execução), para que nada escape numa migração ou auditoria.
Um mapa de interfaces completo, lido a partir do próprio sistema.
Reúne um entregável de projeto (conclusões, roadmap e um veredicto GO / NO-GO) a partir do trabalho feito nos restantes papéis de consultoria.
Um relatório pronto para o cliente, não um monte de notas.
Os papéis só de leitura não conseguem escrever ao nível das ferramentas, e não apenas ao nível do prompt. Um administrador pode substituir a metodologia de qualquer papel ou acrescentar novos. Cada papel pertence a um produto, e todos os papéis fora do Development são só de leitura ao nível das ferramentas. A mesma IA governada, o mesmo canal ADT oficial, as mesmas garantias de só leitura, embalados como três produtos — e os três incluídos numa única licença.
O seu SAP, as suas normas, os seus termos.
Vários programadores ou uma implementação num cliente? Equipas e empresas