Sap drc release date

O risco que já vi é tratar o release como data de calendário, quando ele depende de quando a SAP libera o pacote. Olhando o log, tá, os erros de migração apareceram justamente nas customizações do DRC que o time achava estáveis. Discordo, com educação, da ideia de priorizar só pela criticidade, porque a estabilidade percebida engana. Eu iria por evidência: rodar os testes de regressão e medir o que quebra antes de decidir.

Concordo em parte, Nádia: a ligação com outro módulo pesa, e a matriz da Luciana precisa incluir isso. Veja, a ideia é que o release do DRC pode mexer em pontos que o time nem imagina, então a checagem tem de passar pela cadeia inteira. Discordo só de tratar isso como exceção, porque na indústria química pedido de venda e custo costumam estar conectados de qualquer forma. Vale mapear essa cadeia antes de fixar a prioridade.

Será que a matriz da Luciana cobre o caso de migração? Bem, puxando o fio, Luciana, você separou as customizações por criticidade, mas como fica o item que depende de outro módulo? No meu caso de alimentos, o problema apareceu no pedido de venda e não no DRC em si, então quero entender se você checou essa ligação antes de fixar a prioridade.

O resultado que importa é ter um cenário de contingência com o release alvo mapeado antes de qualquer decisão. Elaine, você tem razão em desconfiar de uma data só, e acrescento um ponto: bem, no meu time a gente guarda o histórico de comunicados do fornecedor, com o dia em que cada aviso chegou, e isso ajuda a cobrar a janela certa. Esse histórico vira prova na hora de renegociar o cronograma com a diretoria.

Quando o release ainda não tem janela oficial, eu usaria uma matriz de risco em vez de cronograma fixo. Veja, se não me engano, a gente separa as customizações do SAP DRC por criticidade e decide quais testes entram primeiro. Vale quando o projeto tem muitas customizações e pouca margem. Para projetos menores, um plano simples com duas datas candidatas resolve, desde que a diretoria aceite revisar o plano quando o release sair.

Não concordo com isso. Por experiência, viu, a janela do release não segue o calendário do cliente, então esperar a confirmação pode deixar o SAP DRC sem tempo para testes. Quando migramos de outro ERP, a diretoria aceitou um cronograma provisório e depois pagou caro. Prefiro montar dois cenários, com a versão alvo e a versão atual, para não depender de uma data só. A dúvida de vocês é legítima, mas o plano não pode parar à espera de papel.

O risco que já vi foi um cronograma fechado em cima de uma data que depois mudou, e o time teve de refazer tudo. Bem, o combinado é que a gente não fala em data antes da confirmação escrita. Na nossa equipe, adotamos outro caminho: montamos um painel com as versões do SAP DRC instaladas e marcamos o release alvo como provisório até a comunicação oficial chegar. Vale para projetos pequenos, quando dá para ajustar rápido. Em projetos grandes, prefiro esperar a janela oficial.

Concordo em parte, Marcelo: a janela do release é o ponto que trava o cronograma, e a resposta curta é que a data sozinha não serve para decidir. Discordo, porém, de começar pela planilha de dependências, porque ela mostra o que você já tem e não o que a SAP vai liberar no DRC. Na última auditoria, viu, a gente olhou primeiro a nota de release e o calendário de manutenção do sistema, e só depois montou o mapa do que muda. No seu caso, eu pediria ao fornecedor a janela oficial por escrito antes de qualquer data entrar no plano da diretoria.