Declaração de trabalho SAP (SOW): o que ela precisa conter

Uma declaração de trabalho SAP (SOW, statement of work) é o documento contratual que diz o que o parceiro vai entregar, com que esforço, por quem e como isso pode mudar. Ela precisa cobrir escopo, premissas e exclusões detalhadas, esforço por fase e por função, entregáveis com critérios de aceite, recursos nomeados e controle de mudanças.

A maioria dos SOWs cobre o escopo razoavelmente bem. O que os clientes costumam deixar de fora são as premissas e exclusões detalhadas, e é essa seção que define quanto você acaba pagando.

Este artigo faz parte do meu guia sobre como escolher um parceiro de implementação SAP. O SOW é a última etapa desse processo, depois da RFP para parceiro SAP e das apresentações orais. Para um exemplo prático de revisão de um SOW antes da assinatura, leia o meu estudo de caso sobre negociação de contratos de ERP.

Um bom SOW SAP se lê como um manual de operação do programa. Qualquer pessoa do seu lado deve conseguir abri-lo e responder a três perguntas: o que estamos recebendo, do que isso depende e o que acontece quando algo muda.

Estas são as seções de que ele precisa, e o que dá errado quando falta uma delas:

Seção	O que deve dizer	O que acontece se for rasa
Escopo	Processos, módulos, empresas, centros, países e usuários no escopo	Cada workshop reabre a questão do que estava incluído
Premissas	As condições das quais o preço depende, cada uma com uma consequência caso se mostre falsa	O parceiro abre solicitações de mudança que você não consegue contestar
Exclusões	O que o parceiro não vai fazer, e quem faz no lugar dele	O trabalho cai entre você e o parceiro, e ninguém assume
Abordagem e fases	O método, o plano de fases e os quality gates	Não há um ponto acordado em que uma fase está concluída
Esforço	Esforço estimado por fase e por função	Você não consegue saber se o ritmo de consumo está no plano
Entregáveis e aceite	Documentos e produtos nomeados, critérios de aceite, prazo de aprovação	Faturas são pagas por trabalho parcial
Recursos	Pessoas-chave nomeadas, funções, alocação e regras de substituição	A equipe que você conheceu nas apresentações orais não é a equipe que está no projeto
Responsabilidades do cliente	O que as suas pessoas precisam fornecer, e quando	Atrasos causados do seu lado viram solicitações de mudança do parceiro
Controle de mudanças	Como uma mudança é aberta, avaliada, precificada e aprovada	As solicitações de mudança viram uma segunda linha de receita
Governança	Comitê de direção, relatórios, escalonamento	Os problemas aparecem tarde, quando já são caros

Escreva o escopo você mesmo antes de pedir preços, para que os parceiros precifiquem o seu escopo e não o deles.

Esta é a seção que os clientes costumam deixar de fora. Sem ela, o preço se apoia em condições que ninguém do seu lado leu ou aceitou.

Uma premissa é uma condição sobre a qual o parceiro precificou. Uma exclusão é um trabalho que o parceiro não precificou. As duas precisam ser específicas o bastante para que um terceiro consiga verificar se se confirmaram.

Tipos de premissa a registrar

Toda premissa precisa de uma consequência. "Se isto se mostrar falso, a mudança passa pelo controle de mudanças com uma avaliação de impacto" transforma uma premissa de enfeite em controle.

Estas são as categorias que um SOW SAP deve cobrir:

1. Escopo organizacional. O número de empresas, centros, organizações de vendas, países e entidades legais que o preço cobre.
2. Escopo de processos. Os processos de negócio no escopo, nomeados, e os processos padrão SAP que o parceiro espera que você adote.
3. Volume WRICEF. O número de workflows, relatórios, interfaces, conversões, ampliações e formulários, por complexidade. Os orçamentos estouram na fase Explore conforme essa lista cresce, então a contagem de base pertence ao contrato.
4. Dados. Os objetos de dados a migrar, o volume de histórico, o número de cargas simuladas e quem faz o saneamento dos dados.
5. Integrações. Cada interface nomeada, com o sistema do outro lado e quem altera esse sistema.
6. Testes. O número de ciclos de teste, quem escreve os roteiros, quem os executa e quem corrige os defeitos.
7. Disponibilidade do cliente. Quais das suas pessoas são necessárias, com quanto do tempo delas, e com que rapidez as decisões precisam ser tomadas.
8. Ambientes e licenças. Quem fornece sistemas, ferramentas e acessos, e até quando.
9. Local e idioma. Onde a equipe trabalha, a combinação onshore e offshore, as viagens e os idiomas dos documentos e do treinamento.
10. Treinamento e hypercare. O modelo de treinamento, o número de multiplicadores treinados e a duração e os critérios de saída do hypercare.

