Vendemos soluções e não produtos!

Encontrei uma expressão interessante recentemente. Um vendedor de software estava falando sobre entregar toda a solução para seu cliente. "Não vendemos furadeiras. Vendemos buracos", disse ele. É uma grande analogia. Muitas pessoas (incluindo eu) foram à loja de hardware e à janela compradas no departamento de ferramentas elétricas enquanto me perguntavam qual projeto eu poderia pensar que justificaria a compra desta grande ferramenta de energia. Mas aplicar essa lógica faz tanto sentido no mundo do -it-yourself quanto nos sistemas de software corporativo.

Se você não tiver um problema, não precisará de uma solução.

Assim como ninguém deve procurar uma simulação a menos que o problema que eles gostariam de resolver seja fazer um buraco, ninguém deve ir à procura de software empresarial a menos que resolva algum problema. Agora, se você tiver um problema que a implantação do software corporativo corrigirá, a próxima coisa a garantir é que o que você está comprando fornecerá a solução necessária. Isso geralmente é muito mais do que apenas comprar o software.

Implantar um sistema empresarial é um desafio complexo, portanto, o pagamento deve valer a pena. No mundo atual das equipes globais de projetos, uma das coisas mais comuns a fazer é dividir o tremendo esforço de uma implantação do sistema empresarial. Embora isso possa nos dar economias de escala no uso de equipes altamente treinadas em seu aspecto do projeto, ele também tem o risco de ignorar aspectos do projeto de maneiras altamente arriscadas. Esse risco é agravado quanto mais desconectados física e organizacionalmente as diferentes equipes são.

Vamos dar uma olhada nos elementos mais comuns de um projeto de sistemas empresariais.

O que é uma empresa?

Em primeiro lugar, o que quero dizer com a empresa? Vou ter uma definição que deve funcionar para quase todos. "Enterprise", nesse contexto, significa qualquer projeto que afetará a função de toda a organização. Direi que isso é verdade para qualquer organização. Implementações que se qualificam como implementações corporativas não são apenas sobre quantos usuários, mas o impacto que eles têm. Portanto, atualizar nosso software de verificação de vírus do fornecedor A para o fornecedor B provavelmente não se qualificaria. A implementação do software de agendamento de projetos na área de trabalho para um punhado de usuários provavelmente não se qualificaria. Centralizar nosso gerenciamento de projetos e usar um sistema centralizado de gerenciamento de projetos empresariais provavelmente se qualificaria.

Ok, então, se esse é um projeto empresarial, quais são os elementos mais comuns de uma implantação de um sistema empresarial? Em nossos escritórios, a experiência mais comum é a implantação de sistemas de planilhas corporativas, como nosso próprio TimeControl ou sistemas de gerenciamento de projetos empresariais, como o Microsoft Project Server, mas esses elementos serão comuns a quase qualquer implementação do sistema empresarial.

Bits e bytes

Primeiro vamos abordar os blocos de construção mais fundamentais do software: a arquitetura técnica. Hoje em dia, temos que dividir nosso pensamento com base em nossa decisão de ir com uma implantação local ou uma assinatura na nuvem. Vou deixar as maravilhas de escolher qual delas é melhor sob quais condições para outro dia, mas aqui estão algumas das noções básicas do que teremos que pensar em cada categoria.

Se estivermos indo com uma instalação local, temos que pensar em qual hardware usaremos. Quais são os requisitos de hardware para memória e CPUs? Usaremos servidores físicos ou servidores virtuais? Usaremos servidores dedicados ou compartilhados? Que tipos de servidores podem ser necessários? Precisaremos de servidores de aplicativo, servidores de segurança, servidores web? E quanto ao balanceamento de carga, recuperação de desastres e backups? Precisaremos de servidores de backup frios ou quentes? Ufa! Mas ainda não terminamos! E o banco de dados? Quais são os requisitos lá? Que tal o suporte para nossas arquiteturas de segurança, aplicativo e banco de dados existentes? E o suporte para navegadores, versões do navegador e dispositivos móveis? Depois que tivermos todas essas perguntas respondidas, temos que lidar com os problemas de instalação, teste e ambientes de produção e, em seguida, integridade e monitoramento do sistema quando o sistema estiver em execução.

Se estamos indo com uma implementação de assinatura na nuvem, ainda temos perguntas a responder, embora possam ser perguntas muito diferentes. Qual serviço online usamos? Vamos com uma instalação dedicada ou um serviço multilocatário? E a segurança? Podemos nos integrar à nossa própria autenticação? Como lidamos com a recuperação de desastre com o serviço de assinatura? Onde os dados estão fisicamente localizados? Isso apresenta problemas legais para nós? Que tal o suporte para nossos navegadores internos e dispositivos móveis? Como vamos tirar nossos dados e como podemos nos conectar com bancos de dados internos ou outros serviços saas externos (Software como serviço) para integrar a funcionalidade?

