Você está na página 1de 45

Como implementar o ITIL em pequenas e mdias empresas Parte 1

Salve, salve, pessoal do Cooperati, hoje vou comear um srie de posts sobre ITIL, mas voltado para pequenas e mdias empresas, mas no no Beaba de sempre, e sim como utilizar ela na prtica, coisa que dificil de se enxergar quando faz algum curso ou leitura sobre o assunto, as coisas ficam muito amplas, nesse primeiro post falarei sobre como definir o nvel de maturidade que quer chegar dando alguns exemplos para isso, ento vamos l. Como sabemos, gerenciar os servios de TI no uma tarefa simples, para tentar facilitar essas atividades foram criados vrios frameworks de gerenciamento, porm um dos mais utilizados e divulgados no momento o ITIL que se encontra em sua terceira verso, contendo muitos conceitos e tcnicas para realizar as Melhores Prticas em servios de TI. Mas uma das grandes dificuldades para a sua implementao a grande variedade de conceitos tcnicos que ela possui e a no explicao de como empreg-los. Sua implementao em pequenas e at mesmo em mdias empresas no muito convencional, pois muitas dessas empresas no tem a estrutura para implement-los, outro problema que ela s diz o que deve ser feito, exatamente como um

guia e no como faze-lo, ento muitos ficam perdidos na sua implementao. Mas mesmo que os argumentos citados sejam verdadeiros no podem ser uma barreira para a sua implementao e digo o porque, o ITIL foi desenvolvido para dar uma rota as melhores prticas, mas ele pode ser adaptvel a sua estrutura, pois se ele for engessado, sua implementao realmente ser muito difcil e outra se voc usar um modulo, ou funo que esteja escrito nele, voc automaticamente estar usando o mesmo. Outra coisa, o ITIL contm nveis de maturidade, ento se voc estiver em um nvel que condiz com a sua realidade, voc ter implementado o ITIL na sua empresa, no precisa estar no nvel mais alto em tudo, pois sabemos que para chegar a esse nvel, muitas coisas alm do mundo da Ti precisam acontecer e tambm no precisa implementar todos os mdulos pois, como j disse, nem toda empresa tem estrutura para todos. Mas voc deve estar perguntando-se: Qual seria o nvel que condiz com a minha realidade?, para responder a essa pergunta vamos aos nveis em si: 1 Inexistente: Preciso dizer algo? Um exemplo simples para esse nvel : Um gerente de uma empresa pergunta ao funcionrio da TI: Quais so os maiores problemas que possuo na minha empresa em relao a TI? e ele responde: Fao a mnima ideia. 2 Inicial: Existe uma noo do que acontece na empresa, mas as tarefas realizadas so informais e bem desorganizadas, geralmente cada pessoa do setor de TI sabe algo da estrutura, mas no documentado. Continuando o nosso exemplo, o gerente faz a mesma pergunta e o profissional responde: Bom, EU atendo muitos chamados de mau uso do software mas no sei porque isso acontece e no sei te dizer se o principal, pois no sigo um padro, vou tentando adivinhar na hora que vou resolver. 3 Repetitivo: Esse nvel existe uma ampliao do que acontece na empresa por parte da TI, a informao ainda fica centralizada em uma nica pessoa, porm existem procedimentos padres para realizao das tarefas, mas todos reativos o problema ocorre vai l soluciona.

Continuando a linha dos nossos exemplos, o gerente faz de novo a mesma pergunta e o profissional de Ti responde Bom, EU atendo muitos chamados de mau uso do software, e sei disso pois sigo uma linha de raciocnio que desenvolvi de tanto atender esses chamados, mas no sei te dizer porque isso acontece, s vou l e resolvo. E o gerente faz outra pergunta Os outros sabem lidar com esse problema? e o profissional responde No sei, provavelmente no, desenvolvi essa tcnica sozinho e ainda no passei para ningum. Vamos dar uma pausa aqui, antes de continuar, como podemos observar os nveis citados acima, no so nveis aceitveis em qualquer tipo de empresa, pois se caso o funcionrio, usado no exemplo acima, sair da empresa, todo o processo que ele criou, ser perdido e a empresa ter que cri-lo novamente. A partir de agora os nveis j so aceitveis dependendo do nvel da empresa. 4 Definido: Esse nvel os processos so documentados e todos os participantes do processo so avisados das mudanas e quando depararem com alguma anomalia no processo pode detectar e consultar a documentao do mesmo, alm de poder evolu-lo com alguma descoberta feita que possa melhorar o processo, alm de tentarem evitar que o problema acontea: Seguindo o raciocnio do nosso exemplo o gerente faz a pergunta Quais so os maiores problemas que possuo na minha empresa em relao a TI? e o profissional de Ti responde: Bom, segundo a nossa documentao e comunicao interna, o maior problema o mau uso do software, pois recebemos muitos chamados dele aqui, como sabemos disso j temos um padro definido para ele e tentamos evit-lo realizando as tarefas preventivas, e o gerente faz nova pergunta Voc sabe porque isso acontece? e o profissional responde Infelizmente no temos essa informao 5 Gerenciado: Nesse nvel todos os processos so gerenciados e medidos, com isso os relatrios so mais elaborados e a deteco de erros so mais fcil de encontrar, o processo fica gerencivel, mas para tornar isso possvel, toda uma estrutura deve ser construda e atingir esse nvel no fcil. Dando prosseguimento ao exemplo que estamos

vendo a resposta dada pelo profissional de TI para a pergunta do gerente a seguinte: Bom, segundo a nossa documentao e comunicao interna, o maior problema o mau uso do software, pois recebemos muitos chamados dele aqui, como sabemos disso j temos um padro definido para ele e medindo o ndice de chamadas verificamos que a grande causa disso devido a um mau treinamento no software, pois as pessoas no esto usando-o da maneira correta. 6 Otimizado: Nesse nvel tudo executado usando as melhores prticas e com um adicional, o processo sempre est evoluindo, segue tipo o dito popular Nada no to bom que no possa melhorar. Seguindo a linha do nosso exemplo, em vez do gerente vir at o profissional, o processo inverso o profissional que vai at o gerente e ainda emitindo um relatrio onde est o problema do mau uso do software e dizendo a ele que para melhorar isso a empresa deve investir no treinamento do pessoal para melhorar a produtividade. Sentiram a diferena entre os nveis? Como podemos ver cada empresa, pelo seu estilo, deve ter um nvel que lhe atenda. Na minha viso uma pequena empresa tem que ter como meta inicial o nvel Definido, pois quem trabalha nesse segmento sabe que os recursos so escassos e geralmente no se tem uma equipe ideal para cuidar desse setor e um funcionrio pode desempenhar vrias funes, desde nvel de usurio a servidor. Ento se ela tem os processos definidos e documentados as tarefas ficam at mais simples, pois permite passar para o nvel Gerenciado mais facilmente, apesar de que sem dar ao departamento de TI as ferramentas necessrias, tanto de maquinrio como de pessoal, chegar ao novo nvel difcil. Mas tendo um nvel Definido bem executado j uma vantagem, pois evita o desgaste de troca de funcionrio que comum nelas, pois o treinamento do novo torna-se mais fcil. Para uma empresa de mdio porte, o nvel aceitvel j passa a ser o gerenciado, pois nesse tipo de empresa, a empresa j tem uma certa dependncia da TI e se os processos no esto correndo certinho, as chances de um pequeno problema tornar-se grande so enormes, um exemplo disso se um processo de restaurao de um sistema critico

para a empresa no tiver documentado e sendo feito de acordo com os padres da empresa, o prejuzo financeiro ser incalculvel (se for executado erroneamente), alm do mais os funcionrios de TI tem sempre que estarem monitorando os processos para ver se eles esto em nveis satisfatrios para poder remediar o problema sem ele ter que acontecer. E para as grandes empresas, nem precisa falar que o aceitvel o Otimizado, porm todos sabem que at para elas isso bem difcil de chegar, pois precisa de uma unio grande de vrios setores e todos precisam estar bem alinhados, mas elas possuem mais recursos para isso acontecer do que as pequenas e medias e por isso esse o aconselhvel, mas elas no so o foco dessa srie de artigos Outro fator que devemos considerar que no ITIL existem vrios mdulos das fases dos processos e cada mdulo pode ter um nvel de maturidade e nisso que vamos focar, quais so os processos que devem estar no mnimo no nvel de maturidade Definido para as pequenas e mdias empresas que no nenhum bicho de sete cabeas de ser implementado. No prximo post falarei dos processos que o ITIL cobre e que podem ser facilmente implementados na sua empresa alm de falar de ferramentas que esto disponveis de graa para voc. Para exemplificar o que estou dizendo, vamos seguir com os nossos exemplos. As ferramentas que o nosso profissional de TI pode ter usado para detectar esse problema seria o OCOMON, para gerenciar os chamados, alm de poder ter criado um base de conhecimentos atravs de wiki tais como o MediaWiki para documentar os problemas enfrentados para mitig-los e poder ser usado para dar o treinamento para os usurios do sistema que est dando defeito. Isso s uma amostra do que pode ser feito ento at o prximo post.

Como implementar ITIL em pequenas e mdias empresas Parte 2