A linha de base WRICEF é a que mais importa para o orçamento. O próprio material de curso da SAP descreve a fase Explore como uma análise de fit-to-standard, em que os requisitos delta aprovados entram no backlog do produto para a fase Realize (SAP Learning). Cada delta aprovado pode virar novo esforço WRICEF, então você precisa da contagem inicial para medir o crescimento.

Tipos de exclusão a registrar

As exclusões devem dizer quem faz o trabalho no lugar do parceiro. "Excluído" sem dono é uma lacuna esperando para ser descoberta durante o cutover.

Estas são as categorias habituais:

1. Saneamento e enriquecimento de dados nos sistemas legados, muitas vezes uma tarefa do cliente.
2. Alterações em sistemas de terceiros e legados do outro lado de uma interface.
3. Licenças e assinaturas de software, que ficam no seu contrato com a SAP, não no SOW.
4. Infraestrutura e hospedagem, a menos que o parceiro as opere explicitamente.
5. Execução do treinamento dos usuários finais, quando o parceiro só treina os seus multiplicadores.
6. Gestão de mudanças organizacional além do que está listado.
7. Desenho de segurança, perfis e autorizações, se outra parte for responsável por isso.
8. Testes de desempenho, de invasão e de regressão fora dos ciclos nomeados.
9. Países, entidades ou localizações que não estão no escopo organizacional.
10. Suporte à aplicação após o hypercare, que é um contrato separado.

Leia as duas listas lado a lado com o seu diretor de programa. Tudo o que não aparece em nenhuma delas é de onde virá uma solicitação de mudança.

O modelo comercial que recomendo para uma implementação SAP é tempo e materiais, com o esforço quantificado. Isso significa que o esforço estimado por fase e por função está escrito no contrato, para que você possa acompanhar todo mês o esforço real em relação a ele.

O preço fixo parece mais seguro para um conselho. Na prática, o preço só é fixo enquanto todas as premissas se sustentam, e um programa SAP põe a maioria delas à prova até o fim da fase Explore. As minhas notas sobre custo de implementação SAP mostram quando uma fase de preço fixo ainda pode fazer sentido.

É assim que os dois modelos se comparam no SOW:

Ponto de comparação	Preço fixo	Tempo e materiais com esforço quantificado
O que o contrato fixa	O preço, enquanto as premissas se sustentam	As diárias e o esforço estimado por fase e por função
Onde fica o risco	O parceiro o embute no preço como contingência	Com você, mas visível todo mês
Quando o escopo muda	Cada mudança vira uma negociação	O esforço muda, e você o vê em relação à estimativa
O que você consegue acompanhar	Marcos e solicitações de mudança	Esforço real em relação ao plano, por fase e por função
O que protege você	Premissas e exclusões precisas	Premissas e exclusões precisas e relatórios de esforço

O esforço quantificado transforma tempo e materiais de cheque em branco em orçamento controlado. Peça a estimativa como uma tabela de fases por funções, em dias-pessoa, e torne obrigação contratual o relatório mensal com base nessa tabela.

Não deixe as diárias se esconderem no esforço. Compare a combinação de funções com as diárias de mercado usando o meu guia sobre planejamento de alocação de recursos em projetos SAP.

Um plano com muitos dias de profissionais seniores no início e de juniores depois é comum. O contrário precisa de explicação.

Um entregável é um produto nomeado com uma definição de pronto. "Apoio ao desenho" não é um entregável. Um documento de desenho da solução para o processo record to report, assinado e revisado com base em critérios acordados, é.

Vincule o aceite aos quality gates

O SAP Activate tem seis fases: Discover, Prepare, Explore, Realize, Deploy e Run. A SAP descreve quality gates formais depois de cada fase, que verificam se os entregáveis da fase estão completos antes de o projeto avançar (SAP Learning).

Use esses gates no SOW. Liste os entregáveis devidos em cada gate, os critérios de aceite e o número de dias que você tem para revisar. Vincule o pagamento aos entregáveis aceitos, não ao calendário.

Alguém do seu lado precisa ser capaz de julgar esses documentos. Este é um dos três momentos em que recomendo trazer um consultor independente: na contratação, no desenho e na avaliação dos entregáveis do parceiro. O meu artigo sobre parceiro SAP ou consultor independente explica como os dois papéis trabalham juntos.

Nomeie as pessoas e verifique-as

A baixa qualidade dos recursos propostos é uma das duas coisas que me fazem descartar uma proposta. A outra é um parceiro que não consegue explicar a arquitetura e o plano.