Já está sem fôlego? Quando estamos falando de um sistema empresarial, essas perguntas e muito mais estão em pauta. Se mudarmos essa parte do nosso projeto para nossa equipe técnica altamente treinada, eles podem começar a pensar nisso como o escopo de todo o projeto, quando esta é apenas a construção da nossa simulação, ainda não a criação do buraco que precisamos.

Configure-me!

Além de apenas fazer nosso sistema funcionar, também há a aplicação da funcionalidade dentro desse sistema aos nossos problemas específicos. Vi implantações do Project Server em que o cliente coloca o Project Server em execução e percebe que não destinou nenhum financiamento para criar fluxos de trabalho, aprender a priorizar seu portfólio de projetos ou aprender a fazer um único relatório. Assim como a Análise de Sistemas 101 de volta à faculdade, normalmente começamos esta parte da implementação no lado direito de um conselho branco, enquanto perguntamos aos empresários que têm o problema comercial real de quais "saídas" eles vão precisar. Eu já falei disso antes em outros escritos então eu não vou belabor-lo aqui, mas as saídas devem, em última análise, ser decisões de negócios. Para tomar essas decisões, quais relatórios, análises e, em última instância, as entradas de dados que preciso? Trabalhamos do lado direito da tela para a esquerda e acabamos com uma lista de todos os blocos de construção que precisaremos na forma de elementos de dados, cálculos analíticos e exportações e relatórios que precisarão ser configurados no sistema. Esse exercício de configuração pode levar semanas ou meses, dependendo de sua complexidade.

Muitas vezes, os tipos de recursos que precisaremos para esse aspecto do projeto são uma combinação de analista de negócios e especialista em sistema, e é comum que, embora essas pessoas possam ser altamente qualificadas na funcionalidade do sistema que está sendo implantado, elas não são tão qualificadas na arquitetura técnica. Isso torna bastante comum ter equipes desconectadas para dois elementos críticos do sistema. Quanto menos esses dois grupos se comunicarem, maior a probabilidade de enfrentarmos desafios mais tarde.

É um processo

É impossível implantar um novo sistema empresarial e não afetar os processos da organização. Mesmo que você esteja abandonando um sistema empresarial centralizado e migrando para seu concorrente, os processos serão alterados. Na verdade, se você não quiser que seus processos sejam alterados, então é inteiramente possível que você não tenha um problema que precise ser resolvido, e aqui reside mais um desafio. Quando a rotina diária de uma pessoa muda, ela causa transtornos. Não quero dizer um pouco do tempo. Na minha experiência, chateado neste momento de mudança é um dado. Isso é verdadeiro mesmo quando a alteração do processo resultará em um processo melhor! Portanto, pensar em como os processos serão alterados e trabalhar com aqueles que serão afetados é fundamental para o sucesso do projeto. No entanto, os próprios especialistas que são fundamentais para projetar essa mudança no processo são provavelmente as mesmas pessoas que serão afetadas por essa mudança, portanto, este pode ser um aspecto desafiador da implementação. Normalmente, um facilitador qualificado e experiente trabalhará com os especialistas internos para orientar a mudança no processo que se tornou possível com a implementação do novo sistema. Em nossa linha de trabalho, vemos esse desafio o tempo todo. "Mas os gerentes de projeto precisam fazer as aprovações da folha de tempo primeiro", diz um novo cliente do TimeControl. "Esse é o nosso processo." Quando explicamos que as aprovações de matriz podem permitir que os gerentes de projeto façam suas aprovações de folha de tempo como parte de um processo maior e mais eficaz, ficamos chateados; Pushback. Neste ponto, temos um de nossos funcionários mais experientes trabalhando com as pessoas afetadas para garantir que suas preocupações sejam cuidadas, e que elas sejam parte integrante de como o processo mudará.

Portanto, as pessoas do processo provavelmente não são as pessoas de configuração ou as pessoas técnicas, mas se não tivermos essa equipe planejada, todo o nosso trabalho duro na instalação e configuração provavelmente não será implantado. Essa equipe também deve fazer parte do nosso planejamento, incluído em comunicações e decisões tomadas pelas outras duas equipes.

Treinamento

