Práticas recomendadas para sistema corporativo

Este artigo faz parte da nossa coleção "From the Trenches". Ele descreve as práticas recomendadas operacionais para sistemas empresariais em geral (incluindo o Microsoft Project Server). Ele explica como, embora os sistemas corporativos se esforcem para oferecer uma interface fácil de usar em nível de usuário, a tecnologia e a infraestrutura necessárias para isso são geralmente muito complexas. Este white paper descreve como essa complexidade requer o uso de algumas práticas recomendadas básicas, que apresentam a melhor oportunidade de se manter um grau elevado de confiabilidade no sistema corporativo.

Para baixar a versão do Word deste artigo, consulte Práticas Recomendadas de Gerenciamento Empresarial.

Para ver mais artigos, consulte white papers "From the Trenches".

Práticas recomendadas de gerenciamento empresarial

Escrevo principalmente sobre a folha de tempo da empresa ou sistemas de gerenciamento de projetos empresariais e a fase mais comum de implantação sobre a qual falo com esses sistemas seria a fase de seleção ou configuração: falar sobre a perspectiva estratégica. Este artigo é muito mais sobre práticas operacionais e não é específico apenas para o timesheet empresarial ou sistemas de projeto como o Microsoft Project Server. Em vez disso, trata-se de sistemas empresariais em geral, embora o assunto certamente possa se relacionar com quase todas as implantações do Project Server.

Quando encontramos sistemas do Project Server já implantados ou falamos com clientes existentes, muitas vezes fazemos perguntas sobre como a organização implantou e tem suporte para o sistema e seu ambiente. Quando começamos no setor, eram conversas simples porque o software de projeto que instalaríamos sempre viveria no computador do usuário final, e cuidar do sistema sempre foi um conceito local. Hoje em dia, isso raramente é o caso. Os sistemas empresariais são simples no nível de interface ou exibição em que os usuários finais normalmente podem acessar a funcionalidade por meio de um navegador da Web no que se parece com qualquer outra página da Web. Por mais simples que esses sistemas possam estar na frente, é tão complexo quanto na parte de trás. A tecnologia necessária para exibir essa interface provavelmente tem várias camadas, depende de várias fontes para a tecnologia e infraestrutura e (se isso não for suficiente) provavelmente está sendo atualizada o tempo todo.

Mas, há algumas práticas recomendadas básicas que podem lhe dar a melhor chance de manter um alto grau de confiabilidade em seu sistema empresarial.

Localizar um proprietário

Na verdade, temos que dividir isso em dois proprietários porque qualquer sistema empresarial bem-sucedido tem um proprietário comercial e um proprietário técnico. Somente quando o proprietário do negócio é um executivo no departamento de TI e o sistema empresarial é principalmente para esse departamento os proprietários podem ser os mesmos. Então, vamos levar isso em duas partes:

Localizar um proprietário de negócios

Essa pessoa deve ser uma pessoa de nível executivo ou de alto nível de gerenciamento que tenha interesse nos resultados do sistema de gerenciamento de projetos. Os benefícios que o sistema deve entregar ou os desafios comerciais que o sistema deve superar terão que ser benefícios e desafios que afetam diretamente esse executivo. E, antes mesmo de alguém dizer isso; Não, normalmente não pode ser um comitê ou várias pessoas.

A responsabilidade tem que estar em algum lugar e isso quase sempre significa uma pessoa. Essa pessoa também pode ser o patrocinador executivo para a implementação do sistema, mas pode não ser. Muitas vezes, o patrocinador executivo não é o maior proprietário de negócios de um sistema empresarial.

Mesmo após o fim do projeto de implantação, o proprietário do negócio ainda será o proprietário do sistema e, caso não exija mais, outro empresário precisa ser identificado e deve se comprometer com o sistema ou o sistema deve ser desativado.

Localizar um proprietário técnico

