Vejo da pergunta "O teste Joel para trabalhos sysadmin" no ServerFault que ninguém disse que é melhor a empresa usar o ITIL ou eles não trabalhariam lá. De fato, ninguém mencionou o ITIL.
O ITIL é uma moda? É muito complicado para ser prático? Você precisa ter um determinado tamanho para que o ITIL funcione bem?
As definições da ITIL de "incidente" versus "problema" são interessantes, mas em um ambiente de suporte rápido, as organizações realmente acharam útil distinguir entre os dois?
Respostas:
Absolutamente. O ITIL não é um conjunto de dez mandamentos que devem ser seguidos à risca.
É simplesmente uma base ou estrutura para operar.
O verdadeiro problema vem na interpretação. Se você levar o ITIL a um nível em que a evasão se torne mais fácil que a implementação, ele nunca funcionará. Porém, quando implementado corretamente, o nível de serviço de TI aumenta e o estresse do Sysadmin diminui MUITO!
Quem implementa o ITIL dogmaticamente é um tolo (e eles me disseram isso em um curso "oficial" do ITIL).
Você pode / deve adaptar-se e adotar partes dele às suas necessidades. Obviamente, é loucura para uma loja de uma pessoa de TI tentar implementar o ITIL, quando a maioria das conversas entre as várias "áreas" de gerenciamento de mudanças, gerenciamento de versões, etc, realmente ocorrerão dentro do cérebro de uma pessoa, mas tendo dito isso, em do outro lado da escala, se você acabou de oferecer uma fortuna para ser gerente interno de helpdesk da Microsoft ou HP ou Apple ou quem quer que seja, com usuários e centrais de atendimento em todo o lugar, como você poderia fazer o trabalho sem o ITIL ou algo semelhante como uma diretriz?
Devo acrescentar, neste ponto, que implementamos o gerenciamento de incidentes versus problemas para o nosso suporte técnico e isso tem sido muito útil.
O ITIL não é uma decisão on / off, você gradualmente lança as coisas que são relevantes para o seu ambiente e aborda as áreas que causam mais atrito / dor em sua organização.
Por exemplo: Se o seu suporte técnico estiver sobrecarregado com solicitações, será útil começar a categorizá-las, analisando as fontes e decidindo as ações para aliviar a situação.
Na verdade, é apenas um conjunto de boas práticas e regras comuns que comprovadamente funcionam nas organizações.
O que eu mais gosto no ITIL é que ele define um idioma comum a ser usado ao conversar com profissionais de TI de outras empresas, ainda mais no ambiente multicultural multilíngue europeu. ...
gerenciamento de problemas, gerenciamento de problemas etc. etc. são entendidos e significam o mesmo.
Além disso, concordo com Robert Moir: quem implementa ITIL dogmaticamente é um tolo
ITIL é uma ferramenta .. não a sua salvação.
Na minha experiência, a ITIL também tem sido uma estrutura que permite que a equipe de suporte e a equipe de TI se mantenham firmes contra demandas irracionais dos negócios e implementem soluções reais para problemas de tecnologia, em vez de "soluções rápidas" e "QUEREMOS AGORA CUZAR, ESTÃO FRESCOS! " demandas.
Eu trabalhei em uma organização que usou "alterações de serviço aos negócios" como uma desculpa para destruir, ignorar ou substituir quase todos os padrões de TI que tentaram implementar (hardware, software, sistemas de autenticação, sistemas de armazenamento etc.). Essa empresa falhou e foi comprada por uma empresa que vive e respira ITIL no modelo de suporte.
Fiz a transição para a nova empresa e não apenas a vida é melhor para a equipe de TI, mas, a longo prazo, o NEGÓCIO é mais feliz porque obtém um ambiente estável, e na verdade obtém melhor suporte e novas tecnologias MAIS RAPIDAMENTE, porque existem padrões definidos para suporte que alimenta padrões definidos de tecnologia. Quando um padrão é atualizado, sabemos qual é o nosso caminho de atualização e sabemos que ele pode ser aplicado a uma grande variedade de sistemas implantados. Isso nos permite seguir esse caminho muito mais rapidamente.
Nós NÃO ainda tem uma proess por permitir que as unidades de negócios e vários desenvolvedores de aplicativos com o pedido equipamento "especial" ou serviços, mas desde que fazer charge-backs isso é muito "caro" orçamento-wise para aqueles que o solicite. A estrutura ITIL fornece a você
Sim, mas enquanto você trabalha nisso, por que não dá uma boa olhada nos procedimentos e nos requisitos de suporte da sua organização, converse com os gerentes e usuários que tipo de nível de suporte eles esperam se tiverem que fazer uma troca entre dinheiro. Em seguida, documente isso e os procedimentos usados para fazer seu trabalho. O que você realmente fez é o mesmo que todas essas coisas de ITIL / ISO também.
Conhecer padrões como o ITIL facilita a tarefa acima, porque você possui uma estrutura que resulta nas perguntas certas para cobrir completamente a tarefa, mas o mais importante é a documentação sobre:
Dividir a documentação para a entidade mais baixa (como uma única tarefa) é uma tremenda quantidade de trabalho, mas assim que você faz isso, provavelmente descobre que uma grande quantidade de tarefas feitas agora manualmente é desnecessária, pode ser automatizada e / ou delegada .
Observar com profundidade a sua organização nunca é popular ou fácil, mas resultará em uma melhor compreensão da empresa e ajudará você a ser mais lucrativo, basta parar de fazer coisas desnecessárias e delegar tarefas a um salário mais baixo nível.
O que realmente vai torná-lo impopular é quando você faz esse tipo de padronização: muitas vezes você descreve inadvertidamente que muitas camadas de gerenciamento só existem por causa delas mesmas e que cortá-las provavelmente melhorará a comunicação e o desempenho.