"Então, vamos precisar de treinamento?", infelizmente é uma pergunta que muitas vezes é feita por último. Alguns treinamentos podem vir através das alterações de processo, pois essa parte do projeto requer muita discussão prática, mas e o guia real do usuário de como o novo sistema funcionará de forma mais passo a passo? Ao mesmo tempo, o treinamento era considerado um elemento crítico de implantações de software e os clientes esperavam deixar de lado cerca de 20% do orçamento total sobre ele. Mas, com as alterações nos custos de software e na velocidade da instalação, gradualmente, 20% se tornaram cada vez menos dinheiro. Se estamos pagando US$ 20 por mês por usuário por um sistema, devo deixar de lado US$ 4 por usuário para treinamento? Não posso prometer que não vai longe demais. Há muitas opções de assinatura online para treinamento, mas nada disso levará em conta a solução exata que você projetou.

Os treinadores podem vir de fora ou podem vir das partes de configuração ou processo do projeto, mas muitas vezes são pessoas que são especialistas em vez das pessoas que realmente fizeram o trabalho de implementação. Então, mesmo que você tenha deixado o financiamento de lado para esta equipe (e espero que você tenha), você ainda precisa ter certeza de que essas pessoas sabem em que sistema eles estão treinando pessoas foi realmente projetado para fazer. Eu vi os treinadores chegarem para o Microsoft Project Server e pedi que eles começassem a explicar aos usuários como configurar campos empresariais e configurar drivers de negócios na análise de portfólio, apenas para que os usuários dêem um olhar em branco porque seus campos empresariais já estavam todos configurados e eles não vão usar a análise de portfólio em sua implantação inicial. Seus treinadores sabem mesmo o problema que essa implantação em particular deve resolver? Eles deveriam. Pensar em treinamento no início do projeto lhe dá a maior chance de sucesso. As equipes técnicas, de configuração e de processo podem estar deixando os dados críticos de lado em todas as suas seções para o treinamento que, em última análise, será entregue. Isso significa envolver a equipe de treinamento mais cedo.

Alteração de distribuição/aceitação/cultura

Se você estava pensando e deixou de lado os recursos para iniciar essas equipes e teve todos eles trabalhando e se comunicando juntos através do projeto, então a implantação do seu novo sistema provavelmente será muito mais suave do que poderia de outra forma, mas não subestime a resistência à mudança de cultura. Ter evangelistas importantes disponíveis no momento certo pode ser crítico. Além disso, todos esses membros da equipe estarão empacotando e passando para o próximo projeto? Haverá muito conhecimento do sistema embrulhado nessas pessoas quando o projeto for lançado. Fiquei particularmente impressionado com um de nossos clientes no início do ano passado. Era o departamento de TI uma grande organização financeira. Uma das preocupações que apresentamos ao usuário técnico chave que estava avaliando o software no início do projeto era "quem será o administrador depois que você encerrar o projeto?" "Eu vou", disse ele. Ele era fiel à sua palavra. Suas habilidades e conhecimentos evoluíram através da implantação de vários meses, que foi um grande sucesso, e ele continua sendo o administrador-chave ainda.

Encerrando

Há centenas de outras coisas sobre as quais pensar em como garantir que suas equipes estejam se comunicando e trabalhando como parte de um objetivo maior, e falamos sobre apenas algumas. Espero que isso já esteja fazendo você pensar na próxima implantação do sistema empresarial. "E a documentação?", você pode estar pensando. "E o suporte técnico?"

O importante a ser lembrado é o seguinte: quando você está planejando uma implantação do sistema empresarial, você precisa expandir sua perspectiva para incluir não apenas o esforço de instalação, mas também a entrega da solução concluída. Verifique se o buraco aparece exatamente onde deve estar no tamanho certo, profundidade direita e ângulo reto.

Sobre o autor

Chris Vandersluis é presidente e fundador da Montreal, hms software com sede no Canadá, um parceiro certificado pela Microsoft. Ele é formado em economia pela Universidade McGill e tem mais de 30 anos de experiência na automação de sistemas de controle de projetos. Ele é membro de longa data do PMI (Project Management Institute) e ajudou a fundar os capítulos montreal, Toronto e Quebec do Grupo de Usuários do Projeto Microsoft (MPUG). As publicações para as quais Chris escreveu incluem Fortune, Heavy Construction News, Computing Canada magazine, e PMNetwork do PMI, e ele é um colunista regular do Project Times. Ele ensina Gerenciamento Avançado de Projetos na Universidade McGill e frequentemente fala em funções de associação de gerenciamento de projetos em América do Norte e em todo o mundo. O HMS Software é o editor do sistema de timekeeping orientado ao projeto TimeControl e é um Parceiro de Solução de Projeto da Microsoft desde 1995.

Chris Vandersluis pode ser contatado por email em: chris.vandersluis@hms.ca

Se você quiser ler mais artigos relacionados ao EPM por Chris Vandersluis, consulte o site de Diretrizes do EPM do HMS (https://www.epmguidance.com/?page_id=39).