Para sistemas de nível empresarial, apenas ter um técnico disponível é insuficiente. Lembre-se de que os sistemas empresariais dependem de muitas camadas de tecnologia. O proprietário técnico deve ser um gerente ou executivo sênior o suficiente no departamento de TI que ele ou ela poderá interagir imediatamente com os proprietários dessas outras camadas de tecnologia. Isso pode incluir pessoas seniores que possuem o banco de dados SQL Server, o servidor de banco de dados no qual SQL Server está instalado, os servidores de aplicativo nos quais o Project Server está instalado, a rede, o servidor Web ou o farm de servidores, a conexão com a Internet, o firewall, servidores Active Directory e Exchange, servidores de segurança ou sistemas e a imagem do sistema operacional no nível do cliente. Alguém sênior deve ser capaz de representar esse sistema empresarial para os gerentes que controlam outros aspectos do ambiente.

Seja proposital

Verifique se o Project Server a) tem uma finalidade e b) está cumprindo sua finalidade. Parece óbvio? Não, não é. Muitas vezes, os sistemas empresariais são adquiridos pelo motivo errado e cabe a alguém em TI procurar uma finalidade para aplicar o sistema. A pessoa que está assinando com o propósito comercial para o sistema empresarial deve ser o proprietário do negócio, embora outros possam estar envolvidos. Sempre faço a esses executivos uma pergunta que uso há anos: "Que decisão de negócios você pode não tomar agora ou só pode fazer com grande dificuldade, cujo uso será habilitado pela implantação desse sistema?" Depois que o requisito de negócios (observe que eu não disse que a funcionalidade desejada) está resolvido, verifique se o sistema empresarial está realmente cumprindo esse requisito. Conheço muitas pessoas que têm uma lista de compras de funções, mas pouca compreensão do que estão tentando realizar com elas.

À medida que a organização evolui, certifique-se de que o proprietário do negócio volte a esse conceito básico. Apenas a implantação de um sistema empresarial como o Project Server pode alterar fundamentalmente os negócios em que ele é implantado, portanto, não é surpreendente descobrir que os requisitos da organização para um sistema podem ser alterados.

É comum entrar em uma organização vários anos depois que o Project Server foi adotado e implantado apenas para achar impossível localizar alguém que saiba por que é importante para a organização. O sistema está em uso para ter certeza. Está sendo levado adiante por pura inércia, mas o propósito foi perdido e os executivos que se beneficiam dele todos os dias não percebem de onde esse benefício está vindo.

Coloque-o em sua arquitetura empresarial

Vários anos atrás eu me lembro de ir com uma de nossa equipe técnica para a localização de um cliente chateado. A instância do Project Server que eles mesmos instalaram estava causando todos os tipos de problemas. Enquanto estava lá pessoalmente, pedimos para entrevistar vários técnicos, rastreando o sistema de volta através de suas camadas. Quando chegamos à camada de banco de dados, ficamos atordoados. Em vez de ser um dos servidores de banco de dados padrão da organização, o SQL Server versão na qual eles instalaram o sistema estava no computador de um usuário final. Toda vez que eles reinicializavam, desativavam o computador ou instalavam algo, o banco de dados ficava indisponível. Isso afetou literalmente centenas de usuários finais.

A organização era grande, portanto, não havia falta de servidores corporativos ou infraestrutura para confiar. Nesse caso, o problema foi facilmente corrigido. Mas foi uma boa lição. O sistema que você está implantando está sendo tecida na infraestrutura corporativa existente na qual a organização pode ter gasto um enorme esforço para ficar estável, ser confiável e ser segura?

Fazer backup

