Como posso comunicar os riscos de alterar o software do fornecedor?

Temos um grande problema em que trabalho, e seu nome é "personalização". Temos um antigo sistema de software de fornecedores (mais de 10 anos) que nossos departamentos de TI e contabilidade adoravam personalizar anteriormente . Em algum momento, esse software começou a ficar muito complicado. Então, fui contratado após a maior parte da personalização.

Quase todos os problemas que encontrei no sistema são resultado direto da personalização; tudo o que mudamos corre o risco de quebrar o software financeiro crítico para os negócios. No entanto, o departamento de contabilidade continua sugerindo mudanças (porque sempre dissemos que sim!) E parece haver pouco respeito pelo impacto das mudanças.

Algumas mudanças não causam problemas; Os formulários podem ser (e devem ser) personalizados no software do fornecedor, podemos mover-se pelos campos do formulário, removê-los, etc. Porém, para toda customização inofensiva como essa, eles também sugerem alterações como procedimentos armazenados e gatilhos para manipular dados no banco de dados do aplicativo do fornecedor.

Recentemente (quase) consegui que eles parassem de tentar importar clientes de um programa de fornecedor para outro, pois as informações eram completamente incompatíveis. Meu problema com a forma como isso foi resolvido é que eu achei que o sistema não funcionava no lado do usuário; a tarefa era mais complicada do que eles pensavam, então desistiram. Independentemente da facilidade da tarefa do lado do usuário, a operação que eles desejavam não deveria ter sido executada.

Como posso comunicar que mudar o modo como esse sistema funciona apresenta riscos, principalmente quando a validade dos dados está em risco? Sou um novo contratado (6 meses) e ele se tornou o status quo, mas está arriscando a validade de nossos dados financeiros e contratos de suporte - uma vez que o suporte do fornecedor ouve "X foi personalizado", o que dá a eles muitos motivos para não para nos apoiar ou nos dizer que a culpa é nossa.

O risco / recompensa dos sistemas de personalização é fornecer uma vantagem competitiva que permita à sua empresa oferecer algo diferente das outras empresas em seu espaço.

As organizações maiores com as quais trabalhei obtêm uma vantagem competitiva da personalização e, nessa mentalidade, as fazem fazer as coisas com mais eficiência, fornecem mais recursos ou ganham mais dinheiro.

O fato de eu me comunicar nessas situações é que é uma troca. Ao fazer essas alterações em um sistema, a organização está desenvolvendo sua própria base de conhecimento / experiência interna de seus sistemas, que eles não serão capazes de fazer facilmente. Essa base de conhecimento interna precisa ser melhor mantida e organizada para que essas mudanças possam ser rastreadas e gerenciadas. Isso também significa que poderia invalidar contratos de suporte ao fornecedor e outros aspectos que os ativos de TI que a empresa usa para esse processo.

O maior risco sobre o qual falo é sobre atualizações de versão para software de fornecedor quando uma empresa adota essa filosofia de gerenciamento de dados. Esse é um dos riscos mais prováveis ​​em que algo vai ocorrer. A empresa precisa entender as compensações que estão sendo feitas e todos precisam estar de acordo com o processo necessário para apoiá-las.

Para sua cultura, você pode introduzir uma analogia ou filosofia, mas precisa de alguém responsável pelos negócios para perceber que eles estão criando um ambiente que possui ainda mais dependências de especialistas em negócios internos que fazem alterações nesses sistemas.

Para a analogia do carro, não é o mecânico que precisa saber quais alterações estão sendo feitas em um carro, é o proprietário que precisa entender que pode levar mecânica especial, mais dinheiro ou perda desse serviço por um período de tempo. Educar o proprietário é a chave para esta conversa.

Comunicando-se aos moradores de escritórios? Eu iria com analogias.

Diga a eles que todas essas mudanças estão transformando seu típico sedã doméstico de 4 portas em um carro estrangeiro exótico. Toda vez que você o traz para a oficina mecânica, desde o ajuste, até a luz esmagada, até a revisão da transmissão, será mais caro. "Não temos as peças, apenas o revendedor com conhecimento especial pode tocar nisso, tentamos, mas o manual está em alemão".

Você é o mecânico encarregado de mantê-lo funcionando. O banco de dados é o mecanismo. Todo o sistema é o carro. Os contadores dirigem o carro. O coelhinho fofo que os contadores perderam é um personagem de trema no sobrenome de um novo cliente. O poste de luz em que eles envolveram o carro é o bug crítico que foi introduzido quando eles queriam adicionar uma bola de discoteca dentro do carro.