Salve, salve, pessoal do Cooperati, vamos hoje dar prosseguimento a nossa srie sobre como implementar ITIL em pequenas e mdias empresas. Como dito no post anterior, para voc implementar a ITIL no precisa que ela seja usada nas supra-sumos das tcnicas de melhores prticas e que ela dividida em nveis de maturidade, outra coisa tambm que vale ser relembrado que ITIL uma srie de boas prticas, mas nem todas elas podem adequar-se a sua estrutura da maneira como relatada no Guia, ou at mesmo se servem para ser implementadas. Algo que tem que ficar bem claro que ela dividida em fases e cada uma tem a sua importncia e dentro de cada uma existem processos a serem desenvolvidos. Para avanarmos ao assunto desse tpico, temos que entender um pouco dessas fases. A primeira ligada a estratgia, muitos no do importncia a ela, principalmente ns brasileiros que preferimos logo botar a mo na massa, mas ela muito importante, pois nela que vo ser definidos o que vai ser implementado e como vai ser feito o acesso, ou seja, definir os recursos do projeto. A segunda fase a de desenho que a parte que, depois da definio do que vai ser implementado, diz o que vai precisar para funcionar e definir os responsveis. A terceira fase a de transio, onde define como o projeto deve ser implementado, pois depois que voc define o que vai ser implementado e o que vai precisar, ser necessrio um manual de utilizao do mesmo, nessa fase que os testes sero feitos para que as tarefas sejam executadas das melhores formas possveis. A quarta fase diz respeito a operao do projeto, essa parte onde os profissionais de Ti mais gostam de trabalhar, porque onde as coisas acontecem, porm para chegar-se aqui, as outras trs fases precisam estar bem consolidadas para a sua realidade, pois no adianta voc colocar algo que voc no vai usar por um longo tempo e

principalmente pecar pela falta de informao, mesmo que seu processo seja pequeno, uma falta de informao pode levar a runa. A quinta e ltima fase, fala sobre uma das partes mais importantes do processo que a monitorao do servio, ou seja, saber se ele est correndo de acordo com o que foi estabelecido nas trs primeiras etapas, j que no adianta voc executar as tarefas e ela estar errada e caso isso esteja ocorrendo aqui que define se ele precisa ser refeito ou ter somente ajustes pontuais. Agora que explicamos um pouco sobre as fases vamos ir ao assunto que nos interessa que colocar a mo na massa, para isso, vamos seguir um exemplo de uma nova aplicao que precisa ser implementada, com isso precisar ser feito toda uma infra para ele, compra de novos equipamentos, utilizao do produto e etc. Como disse, a primeira etapa que a parte de estratgia uma parte que muitos no do muita importncia, por ter que ser calculado e medido com uma boa margem de certeza, nela voc definir quais so os recursos que o seu servio precisar ter e o que ser disponibilizado, nessa etapa existem 3 processos: Portflio de Servios, Gerenciamento de Demanda e Gerenciamento Financeiro. No nosso exemplo essas 3 etapas precisariam ser executadas de uma maneira geral da seguinte forma. A primeira delas, eu prefiro que seja a de Gerenciamento de Demanda, pois ela que defini quem vai acessar a aplicao e quais os recursos que essa aplicao usa quando est em produo. Ela importante pois se voc definir errado como os recursos sero alocados, voc ter duas situaes: A primeira a falta de recursos que acaba comprometendo diretamente no uso da aplicao, porque a resposta no ser em tempo hbil com isso impactar diretamente no negcio, gerando perda de rendimento e consequentemente dinheiro. Sentiram o drama? A segunda a sobra de recursos: ela no to grave igual a falta, mas tambm gera problemas, e digo porque, todos ns temos mania de colocar um pouco a mais para dar a famosa sobra para algum

eventual problema ou mudana de roteiro, isso no totalmente errado, porm o errado que muitas vezes colocamos essa sobra MUITO maior do que ela realmente precisa, com isso se o seu projeto for aprovado, voc no ter problemas de capacidade e todos ficaro felizes, at o belo dia que algum do financeiro da empresa, descobre que voc usou recursos a mais e vai te questionar se isso era realmente necessrio, ai o problema maior aparecer, as chances de voc conseguir aprovar um novo projeto que precisa de um bom honorrio ser bem menores, pois eles sempre ficaro com um p atrs quanto ao seu planejamento. (Isso realmente ruim e acreditem acontece e principalmente em pequenas empresas onde o gasto que voc pediu poderia ser usado em outro setor). Mas voc deve estar perguntando-se como saber se os meus recursos ficaro de acordo com o que preciso? Realmente isso no uma tarefa simples, mas temos que ter algumas coisas em mente que no falham, a primeira delas verificar quantos usurios iro usar a aplicao e a segunda verificar quantos deles acessaro simultaneamente, pois existe uma diferena bem simples nisso, pois nem sempre todos os usurios acessaro a aplicao juntos e com isso gera o primeiro erro bsico de muitos, pois sempre planejamos o pior cenrio possvel e com isso os gastos ficam astronmicos e o projeto ser vetado. Outro ponto importante que precisa ser levado em conta o quanto essa aplicao precisa ficar ativa, ou seja, ela precisa ficar ativa no horrio comercial, somente no perodo diurno e etc, tudo isso necessrio para desenhar um projeto bem estruturado. Obs: A parte de disponibilidade, no uma etapa da fase de estratgia em si, e sim da de Desenho, porm devido a sua importncia impactar diretamente no oramento da aplicao, vamos transferir somente a parte que fala de disponibilidade para essa fase. Para evitar essa sinuca, entre em contato com TODOS os envolvidos diretamente no projeto, e pergunte a eles quantas pessoas devero usar

a aplicao, lembre-se isso no papel da TI, a TI no responsvel por saber quantas pessoas existem em um setor, esse o outro erro comum, pois muitos tentam adivinhar o que se passa na empresa e o erro inevitvel. Outro erro que muitos querem marcar reunies que dependem de muitas pessoas e quase sempre as agendas no batem, e no pensem que isso s acontece em grandes empresas, at em pequenas isso existe, principalmente onde muitos funcionrios executam vrios cargos. Um jeito de facilitar isso usar uma arma que muito mal utilizada nesse aspecto: o e-mail. Mande um para quem necessrio questionar e espere um pouco para a resposta, no saia cobrando a todo instante, isso irrita e pode acabar fazendo com que a pessoa informe algo errado, com isso o projeto j comea errado. Mas esperar demais tambm no bom, caso a resposta demore demais, mande um outro e-mail e caso isso repita, d uma ligadinha e pea educadamente se ela viu o e-mail, caso a resposta ainda demore, comunique a um superior. Esse processo como disse de muita importncia e qualquer erro cair sobre a TI . Aps as informaes estarem nas mos, ai sim a TI precisa usar os seus conhecimentos, que montar uma estrutura que seja adequada a ela, para isso precisamos tambm consultar o fornecedor da aplicao para que ele informe as condies ideias para que a aplicao rode nos termos que foram informados nos relatrios dos envolvidos. Ciente das informaes que o fornecedor te enviou, monte uma estrutura que melhor adeque a capacidade da sua empresa. Obs: A parte de Gerenciamento de Capacidade tambm no da fase de Estrategia e sim da de Desenho, porm devido a alta relao entre custo X Disponibilidade X Capacidade tambm ser falado nessa etapa. Depois verifique no Catalogo de Servios, se h alguma aplicao que execute o que a nova ir executar e vejam quais so as melhorias. Aps tudo est encaixado monte uma apresentao demonstrando o que a empresa pode ganhar com o novo recurso, essa etapa est na parte de Gerenciamento Financeiro, mas as pessoas enganam-se

pensando que essa etapa s para mostrar os custos, mas ela tambm a hora para mostrar que a empresa pode ganhar em pequenas e medias empresas isso tem que ficar bem explicito, pois se voc chegar com uma apresentando s custos, as chances disso ser vetado so BEM grandes. Em uma apresentao para demonstrar esses dados, sempre comece usando quais so as deficincias que a empresa possui por causa da no utilizao da aplicao, depois disso mostre os ganhos que a empresa vai ter ao implant-la, esses ganhos podem ser diretamente financeiros, tais como reduo de manuteno da aplicao e a reduo de tempo de uma parada da aplicao e valores agregados, tais como a melhoria da produo dos funcionrios, pois a aplicao vai dar informaes mais detalhadas e em velocidade melhoradas, com isso o operador pode realizar mais tarefas com uma qualidade melhor. Aps isso, demonstre quais so os custos que isso ter, tanto com a aquisio de novos equipamentos, custo com treinamentos e etc. Aps isso mostre quando que o valor investido retornar a empresa lembrese esse retorno no s com cortes, mas com aumento de produtividade. Mas lembre-se no omita nada, faa um balanceamento de tudo, pois caso voc omita algo nessa etapa e precise de mais recursos no futuro, as chances de serem negadas so bem grandes. Com isso fechamos a parte de planejamento do ITIL, como podemos ver a parte de planejamento bem importante e precisa ser bem executada, mas ela tem que ficar bem clara e transparente para os gestores, pois um mnimo erro pode colocar todo um projeto em risco e tambm verificamos que alguns processos de ITIL esto bem interligados e o bom funcionamento de um depende diretamente de outro para funcionar. Espero ter colaborado mais um pouco sobre esse assunto e at o prximo post.

Como Implementar ITIL em pequenas e mdias empresas Parte 3


Salve, salve pessoal do Cooperati, vamos prosseguir com a nossa srie de como implementar ITIL em pequenas e mdias empresas. No ltimo post falamos sobre a fase de estratgia de servio e que ela uma fase crucial para o bom inicio dos processos j que nela traado quais so as bases para um bom funcionamento dos processos de TI para o negcio, pois lembrando a TI no um brao separado do negcio e sim uma parte dele e a sua funo ajud-lo a trabalhar na melhor forma possvel. Como j dito anteriormente, ns temos a pssima mania de sempre comear pelo trabalho braal sem ter uma estratgia traada e com isso em alguma hora na execuo das atividades vamos ter problemas e ficaremos sem um norte e isso j pode ocorrer na fase seguinte da ITIL que a de Desenho de Servio, pois todos os processos a seguir dependem do que foi decidido na fase anterior, um exemplo disso vem do que foi decidido da empresa sobre o que critico ou no e quais so os recursos para tal. Mas o que a criticidade tem relao com os recursos que temos? Resposta simples, imagina voc ter um recurso X disponvel para o departamento de TI e ter que utiliz-lo para que o negcio da empresa funcione sem ter srios problemas de paradas, um exemplo prtico seria, a empresa do ramo de comercio e tem loja(s) fsica(s), mas tambm vende pela internet, porm ¾ das vendas feita pela internet e o restante na loja fsica, onde muitas vezes o cliente vai s para ver o produto de perto. Mas essa informao no foi passada pela gerncia quando foi definido a estratgia do servio, com isso ¾ dos recursos destinados foram colocados para a(s) loja(s) fsica(s) e o restante para a parte de venda na internet, e esses recursos no so o suficiente para que algum problema nessa rea seja sanado de uma forma rpida e com isso o dia que esse problema ocorrer as perdas sero sensveis, porm lembrando