O SOW deve nomear o arquiteto de soluções, o gerente do programa e cada líder funcional e técnico. Inclua a alocação deles, o seu direito de entrevistar substitutos e a sua aprovação para cada substituição. O estudo de caso sobre negociação de contratos de ERP mostra a cláusula de recursos nomeados na prática.

Verifique as certificações em vez de acreditar no currículo. A SAP emite selos de certificação pela Credly, que permite verificação em tempo real (SAP Learning). Pelo processo stay certified da SAP, uma certificação expira se o titular não fizer a avaliação obrigatória (SAP Learning).

Esta cláusula importa mais do que parece. Já troquei de parceiro no meio de um programa, e o gatilho foi que o parceiro não conseguia fornecer recursos de qualidade. O meu guia sobre como trocar um parceiro SAP no meio do projeto mostra o que garantir antes de chegar a esse ponto.

O controle de mudanças é onde um SOW raso fica caro. Se as premissas forem vagas, quase tudo pode ser apresentado como mudança.

Uma seção de controle de mudanças que funcione precisa destes elementos:

1. Um gatilho. Uma mudança só existe quando uma premissa falha, uma exclusão entra no escopo ou você pede algo novo.
2. Uma avaliação de impacto. Escopo, esforço por função, cronograma e custo, por escrito, antes de o trabalho começar.
3. Uma tabela de valores. As mudanças são precificadas pelas diárias do contrato, sem adicional por urgência, salvo acordo.
4. Um nível de aprovação. Quem do seu lado pode aprovar mudanças até qual valor, com o CFO acima de um limite definido.
5. Um registro. Cada mudança, aprovada ou rejeitada, reportada ao comitê de direção com o total acumulado.
6. Um vínculo com a linha de base. Novos objetos WRICEF são medidos em relação à contagem das premissas.

O parceiro vai abrir mudanças legítimas. Os programas SAP descobrem coisas que ninguém sabia na assinatura do contrato. O objetivo é que cada mudança seja visível, precificada e aprovada antes que alguém gaste o dinheiro.

Nos 21 programas SAP que liderei ou resgatei, o maior erro que vejo é não planejar direito no início. O SOW é onde esse planejamento se torna vinculante, e o tempo investido nele é barato perto de solicitações de mudança contestadas.

O próximo passo concreto: pegue o SOW que você tem em mãos e liste cada premissa e exclusão em uma única página. Ao lado de cada uma, escreva o que acontece se ela se mostrar errada e quem paga. Se você não conseguir preencher essa coluna, o SOW não está pronto para ser assinado.

Se você quiser uma leitura independente de uma declaração de trabalho SAP antes da assinatura, eu ajudo clientes com isso durante a contratação. Você pode falar comigo aqui.

O que uma declaração de trabalho SAP deve incluir?

Escopo, premissas detalhadas, exclusões, abordagem e fases, esforço estimado por fase e por função, entregáveis com critérios de aceite, recursos nomeados, responsabilidades do cliente, controle de mudanças e governança. A parte que mais fica rasa são as premissas e exclusões, e é ela que define o custo final.

Qual é a diferença entre premissas e exclusões em um SOW SAP?

Uma premissa é uma condição sobre a qual o parceiro precificou, como o número de empresas ou de objetos WRICEF. Uma exclusão é um trabalho que o parceiro não precificou, como o saneamento de dados legados. Cada premissa deve dizer o que acontece se ela se mostrar falsa, e cada exclusão deve dizer quem faz o trabalho no lugar do parceiro.

Preço fixo ou tempo e materiais: o que é melhor para uma implementação SAP?

Recomendo tempo e materiais com o esforço quantificado: o esforço estimado por fase e por função escrito no contrato e acompanhado todo mês. Um preço fixo só se sustenta enquanto todas as premissas se sustentam, e um programa SAP põe a maioria delas à prova durante a fase Explore.

Como definir critérios de aceite para entregáveis SAP?

Nomeie cada entregável, descreva como ele é quando está completo e defina um prazo de revisão para a sua equipe. Vincule-os aos quality gates do SAP Activate no fim de cada fase e libere o pagamento só quando o entregável for aceito.

O SOW SAP deve nomear os consultores?

Sim, para as funções-chave: arquiteto de soluções, gerente do programa e os líderes funcionais e técnicos. Inclua a alocação deles, o seu direito de entrevistar substitutos e a sua aprovação para qualquer substituição. Verifique as certificações pelos selos SAP na Credly em vez de confiar no currículo.

Quem deve escrever a declaração de trabalho SAP?

O parceiro faz a minuta, mas o escopo e as premissas devem vir de você. Escreva o seu escopo antes de ir ao mercado e peça a alguém independente do parceiro que revise as premissas, as exclusões e os entregáveis antes da assinatura.