Eu sei. Isso é bobagem, certo? Surpreendentemente e infelizmente não é. Os sistemas empresariais podem ser notoriamente complexos para fazer backup, pois podem depender de vários aspectos do sistema a serem apoiados ao mesmo tempo. Há os dados básicos, é claro, mas também os dados de metadados e configuração da implementação. E qualquer dado relacionado de sistemas auxiliares que possam ter que corresponder ao sistema pode ter que fazer parte do mesmo esquema de backup. Quando pensamos em Project Server, temos que pensar em fazer backup não apenas dos bancos de dados do projeto, mas também do banco de dados do SharePoint Server. Nas versões do Project Server antes de 2010, talvez seja necessário fazer backup do Modelo Global. Mesmo agora, pode haver elementos de modelos que estão em PCs individuais.

E fazer backup não é suficiente. Quando os sistemas forem alterados ou atualizados, faça uma restauração de banco de dados pelo menos uma vez. Lembro-me de anos atrás estar com um cliente para o qual tínhamos ajudado a projetar uma estratégia de backup. Ele desligou o servidor, tirou o disco rígido, colocou outro disco rígido e olhou para nós e disse: "Lá. O disco rígido acabou de falhar. É um disco rígido recém-formatado. Restaure meu Project Server.". Fiquei surpreso, mas mais ainda porque percebi o quão bom era um pedido, e quanto mais eu pensava nisso, mais eu percebia o quão chocante era que ninguém nunca tinha feito o pedido antes (ou desde então). Portanto, faça um teste de restauração pelo menos uma vez. Fomos capazes de restaurar esse sistema por sinal, mas ele não voltou tão limpo quanto suspeitamos que faria e tivemos que atualizar nossos procedimentos de backup.

Preparo/Produção

"Todo o mundo é um palco, e todos os homens e mulheres meramente jogadores", disse Shakespeare há muito tempo. Nesse caso, o estágio é mais sobre preparo e isso é fundamental para qualquer sistema empresarial. Depois que o sistema estiver em produção, você tentará novas configurações, adicionar novas personalizações, experimentar novos relatórios, links, campos e outras alterações. Você terá atualizações e atualizações e todas elas devem ser testadas primeiro em um ambiente de preparo ou desenvolvimento antes que sejam infligidas aos usuários no ambiente de produção. Algo tão básico quanto uma atualização do navegador ou uma atualização de banco de dados pode gerar sistemas empresariais para um loop, portanto, certifique-se de manter e manter um ambiente de preparo separado de um ambiente de produção. Nos dias de hoje de servidores virtuais, isso pode ser mais fácil do que poderia ter sido no passado. Um ambiente inteiro agora pode ser clonado apenas do sistema de produção, mas isso pode ser mais fácil de dizer do que fazer dependendo de como você implantou. Lembre-se de que muitas partes diferentes do quebra-cabeça de tecnologia podem ser referenciadas, mesmo que você tenha copiado um servidor inteiro.

Monitorar, monitorar, monitorar

Há muitos pontos de supervisão que podem ser usados para monitorar um sistema empresarial. Em primeiro lugar, garantir que o Project Server esteja disponível para usuários finais é fundamental e garantir que a equipe técnica apropriada seja notificada o mais rápido possível se ele nunca estiver disponível também é essencial. Felizmente, há muitas ferramentas no mercado para garantir que o sistema esteja funcional e disponível que possam notificar automaticamente a equipe técnica, mesmo que os usuários finais ainda não tenham notado o problema. Mas há outros aspectos do monitoramento que também são importantes. É bom manter um relógio e um log da integridade do aplicativo, incluindo a quantidade de memória que ele está usando, a quantidade de CPUs que ele está tomando, quaisquer erros que o sistema possa ter relatado mesmo se ele se recuperou deles em si, quaisquer reinicializações do servidor necessárias e a integridade relevante de outros elementos da infraestrutura técnica. Saber, por exemplo, que o IIS está tendo problemas técnicos pode ser muito importante para manter a disponibilidade do seu aplicativo empresarial.

Mesmo pequenas alterações são alterações