esse tipo de deciso no de competncia da rea de TI, mas temos que auxiliar na deciso. Viram como uma informao faltante pode acabar com todo um planejamento? Mas agora vamos ao que interessa, e partindo do pressuposto que a estratgia de servio foi traada corretamente, o primeiro passo definir, a partir dos dados chegados da gerencia, quais so os setores crticos que merecem mais recursos para ter a capacidade no mnimo suficiente para atender o negcio e definir qual o grau de disponibilidade que esses recursos devem possuir. E com isso entramos nos primeiros processos da fase de Desenhos de Servio que so o Gerenciamento de Capacidade e o Gerenciamento de Disponibilidade. Esses dois processos andam quase que de mo juntas, e isso se deve a um motivo se a capacidade do servio no atende aos requisitos que ele pede, logo a disponibilidade no chegar tambm ao mnimo exigido e se a disponibilidade no est chegando ao seu mnimo e porque a capacidade no est sendo atingida. Mas como podemos fazer isso com recursos limitados, o que o caso geralmente das PMEs, a resposta parece bvia us-los conscientemente, o que nem sempre simples, vamos pegar o exemplo da nossa loja, quando voc pegou os dados que veio da Gerencia foi dito que ¾ das vendas feito pela internet ento o que podemos fazer concentrar nossos investimentos nessa rea, tendo um link reduntante de internet, no precisa ter dois links dedicados com velocidades exorbitantes , voc ter um link bom que atenda ao seu negcio e um link um pouco menor para suprir uma possvel queda do outro link, e comprar um roteador dual-wan que faa esse balanceamento, com isso j elimina uma boa parte dos problemas. (Todos ns sabemos como o servio de internet no Brasil e o que menos podemos confiar so neles). Outro ponto importante investir em um bom servidor, ultimamente o Cooperati vem batendo bem nessa tecla e mostrando como bom ter algo um pouco mais caro que vai no futuro te livrar de muitas dores de cabea.

No comeo, a alta gerencia quando voc mostrar os valores para a aquisio desses componentes talvez no vo querer aceitar a compra e possivelmente vo falar, Mas e os nossos outros setores como ficaro?, mas ai que entra o papel da TI, mostrar para eles o quanto seria a perda que eles sofreriam com uma queda de algum desses componentes, e que o Investimento no futuro vai ser o menor dos custos, inclusive com manuteno. Outro ponto importante mostrar quais so os custos no futuro no somente no presente, voc vai ter muito mais credibilidade com a gerencia mostrando esses valores. Obs: Como puderam ver o Gerenciamento de Capacidade pertence a fase de Desenho, mas a liberao de verba vem do Gerenciamento Financeiro, porm isso uma prtica comum na Itil, um processo retroceder a outro quando no esto de acordo, pois os processos sempre esto em constante reviso. Com a aprovao para a aquisio dos componentes para atender a capacidade, vamos ao Gerenciamento da Disponibilidade, essa etapa define por quanto tempo um sistema pode ficar indisponvel, sem ter que afetar a produo da empresa, e tudo isso depende da capacidade que foi estabelecida no Gerenciamento de Capacidade. Mas a disponibilidade no somente medida se o sistema est ativo, mas tambm se as informaes so verdadeiras e confiveis, pois isso tambm pode atrapalhar na produo da empresa. E tambm cada setor da empresa pode ter o seu tempo de disponibilidade da empresa de acordo com a criticidade. Voltando ao exemplo da nossa loja, o setor de RH no precisa ter o mesmo nivel de disponibilidade do que o setor de vendas da empresa, ento o setor de RH pode ter uma disponibilidade de 95% e o de vendas 99%. O que significa que o setor de RH precisa ter 95% do tempo do sistema deles disponvel quando for requisitado e o de vendas 99%, mas um outro fator tambm as horas que esses setores acessam as informaes, no caso do setor de RH, somente no horrio comercial, no caso de 8 s 18 de segunda a sexta-feira e o de vendas no famoso esquema 247, 24 horas por 7 dias da semana, ento se fizermos a conta o setor de RH

pode ter uma parada de 11 horas em 220 no total do ms: 22 dias no ms x 10 horas por dia e subtraia do tempo que ele precisa estar disponvel, 220 horas x 0.95. J o setor de vendas pode ter uma parada de 8 horas em 720 horas possveis que so: 30 dias no ms x 24 horas 720 x 0.99. Como podemos ver isso faz uma enorme diferena, mesmo o tempo de parada entre os dois serem quase os mesmos, mas o mximo de tempo que eles podem estar ativos muito maior, ento sempre leve em conta esses fatores. Porm um outro processo que te auxilia nessa tomada de deciso o Gerenciamento de Nivel de Servio, essa etapa de suma importncia pois ele que define em quanto tempo um servio indisponvel precisa voltar, mas ao que muitos pensam os contratos de nivel de servio no so feitos somente entre empresas, mas tambm entre setores da prpria empresa e nessa etapa que muitos acabam se enrolando, pois os prprios funcionrios no fazem valer um tempo de resposta gil. Porm nas PMEs o setor de TI no demanda de muitas pessoas, ento isso deve ficar bem claro entre os membros, ento para isso funcionar algumas tcnicas simples podem ser usadas, uma delas a prpria comunicao, seja ela feita verbal ou por meio de e-mail ou qualquer outro documento, mas sempre tenha algo assinado ou com alguma confirmao que a pessoa tem conscincia dos termos acordados e uma outra forma de verificar se os acordos esto sendo efetuados e ver como eles podem melhorar e fazendo uma reunio em no minimo entre 15 e 15 dias, pois mesmo em um departamento pequeno, pois voc ter um tempo exclusivo para isso, torna as coisas mais simples do que fazer na correria do dia a dia. E esses acordos tambm podem variar de setor para setor dentro da empresa, um tempo de atendimento pode variar, seguindo o exemplo um tempo de atendimento para o setor de RH pode ser diferente do setor de vendas, depende do nvel de criticidade do negcio, mas tambm pelo qual a gravidade do caso. Mas tambm temos os contratos de nvel de servio com prestadores de servio externo, e todas as empresas hoje tem pelo menos um

prestador externo e preciso tambm gerenciar isso para ter um bom funcionamento dos servios e para auxiliar isso existe um outro processo na ITIL que o Gerenciamento de Fornecedores que trata exclusivamente desses fornecedores, para uma boa relao sempre tente te-lo como um aliado no como um inimigo, pois se voc tem a confiana dele com certeza negociar novos contratos ser bem mais fcil. E isso com certeza vale muito nas PMEs, pois os prestadores de servios que as atendem geralmente possuem bastante contratos e as vezes os nveis de servio no so atendidos, caso isso seja constante, seria uma boa ideia estudar um novo prestador de servio. OBS: Caso a sua empresa seja uma prestadora de servio, atente-se a esse ponto, fazer valer o Nivel de Servio acordado no sai caro, mas se os niveis de acordos no esto sendo feitos tente renegociar isso com o cliente, negociar tambm no sai caro. E para o gerenciamento dos nveis de servio com fornecedores externos tambm vale algumas atividades para os nveis de servio interno, sabemos que marcar reunies com eles so dificeis, mas sempre troque informaes e se possvel marque uma reunio e tente mostrar o que est faltando, mas tambm mostre o que est bom, assim voc acaba ganhando esse fornecedor. Como vimos, so algumas aes que tomamos que fazem toda a diferena, saber planejar tambm faz toda a diferena, no prximo post continuaremos a falar da fase de Desenho do Servio, at l.

Como Implementar ITIL em pequenas e mdias empresas Parte 4


Salve, salve pessoal do Cooperati, vamos continuar com a nossa srie de Como Implementar ITIL em Pequenas e Mdias Empresas. No ltimo post demos incio a fase de Desenho de Servio, e como na fase de Estratgia de Servio, essa fase mais pensante, ela discute como o servio de TI deve funcionar e quais so os suportes que ele deve ter. Isso foi mostrado nos processos de Gerenciamento de Capacidade, Gerenciamento de Disponibilidade, Gerenciamento de Nvel de Servio e Gerenciamento de Fornecedores. Esses processos so bastante interligados entre si, um exemplo disso que para voc definir o quanto um sistema pode ficar disponvel, voc precisa saber com qual capacidade ir trabalhar, pois no adianta falar que um sistema vai ficar 99% disponvel, se os recursos que voc possui no te daro isso e de acordo com essas informaes voc pode definir qual ser os acordos de Nvel de Servio pois voc no pode assinar algo que no pode fazer e se caso viu que no pode atingir os nveis desejados pela empresa, voc pode optar por servios terceirizados e de brinde voc ter que gerenciar os seus fornecedores para ver se eles esto te atendendo ou no. Mas a fase de Desenho de Servio, no se limita somente a esses processos, ela possui mais 3 processos sendo 2 altamente ligados: o Gerenciamento de Segurana da Informao e o Gerenciamento de Continuidade do Servio e como podem ver os prprios nomes j falam por si s e so dois processos importantssimos, pois eles lidam diretamente com a segurana da informao. Porm, como a Continuidade do Servio, tem ligao com a Segurana? Simples, a segurana baseada em 3 pilares que juntos so chamados de CID (Confidencialidade, Integridade e Disponibilidade) e a Continuidade lida diretamente com a Disponibilidade e Integridade dos dados. Mas como assim? Bom ele lida, como o nome diz, com a continuidade dos servios, principalmente com a recuperao de

