IT Procurement Essentials for Hardware Maintenance RFPs: Parte Um de Três

Quando os profissionais de aquisição de TI procuram proactivamente a contenção de custos e a redução de fornecedores nos seus objectivos para 2020, uma das estratégias deve incluir um enfoque nas despesas operacionais de hardware (centro de dados e/ou rede), e as propostas de valor comprovado do mercado independente de suporte de hardware. Muitos de nós nesta indústria de apoio independente, bem como os analistas do Gartner, descobrimos que os RFPs padronizados incluem demasiadas vezes componentes/questões que não se aplicam. No entanto, quase todos os RFPs para manutenção de hardware carecem gravemente dos elementos centrais que ajudariam a equilibrar as reduções de custos com um risco minimizado. De facto, estes RFPs são muitas vezes bidimensionais e permitem uma representação deturpada e um serviço sub-par. Ajude-nos, ajude-o! Este blogue de três partes foi concebido para educar, ao mesmo tempo que chama mais atenção para as melhores práticas internas, elementos críticos de RFP, priorização de activos e um custo reduzido sem sacrifício ao serviço necessário.

Esta primeira prestação vai concentrar-se em dois aspectos muito específicos dos contratos de serviços de manutenção de hardware do centro de dados: a importância da colaboração interna, e a qualidade dos dados.

Crie uma Cultura de Colaboração com o seu cliente interno de TI

É improvável que possa ocorrer uma ênfase excessiva neste ponto - é preciso trabalhar em estreita colaboração com o ramo de TI para se ter um evento e um resultado de transição bem sucedidos. Obtenha a maior adesão possível da organização de TI, e peça a este executivo que faça com que o seu pessoal leve este projecto a sério. Não vai ser apenas uma única reunião, mas uma série de reuniões ao longo do processo de RFP. Temos assistido a muitos eventos que se prolongam por mais de oito meses desde o início até à conclusão, e quando devidamente organizados, dá amplas oportunidades de obter todos os consensos e feedback necessários.

Uma mentalidade colaborativa é importante porque muitas vezes, para ser eficaz e bem sucedido, tem de se ser perturbador. Neste caso, disruptiva pode ser a defesa de uma abordagem diferente na selecção e gestão de vendedores no espaço, a "forma como as coisas têm sido sempre feitas" deve ser posta em causa. Não se furte a isso, mas certifique-se de que esta mentalidade de colaboração assegura tanto a aquisição de TI como o(s) seu(s) interveniente(s) têm uma compreensão clara e mútua deste tipo de tópicos:

  • Como identificar, avaliar e mitigar o risco de disponibilidade/interrupção de tempo de funcionamento na sua organização de TI?
  • Que risco de interrupção podem as políticas e práticas dos seus potenciais vendedores colocá-lo em?
  • Que montante de risco está disposto a aceitar, em que agrupamento(s) de activos e por que recompensa?
  • Para além do risco de interrupção, que risco comercial poderá encontrar?
  • Se encontrar medo, incerteza ou dúvida projectada sobre si, como determinar o que é real a partir do que é artificial (FUD)?
  • Há alguma política de vendedores que o restrinja de um determinado curso de acção? Que soluções podem ser encontradas para estas políticas?
  • Como é que o grupo irá pontuar e classificar as ofertas? Que peso poderá atribuir à poupança, em comparação com a qualidade e a certeza/claridade da solução?

Estas conversas devem dar resposta a uma lista prioritária de requisitos e objectivos. Assim, sente-se com os seus parceiros de TI e discuta, depois estabeleça prioridades. Tanto o cliente como os titulares das suas participações de TI precisam de ter uma boa compreensão de como o risco pode manifestar-se nos contratos de apoio a centros de dados/equipamentos de rede, e que grau de risco é aceitável para que montante de recompensa. Ao fazer isto, estará muito melhor preparado para implementar tácticas orientadas por uma estratégia directamente centrada na consecução destes objectivos priorizados. A última situação que pretende é contratar para uma poupança fantástica que está carregada de riscos que não previa. Ouvimos falar das histórias de horror, mas sabemos que elas podem realmente ser evitadas!

Trabalhar para obter os dados mais pormenorizados possíveis, de forma antecipada

Sem informação detalhada sobre o servidor/armazém/activos da rede, e especificamente a configuração personalizável/escalonável destes activos, os seus concorrentes fornecedores terão de adivinhar ou fazer suposições sobre detalhes muito importantes. Detalhes que, se desconhecidos pela equipa de apoio ao vendedor, tornarão difícil, se não impossível, o seu cumprimento de um SLA acordado. Uma questão secundária, que comporta um risco comercial, é que sem detalhes específicos um vendedor poderia (inexactamente) assumir a configuração mais baixa possível e licitar em conformidade. Isto parece óptimo à superfície porque a percepção de poupanças pode fazer com que pareça heróico, mas é provável que o seu fornecedor afirme que certos aspectos (múltiplas CPUs num sistema, por exemplo) não estão cobertos pelo contrato. Podem então solicitar ordens de alteração que podem não só degradar as suas poupanças, mas também criar uma situação em que o seu fornecedor de segundo lugar tenha realmente a melhor oferta de valor. Oy! Que confusão. A clareza é o melhor!

No mínimo, deverá ter esta informação. E francamente, isto é abreviado e mostrado aqui como uma ilustração:

Para todos os tipos de dispositivos:

  • Fazer
  • Modelo
  • Número de série
  • Localização (país, cidade, estado, instalações, sala/gaiola)
  • Nível de serviço preferido

Para servidores:

  • Número de núcleos de CPU e MHz
  • Quantidade de memória física
  • Número e capacidade dos dispositivos de armazenamento: disco e fita
  • O número de Adaptadores de Autocarros Anfitriões (HBAs)
  • A presença de quaisquer dispositivos ligados externamente

Para armazenamento em massa:

  • Número e capacidade dos dispositivos de armazenamento: disco ou fita
  • A quantidade e capacidade da memória cache

Para dispositivos de rede configuráveis, a sua melhor acção é executar um comando de "inventário":

  • Para os dispositivos Cisco isto é: mostrar inventário, e em alguns casos mostrar diag ou módulo de exposição - os outros OEMs têm o seu próprio corolário.

Isto pode parecer um pouco assustador, mas o seu pessoal de TI e de rede deve já possuir esta informação, ou ser capaz de recolher a maior parte, se não todas, se não todas. É REALMENTE importante obter o máximo possível desta informação.

Aplicar uma cuidadosa consideração e um acompanhamento diligente a estes tópicos será tremendamente útil no seu próximo serviço de manutenção de hardware RFP para equipamento de centros de dados. Procure as Partes Dois e Três deste artigo para recomendações adicionais e mais específicas.

Sobre o Autor

Todd fundou a XS International em 1990, ajudando a construir uma organização independente de apoio informático, liderada por executivos pioneiros com posições comprovadas na Cisco Systems e Juniper Networks. Ocupa cargos de direcção nas duas associações mais proeminentes do mundo para fornecedores independentes de apoio informático - Associação da Indústria de Serviços (SIA) e ASCDI (revendedores de hardware). Foi membro fundador da Digital Right to Repair Coalition (agora conhecida como Repair.orge continua a fazer parte do seu Conselho de Administração. Muito empresário em série, Todd obteve o seu Bacharelato em Finanças pela Universidade Estatal de Ohio e mais tarde completou um Programa de Mestrado Empresarial de três anos, dado pela Organização de Empresários & Fórum Empresarial do MIT. Actualmente reside na área da grande Dallas com a sua família.

Siga-nos no LinkedIn

ícone linkedin
Deslocar-se para o topo