Outros forneceram alguns bons exemplos de uso de analogias e outro idioma para responder à sua pergunta principal, que era "Como posso comunicar que mudar o funcionamento desse sistema tem riscos, principalmente quando a validade dos dados está em risco?"

Mas, com base no seu comentário esclarecedor sobre como a atribuição de tarefa chega até você, não tenho certeza de que qualquer analogia o ajude na situação - não parece realmente que as pessoas entendam mal o que estão pedindo, mas ao contrário, eles não se importam. Eu já estive lá - provavelmente todos já estivemos lá - e, nessas situações, costumo fazer um esforço maior para ser perfeitamente claro quanto às questões, em vez de abordá-las em termos que pretendem ensinar e não alertar .

Concentre-se no que você pode fazer, que não está mudando sozinho a opinião de todos que solicitam personalizações que colocam em risco a integridade dos dados e os contratos de suporte a fornecedores, mas sim falando diretamente ao seu CTO (e, por sua vez, ao CFO) e sendo muito claro quanto às questões em questão.

Especificamente:

• Peça ao seu CTO ou CFO (ou quem o detém) para ver o contrato de serviço com o fornecedor, porque (e eu diria essas palavras) você está sendo solicitado a executar tarefas que potencialmente violam o contrato e você deseja seja capaz de apontar isso no seu relatório de viabilidade de tarefas. Eles podem não dar a você, mas dizer essas palavras muitas vezes faz com que as pessoas nessas posições entendam melhor que você está falando sério, e a situação é potencialmente grave.

• Se você fazer obter uma cópia do acordo, então quando você escrever seu relatório de viabilidade de tarefas, citar diretamente do que quando há uma violação clara.

• Se você não receber uma cópia do contrato, deixe suas reservas muito claras sobre como a mudança pode colocar a empresa em uma posição ruim no que diz respeito ao relacionamento com o fornecedor.

• Se sua preocupação não for problemática por causa do contrato do fornecedor, mas for "simplesmente" problemática por causa dos efeitos em cascata da mudança, descreva o que isso significa: se for tão confuso quanto você diz, provavelmente terá apenas um ou dois pontos antes de poder usar a linha "e ela tombará como um castelo de cartas".

Em resumo, faça o que puder para apontar de maneira muito clara e concisa o problema e seus efeitos, mesmo um ou dois passos adiante. É bom que você já tenha a oportunidade de apresentar um relatório de viabilidade aos tomadores de decisão; você não tem a estrutura ou o suporte de gerenciamento (ou ética) para dizer "Eu preciso que você assine isto dizendo que entende que isso é uma coisa ruim e eu não o recomendo e não serei responsável pelos efeitos disso" má decisão "(como se você fosse um fornecedor e ele fosse um cliente), mas ainda é possível colocar muitas coisas no papel que mostram que está considerando o que é do melhor interesse da empresa e de seus ativos.

Se eles estão dizendo para você implementar procedimentos armazenados e gatilhos - você tem um grande problema de processo de negócios.

Seu maior desafio é convencer os usuários a mudarem sua forma de pensar. Eles precisam fornecer o problema ou requisito. Por exemplo, precisamos que os dados sejam movidos daqui para aqui .

Deve ser você quem está implementando a solução com o menor risco / maior ganho, e é você quem pode fazer isso de uma maneira que ajude a evitar futuros problemas de desenvolvimento.

Algum controle na forma de aprovação ou requisitos do usuário e, em seguida, a aprovação do desenvolvimento entregue também ajudará. Se o usuário precisar assumir alguma responsabilidade / responsabilidade pelo que está pedindo, talvez pense um pouco mais sobre isso.

Você parece estar sugerindo que sua escolha é entre uma implementação arriscada de um requisito de negócios ou nenhum. Raramente é preto e branco. É difícil acreditar que os contadores estejam solicitando procedimentos armazenados diretamente, mas, se forem, você precisará fornecer o que eles significam em vez do que eles estão pedindo. Descubra qual é o requisito comercial e descubra a maneira menos arriscada de implementá-lo.

Se o seu fornecedor não estiver fornecendo os ganchos necessários para implementar com segurança os requisitos desejados pelos usuários, esse problema está no fornecedor, não nos usuários.

Você está basicamente desenvolvendo software e, como tal, precisa de uma metodologia de desenvolvimento. Como as alterações são documentadas? Testado? Implantado no controle de qualidade? Implantado na produção? etc. Acho que se você começar a criar uma metodologia e os custos associados a ela, eles começarão a entender. Talvez os custos sejam bem justificados e você só precise implementar um procedimento para que o carro nunca se envolva em um poste de luz.