desastres, ou seja, caso algo falhe na sua empresa esse processo que ir decidir o que deve ser feito para que tudo volte o mais rpido possvel, ento a disponibilidade est diretamente ligada a esse fator. Contudo temos que tomar cuidado com uma coisa, quando fala-se em desastre, logo vem a cabea: Meu Deus, o predio da empresa caiu!, mas no bem assim, um desastre no conceito de TI pode ser um servidor de aplicao que caiu, por causa de um desligamento indevido, e esse servidor o que tem a liberao dos pagamentos da empresa e esse fato ocorre justamente no dia do pagamento, ento a sua volta tem que ser feita rapidamente, se esse servidor tivesse caido um dia depois, talvez a criticidade no fosse to alta. Ento um desastre no conceito da Continuidade de Servio e algo que afeta diretamente o funcionamento da empresa e pode causar um grande dano seja ele financeiro ou a sua imagem. Para implementar esse processo em uma pequena ou mdia empresa, a primeira coisa a se fazer e ter um backup, pois em caso de perda de dados (um dos maiores desastres que pode ter), voc est precavido. E ter uma soluo de backup hoje no custa muito caro, hoje pequenos storages esto com preos bastante acessveis, (no Cooperati j foi falado de um micro server da HP, onde pode ser instalado o FreeNas nele e ser transformado em um storage) e junto com o software de backup Bacula, que possui um timo gerenciamento do que foi feito, te informando logs, tempo de reteno do backup, e realizao dos vrios niveis de backup (normal, diferencial e incremental), formam uma soluo bem robusta. Para usurios de Windows a verso Server 2003, possui o NTBackup, est certo que no uma ferramenta completa de backup, mas pelo menos os recursos bsicos de realizao e restaurao de backup ele faz e no Windows Server 2008 tambm existe um ferramenta de backup, mas se voc possuir uma licena do Server 2003 que est encostada, convm instal-la para usar esse servidor como gerenciador de Backup, pois a ferramenta nativa do 2008 tem muitos poucos recursos (menos ainda que o NTBackup). Mas lembre-se o importante ter um.

Contudo um backup feito em uma mdia somente, pode no ser o suficiente, j que esta pode falhar, ento a continuidade lida com isso, ditando outras tcnicas que podem ser feitas, entre elas esto o armazenamento em mais de um dispositivo e at mesmo fora da localidade, e nesse quesito uma simples prtica pode ser eficaz que o caso de entreg-lo para algum do alto escalo, e melhor se for um reserva, pois caso realmente um desastre acontea como o prdio cair, a empresa no perder tudo, e caso esta opo seja adotada a pessoa que sair com o backup, tem que assinar um termo que ele est sob responsabilidade dela. Uma outra tcnica que est ganhando bastante adeptos colocar os dados na nuvem porm o preo de armazenamento talvez no seja atrativo e outro fator o caso da confidencialidade, pois se os dados no esto em suas mos voc no tem como control-los. Outro fator que o processo de Continuidade de Servio tambm lida testar as solues para quando realmente elas precisam ser usadas vo funcionar. Todos ns sabemos que em pequenas e medias empresas, as vezes isso dificil, mas isso de vital importncia pois lida com o segundo pilar da segurana que a integridade, pois se o dado no est consistente tudo o que foi feito anteriormente no ter valido de nada. No caso das solues de backups, uma data propicia para ser realizado esses testes e no final de semana, onde voc poder deixar rodado uma restaurao em um local de testes (pode at ser um pc velho) e quando chegar ao trabalho verificar se tudo saiu conforme era esperado. Um ponto importante tambm a documentao do que considerado um desastre, e tudo isso deve estar bem explicado em um documento, porm nas PMEs isso complicado, pois os recursos so escassos, mas uma forma de mitigar isso fazer um documento por tpicos dando uma breve explicao do que pode ser feito e quais os procedimentos (mas isso claro se voc no tem como detalhar o processo do inicio ao fim, pois quanto mais detalhado maiores so as chances de sucesso), outro ponto importante ter uma cpia desse documento impresso e no s em verso digital, pois imagina se algo acontece e o servidor onde est guardado a cpia o que precisa ser restaurado? E tambm

avise mais de uma pessoa sobre os procedimentos, mesmo que o departamento de TI seja o EU-TI-smo. Caso isso seja a sua situao o escolhido pode ser algum perto do departamento que conhea algo de TI. E no se esquea, tudo isso deve passar pela aprovao da alta gesto, porque se voc no tiver a aceitao deles as chances da implantao dar certa quase nula. Com isso podemos ver que o processo de Continuidade do Servio um processo muito importante, pois lida com casos extremos de paralisaes nos servios, alm de cuidar da segurana dos mtodos de como elas so guardadas e restauradas e o outro processo que segue essa linha o Gerenciamento de Segurana da Informao, que como o nome diz cuida da segurana dos dados da empresa. Nesse processo alm de determinar como as informaes devem ser protegidas ele lida tambm como elas devem ser usadas. Como todos ns sabemos a segurana um tpico que est em alta e deve ser gerenciada de forma correta, pois o nvel dela medido pelo elo mais fraco que ela possui, ou seja, fazendo uma analogia, no adianta voc ter uma casa ultra protegida se a chave da porta de entrada est escondida debaixo do tapete de entrada. Alm como dito anteriormente no adianta voc ter implantado, mas no sabe se est funcionando. O primeiro passo para gerenciar a segurana dos servios definir quais so as informaes mais sensveis da empresa e categorizar por nveis, onde o nvel mnimo que a informao do carter pblico e o mximo o nvel confidencial onde somente alguns membros da empresa sabero que ela existe. Nota: Essa categorizao exemplo e voc pode escolher o seu. Um bom inicio para deixar bem claro como as pessoas devem funcionar no quesito da segurana definir um modelo de segurana, onde ser descrito quais so as polticas de segurana, a maneira como dever ser usado os recursos da empresa de uma maneira que no comprometa os dados, guias para auxiliar na adoo de maneiras seguras de proteger os dados e etc.

E voc pode ter vrios modelos de segurana dentro da sua empresa, um para o pblico em geral, dividido por setores e os para a rea de TI, assim voc pode colocar de uma forma clara para cada um, assim as informaes chegam claras a quem elas precisam chegar. Um exemplo: um modelo de segurana para pessoas no tcnicas deve ter uma linguagem mais simples e de fcil entendimento tal que, as para o setor de TI pode j ter mais recursos tcnicos que explica de uma forma mais detalhada como a segurana funciona. Mas tudo isso deve ser baseado no CID (Confidencialidade, Integridade e Disponibilidade), pois se uma informao for acessada por uma pessoa no autorizada ou vir com dados errados ou no estar disponvel na hora que for requisitada pode causar um enorme estrago. Mas uma coisa no processo de Segurana da Informao no ser implantado a segurana por si s, neste processo ser somente definido como ser a estrategia de segurana da empresa e definir os rumos para isso, a segurana ser implantada na fase de Operao de Servio. Com isso, finalizamos quase todos os processos da fase de Desenho, faltando somente o Gerenciamento do Catlogo de Servios, que so onde os servios que a empresa possui so apresentados e disponveis ao pblico, a principio esse processo pode ser um pouco simples, mas ele de suma importncia, pois ele evita casos de contrataes de servios que j existem na empresa. Um exemplo disso, seria o setor financeiro possui um sistema de pagamentos e ele queira implementar um servio de dbito automtico em suas contas, porm ele tenta fazer no sistema atual e no consegue, ento ele mesmo faz os contatos com outras empresas que possuem isso, adquirem e chega no departamento de TI para implementar, s que o sistema que eles usam executa essa funo, mas no estava documentado no catlogo de servio. Viram como um catalogo bem atualizado pode livrar de vrios problemas? E tambm ele dividido em duas formas: um catlogo de negcios, onde estar todos os produtos que existe na empresa e suas funes e um catlogo tcnico que voltada para o setor de TI, onde

consta como so feitas as funes ou seja o que cada uma faz para chegar ao resultado que o usurio quer chegar. Um jeito simples de fazer um catlogo de servios usar uma intranet, pois ela de fcil acesso a todos, alm de ser uma forma centralizada de informao. Uma ferramenta bem eficaz para isso o Sharepoint e no precisa ser a verso server, j que para as PMEs no necessita de muitos recursos e a verso Foundation dele possui recursos bastante uteis alm de que se voc possui um Windows Server 2008 licenciado voc pode instal-lo sem custo adicional algum. Caso voc queira partir para uma soluo totalmente grtis, pode usar uma ferramenta que cria uma wiki, tais como o Dokuwiki ou o MediaWiki, falado aqui tambm no Cooperati, mas independente da ferramenta, lembre de sempre ter ele atualizado e de uma forma clara. Depois desse processo fechamos a fase de Desenho de Servio, que a fase onde os procedimentos comeam a tomar uma forma e de vital importncia pois qualquer coisa desenhada errada pode gerar enormes problemas no futuro, j que as prximas fases simplesmente coletam as informaes vindas dela e as transformam em real valor para o cliente. Ento pessoal at o prximo post onde iniciaremos a fase de Transio do Servio, onde tudo que foi desenhado ser testado para ver se nada est errado e se tiver voltar para ser melhor feito.

Como Implementar ITIL nas pequenas e medias empresas Parte 5


