Objeto (o que terceirizar?)

Significado

A condicionante Objeto será o objeto do contrato de terceirização. No processo decisório proposto por Drucker (2006), pode ser resultante da “Classificação do problema” e da “Definição do problema”. Para a manutenção de software, podem ser a categoria de manutenção, partes do processo de manutenção ou ambas. Para a terceirização e o e-SCM- CL, podem ser as oportunidades e propostas de terceirização, porém, para se chegar a esta condicionante, todas as práticas da fase de análise e relacionadas tiveram de ser executadas, em especial a “opa03 – Identificação da demanda” e “opa04 – Opções de terceirização”.

Relação com o processo decisório

Para o processo decisório da terceirização da MS, o objeto é, em parte, sua razão de ser. Porém, pode, ou não, ser o problema que se queira resolver. O objeto é o problema quando, entre outras, há falta de conhecimento, ou competências, na organização para fazer a correção dos erros, adaptar o sistema a um novo ambiente, incluir uma nova regra de negócio solicitada pelo usuário, como também fazer as alterações citadas com a qualidade desejada.

O objeto não é o problema quando o que motiva a terceirização é a falta de pessoal para outras tarefas (desenvolvimento), incapacidade gerencial e administrativa em lidar com a MS, gastos da TI além do orçamento, entre outros. Anseia-se buscar com o objeto soluções para problemas fora do escopo do objeto. Assim, por exemplo, no caso de falta de pessoal para o desenvolvimento de novos sistemas, talvez a solução fosse aumentar a quantidade de profissionais para aquela tarefa, ou melhorar seus processos e produtividade.

Também há a possibilidade da MS ser terceirizada como conseqüência da terceirização do desenvolvimento de software. Contratos de desenvolvimento costumam prever um período de garantia dos artefatos entregues que vão muito além do período logo após a entrega. Assim, por exemplo, se o período de garantia se estender por mais 1 ano, é possível que atividades de MS sejam fornecidas para honrar a garantia.

Relação com a terceirização e o eSCM-CL

O objeto é parte obrigatória de um contrato, assim, no contexto de terceirização, é o que se está terceirizando. Como em engenharia de software há o conceito de sistema de informação e de processo e tarefa de MS, há a possibilidade do objeto ser terceirizado para um ou vários fornecedores e com várias combinações. Pode-se ter vários fornecedores fazendo o mesmo trabalho em sistemas diferentes (terceirização por lotes de sistemas) ou um ou mais fornecedores trabalhando em determinado processo ou atividade para todos os sistemas terceirizados (terceirização de processos). No primeiro caso, pode-se entregar a manutenção corretiva para um fornecedor e as outras para outro fornecedor. No segundo caso, pode-se entregar a análise de requisitos para um fornecedor e a implantação, ou somente testes, para outro, por exemplo.

Nas inúmeras combinações possíveis, quando mais atores envolvidos, mas difícil se torna a administração da MS e da terceirização no cliente. Por isso, talvez a escolha, em clientes com pouca ou nenhuma maturidade em terceirização da MS, seja pela redução de atores. Com isso, uma escolha comum é a entrega de um ou mais sistemas (lote) para um mesmo fornecedor executar uma ou mais categorias ou atividades do processo de MS.

Querer terceirizar sistemas não essenciais gera a dificuldade de o cliente possuir o entendimento de quais sejam estes sistemas. Em organizações que possuem muitos sistemas, mais de 500, somente esta escolha pode demorar e gerar muitas discussões.

Relação com a manutenção de software

Em MS pode-se entender que são possíveis quatro categorias e em seus processos são várias as atividades, o objeto deve especificar claramente o que se está contratando para ser fornecido por terceiros. Pode-se contratar todas, algumas ou uma de suas categorias (corretiva, adaptativa, perfectiva e preventiva), pode-se contratar algumas atividades (análise, construção, codificação, testes, documentação, entre outras), também pode-se contratar apenas algumas atividades de alguma categoria. Nos contratos que prevêem dois tipos de pagamento, por exemplo, um para correção de erros e outro para desenvolvimento de novas funcionalidades, há um problema significativo no entendimento do que é um erro e da solução adequada para o mesmo. Esse entendimento pode gerar divergências entre o cliente e o fornecedor.

Pode acontecer que no entendimento do cliente todo erro (parada ou mal funcionamento do sistema) deva ensejar uma modificação de código que evite novas manifestações do erro e, se este erro acontecer novamente, sua correção não deverá ser paga. Por outro lado, o fornecedor entende que correção de erros é colocar o sistema em funcionamento o mais breve possível, efetuando uma alteração que, por exemplo, expurgue os dados que estejam causando o mal funcionamento. Porém, a alteração para que o dado não chegue a ficar corrompido é uma manutenção evolutiva e deve ser paga à parte.

Uma questão importante é que o cliente pode desejar que a quantidade de erros diminua com as ações de manutenção do fornecedor, então, deve-se prever formas de compensação, como também diminuição de valores pagos no decorrer do contrato. Porém, deve-se evitar a armadilha do estabelecimento de pagamentos por erros consertados.

Dependendo da honestidade do fornecedor e dos mecanismos de controle do cliente, ao invés do sistema tornar-se cada vez mais estável (com menos erros), pode tornar-se cada vez mais instável, com erros se multiplicando. Na primeira possibilidade, o fornecedor terá sua receita reduzida e na segunda, o cliente terá seus custos aumentados, além dos problemas decorrentes de sistemas com mau funcionamento.