Aderência

A adoção de melhores práticas sugeridas por diversos modelos encontra-se ainda com baixos níveis de maturidade, logo, há o sentimento de que se deve considerar o que já foi feito. No entanto, não há como garantir que a introdução da terceirização não gere dificuldades, ou adaptações, em diversos outros processos organizacionais da empresa.

Os modelos de terceirização praticados pelo mercado influenciaram o processo de terceirização do BANCO, em como fazer e por que fazer.

8.4.2 Fornecedores

O uso de mais de um fornecedor justifica-se pela necessidade de comparação da qualidade do serviço prestado. Entendeu-se que um único fornecedor, sem “concorrentes”, o deixaria em uma posição muito tranqüila e seria repetir erros de contratações anteriores. Porém, há o sentimento de que o uso de muitos fornecedores impõe maior dificuldade controle e esforço. Assim, mais de um, até um número possível para o BANCO avaliar os serviços com métricas em produtividade, gastos, tempo de resposta, entre outros, é o ideal para o modelo.

Os serviços a serem entregues aos fornecedores têm de ser previamente conhecidos/definidos, ou seja, o lote de sistemas tem de estar estabelecido. Não há possibilidade legal de contratar alguns fornecedores e, depois, fazer a distribuição de cotas de trabalho pelo histórico da qualidade dos serviços apresentados. Se houvesse essa possibilidade poderia haver questionamentos sobre essa preferência. Porém, para manutenções evolutivas e adaptativas pode-se optar por não fazê-las.

8.4.3 Indicadores

As métricas que utilizam horas possibilitam a contratação no modelo body shop, que não é recomendado para empresas públicas. Quando se contrata por serviço entregue, paga-se pelo resultado, sendo que a medida é a do tamanho da tarefa, e isso pode ser feito por PF. Entende-se que horas de trabalho não medem funcionalidades do sistema. Porém, para estabelecimento do preço da contratação de manutenção de software pode-se recorrer a uma série histórica da quantidade de horas que o BANCO vinha gastando.

Para aceite dos serviços são necessários alguns indicadores, principalmente no que diz respeito ao desempenho do sistema. Por exemplo, os programas têm de obedecer a medidas de desempenho do BANCO, senão, não se pode aceitar a entrega.

Com relação a multas, as medições e indicadores podem ser por um evento específico, como o atraso na entrega de um serviço, ou um percentual da quantidade de entregas no prazo de um período.

8.4.4 Legislação

O BANCO foi “obrigado” a mudar seu modelo de contratação de body shop para contratação de serviços devido à legislação, logo, o modelo adotado atualmente é o permitido por lei.

Há a percepção de que a lei é inflexível quanto à sazonalidade de necessidades próprias da área de TI. Assim, é difícil tratar esta questão como uma empresa privada, que pode contratar e finalizar o contrato com mais agilidade.

8.4.5 Objeto

A maior dificuldade na definição do objeto, sistemas a serem sustentados, foi evitar o problema da contagem do tamanho por PF. O problema existe devido a alguns sistemas, se contados por funcionalidades, serem muito grandes; e se aplicado um percentual a ser pago, tornaria muito cara a manutenção, inviabilizando o negócio/licitação. Dado este problema, optou-se por precificar o custo da manutenção baseado na série histórica de quantidade de

horas gastas pelo BANCO nesta atividade. Logo, paga-se o preço de mercado das horas gastas atualmente, deixando o problema da sazonalidade a ser resolvido quando da sua ocorrência. O levantamento da quantidade de horas gastas necessita que se tenha essas informações disponível, ou há um grande esforço para que se obtenha.

A escolha dos sistemas teve como principais critérios: o sistema não poderia estar ligado à atividade principal da empresa (core), sistemas que liberariam mais profissionais para outras atividades; o sistema não poderia impactar o atendimento ao cliente, não poderia colocar para terceiros informações que pudessem trazer vantagens competitivas para o BANCO; sistemas que pudessem ser considerados commodities pelo mercado, como gestão de pessoas e logística, e alguns sistemas que pudessem estar relacionados com as outras áreas que mais demonstravam dificuldade para entender os custos da manutenção.

A terceirização de fases do processo de manutenção não foi adotado devido ao sentimento de falta de maturidade para esse tipo de ação. Por exemplo, seria difícil lidar com dois fornecedores, um culpando o outro, pelo erro em um artefato. O BANCO ainda não tem como fazer isso; a atual organização interna das equipes de manutenção não tem essa experiência ou processo.

8.4.6 Pessoas

Consultores criaram processos para o desenvolvimento de sistemas e opinaram quanto à parte de manutenção de software. Decidiu-se que haveria um departamento, o escritório de terceirização, para fazer o relacionamento entre equipes internas do BANCO e o gerente do contrato do fornecedor.

Os funcionários e contratados que realizavam o trabalho de manutenção de software dos sistemas que iram ser terceirizados não foram ouvidos e tinha-se a percepção de que seriam muito “reativos” à idéia devido às experiências anteriores. Porém, obteve-se subsídios em entrevistas com pessoas de outras organizações que trabalham com o modelo.

