Na primeira parte da série, discutimos como podemos tornar-nos dependentes de forma prejudicial do nosso fornecedor e, acima de tudo, que problemas isso pode causar à nossa empresa.
Hoje, vamos ver o que podemos fazer para evitar essa dependência.
1. Manter a propriedade do know-how relativo aos processos e sistemas, bem como dos planos para o seu desenvolvimento
Se decidir que não quer preocupar-se about e der instruções genéricas ao seu fornecedor de TI, estará a caminhar a passos largos para a dependência. O que talvez o surpreenda é que esta abordagem muitas vezes causa problemas ao próprio fornecedor; porque, passado algum tempo, os requisitos do cliente começam a sobrepor-se e a tornar-se confusos, e satisfazer novos requisitos torna-se um grande problema para o fornecedor.
Para uma empresa que pretende manter-se competitiva, é importante encarar as TI como uma ferramenta para apoiar, melhorar e avaliar os seus processos. Não é difícil perceber como o fazer, pois hoje em dia dispomos de metodologias e normas suficientes que nos permitem manter uma visão global dos processos e realizar um planeamento eficaz:
- Arquitetura Empresarial – uma forma de descrever os objetivos de uma organização; as formas como esses objetivos são alcançados através de processos de negócio; e como esses processos podem ser apoiados pela tecnologia. Para mais informações, consulte o artigo «Não se deixe atrapalhar» por uma arquitetura empresarial deficiente. As duas abordagens mais conhecidas à arquitetura empresarial podem ser encontradas nos sites do The Open Group e de Zachmann.
- Descrição de processos – as normas mais conhecidas e amplamente utilizadas são criadas pelo Open Management Group (www.omg.org). A descrição de processos de acordo com a especificação BPMN (Business Process Model and Notation) permite que a direção da empresa leia e registe facilmente os processos que ocorrem na sua empresa.
- Documentação do utilizador – não tem de ser um documento redigido pelo fornecedor e guardado numa gaveta a ganhar pó. Uma boa abordagem consiste em gravar vídeos que mostrem aos utilizadores como utilizar a aplicação no seu trabalho diário; simplificando assim o suporte ao produto e a formação para novos utilizadores. Os vídeos têm frequentemente apenas alguns minutos de duração e descrevem tudo o que é necessário saber para utilizar o sistema de forma eficaz. Por exemplo, veja o guia de utilização do Yammer num projeto de investigação; ou o guia sobre como encomendar produtos numa loja online.
Todas as normas e metodologias são acompanhadas por documentação exaustiva e materiais de estudo que descrevem cada área em pormenor. Pela minha experiência, vale a pena contratar um especialista que selecione os aspetos da metodologia adequados a uma empresa específica.
Se sistematizar o seu know-how, não só terá uma ferramenta para debater temas que conduzem à melhoria da empresa, como também terá a certeza de que encontrará pontos em comum com a grande maioria dos seus fornecedores atuais e potenciais.
Se pretender alterar algo nos seus processos e no fluxo de informação, comece por introduzir mudanças na organização do trabalho, seja ao nível do modelo ou através de um projeto-piloto – verifique se a mudança trará os benefícios esperados. Em seguida, calcule os benefícios da mudança e os custos da sua implementação. Se tudo estiver como deveria estar, comece a modificar os sistemas; caso contrário, pode interromper a ação sem quaisquer problemas. Quando se confia isto totalmente a um fornecedor externo, poucas pessoas têm a coragem de interromper um projeto no qual já investimos recursos.
2. Os dados devem ser seus em todas as circunstâncias
Os dados estão armazenados junto do nosso fornecedor; agora, tivemos um desentendimento com eles e eles informaram-nos de que os dados lhes pertencem... Infelizmente, esta situação não é tão invulgar como se possa pensar. Não acontece com frequência com fornecedores de serviços na nuvem e de alojamento, como muitas vezes se pensa, mas sim, na maioria das vezes, com sistemas desenvolvidos à medida, onde os dados são armazenados numa «caixa preta» totalmente controlada pelo fornecedor.
Esta é uma forma tradicional de manter o cliente sob o controlo do fornecedor. O problema pode, geralmente, ser resolvido de duas maneiras: controlando diretamente os dados ou garantindo uma forma fiável de os obter num formato utilizável.
Por exemplo: um serviço de gestão de contactos de e-mail que obtemos ao registar-nos no site do nosso fornecedor. A primeira abordagem consiste em garantir que os dados são replicados nos nossos próprios sistemas; e a segunda consiste em descarregar regularmente as informações armazenadas nos sistemas do fornecedor e guardá-las connosco, «por precaução».
Mesmo no nosso próprio sistema, onde o armazenamento de dados está bem documentado, a metodologia de exportação de dados para uma tabela padrão, uma base de dados ou XML pode facilitar significativamente a integração de um novo sistema. É importante estabelecer procedimentos para a extração de dados, verificar se a exportação está a funcionar e se o formato está bem documentado, porque o momento crítico em que precisamos de recuperar os dados é exatamente o pior momento para descobrir que a exportação não está a funcionar ou que os dados perfeitamente exportados estão codificados num formato com o qual não podemos trabalhar.
Os requisitos acima referidos devem ser verificados sempre que se aceitem novas funcionalidades ou alterações aos sistemas por parte do fornecedor.
3. Manter os direitos de propriedade intelectual sobre as aplicações
A propriedade das aplicações consiste na propriedade do código-fonte ou do design da aplicação. Se não tivermos controlo sobre o código-fonte, corremos o risco de, quando quisermos mudar de fornecedor, descobrir que o fornecedor atual detém uma parte crítica do código e não estará disposto a disponibilizá-la gratuitamente. Podemos evitar isto definindo claramente a propriedade no contrato, indicando que o código desenvolvido em resultado das alterações solicitadas é de nossa propriedade exclusiva, ou que essas alterações são criadas ao abrigo de uma licença que nos permite utilizá-las e distribuí-las gratuitamente.
Mesmo que tenhamos garantido a propriedade por contrato, isso não significa que o fornecedor com quem estamos about rescindir o contrato nos conceda acesso ao código. Por esse motivo, é altamente recomendável que o sistema de controlo de código-fonte, o wiki e outros documentos sejam armazenados por um terceiro e que o parceiro seja obrigado a guardar os dados num local específico e num momento específico, para que tenhamos acesso às versões atuais.
4. Integração do sistema em vez de expansão das funcionalidades
As APIs (Interfaces de Programação de Aplicações) de serviços web são hoje uma característica comum em muitas aplicações comerciais e de código aberto. Isto significa que todas as funcionalidades ou funções disponíveis para os utilizadores das aplicações também estão disponíveis para utilização entre diferentes sistemas e aplicações.
Ao utilizar protocolos e normas para definir esta interface, estes serviços constituem um meio de comunicação e uma plataforma unificados; uma aplicação escrita numa determinada linguagem ou num determinado sistema operativo torna-se acessível a sistemas escritos de forma completamente diferente. Os dados são transferidos num formato comum, como XML ou JSON, e as bases de código de ambos os sistemas permanecem totalmente independent.
Hoje em dia, qualquer utilizador consegue imaginar como funciona a integração de sistemas. Afinal, todos nós utilizamos serviços de aplicações web que estão integrados entre si – por exemplo, o Google Calendar com o Google Contacts e o Gmail. Se decidirmos começar a utilizar um calendário diferente em vez do existente, basta ligá-lo aos dados já existentes. Este método de mudança de sistemas não é possível se tivermos o nosso próprio sistema, que inicialmente adquirimos apenas para contabilidade e, gradualmente, pedimos ao fornecedor para desenvolver um módulo de CRM, um módulo de serviços, etc.
A mesma lógica aplica-se à integração com sistemas fornecidos como serviço por prestadores de serviços na nuvem (SaaS – Software as a Service). A utilização de serviços web separa as aplicações individuais umas das outras, tornando todo o sistema mais flexível e transparent. Pelo contrário, ligações fixas entre diferentes módulos facilitam ao fornecedor aumentar a nossa dependência em relação a ele, aumentam a complexidade do código e a flexibilidade do sistema fica limitada à parte menos flexível.
5. Tente minimizar as alterações ao sistema padrão
Tente implementar o sistema necessário com o mínimo de alterações à implementação padrão. Normalmente, não é o primeiro cliente do fornecedor. Tente tirar o máximo partido da experiência do fornecedor com outros clientes durante a implementação. Provavelmente ficará surpreendido com a eficiência com que alguns processos podem ser implementados ou com o facto de certos dados que anteriormente ignorávamos se tornarem uma vantagem competitiva.
Se for necessário introduzir alterações significativas na funcionalidade da aplicação, isso poderá complicar significativamente a transição para novas versões no futuro; e qualquer transição será um desafio em termos de desenvolvimento e implementação.
6. Recorra a vários fornecedores
Tente gerir você mesmo todo o processo de conceção, desenvolvimento, implementação e operação do sistema, e não deixe isso a cargo do fornecedor. É aconselhável separar os analistas de negócios dos programadores, por exemplo. É aconselhável que o sistema seja testado por testadores que não façam parte da equipa de desenvolvimento. Eles realizarão o trabalho de forma mais eficiente e a probabilidade de obter um produto sem falhas é muito maior. Se outra entidade for responsável pela operação (por exemplo, um fornecedor de serviços na nuvem), certifique-se de que esta pressionará os programadores a entregar um produto que minimize os problemas de operação do sistema.
7. Especificar no contrato o processo de rescisão, incluindo as penalizações aplicáveis ao fornecedor
Como é que a rescisão da cooperação está prevista no contrato? Com um pré-aviso de três meses; após o qual deixam de pagar e o fornecedor deixa de prestar assistência? Isso é lamentavelmente insuficiente.
É necessário especificar que documentação e com que qualidade o fornecedor deve fornecer-lhe — ou diretamente ao novo fornecedor — durante o período de pré-aviso. Se tiver garantido os direitos de propriedade intelectual sobre o design, o código-fonte e outras partes da documentação mencionadas no ponto 3, tanto melhor. Ao celebrar um contrato com um fornecedor, é aconselhável verificar junto das empresas que ficaram em 2.º e 3.º lugar o que estas necessitarão caso venham a assumir o desenvolvimento e a manutenção do vencedor.
8. Informar os fornecedores sobre os planos de desenvolvimento futuros
Trabalhe no sentido de estabelecer uma parceria de longo prazo com os seus fornecedores. Se discutir regularmente com eles os seus planos de desenvolvimento e questões estratégicas — e não apenas as alterações atuais na funcionalidade —, o fornecedor poderá apresentar propostas que criem uma arquitetura de sistema estável, eficiente e económica, não só para as suas necessidades atuais, mas também para as futuras. Para clarificar os seus requisitos, pode utilizar, por exemplo, o método MuSCoW, que divide os requisitos nas seguintes categorias:
- Imprescindível – imprescindível
- Devia ter – devia ter
- Poderia ter – seria bom ter
- Não vai acontecer desta vez – não é necessário que aconteça neste momento
9. Recolher ideias e opiniões de outras partes
Não fique estagnado; acompanhe as tendências; procure as melhores abordagens e práticas; e mantenha-se atento a tudo. Contrate uma empresa para obter uma opinião independente – eles avaliarão as suas decisões tanto de uma perspetiva técnica como estratégica. Não tem de ser caro. E essa consultoria vale a pena, pois irá ajudá-lo a evitar erros. Pela minha experiência, conheço um caso em que um fornecedor obrigou um cliente a investir vários milhões de coroas na resolução de um problema que ele próprio tinha causado; e um consultor descobriu que o investimento não resolveria de todo o problema, porque a origem do problema estava noutro lugar.
Um consultor pode ajudá-lo a definir a sua estratégia, a criar procura, a avaliar opções e a analisar as coisas sob um ângulo inesperado. Também pode ajudá-lo a avaliar os seus fornecedores e a garantir o melhor resultado possível para si. Um consultor deve ter sempre em mente que pretende ser independent um determinado fornecedor e que reconhece o valor do seu know-how como uma vantagem competitiva.
A escolha certa dos fornecedores tem about a gestão about
Acredito que, depois de ler este artigo, terá uma ideia mais clara de como transformar os seus fornecedores em parceiros do seu sucesso, em vez de se tornar seu vassalo. Evitar situações desagradáveis passa about uma gestão de riscos about e about escolha de soluções que equilibrem as necessidades atuais com a flexibilidade futura. Ao seguir os princípios acima referidos, garantirá a escolha certa de fornecedores e de novos sistemas.