Salve, salve pessoal do Cooperati, vamos dar prosseguimento a nossa srie sobre Como Implementar ITIL nas pequenas e medias empresas. No ltimo post terminamos a fase de Desenho do Servio, que a fase onde os processos so estruturados e definidos, como sero implementados na empresa e, principalmente, como sero suportados atravs de nivel de servios e gerenciando qual ser a capacidade e a demanda para que eles possam rodar sem sobrar nem faltar recursos. A prxima fase a Transio de Servios, que nada mais que a fase onde so testados os processos, se eles precisam de algum ajuste para poder entrar em execuo e, se precisar, voltar para o processo anterior. Nessa fase, tambm so realizadas tambm as requisies, aprovaes e planejamento para realizao de mudanas no ambiente, ou seja se algo precisa de alterao a etapa aqui e para isso acontecer uma requisio deve ser feita, nesta requisio devem conter: quem requisitou, qual recurso mudar, o motivo para essa mudana e quais as melhorias que essa mudana ir causar. Esse o passo inicial, pois assim a avaliao ficar mais fcil para ser aprovada ou no, pois os motivos estaro mais centralizados e detalhados, pois imagina chegar uma requisio de mudana escrita da seguinte forma: Troquem o monitor. Bom essa requisio s atende a um requisito, que : qual recurso mudar. Mas todas as outras no e com certeza se voc tivesse que aprovar essa requisio teria que procurar saber, no mnimo, quem requisitou e o motivo para ver se aprovava ou no, e isso demandaria um tempo que poderia ser precioso para realizar outras tarefas, ou ento voc excluiria o pedido sem saber do que se tratava, porm se no tiver algo que te respalde de fazer isso, voc poderia ter srios problemas em ter eliminado ela sem aviso prvio e o motivo para tal, em que, no caso da requisio, era no conter os dados mnimos para realizar uma mudana.

E para isso, o primeiro passo ter um modelo de requisio de mudana publicado na rede, ou ter um sistema para tal e tambm um documento dizendo que todas as mudanas s sero aceitas se estiverem no padro desse modelo. Aps voc ter um modelo pronto, voc precisa saber quais mudanas precisam de uma validao para aprovao ou se j so automaticamente aprovadas ou comumente chamando de mudanas padres, o motivo para isso que se todas as mudanas que forem solicitadas tiverem que passarem por um perodo de avaliao, o andamento do negocio da empresa pode ter uma parada no programada, que pode acarretar em srios problemas a empresa e um tipo de mudana padro a alterao de senha ou troca de tonner de impressora, que sabemos que so mudanas rotineiras. Mas independente de uma mudana ser padro ou no, o que no pode deixar de acontecer o registro de qualquer mudana feita na rea de TI e o motivo para isso bem simples, para em um futuro poder avaliar quais so as mudanas que so mais rotineiras e talvez transforma-las em uma mudana padro, isso se no impactar diretamente no negocio da empresa. Outro fator importante no Gerenciamento de Mudanas que as mudanas que precisam de avaliao, no podem ser tomadas por uma nica pessoa, sempre bom ter mais de uma para poder discutir e verificar as melhores opes, como j foi dito em artigos anteriores sabemos que em muitas empresas o EU-TI-SMO impera, mas algumas mudanas precisam ser levadas para os responsveis pela empresa, ento NUNCA decida algo sozinho em que pode afeta-la, mas caso a mudana de carter tcnico e voc possuir mais de uma pessoa na equipe, sempre discuta essa mudana com ela(s), pois algum detalhe que voc no prestou ateno pode ser levado em conta, outro ponto, mesmo que a mudana no necessite da interveno do alto escalo da empresa, sempre mantenha-os informado, para que eles saibam o que est acontecendo e no chegarem e falar mas eu no sabia que isso estava acontecendo.

Aps ser feita a avaliao e autorizao da mudana necessrio ter um documento detalhando como a mudana deve ser executada, pois se algo sair errado a mudana poder ser uma catstrofe e falando nesse assunto, voc tambm tem que estar preparado para mudanas emergenciais, onde no h tempo hbil para avaliar a mudana, j que ela impacta diretamente a empresa, caso isso acontea, tente informar o mximo POSSIVEL de pessoas da realizao desse tipo de mudana, mas tente informar necessariamente as pessoas chaves e no todas que precisariam saber. Outro elemento importante na fase de transio de servios e que tambm est ligado ao Gerenciamento de Mudanas o Gerenciamento de Configurao e Ativos de Servio. Esse processo lida diretamente com o que a sua empresa possui, falando em midos o hardware e o software, pois imagina voc precisar saber em qual hardware um determinado software est rodando para resolver um problema e no saber, isso geraria um outro problema, ento ter documentado o que a sua empresa possui de fundamental importncia. A ITIL chama tudo que a empresa possui na rea de TI de IC (Itens de Configurao), geralmente as pessoas pensam que um IC ligado com o hardware, mas um software de Banco de Dados tambm um IC, pois ele um item configurvel que est relacionado a um servidor. Ento tenha sempre em mos um mapa que diz, onde determinado IC est instalado ou localizado e tambm um inventrio de fcil acesso para tal, outro ponto importante que esse processo cobre : sempre ter estoques de ICs da sua empresa para trocas emergenciais, pois imagine queimar um monitor de um funcionario e o mesmo ter que esperar a aquisio de um outro para ter que trabalhar? Isso no seria uma boa ideia. Mantenha um estoque minimo de peas, para o tamanho da sua empresa, para essas situaes, outro detalhe crucial ter um local para armazenar os softwares que ela possui, para que a instalao ou troca do mesmo, no torne-se um processo dispendioso. Outro ponto ter uma base de configurao dos seus ICs, pois imagina voc ter que configurar uma mquina sem saber o que ela deve ter ou

os requisitos minimos para tal? E essa base no precisa ser s de mquinas pode ser de software tambm, pois implementar um, tambm tem que ter um guia e os requisitos. Essa base tambm pode variar de setor para setor, pois uma mquina que configurada para o Financeiro no a mesmo que vai para o de Vendas, e o seu sistema de Banco pode ser configurado de uma maneira para o Financeiro e outro para o de Vendas. A base tambm pode ser utilizada para retornar a um ponto inicial para resolver um problema ou comparar com um estado atual de um IC. Pois imagina voc no ter um ponto inicial para saber o que est certo ou errado? E um ponto chave saber as ligaes de cada IC tem um com o outro, pois nenhum deles trabalha sozinho e saber qual a relao que eles possuem de suma importncia para resoluo de vrios problemas. Mas falando um pouco de como implementar vou falar rapidamente de dois softwares MUITO uteis nesse quesito e que interligam entre si, um o OCS um software de inventrio Open Source que te d todas as informaes dos ICs presentes na sua empresa. Esse software possui um agente que ao instalar em uma mquina puxa todas as informaes contidas nele, tais como software instalado, configuraes de componentes, como processador, memria, HD e etc, e tambm quem o usurio que est vinculado a ele, alm de te fornecer relatrios sobre tais, alm de fcil implementao. E outro software que falaremos bastante aqui o GLPI, que tem integrao direta com o OCS. Mas o que isso me ajudaria? Eu respondo em muita coisa. O GLPI um software voltado quase todo para as tcnicas do ITIL, ele possui um sistema de abertura de chamados em que voc pode abrir requisies de mudanas e junto com a integrao ao OCS, o usurio pode vincular diretamente o componente que ele quer mudar a sua requisio e isso porque voc pode importar do OCS os componentes e vincular ao usurio correspondente. Alm tambm de ter um histrico de vida do componente e tambm do usurio para detectar quais as mudanas que mais so abertas. Alm de poder cadastrar as peas

sobressalentes e assim que forem utilizadas dar baixa e importa-lo do OCS. Ento pessoal mostramos um pouco de processos bem interligados da fase de Transio de Servios e como eles podem nos ajudar a desvendar o nosso parque de TI no nosso prximo post falaremos sobre os testes e liberao de servios e como gerenciar o conhecimento da sua empresa, at l. PS: Link com mais detalhes sobre o OCS

Como Implementar ITIL nas pequenas e mdias empresas Parte 6


Salve, salve pessoal do Cooperati, continuando nossa srie sobre Como Implementar ITIL nas pequenas e mdias empresas, vamos dar prosseguimento a Fase de Transio de Servio. No post anterior falamos de dois processos dele e que so intimamente ligados: o Gerenciamento de Mudanas e o Gerenciamento de Configurao e Ativos de Servios. Estes processos lidam com o processo de mudana do parque de TI da empresa, o primeiro abre, avalia e v se a mudana solicitada deve ser atendida e o segundo um auxilio para o primeiro j que nele listado todos os ativos da empresa (sejam eles hardware ou software), com isso o departamento de TI pode verificar se a mudana deve ser feita, baseada nos ativos atuais, alm de poder solicitar uma atualizao do parque e armazenar peas para reposio. Mas o que fazer, caso a mudana seja realmente aprovada? Liberar de uma vez? bvio que no! Deve testar antes. Mas depois que testar, liberar tudo de uma vez? S se o alvo forem poucas pessoas ou no tiver outra pessoa. Essas e outras perguntas so respondidas no Processo de Gerenciamento de Liberao e Implantao. Esse processo lida, com os testes, mtodos de liberao e implementao dos projetos e mudanas. O primeiro passo desse processo a parte de testes, neste caso o principio bsico ter um ambiente de testes preparados e simule alguns testes. Como venho falando ao longo desta srie algumas empresas no possuem ambientes adequados para tal, e as vezes o setor de TI tem que se virar com o que tem, ento algumas dicas talvez ajudem: no caso de teste de software hoje contamos com a virtualizao para nos ajudar, hoje mquinas conseguem fazer esse processo perfeitamente, ento no necessrio que fiquem mquinas exclusivas para esse fim. Ento use e abuse desse recurso, que ajuda bastante. Programas free para isso que no faltam, para ambientes desktops temos o virtual box e caso voc tiver um servidor disponvel