As empresas públicas têm muita dificuldade para movimentar o pessoal para novas atividades, assim, terceiriza-se determinados sistemas, mas não se consegue com facilidade o aproveitamento da mão-de-obra em outros sistemas. Nas empresas privadas pode-se entregar essa mão-de-obra ao terceirizado ou, até mesmo, demiti-la.

8.4.7 Processo

Buscou-se a escolha de empresas com certificações adequadas para a área de TI, como CMMI e ITIL, e que possuíssem fábrica de testes; assim, há expectativa de que isso agregue qualidade aos processos internos do BANCO.

Procurou-se contratar os serviços considerando a maneira como se desejava que a manutenção de software fosse feita internamente. A demora de dois anos para que as empresas fossem escolhidas deu tempo ao BANCO para estar melhor nesse processo do que quando se iniciou o processo de contratação.

Para a manutenção evolutiva e adaptativa houve o aproveitamento dos processos definidos para o desenvolvimento de sistemas e, em princípio, os mesmos não foram adaptados à realidade de sistemas existentes, ou às especificidades da manutenção.

Há a percepção de que as experiências anteriores de manutenção corretiva terceirizada não foram bem-sucedidas devido à falta de documentação dos sistemas entregues. Essa constatação desencadeou a ação efetiva de exigir que, em até 180 dias, a empresa produza ou complemente a quantidade mínima de artefatos documentais dos sistemas sob sua responsabilidade.

8.4.8 Riscos

Considerou-se o risco do pagamento por algo que não foi feito ou feito com má qualidade. Essa preocupação estabeleceu um rigor maior ao processo de aceite e de aplicação de multas e penalidades previstas em contrato.

Há o entendimento de que o conhecimento dos requisitos e da definição do sistema são suficientes para se manter no BANCO os conhecimentos necessários. Assim, proibiu-se a terceirização da fase de levantamento de requisitos e definição do sistema, que deverá ser executada por funcionário nas manutenções adaptativas e evolutivas. Porém, devido à falta de formalismo nos processos internos de relacionamento com fornecedores pode haver deterioração deste relacionamento.

Quanto ao risco da terceirização falhar devido ao BANCO não cumprir com sua parte no contrato, não foram relatadas ações de mitigação. Essa confiança deve-se à crença que as experiências anteriores foram suficientes para minimizá-los, principalmente porque a

maturação do modelo adotado levou de quatro a cinco anos. Porém, há o sentimento de que o risco do fornecedor é maior, mas que se pode mitigar com ações desenvolvidas pelo BANCO.

Há o entendimento de que o custo para a manutenção terceirizada é maior, o modelo de sustentação é mais caro que o modelo de body shop, porém, o BANCO não considerou se era mais caro que o insourcing por ainda não ter um processo para levantamento de todos os custos envolvidos. Mesmo que o modelo sustentação seja mais caro, é um padrão de mercado, sendo assim, acredita-se ser menos questionado por órgãos controladores internos e externos.

A escolha dos sistemas a terceirizar levou em conta processos críticos da organização, assim, somente sistemas que não influenciavam nestes processos foram escolhidos.

8.4.9 Tempo

Um dos departamentos de controle interno do BANCO estabeleceu o prazo em que deveria estar concluída a nova contratação devido ao término do contrato em vigor. A expectativa do BANCO era concluí-la em seis meses, durou dois anos. A grande quantidade de recursos e questionamentos à licitação forçou a renovação do contrato em vigor por duas vezes. Parte da quantidade de questionamentos aconteceu devido à falta de detalhamento do que o BANCO queria, ou como iria funcionar a prestação dos serviços. Muitos recursos eram infundados e percebeu-se que havia uma briga entre os concorrentes a fornecedor, na qual um queria “atrapalhar” as chances do outro. Há o sentimento, ou aprendizado, de que as próximas licitações devam começar dois anos antes para que não forcem a renovação dos contratos em vigor.

Os prazos para conclusão de tarefas dos serviços contratados baseou-se em atividades de desenvolvimento de software, como também na crença de que o prazo fornecido para a entrega é questão de credibilidade. Assim, muitos dos indicadores e multas a aplicar referem- se a questões de prazo de atendimento e entrega.

Os prazos de contratos podem ser de poucos meses a 60 meses, no máximo. A regra interna da organização é de seja, no mínimo, de 1 ano. Porém, optou-se pelo mínimo de 24 meses porque entende-se que as fases de transição e a transferência de conhecimento consumiriam muito tempo e, assim, diminuir as possibilidades das vantagens que se quer obter.

Quanto ao prazo de realização dos serviços no modo outsourcing em comparação com os insourcing, há a percepção de que aqueles prestados envolvendo outsourcing será maior.

Isso deve-se à criação de novas tarefas entre as atividades iniciais e finais do processo de manutenção para atender aos controles e atividades necessárias no relacionamento com terceiros. No entanto, para atividades de manutenções evolutivas, espera-se ter prazos menores daqueles semelhantes no desenvolvimento de sistemas terceirizados devido às etapas ficarem menos fragmentadas com menos intervenientes.