Sap drc launch date

Já vi a equipe trocar o projeto de data pelo projeto de dependência, e o fechamento ficou sem dono. No mês passado, a gente tentou o painel no ECC e ele não cobria os tributos de saída, então sobrou um buraco grande. Por isso sugiro uma reunião só com quem assina a apuração, e não com quem monta o ambiente. Vale quando a equipe de integração já tem o escopo; não vale quando ainda estamos descobrindo o que falta.

Concordo em parte com o que o Sérgio Barbosa colocou sobre o volume. Discordo de um ponto: a planilha não resolve o cadastro sozinha. No print de tela que eu tenho aqui, bem, só um detalhe, o campo de escopo aparece vazio em boa parte dos casos, então a conferência só funciona se o campo estiver preenchido. Sérgio Barbosa, quando você roda a conferência, filtra por esse campo ou confere tudo?

Na minha rotina de e-commerce, o caso concreto é o cadastro de produto que entra e sai todo dia, e a gente não pode parar para esperar o DRC. Então montamos uma conferência semanal com o que já funciona e documentamos o que falta. Quem tem volume alto sabe que, bem, o custo é manter essa conferência viva, e eu acho que compensa quando a equipe é enxuta. Não compensa quando a operação muda de escopo toda semana, porque aí a planilha vira o gargalo.

Nós fizemos diferente aqui. A equipe, então, diga-se de passagem, não esperou o DRC para começar. Montamos um painel com o que já está disponível e chamamos o fornecedor só para validar. Assim o projeto deixa de depender de uma data única. Vale quando a equipe é pequena e o escopo fiscal está fechado; não vale quando a integração depende de dados que ainda não existem. Quando o painel bater com o ambiente de teste, aí sim dá para planejar a virada.

A lista de dependências é o que importa aqui. Ricardo Monteiro tem razão no risco de governança, e, olha, na minha rotina, o que eu acrescento é que essa lista precisa sair antes do cronograma, senão a data não significa nada. Eu peço ao fornecedor duas coisas por escrito: o escopo que entra em cada onda e o que fica de fora. Assim a gente sabe qual parte do fechamento depende do DRC e qual pode seguir com o processo atual. Também fica mais fácil negociar a janela de teste.

Bruno Almeida, eu entendi o recado da data, mas, como vimos, pois é, a diretoria cobra um número. Quando você fala em janela de teste, ela começa depois de qual entrega do fornecedor? Porque eu não tenho como explicar um intervalo aberto para quem pede resposta objetiva.

Concordo em parte: não dá para cravar data só de conversa, e o cronograma precisa vir por escrito. Mas discordo de planejar a virada em cima de um comunicado verbal, porque, olha, na virada do ano nós vimos atraso em mais de um ciclo. Eu trabalharia com uma janela de teste, não com uma data fixa. Enquanto isso, separe a configuração que é só de dados da que depende de código, porque a segunda costuma ser a que trava. Se a equipe de Basis insistir em data, peça que ela confirme por nota oficial.

O risco que eu já vi é o projeto parar esperando um comunicado que nunca chega. Bruno Almeida tem razão na parte da configuração, e eu acrescento que vamos lá separar a equipe de testes da equipe de virada, porque quem testa não deve assumir a data de produção. Em siderurgia a gente teve uma migração travada por isso, e a lição foi colocar o marco de decisão na reunião de governança, e não no calendário do fornecedor. Peça ao fornecedor um documento com o escopo e as condições de entrega.