para esse fim o VMWare ESXi e se voc tiver uma licena de Windows Server sobrando temos o Hyper-V que agora tambm vir no Windows 8. Com essas ferramentas possvel simular o seu ambiente e ver exatamente o que a aquisio ou mudana do software pode causar. Repetindo use e abuse desse recurso. No caso de hardware, separe um lugar para poder testar se eles esto funcionando corretamente, esse espao no precisa ser uma sala, que muitas empresas no possuem, pode ser uma pequena mesa que comporte o espao para eles, sempre teste se os equipamentos esto funcionando, pois a pior coisa que existe e voc colocar um aparelho para um usurio e 5 min voc recebe uma reclamao dizendo O equipamento no est funcionando!. Est certo que as vezes as mudanas de hardware para usurios, tem que ser imediatas e no h tempo de testar, ento voltando ao tpico anterior, sempre tenha peas reservas e quando elas chegarem teste-as para evitar conflitos. Aps os testes serem realizados, temos que partir para a liberao e implementao da mudana. Na parte de liberao temos que definir como elas sero feitas e isso no uma deciso isolada, ela depende muito do que vai ser liberado. Por exemplo, se voc vai liberar uma nova verso de software, se caso essa mudana no afetar o BD atual e pode conviver sociavelmente com a verso antiga, escolha algumas pessoas dentro da empresa para verificar se algum problema no foi visto nos testes. (Todos ns sabemos que um erro ou outro passa durante a parte de testes, ento nunca bom fazer uma liberao total). Caso a mudana impacte no Banco e com isso as verses no possam coexistir, a liberao tem que ser feita para todo mundo, neste caso os testes tem que serem bem mais rigorosos, pois qualquer erro afeta todo o sistema da empresa e outra coisa sempre tenha um backup para voltar em casos de pane geral, isso tem que estar bem relacionado com o Gerenciamento da Continuidade de Servios de TI, este tipo de mudana so chamados de Por Fases ou Big Bang, respectivamente. Obs: Este tipo de liberao pode ser usada tanto para software quanto hardware.

Para a liberao de software, existem outros mtodos de liberao que podem ser usados em conjuntos com os citados anteriormente, entre eles esto o modo manual ou automtico, que o prprio nome diz como funciona, ou voc libera a atualizao indo pessoalmente nas mquinas ou cria um modo automatizado, atravs de scripts, programas de atualizao e etc. E o outro modelo de liberao o Empurra e puxa, que significa, a atualizao empurrada para um ponto central e depois os alvos que sero atingidos por essa liberao puxam desse ponto central. Este tipo de modo usado comumente com o modo de liberao automtico em que um pacote enviado a um servidor e a aplicao a ser atualizada ao iniciar verifica se a verso que ele usa igual a verso que est no servidor se no ele, baixa e atualiza a sua aplicao. Ento utilizando usando esses modelos de liberao, separadamente ou em conjunto, temos uma gama de formas para melhor fazer a atualizao das mudanas no ambiente de TI. Ento para encerrar essa parte de liberao, temos um ltimo ponto em comum com o Gerenciamento de Mudana, uma Requisio de Mudana s deve ser fechada aps a implantao da mudana ser completamente executada, ento o Gerenciamento de Liberao e Implantao est dentro do Gerenciamento de Mudanas, mas sendo processos em separado. E o ltimo processo dessa fase o Gerenciamento de Conhecimento, que lida diretamente com a documentao da TI. Este processo muito importante, pois ele que dir aonde a informao deve ser guardada e atravs de relacionamento com outros processos voc ter uma base de conhecimento bem grande. Neste processo, uma base das coisas : registre tudo o que foi feito! Isto se d pois voc nunca saber quando vai precisar de uma informao de algo que aconteceu a por exemplo 6 meses atrs ou ento saber como configurar uma aplicao que foi implementada a 1 ano e ter que ser reconfigurada novamente e uma das mais utilizadas funes desse processo a base de conhecimento para resoluo de problemas, que ser discutido nos prximos posts.

O Gerenciamento de Conhecimento talvez seja o processo mais ligado com todos os outros, pois tudo que registrado nos processos recai aqui, ele engloba: a relao dos ICs (Itens de configurao) do ambiente, as requisies de mudana, o plano de contingncia para recuperao de desastres, os contratos de SLA, os modos para resoluo de problemas e etc. OBS: Um famoso caso de Gerenciamento de Conhecimento so os famosos Knowlegde Base ou os KBs da Microsoft, onde todo um guia para a resoluo de problemas esto nele e todos sabemos que eles so inmeros que juntos formam a Base de Conhecimento. Como podem ver o Gerenciamento de Conhecimento um ncleo principal da ITIL, um modo bem importante para faz-lo funcionar montando uma intranet na sua empresa, onde todos os usurios tem um fcil acesso a informao e podem atravs dela resolver o seu problema, sem ter que abrir um chamado no setor de TI. Outro ponto tambm importante que aps uma requisio de mudana ser completada e finalizada, ela vem para a base de conhecimento para que fique salvo tudo o que foi feito e no futuro poder ser analisada e ver quais foram as maiores mudanas e como foram e levantar uma estatstica, como j dito nos posts anteriores. O Gerenciamento de Conhecimento tambm ajuda a transformar um simples dado em sabedoria, pois atravs dele voc pode interligar vrias informaes sobre vrios assuntos diferentes e transforma-los em um conhecimento que possui e passar a entender como as coisas funcionam e porque elas acontecem. Mas um grande mal, que no deixa as pessoas a implementar o Gerenciamento de Conhecimento a internet, pois tudo o que procuramos est l e isso um fato, mas no imaginamos que o site onde aquela informao est pode sair do ar e um exemplo disso o MegaUpload que foi retirado do ar e com isso vrios arquivos de pessoas deixaram de existir, pois possuam somente a cpia nele. Um outro ponto que tambm pesa positivamente para a implementao do Gerenciamento do Conhecimento que voc ter um acesso mais rpido as informaes da empresa, sem ter que

procurar em outro local, alm dela estar dentro da sua empresa e caso tenha uma queda de um link, voc ainda tem acesso a ela. OBS: Mantenha sempre atualizado a sua Base, pois se tiver desatualizado a mesma coisa que no ter. E algumas ferramentas ajudam bastante na implementao destes processos citados acima, na fase de Gerenciamento de Liberao e Implementao, na parte de atualizao do Windows, temos o WSUS, que usa a implementao empurra e puxa, onde ele baixa as atualizaes dos servidores da Microsoft e depois distribui para as mquinas clientes. Outra ferramenta que pode ser utilizada so as GPOs, onde voc pode atualizar os softwares atravs dela, alm da famlia system center que possui ferramentas para gerenciar todo um ambiente inclusive na liberao de software, com recursos melhorados que por GPOs. Na questo da documentao, como disse, bom usar uma intranet e uma tima ferramenta para isso o sharepoint, em que a verso gratuita oferece grandes recursos que podem auxiliar, uma boa estrategia para a parte de documentao criar categorias tais como: Mquinas Clientes e Servidores e dentro delas colocar subcategorias, tais como resoluo de problemas, configurao de aplicativos e etc. Uma outra opo usar o WordPress como Base de Conhecimento que pode ser visto neste post e tambm o GLPI que possui uma parte para colocar as solues para os chamados, alm de colocar na base de conhecimento do prprio sistema. Ento pessoal com isso terminamos mais uma fase do ITIL e no prximo post comearemos a parte em que a ITIL mais empregada que a Operao do Servio, que onde as coisas acontecem, ento at l.

Como Implementar ITIL nas pequenas e mdias empresas Parte 7


Salve, salve pessoal do Cooperati, vamos prosseguir com a nossa srie de Como implementar ITIL nas Pequenas e Medias empresas, no nosso post anterior finalizamos a fase de Transio de Servios, que discute como deve ser feito os testes e a documentao de todo o processo que foi desenhado para que na hora da real implementao nada fique despercebido ou que as chances disso ocorrer sejam a menor possvel e principalmente que quando ocorrer falhas no sistema a sua empresa esteja munida de ferramentas para solucion-los o mais rpido possvel. Mas e se algo passar em branco ou se um dos problemas que foram diagnosticados na fase anterior acontecer, como proceder? pensando nessa questo que entra a Fase de Operao de Servios, nela citado tudo o que ocorre na parte operacional dos sistemas de TI, e normalmente muitos resumem a ITIL a essa etapa ou comeam a implementa-la por aqui, sem verificar as etapas anteriores que como visto so to importante quanto ela. Ento vamos l, o primeiro processo dessa fase que entra em ao quando algo acontece fora dos padres o Gerenciamento de Eventos. Esse processo emite alertas de 3 tipos: Informao, Aviso e Erro. O primeiro como dito alguma informao do tipo, um servio iniciou ou parou, que alguma tarefa foi realizada com sucesso entre aes similares, como o nome disse uma informao onde voc pode tomar alguma ao ou ignora-la. O segundo tipo, que o aviso, j merece um pouco mais de ateno, pois ele serve como um alerta de que algo talvez no esteja funcionando da maneira correta e que pode interferir ou no no andamento do sistema, um exemplo de aviso : a memria do servidor est chegando ao seu limite ou o espao em disco est chegando perto de um nvel critico, voc pode tomar uma ao ou no, vai depender de como voc achar que deve proceder. J o terceiro tipo pode-se resumir em A casa caiu, pois como o prprio nome diz,

ocorreu um erro ou exceo e alguma coisa do sistema no est funcionando e isso vai acarretar em mau funcionamento do prprio, esse tipo deve ser tratado com todo o carinho possvel, pois quando ele acontece ou algo vai parar ou j parou e sua situao est delicada. O Gerenciamento de Evento tambm um timo auxilio para o Gerenciamento de Problemas e o Gerenciamento de Incidentes que sero falados posteriormente, pois como foi dito, eles do a ideia exata de onde a exceo est ocorrendo (ou pelo menos essa devia ser a funo, por essa questo que um sistema deve ser bem documentado e principalmente mostrar as suas excees ou erros bem detalhadas para que a deteco e a resoluo da anomalia possam ser rpidas e indolores). Essa etapa tambm tem alguns extras que merecem ser mencionados, como falado a base para que esse processo ocorra ter um sistema de eventos bem detalhado ou pelo menos de fcil entendimento e isso pode variar de sistema para sistema, se for um sistema pequeno talvez aparecer um pop-up na tela passando a informao que deseja seja o suficiente, mas se voc quer incrementar o seu gerenciamento de evento dependo da ao que o usurio tome deva ser registrado em logs, que so a forma mais difundida de gravao de eventos e que muitos de ns j utilizou ou utiliza frequentemente, mas no caia na tentao de querer gravar tudo o que ocorre, pois voc ter tanta informao que acabar se perdendo ou cansando de procurar o que precisa, ento tenha como meta: guarde somente aquilo que ser realmente necessrio para voc ou para quem for dar assistncia ao sistema. Porm um bom Gerenciamento de Eventos aquele que possa ser programado para emitir um alerta assim que algo de importante acontea e para quem programa isso tenha que por em mente que essa informao tem que chegar a quem realmente necessita saber, no adianta disparar um e-mail para N pessoas e nenhuma delas dar confiana ou at precise saber, mas pensa a outra pessoa tambm recebe e vai verificar isso e vice-versa, como diz um ditado Cachorro com 2 donos morre de fome.