A tecnologia na qual o Project Server se baseia muda dia após dia. É impossível evitar todas essas alterações. O sistema operacional Windows Server geralmente recebe atualizações a cada poucos dias, SQL Server pode receber atualizações a cada poucas semanas. Sistemas operacionais cliente Windows individuais, seus scanners de vírus, firewalls e Internet Explorer e seus suplementos recebem atualizações regularmente. Qualquer parte da cadeia entre os dados e o usuário final é um ponto potencial no qual o aplicativo pode quebrar, portanto, crie uma estrutura para gerenciar alterações em toda a pilha de tecnologia.

Isso pode ser um desafio, pois muitos aplicativos empresariais diferentes podem depender de aspectos semelhantes da pilha. Tivemos um cliente que atualizou inocentemente o Project Server um tempo atrás apenas para descobrir que todo o ambiente do SharePoint Server foi derrubado. Claramente houve um erro em como a atualização do Project Server/SharePoint Server foi aplicada. Embora houvesse backups completos e nenhum dado tenha sido perdido, o processo de atualização não tinha uma provisão de reversão instantânea e, portanto, os efeitos foram devastadores, pois levaram dias para serem revertidos.

Em outra organização, tivemos um cliente que havia atualizado outro aplicativo empresarial para descobrir que ele exigia absolutamente que todos os usuários atualizassem sua versão do navegador apenas para descobrir que outros aplicativos empresariais já em uso na empresa não dão suporte à versão mais recente do navegador. Era a rocha proverbial e o lugar duro. No final, eles tiveram que reverter a atualização do sistema empresarial e aguardar até que todos os aplicativos corporativos pudessem avançar com uma nova atualização do navegador.

Às vezes, é melhor parecer integrado do que ser integrado

Demonstrações de vendas sempre fazem com que a integração de várias ferramentas pareça tão fácil. Ei presto, os dados começam aqui e terminam aí! Estabelecer um vínculo entre ferramentas altamente flexíveis como o Project Server e outros sistemas empresariais, como o Finance/ERP, é bastante difícil e sempre recomendamos que ambos os sistemas estejam em produção e estáveis antes que quaisquer links sejam estabelecidos. Uma vez que eles estão em andamento, no entanto, é ainda mais importante monitorar quaisquer alterações dos dois sistemas com a mente para garantir que eles continuarão a se vincular corretamente.

Com qualquer atualização de qualquer sistema, pode haver alterações de dados, alterações de estrutura ou requisitos técnicos diferentes. Também pode haver novos recursos e benefícios possíveis, mas certifique-se de que a funcionalidade de vinculação existente seja testada em seu ambiente de preparo antes de ser distribuída para produção.

Documento, documento, documento

As pessoas que estavam lá quando o Project Server foi selecionado e implantado não estarão nessas funções para sempre. Na verdade, se eles fizeram um ótimo trabalho, eles estarão fora do gerenciamento da próxima implantação corporativa que a organização precisa. Portanto, documentar as decisões de configuração, os benefícios projetados, as expectativas operacionais e os parâmetros usados para tomar essas decisões é essencial. No futuro, outros olharão para este sistema e coçarão a cabeça dizendo: "O que eles estavam pensando?" Certifique-se de dizer a eles.

Os documentos do sistema empresarial devem estar vivendo documentos atualizados a cada atualização, cada alteração nos negócios ou no proprietário técnico ou qualquer alteração importante na estrutura operacional ou nos requisitos de negócios.

Olhe antes de saltar

É o conselho que damos às pessoas mergulhando em um lago escuro pela primeira vez. É superficial? Há rochas logo abaixo da superfície? Sistemas de gerenciamento de projetos empresariais, como o Project Server, podem de fato trazer elementos de dados complexos para um só lugar em que as decisões baseadas nesses dados podem ser mais eficazes e os benefícios dessas decisões podem fazer uma profunda diferença para uma organização. Mas você precisa fazer sua lição de casa para garantir que você esteja operando seu sistema empresarial de uma maneira que você possa obter os benefícios necessários sem expor sua organização a custos e riscos que podem acabar rapidamente com o valor desses benefícios.

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).