E para exemplificar um sistema de Gerenciamento de Eventos no lado Windows temos o nosso bom e velho Visualizador de Eventos que armazena vrias informaes por tipos e se bem configurado guarda aquilo que realmente interessa, alm de ter filtros para verificar somente um tipo de evento ou quais eventos ocorreram em uma determinada data, alm de ser integrado com o Perfmon que fica verifica se um determinado evento ocorre e dispara um aviso a quem interessa. Juntos essas ferramentas podem evitar vrias dores de cabea futuras. E do lado Linux temos o arquivo messages que fica dentro /var/log/messages que informa as mensagens de sistema e as armazenam nele, e que podem ser gerados scripts para verificar e filtrar determinados eventos e executar as devidas aes, no Linux geralmente os sistemas possuem seu prprio arquivo de eventos e cada um tem a sua localizao, mas na documentao do produto possui o arquivo (pelo menos nos programas que se prezem) e tambm podem ser tratados da mesma maneira. Porm existem eventos que j so conhecidos e podem ser tratados sem ter que passar por uma interveno de nvel superior e que podem ser resolvidos pelos nveis inferiores de atendimento e nessa etapa possuem pessoas que seguem alguns roteiros para poder tratar esses eventos de uma maneira mais rpida. Esse tipo de atendimento tambm possui um processo chamado de Cumprimento de Requisio, neste processo so tratadas todas as requisies que podem ser atendidas de uma forma rpida e que no comprometem ao bom andamento dos negcios e funcionamento da empresa, dentre essas requisies esto troca de senha de usurio, instalao de softwares pr-aprovados e etc. Uma caracterstica especifica desse processo que geralmente quem trabalha nessa parte, tem um roteiro a ser seguido e so o primeiro contato do usurio com a resoluo de problemas e em alguns locais so eles que escalonam para onde o problema vai ser direcionado, se caso eles no conseguirem resolver a requisio.

Este processo, repetindo, por poder ser um ponto de contato primrio ele tambm age como um ponto de tira-dvidas do sistema da empresa. Geralmente, o setor que cumpre o papel de Cumprimento de Requisio possui mais pessoas que os outros setores, por justamente serem mais demandados e um outro ponto que a pessoa para estar nesse setor no precisa ser totalmente tcnica, sabendo operar um sistema que o guia para instruir o usurio j o suficiente. Para elucidar melhor o que digo, todo mundo aqui j ligou para uma empresa de algum sistema para poder reativa-lo ou tirar alguma dvida, ento quem te atendeu voc no sabe se era algum tcnico ou no, mas que provavelmente resolveu a sua requisio ou dvida, este processo muito importante dentro de uma empresa, pois ele alivia os outros setores, mas como no nosso caso estamos falando de pequenas e medias empresas, ento no caso das empresas que possuem o EU-TISMO, geralmente uma pessoa para realizar tudo, mas uma dica para esse tipo investir em treinamento no sistema para que as requisies que chegarem a voc sejam aquelas que realmente precisariam chegar e no aquelas dvidas que com um simples treinamento poderia ser esclarecida. Mas se possuir mais de uma pessoa no setor pode haver um revezamento entre elas para que cada um possa realizar as outras tarefas ou se haver uma disparidade grande de conhecimento, deixe a que possui um pouco menos de conhecimento fazer esse procedimento e a outra para resolver os problemas mais srios, e no desmerecimento, j que quem est realizando a funo de Cumprimento de Requisio pode aprender muito com algumas dvidas dos usurios. E para auxiliar mais o processo de Cumprimento de Requisio, uma parte da documentao gerada no processo de Gerenciamento do Conhecimento pode ser liberada para ele, assim a informao passada de forma mais rpida e com isso uma boa ferramenta para isso continua sendo o Sharepoint Foundation ou o GLPI que possui uma

sesso somente para solues de problemas, onde as solues conhecidas so liberadas. Mas e se caso o Cumprimento de Requisio no conseguir sanar a requisio do usurio? Como foi dito passa-se o problema para o Gerenciamento de Incidentes ou o Gerenciamento de Problemas, e este ser o assunto do nosso prximo post dessa srie, espero que possam tirar algo de proveito do que foi passado aqui, at a prxima.

Como Implementar ITIL em pequenas e mdias empresas Parte 8


Salve, salve pessoal do Cooperati, vamos dar prosseguimento a nossa srie de Como Implementar ITIL nas Pequenas e Mdias empresas, no post anterior iniciamos a fase de Operao de Servios, e como falado, aqui onde as coisas acontecem, estruturado o que fazer para que as coisas funcionem e se der algo de errado como resolver da melhor maneira possvel. Ns j falamos de dois processos dessa fase que so: Gerenciamento de Eventos e Cumprimento de requisio. O primeiro lida com os eventos gerados pelos sistemas e processos dentro da empresa e fala como lidar com eles quando aparecem, se devem tomar alguma ao ou no e o segundo o contato inicial do usurio com o setor de TI para resolver alguma pendncia na rea, seja retirar uma dvida, solicitar alguma troca que no interfira no funcionamento da empresa, ou seja, desafogar os setores dos prximos assuntos a serem falados, que so o Gerenciamento de Incidentes e o Gerenciamento de Problemas. Estes dois processos, talvez sejam os processos mais intimamente ligados dentro de todo o ciclo da ITIL, pois um depende do outro para funcionar, mas para comearmos temos que explicar a diferena entre incidente e problema. Incidente algo que no est funcionando em seu estado normal, ou seja, algo que causou algum tipo de dano aos servios de TI, seja de pequeno ou grande porte. Exemplo: um computador de um usurio parou. Problema a causa ainda no explicada do incidente, dando prosseguimento ao exemplo do incidente um exemplo de problema seria: um computador parou, mas a causa aparente da parada desconhecida. Perceberam a relao entre eles? O Gerenciamento de Incidentes tem como ponto principal, voltar atividade normal o mais rpido possvel, ou, no mnimo, dentro do prazo acordado no SLA, que foi criado no Gerenciamento do Nvel de Servio. Geralmente esse tempo definido por categorias, e obviamente os processos mais crticos tem que voltarem o mais rpido possvel,

pois se ficarem parados causaro grande dano seja a reputao ou ao financeiro da empresa. Um bom mtodo para definir o que deve voltar o mais rpido possvel seguir os passos: Identificar, registrar, categorizar e priorizar. A parte de identificar consiste em ver aonde o incidente ocorreu e posteriormente registr-lo. Completando o nosso exemplo, uma identificao seria: o computador de Fulano que fica no setor de vendas parou de funcionar, sem uma causa aparente. Esse texto j identifica o incidente e j est pronto para ser registrado, com isso a parte de categorizao j ficaria facilitada, pois voc poderia ter uma categoria principal chamada computador e uma sub-categoria chamada interrupo de funcionamento, onde o nosso exemplo se encaixaria e consequentemente a priorizao tambm estar facilitada. Nota: A forma como fazer uma boa categorizao de incidentes, ficar para um post futuro, por se tratar de algo bastante extenso. A priorizao se d por dois critrios, impacto e urgncia, estes dois critrios parecem o mesmo mas no so, o impacto seria a abrangncia do incidente, ou seja qual a expanso do problema e urgncia e o quanto rpido este incidente deve ser resolvido, mas nem todo grande impacto uma grande urgncia e vice versa. Um exemplo de impacto alto e urgncia baixa: o sistema online de cotao do dlar que o financeiro usa, no est funcionando, porm eles conseguem usar uma forma manual de coletar a cotao, ento o impacto alto pois eles tero que realizar mais de uma tarefa para conseguir o que queriam, mas iro conseguir, com isso a produo no fica totalmente parada e um exemplo de urgncia alta e impacto baixo um sistema online de aes que um gerente usa, no est funcionando corretamente, porm se ele precisar de uma informao na hora e no conseguir, o caos estar implantado, mesmo atingindo uma s pessoa a urgncia grande j que uma pequena falha elevar o impacto para alto.

Ah, no se esquea de votar no CooperaTI para o TOP BLOG 2012 e tambm de participar do projeto curso grtis!

Para isso podemos montar uma tabela de impacto x urgncia e definir inicialmente 3 niveis: Alto, mdio e baixo e com isso ficar muito fcil definir o que deve ou no ser solucionado. Nota: Um modelo de criao de tabela urgncia x impacto pode ser visto no link:http://www.administradores.com.br/informe-se/artigos/matrizde-priorizacao/25080/ Feito estas etapas o passo seguinte partir para a resoluo. A primeira etapa fazer um diagnostico inicial, onde alguns procedimentos bsicos sero realizados, geralmente esta etapa realizada pelo nvel mais baixo do Gerenciamento de Incidentes, pois a maioria dos incidentes que ocorrem so incidentes conhecidos e suas aes j foram documentadas, ou pelo menos deveriam estar, se voc j chegou at essa etapa da ITIL, caso a resoluo no for possvel ento comea um novo processo no Gerenciamento de Incidentes que a etapa de escalonamento, existem dois mtodos de escalonar, o escalonamento funcional, onde os problemas so passados de nvel de atendimento, por exemplo, o nvel 1, cuida da parte de desktop, o nvel 2 da rede e o nvel 3 dos servidores, onde o nvel 3 o mais alto da pirmide e geralmente o menos utilizado porm mais especializado e o hierrquico onde passado por posies ocupadas dentro da empresa, por exemplo, tcnico, analista e gerente, este nvel mais utilizado onde h duvidas para onde enviar um registro de incidente e o nvel superior definir isso. Nas PMEs, que no adotam o EU-TI-SMO, geralmente o nvel 1 tambm cuida do cumprimento de requisio e caso a pessoa no esteja capacitada passa para o superior e no caso do nvel hierrquico geralmente passa diretamente para os responsveis da empresa, j que o recurso humano na TI escasso, e geralmente eles no gostam de ser incomodados quanto a assuntos de tecnologia, para isso o processo de conscientizao primordial. Aps isso, necessrio investigar e diagnosticar o problema, esta etapa de suma importncia pois nela verifica exatamente o que est acontecendo erroneamente e diagnostica-lo, caso esse tipo de incidente j esteja registrado basta aplicar a correo mas caso no esteja registrado ou as solues documentadas no funcionarem o Gerenciamento de Problemas acionado, pois eles so responsveis por fazerem a verificao da causa raiz do incidente que se tornou um

problema e assim que terminar a verificao mais detalhada voltam alguma soluo para o Gerenciamento de Incidentes. Esta etapa muito importante, pois caso realmente tenha que ser passado o problema para o Gerenciamento de Problemas, as informaes que forem para l tero de serem bem claras e objetivas, alm de no serem passadas faltando detalhes, pois com isso a resoluo poder vir bem mais rpida e como existe o tempo de volta previsto em contrato, talvez uma soluo seja temporria at ter uma definitiva e para isso chamamos de Soluo de Contorno, que no deixa de ser uma resoluo para o problema. Assim que tiver com uma soluo em mos, seja ela definitiva ou no, partir para a resoluo do problema (lembrando nem sempre as solues propostas podem funcionar, caso isto ocorra, como falado anteriormente, o incidente deve ser repassado para o Gerenciamento de Problemas. No caso das PMEs, geralmente quem cuida do Gerenciamento de Problemas o nivel mais avanado do Gerenciamento de Incidentes, pois por ter pessoal mais capacitado, eles conseguem detectar o problema com mais facilidade, ento podemos ver que nesse estilo de empresa, o funcionamento da estrutura fica assim: - Cumprimento de requisio e Gerenciamento de Incidentes de 1 nivel so colocados aos cuidados do mesmo setor. - Gerenciamento de Incidentes de 2 e 3 nivel (se existir) e Gerenciamento de Problemas so colocados aos cuidados do mesmo setor. Esta estrutura, na maioria dos casos, funciona em harmonia, pois quem desempenha estas funes tem que desenvolver o seu servio em ligao com os processos citados. O Gerenciamento de Incidentes tambm contm um aspecto importante para o setor de TI dentro da empresa, se as solues so apresentadas dentro de um tempo hbil a TI estar com conceito bom, caso no, vem as dvidas e reclamaes e retirar esse pensamento ser bem mais complicado ento manter esse processo em conformidade de vital importncia, talvez por isso que seja o que a maioria d mais ateno a esse setor e esquece dos outros, mas para isso funcionar da melhor maneira possvel e bom usar um sistema para controlar isso e novamente poderemos usar o GLPI, pois o mesmo tem uma funo especifica para controle de chamado, integrao com o AD, relatrio de

estatsticas para verificar os chamados mais abertos, com inmeros filtros, uma ferramenta bastante poderosa nesse quesito. Com isso chegamos ao fim de mais um processo, no prximo post falaremos sobre o Gerenciamento de problemas e como ele deve agir at l.

Como Implementar ITIL nas pequenas e mdias empresas Parte 9


Salve, salve pessoal do Cooperati hoje vamos continuar a nossa srie sobre Como Implementar ITIL nas pequenas e mdias empresas, no post anterior falamos sobre o Gerenciamento de Incidentes e vimos que ele de fundamental importncia para que a avaliao da TI dentro da empresa seja boa e com isso ela consiga trabalhar de uma maneira mais confortvel, j que, um setor de TI pressionado no consegue exercer as funes adequadamente. Mas para que o setor de incidentes funcione de uma maneira satisfatria, outro processo da ITIL tem que ter um funcionamento satisfatrio tambm, estamos falando do Gerenciamento de Problemas, ele lida com os incidentes que o Gerenciamento de Incidentes no consegue resolver, pois recapitulando incidentes algo que cause uma parada em algum servio na empresa cujo a causa seja conhecida, caso a causa seja desconhecida se torna um problema e quem cuida disso o Gerenciamento de Problemas. O principal objetivo deste processo eliminar que incidentes ocorram novamente ou minimizar quando eles no so conhecidos. As fases com que se lida com um problema geralmente so as mesmas que se lida com um incidente. A primeira etapa a deteco, registro, categorizao e priorizao do problema, s que para essa etapa ser rpida e eficiente, o Gerenciamento de Incidentes tem que passar as informaes necessrias e adequadas atravs de abertura de chamado de problema, j que ele que define quando um incidente torna-se um problema, com estas informaes o Gerenciamento de Problemas detecta qual o caso real e logo aps registr-o para assim, comear a tomar as devidas aes. Nota: A maneira como fazer os procedimentos citados acima so os mesmos dos citados no post anterior. Logo aps realizar os passos acima, comea a parte de resoluo do problema, a primeira delas investigar e diagnostic-lo. Esta etapa um pouco diferente da parte do Gerenciamento de Incidentes, j que neste processo no se tem uma base do que est ocorrendo e as pessoas do as solues atravs de bases de conhecimentos externas ou atravs da vivncia na profisso.

Nesta etapa no necessariamente tem que se dar uma soluo definitiva, solues de contorno podem ser usadas para que este problema no tome propores maiores, j que, se existe um problema algo no est funcionando e precisa voltar a normalidade o mais rpido possvel. Assim que uma soluo de contorno seja encontrada, imediatamente deve ser passada ao Gerenciamento de Incidente para que eles a apliquem para mitigar os efeitos que o problema possa ter causado. Participar do projeto curso grtis! Se a soluo de contorno funcionar, ela deve ser registrada no registro do problema e colocado como uma soluo de contorno e divulgado para todos. As solues de contorno so uma boa ttica para que o Gerenciamento de Problema possa trabalhar de uma forma mais tranquila, sem a presso de ter que resolve-lo de uma forma definitiva, mas ele no elimina que o problema tenha que ser resolvido por definitivo. Porm se ela no funcionar o passo de investigao e diagnostico do problema tem que ser reinicializado at alguma soluo ser encontrada. Assim que uma resoluo for encontrado, seja ela de contorno ou definitiva, deve ser registrada na base de conhecimento, pois assim o Gerenciamento de Incidentes pode aplicar a correo sem passar para o Gerenciamento de Problemas. Se a soluo definitiva for encontrada o registro do problema deve ser fechado e feito as devidas consideraes, e relatado qual foi a causa raiz, se na implantao, se no desenvolvimento e etc. e colocar a descrio do que deve ser feito para que isso no ocorra novamente. Uma boa forma para que um Gerenciamento de Problemas possa ser feito adequadamente colocar os profissionais mais experientes neste setor, mas como estamos falando de PMEs, como j falamos bastante aqui, o principal problema a parte de Recursos Humanos, ento se voc dispe de pouco material siga o que falei cima, caso seja um EU-TI-SMO, voc vai ter que analisar e categorizar entre incidentes e problemas, uma boa dica para isso resolver os incidentes mais simples, que voc sabe que o tempo de resoluo curto e deixar os mais longos para depois, a nica exceo se o problema for de carter emergencial onde algum servio critico est parado, por isso uma boa categorizao auxiliara bastante no seu dia a dia. Agora podemos falar do ltimo processo da Fase de Operao de Servios que o Gerenciamento de Acesso, este processo est ligado ao Gerenciamento de Segurana, pois nesta etapa definido quem pode

acessar os recursos de TI da empresa definido nas politicas de segurana. Mas uma regra bsica para essa parte saber identificar e definir se a pessoa est autorizada ou no a acessar o recurso, mas muitos aqui pensam que este gerenciamento deve ser feito somente na parte de software, ou seja, somente aos sistemas, mas ele tambm lida com o acesso fsico, pois imagina voc ter um belo sistema de proteo de sistemas mas deixa o seu servidor exposto em uma sala aberta onde qualquer um pode abrir ou at mesmo roubar o mesmo, ento atentese a essa parte e caso veja que est faltando, deve ser alertado o Gerenciamento de Segurana para incluir nas politicas de segurana a parte do acesso fsico. Para implantar uma politica de acesso fsico nas PMEs, um pouco simples, pois so poucos lugares ou geralmente um s que deve ser protegido que onde fica os servidores, switchs e alguns outros equipamentos e para proteger geralmente so colocadados dentro de uma sala trancada a chave, ento como o nico modo de acesso, a chave tem que ser bem guardada. Quanto a acesso lgico em sistemas tambm deve ser levado em considerao, um sistema que no conta com nveis de segurana no um sistema confivel e se existi-los tem que ser de fcil configurao se no fica invivel a sua implementao, pois voc pode acabar perdendo tempo e configurao e deixar o seu sistema vulnervel a questo de acesso indevido. Um exemplo prtico de como pode ser usado o Gerenciamento de Acesso a questo dos Domnios de Rede, seja ele por AD ou Samba, j que eles te do a oportunidade de criar grupos de segurana e colocar dentro desses grupos os membros que podero ter acessos aos recursos necessrios, pois liberar acessos a grupos a forma mais simples de controle, pois voc libera o acesso a eles e caso precise adicionar ou retirar alguma pessoa basta ir direto nos grupos e no ao recurso em si. Este recurso to simples que vrios sistemas acabam integrando estes domnios a sua parte de segurana para facilitar a vida dos administradores de sistemas. Ento uma dica para ter uma boa implementao desse processo ter um AD ou Samba bem configurado. Bom pessoal com isso chegamos ao fim a parte dos Gerenciamento da Fase de Operao de Servio, porm nesta fase tambm existem

funes que devem ser implantadas na sua rede entre elas a funo de Service Desk e este ser o assunto do nosso prximo post at l.