No mês passado, a Microsoft lançou o System Center Service Manager (SCSM) 2012 CTP1 para os clientes listados nos testes assistidos.  Por enquanto ainda não é uma distribuição pública, por que ainda não está em Beta oficialmente, já é um primeiro ciclo de testes fora da Microsoft, com algumas empresas que se cadastraram para usar e testar o produto.

Principais características do CTP1:

• Suporte ao processo de Gerenciamento de Liberação (Release Management) com atividades paralelas;
• Enterprise Data Warehouse com Business Intelligence (OLAP);
• Suporte a notificação periódica;
• Melhoria do suporte a PowerShell;
• Melhorias de performance;
• Atualização dos conectores, com suporte aos produtos da chamada Wave 12 da família System Center;
• Suporte a relacionamento Pai-Filho no Gerenciamento de Mudanças e Liberação;

Algumas imagens do SCSM 2012 CTP1 abaixo...

Enterprise Data Warehouse e BI Analytics

• Substitui o System Center Reporting Manager (SCRM);
• Pode concentrar dados do SCCM, SCOM e SCSM para uma visão mais completa e integrada da TI;
• Possibilidade de Relatórios Self-Service com integração com o Office.
?

Gerenciamento de Liberações

• Automatiza o processo de Gerenciamento de Liberações, conforme descrito por MOF e ITIL;
• Registro de Liberação (Release Record) é um novo tipo de registro, possível de ser rastreado;
• Atividades em paralelo ou sequenciais permitem modelar processos mais complexos;
• Diagrama de Atividades (Activity Diagram) permite visualizar o fluxo de processo;
• Relacionamentos Pai-Filho permite linkar múltiplos pequenas liberações em um pacote-pai de liberação;
• Oferece importante base para o suporte a Requisição de Serviço (Service Requests) e Registros de Mudança (Change Records).

A fase de Beta público será no terceiro trimestre desse ano de 2011.  Aguardem mais notícias!

Abraços e até o próximo post,

Ronaldo Smith Jr.

Por Que um Caso de Negócio Deve Ser Escrito?

O motivo mais óbvio de escrever um caso de negócio é para formalizar os recursos, o capital necessário de investimento e o retorno esperado com o projeto.  Entretanto, isso implica em que o caso de negócio seja um documento financeiro principalmente.  Logicamente todos os casos de negócio precisam ter a justificativa financeira, mas não deve ser o único propósito do documento.

Um caso de negócio deve ser o local a armazenar todas as informações relevantes sobre a “dor de negócio” e o projeto a ser implantado.  Deve possuir justificativa de negócio, financeira, de satisfação de cliente e qualquer outra que seja necessário ser documentada.  Esse documento deve “contar a história” de porque, o que, como, quando e aonde.

• Por que o projeto é necessário?
  • Essa parte deve conter todos os problemas atuais, possivelmente justificado nos 3 pilares (pessoas, processos e tecnologia), bem como as opostunidades de melhoria.
• Como o projeto ajudará a resolver os problemas identificados pela organização?
• Qual a solução recomendada?
  • Essa parte deve propor uma solução (teoricamente, a melhor solução para os problemas identificados), bem como, se for necessário para avaliação, justificar por que essa solução foi escolhida em detrimento de outras possíveis.
• Quais os benefícios esperados?
  • Como a solução e a sua operação no dia a dia resolve os problemas identificados
  • Tente avaliar e demonstrar com estudos de simulação o impacto da solução nos 3 pilares: pessoas, processos e tecnologia.
• O que vai/pode ocorrer ao negócio se a solução não for implantada?
  • Aqui é a avaliação da opção de não se fazer nada…
• Quando a solução será implantada e os recursos necessários para tal?
  • Aqui deve-se apresentar o cronograma inicial estimado, recursos necessários, etc.
  • Quanto de investimento será necessário? Qual o prazo de investimento?
  • Grupo de pessoas envolvidas, bem como listando as responsabilidades e conhecimentos necessários.
  • Estudo de retorno de investimento e o tempo esperado.

Quais as 3 Funções de um Caso de Negócio?

A escrita de um caso de negócio força a equipe a parar, sentar e refletir sobre todo o trabalho de análise de problemas e estudo de soluções. É muito fácil para todos simplesmente continuar trabalhando, sem documentar o que foi atingido.  Eu chamo isso de “Método Nike^(*1) – Just Do It”.

O processo de documentação é muito importante e exerce papel essencial no que eu chamo de “Consolidar o Conhecimento”.  Muitas pessoas usam um termo amplamente difundido como “Captura do Conhecimento”, mas eu acho o processo de documentar algo de forma estruturada não apenas captura, mas consolida e difunde o conhecimento entre o time e também para as partes interessadas externamente ao time de trabalho.

A segunda função do Caso de Negócio é verificar que a solução proposta endereça as necessidades de negócio e se torna o veículo para receber investimentos internos e aprovação para passar para a próxima fase.  Por isso é tão importante para o time de trabalho documentar também o que pode ocorrer se o projeto não for aprovado.  Não apenas os problemas de negócio indentificados vão continuar como o cenário pode evoluir e essa evolução deve ser projetada e documentada, a fim de prover essa informação a alta administração para que a decisão seja bem embasada.

Tendo tudo consolidade em um único documento, é fácil ligar os problemas, solução e benefícios esperados.  O desenvolvimento do caso de negócio com todos esses itens facilita o desenvolvimento da justificativa financeira e pode comumente também identificar falhas e problemas não endereçados pela solução proposta.  Nesse ponto, a solução deve sder revista e verificada que endereça todos os pontos identificados durante a fase de estudo e análise.

Isso possibilita também a alta administração priorizar os projetos, já que os problemas identificados, benefícios esperados, investimento necessário, ROI e custo de não implantar a solução estão identificados e podem ser comparados com outros projetos/casos de negócio.

A outra função importante do caso de negócio é enviar uma mensagem consistente e única para todas as partes interessadas (stakeholders).  O caso de negócio é possui uma visão de alto nível sobre o problema, solução proposta e benefícios esperados, também documentando as partes afetadas da organização – clientes, gerência, operação, pesquisa e desenvolvimento, vendas, etc…).  Assim todos podem tomar conhecimento sobre o projeto.

Quem deveria escrever o Caso de Negócio?

O Caso de Negócio deve ser visto como uma história.  Logo, todos os participantes do time de trabalho devem contribuir com o seu desenvolvimento.  Não sdignifica que cada um terá que escrever um parágrafo ou um capítulo.  Simplesmente significa que o time de trabalho é responsável pelo documento e deve refletir o pensamento, as soluções propostas e o conhecimento adquirido por todo o time.

Para que o documento tenha um formato e estrutura consistente e coerente, apenas uma ou duas pessoas devem efetivamente escrever o documento, mas, de acordo com a forma de trabalho, todos podem revisá-lo e sugerir alterações no mesmo.

Quando um Caso de Negócio deve ser Escrito?

O ciclo de vida de um projeto, de acordo com a metodologia MSF – Microsoft Solutions Framework possui 5 fases, a saber:

O MSF atualmente está inserido no MOF – Microsoft Operations Framework, como a Fase Entregar (Deliver Phase).  Para mais detalhes e explicações sobre a Fase Entregar do MOF, veja o documento MOF 4.0 Overview.

O Caso de Negócio precisa da Fase de Visão e Escopo concluída para que possa ser feito. Assim, todas as necessidades, problemas e cronograma estimado já estão concluídos e podem ser inseridos no documento de Caso de Negócio.  Em alguns casos, dependendo do nível de análise necessário e exigido pela alta administração, um pouco da fase de Especificação pode ser necessário também para que a solução seja mais clara e possa dar uma maior garantia aos aprovadores do projeto.

Visão Geral

Enquanto um dos seus principais objetivos possa ser (e deve ser!) conseguir investimento para o desenvolvimento e implantação do projeto, suas chances de sucesso podem ser maiores se os seguintes objetivos também estiverem em mente:

• Torne o documento interessante.  Lembre-se, alguém irá lê-lo e não pode ser um convite ao sono…
• Mantenha-o claro e conciso. Vá direto ao ponto, um documento de Caso de Negócio não é um romance nem uma novela…
• Minimize o uso de jargões e termos muito técnicos e específicos.  Quem vai ler (e aprovar!) não necessariamente entende de tecnologia nem de Gestão de Serviços de TI…
• Documente todos os fatos como parte da história do projeto.  Essa é a hora de mostrar que o time de trabalho fez um trabalho completo e consistente…
• Forneça uma visão completa da situação atual e da situação proposta.  Tente colocar mais gráficos e figuras ilustrativas do que textos longos e complexos…
• Finalmente, demostre o valor do projeto para a operação, para os clientes e para a parte financeira da empresa.

Os benefícios esperados em escrever (documentar) um Caso de Negócio podem ser vários, mas posso citar, no mínimo:

• Organização do pensamento, atividades e conhecimento.
• Captura e consolidação do conhecimento adquirido.
• Habilidade em identificar gaps, inconsistências ou falhas de projeto.
• Melhoria na habilidade de comunicar os objetivos do projeto e seus benefícios.
• Justificativa financeira em linha com os beneficios esperados.
• Senso de união e trabalho em time.

Bem, espero que o texto tenha sido útil.

Abraços e até o próximo post.

Ronaldo Smith Jr.

Gostaria nesse retorno de falar sobre COBIT. Muitas pessoas, quando escutam o termo Governança de TI, pensam diretamente em COBIT. Acham que simplesmente devem implantar COBIT, normalmente por intermédio de uma consultoria, e pronto! Mas, infelizmente, não é tão simples assim.

Como já disse em outros posts, Governança de TI é a formalização do processo de gestão e direcionamento futuro, processos de aprovação, níveis de poder decisório e etc. Isso não é simplesmente implantar um framework, muito menos alguma ferramenta.

Bem, de qualquer modo, COBIT ajuda muito a direcionar o controle da TI. Então vamos falar um pouquinho sobre isso.

1. Qual é a finalidade do COBIT?

A finalidade do COBIT é fornecer aos gerentes e donos de processos de negócios um modelo de governança de TI que ajude em entregar valor com TI e compreender e gerenciar os riscos associados a TI. COBIT ajuda a preencher as lacunas entre requisitos de negócios, necessidades de controle e problemas técnicos. É um modelo de controle para suportar as necessidades de governança de TI e tem como objetivo garantir a integridade das informações e sistemas de informação.

2. Quem está usando o COBIT?

COBIT é usado amplamente por aqueles que têm responsabilidades em processos de negócios e de tecnologia, aqueles que dependem de uma TI relevante, confiável e controlada.

3. Quem são os donos de processos?

COBIT é orientado a processo de TI e, portanto, destina-se em primeiro lugar para os proprietários desses processos, os responsáveis por eles. Referindo-se ao Modelo de Negócios Genéricos de Porter, processos principais (por exemplo, contratos, operações, marketing, vendas) são discutidos, bem como processos de suporte (por exemplo, recursos humanos, administração, tecnologia da informação). Como consequência, COBIT não limita-se apenas a ser aplicado pela TI, mas para o negócio como um todo.

Essa parte, inclusive, se refere a um outro post que fiz “Existe Governança de TI sem Governança Corporativa?”

Essa abordagem resulta do fato de que os donos dos processos são responsáveis pelo desempenho dos mesmos, dos quais IT tornou-se parte integrante e imprescindível. Em outras palavras, eles são mais importantes, mas também devem ser responsáveis pelo seu funcionamento. Como consequência, donos de processos de negócios têm responsabilidade sobre a tecnologia implantada dentro dos limites do seu processo de negócios. Claro, eles vão fazer uso dos serviços fornecidos pelas partes especializadas como a TI tradicional ou serviços terceirizados.

COBIT fornece aos donos de processos de negócios um quadro de controle geral, incluindo as partes de TI relevantes ao funcionamento do referido processo de negócio. Como resultado natural, passa a existir o tão falado “alinhamento de TI e negócio”, por que a parte implantada de TI é exatamente o que o processo de negócio precisa.

4. Por que a orientação do COBIT está voltada para o processo, e não para funções ou aplicações?

O framework do COBIT foi estruturado em 34 que processos de TI de atividades inter-relacionadas. O modelo de processo foi preferido por várias razões. Em primeiro lugar, um processo por sua própria natureza é orientado a resultados, por que tem foco no resultado final, tentando sempre otimizar o uso de recursos (receber mais, usando menos). Em segundo lugar, um processo, especialmente seus objetivos, é mais permanente na sua estrutura de funcionamento e não muda tanto como uma entidade organizacional. Em terceiro lugar, a implantação de TI não pode é restrita a um único departamento e deve envolver usuários, gerentes, bem como especialistas em TI. Neste contexto, o processo de TI permanece como denominador comum – o resultado necessário do processo ainda deve ser atingido.

Para COBIT, aplicativos são tratados como um dos quatro recursos existentes. Portanto, eles devem ser controlados e otimizados a fim de entregar o resultado necessário do processo de negócios.

5. Por que há sobreposição nos objetivos de controle?

A sobreposição nos objetivos de controle, embora não ocorra com frequência, foi intencional. Alguns objetivos de controle transcendem a domínios e processos e, portanto, devem ser repetidos para garantir que eles existem em cada domínio ou processo necessário. Alguns objetivos de controle devem ser os controles cruzados entre si e, portanto, devem ser repetidos para garantir a aplicação consistente em mais de um domínio ou processo.

6. O COBIT tem três dimensões de maturidade. O que elas significam?

As três dimensões são capacidade, cobertura e controle. Elas podem ser usadas ao avaliar a maturidade de um determinado processo de TI em uma situação específica. A aplicação destas dimensões é deixada para que o avaliador/implementador do COBIT decida se e como serão usadas, dependendo do detalhamento necessário da avaliação em curso.

Capacidade é o nível de maturidade necessário para o processo atender às necessidades de negócios (idealmente conduzidos por objetivos de TI e negócio claramente definidos).

A Cobertura é uma medida de desempenho, ou seja, como e onde o recurso precisa ser implantado com base na necessidade dos negócios e as decisões de investimento com base em custos e benefícios. Por exemplo, um alto nível de segurança deverá estar voltado apenas para os sistemas corporativos mais relevantes...

Controle é uma medida de controle real e execução do processo, na gestão de riscos e sobre a entrega efetiva de resultado dos processos de negócio. COBIT fornece um modelo de maturidade genérico para controle interno e os processos PO6 e ME2 podem ajudar a institucionalizar a necessidade de bons controles.

Resumo…

Em resumo, o COBIT tem o objetivo de ser um framework de controle de processos de TI e de negócio, mas deve ser implantado em fases, e com a clara visão de que o COBIT isoladamente não resolve nem institui a Governança de TI. Governança de TI deve ser um processo permanente e gradual de definição e implantação.

Obrigado e até o próximo post,

Ronaldo Smith Jr.

É possível?  Tecnicamente sim, embora, na minha opinião, não creio que seja muito útil.

Sabemos que, atualmente, as organizações precisam controlar de forma mais precisa seus principais ativos. O bom uso de padrões e melhores práticas de mercado ajuda a agilizar e facilitar a efetividade desse controle. Mas se a organização não toma suas decisões estratégicas aplicando algum padrão, como fazer isso a partir da TI?  Se o processo de tomada de decisão é centralizado e sem formalização para a priorização e autorização de investimentos e foco de negócio, como fazer isso apenas com a TI?

O Que é Governança de TI?

Governança de TI é uma atividade em nível gerencial que, quando bem executada, ajuda a clarificar quem tem a autoridade para tomar decisões, determina a responsabilidade de ações e ajuda a definir como o desempenho será avaliado. Muitas organizações tentam endereçar Governança de TI através da criação de comitês executivos que tragam as pessoas com poder de decisão para um mesmo fórum.

Segundo a definição do ITGI (IT Governance Institute), Governança de TI é “a capacidade da organização em controlar o planejamento e a implementação da estretégia de TI e dar direção de novos rumos e investimentos a fim de atingir vantagem competitiva para a companhia”.

Governança em nível organizacional resulta, entre outras coisas, em resultados positivos e crescimento esperado, aumento de satisfação dos clientes, novos produtos e desenvolvimento de mercado – todas as áreas que TI pode contribuir significativamente quando os esforços de governança são coordenados.

A imagem abaixo mostra também a diferença entre Governança de TI e gerenciamento de TI.  Governança de TI tem a preocupação de direcionar o futuro, as decisões de investimento e etc baseado em informações principalmente do mercado e novas oportunidades.  O gerenciamento tem a preocupação de garantir a execução correta do planejamento estratégico feito anteriormente.

Vou tentar falar mais resumidamente ainda: governança é poder com controle.  Logicamente, o ser humano não aplica controles aonde não acha necessário. Isso faz parte de um processo de gerenciamento de riscos, que pode ser apressado ou priorizado por fatores externos.

Agora podemos voltar à pergunta inicial: é possível implementar Governança de TI sem Governança Corporativa?  Uma empresa média, com gestão familiar, sem uma governança corporativa instaurada vai ter algum ganho (verá algum valor) na implantação de Governança de TI?

Governança de TI e Governança Corporativa

As questões típicas de Governança Corporativa são:

• Como os financiadores se asseguram de que os gestores vão dar retorno de seus investimentos?
• Como os financiadores se asseguram de que os gestores não vão expropriar o capital que investiram ou investir em projetos ruins?
• Como os financiadores controlam os gestores?

Tais perguntas podem ser desdobradas para outras áreas da organização, tornando-se mais específicas e mantendo o alinhamento com a Governança Corporativa.  Essa empresa média, sem distinção entre financiadores, gestores e acionistas passa por essas questões?  Eu acho que não.  As decisões são tomadas pelo controlador majoritário, e a prioridade de investimento é de acordo com o sentimento de necessidade.  Em geral, as ações são reativas de acordo com o direconamento de mercado, ao invés de investir em novos mercados.

Não existe um processo formal de tomada de decisões e escalação de poderes, por que a empresa não é tão grande e o tomador de decisões é o próprio controlador, financiador e gestor…

Questões equivalentes às listadas acima, quando o foco é Governança de TI podem ser as das tabela abaixo:

Conclusão

A Governança de TI deve ser vista como parte da Governança Corporativa e deve oferecer as estruturas organizacionais que permitam a criação de valor ao negócio através da TI, a garantia que não é feito investimento em projetos que não estejam alinhados com o objetivo do negócio e que os mecanismos de controle e gestão da TI estejam implantados adequadamente.

Existem várias metodologias, como por exemplo, BSC – Balanced Scorecard, COBIT – Control Objectives for Information and related Technology, ITIL – IT Infrastructure Library, MOF – Microsoft Operations Framework.

Essas metodologias combinadas podem ser usadas como um mecanismo de medição e gerenciamento sistêmico poderoso para suportar a implantação dos processos de Governança de TI e o necessário alinhamento entre TI e negócio, quando necessário esse controle explícito.

Abraços e até o próximo post,

Ronaldo Smith Jr.

O System Center Operations Manager (SCOM) 2007 é o produto de gerenciamento de serviços de ponta a ponta que ele funciona perfeitamente com a Plataforma Microsoft e aplicações, ajudando as empresas a aumentar a eficiência, permitindo maior controle do ambiente de TI.

O System Center Operations Manager fornece gerenciamento de serviço de ponta a ponta que é fácil de personalizar e estender para melhores níveis de serviço em seu ambiente de TI.  Isso permite operações e gerenciamento de equipes para identificar e resolver problemas que afetam a saúde dos serviços de TI.  Gerenciamento de serviços de ponta a ponta não está restrito a ambientes baseados em Microsoft.  O SCOM 2007 também suporta o WS-Management, SNMP (Simple Network Management Protocol) e soluções de parceiros que permitem que hardware e sistemas não-Microsoft possam ser incluídos no serviço de monitoramento fim-a-fim.

Vou aqui fazer uma compilação das várias atualizações liberadas pela Microsoft para o System Center Operations Manager (SCOM) 2007.

Dentre as liberações, existem pacotes de atualização para o SCOM 2007 e também para o SCOM 2007 R2.

SCOM 2007 R2 Cumulative Update 1

O SCOM 2007 R2 Cumulative Update 1 tem quase 85 MB de correções que você pode fazer o download aqui. A ordem de atualização sugerida é:

1. Root Management Server
2. Management Server
3. Gateway Server
4. Operations console
5. Web Console server
6. Agent (que haviam sido instalados manualmente)
7. Audit Collection Service (ACS)

Se um servidor possuir mais que um dos componentes citados acima, a atualização deve ser feita apenas uma vez, por exemplo. Se eu tenho apenas 2 servidores formando meu Management Group, um como a Base de Dados e o Reporting Services e o outro com o RMS, ACS, Web Console, vou fazer a instalação apenas duas vezes. Os agentes instalados pela console serão atualizados pela console.

SCOM 2007 R2 Cumulative Update 2

O SCOM 2007 R2 Cumulative Update 2 já possui todas as correções do Cumulative Update 1 (ou seja, você não precisa instalar o primeiro pacote e depois instalar o segundo) e mais algumas correções, como apresentação do nome do dispositivo na View de Network Devices State, problemas de apresentação resolvidos nos relatórios exportados em PDF e TIF, etc.

O download desse pacote de atualizações pode ser feito aqui.

SCOM 2007 SP 1 (Service Pack 1)

O SCOM 2007 SP1 ajuda a melhorar a eficiência e dar maior contrrole sobre o seu ambiente de TI.  Com o SP1 existem novas funcionalidades habilitadas, assim outros cenários são suportados oficialmente pela Microsoft.

As melhorias incluem:

• Melhoria de performance da console
• Aumento dos limites de escalabilidade
• Suporte a solução de Recuperação de Desastres para todas as funções do SCOM 2007

O download do SCOM 2007 SP1 pode ser feito aqui.

Mais detalhes sobre esse Service Pack, pode ser encontrado aqui.

SCOM 2007 SP1 Cumulative Update 1

Sim, agora vou falar sobre a atualização do SCOM 2007 SP1.  Não é a mesma coisa que as atualizações citadas acima, já que elas são para o SCOM 2007 R2.  O SCOM 2007 R2 não é um pacote de atualização do SCOM 2007.  É um produto diferente, um Release 2 mesmo, que envolve até licenciamento diferente.  Logo, não pode ser assumido que todos que estão utilizando o SCOM 2007 irão utilizar o SCOM 2007 R2.  Por isso a Microsoft ainda continuará a lançar atualizações para o SCOM 2007, entre elas, o Cumulative Update 1 para o Service Pack 1 do SCOM 2007.

O pacote lançado tem 21 MB de atualizações e pode ter o download feito aqui.

Note que esse pacote de atualizações é para o SCOM 2007 SP1, então a instalação prévia do Service Pack 1 é necessária para que possa ser instalado esse Cumulative Update 1.

Os detalhes sobre esse pacote de atualizações pode ser encontrado aqui.

Referências

• Cumulative Update 1 for System Center Operations Manager 2007 SP1 (KB 2028594)
• Description of System Center Operations Manager 2007 Cumulative Update 1
• Cumulative Update 2 for System Center Operations Manager 2007 R2 (KB 979257)
• System Center Operations Manager 2007 R2 Cumulative Update 2 Release Notes
• Cumulative Update 1 for System Center Operations Manager 2007 R2 (KB974144)
• System Center Operations Manager 2007 R2 Cumulative Update 1 Release Notes
• Blog do time de SCOM
• Página Web da Família System Center
• System Center Operations Manager Overview white paper

Abraços e até o próximo post,

Ronaldo Smith Jr.

Numa linha diametralmente oposta a essa, tem o pensamento que a área de TI é *sim* diferencial de negócio e deve dar total suporte às ofertas da organização para o mercado, ou seja, faz parte do negócio e não deve apenas ficar alinhada ao mesmo.  Podemos veer o artigo “IT Doesn’t Matter – but only at Harvard”, de James Champy, como uma das primeiras reações ao artigo mencionado acima.

Vamos voltar um pouco e analisar cada uma das teorias?

Teoria 1: TI é um Centro de Custos e não deve ser Alinhada ao Negócio

No caso de Nicholas Carr, um conceituado professor e ex-editor da revista Harvard Business Review, a linha de pensamento é que gastar muito em TI para tentar se diferenciar é um lugar comum.  Todas as empresas estão indo nessa direção.  O que ele sugere é que TI é commodity e deve-se buscar:

• Menor gasto;
• Siguir um padrão estabelecido, não deve-se tentar liderar, criar novas idéias;
• Focar em gestão de riscos e não em novas oportunidades.

Plummer, do Gartner, reforça essa teoria ao comparar TI a uma lavanderia: “você não alinha a sua vida à loja que lava suas roupas”.

OK, desde o final dos anos 80 (1980), ITIL, e mais recentemente MOF, diz que TI entrega um serviço ao seu cliente e não um produto.  Mas isso não quer dizer que esse serviço é totalmente básico e igual em todos os lugares (para ser considerado commodity).  Uma commodity tem características básicas e igualmente fornecido por qualquer um dos fornecedores, por isso o preço das commodities não variam entre os fornecedores.  Se um determinado fornecedor quiser cobrar mais pelo preço da tonelada do minério de ferro, pode-se comprar no outro fornecedor sem problema algum, por que os produtos fornecidos serão muito equivalentes.

TI é Realmente uma Commodity?

Na minha opinião, não.  TI não é uma commodity, mas um grande diferencial de negócio! Pode ser que os equipamentos de rede, hardware e comunicação sejam.  Sim, links de comunicação ou ainda servidores HP ou DELL basicamente são equivalentes.  Mas a áre de TI de uma organização não fornece apenas isso aos usuários. Na verdade, isso deve ter sido também na década de 80 apenas…

Atualmente a TI pode e deve oferecer serviços personalizados, configuráveis e confiáveis, de acordo com a necessidade do cliente e da organização.  Não se pode pensar que a área de TI pode ser facilmente substituída por completo por uma outra área de TI ou por fornecedores.  Isso não ocorre da noite para o dia e também, quando há terceirização “completa”, o terceiro herda os serviços já configurados, sistemas e etc.  TI não é uma commodity!  As várias organizações de TI não fornecem os mesmos serviços, não possuem os mesmos SLAs, nem os mesmos requerimentos de negócio.

Ao mesmo tempo, alguns serviços são básicos e bem padronizados, como o de correio eletrônico e nesse caso podem ser “commoditizados”, correto?  Por isso existem várias ofertas de Cloud Computing (Computação nas Nuvens) que oferecem esse serviço.  Por exemplo, a Microsoft oferece o BPOS – Business Productivity Online Suite.

Teoria 2: TI é Diferencial Comercial e Agrega Valor ao Negócio?

Nem sempre.  E também não é em todas as organizações…  Mas deve-se caminhar nesse sentido.

É preciso definir bem os riscos envolvidos, definir quais os benefícios esperados e também os níveis de serviço necessários.  A partir disso, deve-se trabalhar no sentido de cumprir os acordos estabelecidos e entregar valor ao seu cliente (o negócio).  A automação dos serviços necessários (e diferenciados daquela organização) será feita apenas com um trabalho sério e profundo de gestão de TI e das expectativas dos clientes e resultados alcançados.

Mapeamento dos processos de negócio, automação e capacitação de pessoal devem ser as maiores e mais importantes iniciativas de uma área de TI para aumentar a sua maturidade e efetividade junto ao negócio.

Eu prefiro comparar TI a área de Marketing, ao invés da área de Contabilidade.  Na área de marketing, quando há um lançamento de produto ou serviço novo de uma empresa, cria-se um “projeto”, times de trabalho e começa-se a desenvolver aquela idéia, com estudos de mercado, resultados esperados e etc…  As teorias de marketing todos sabem, mas qual CEO teria coragem de terceirizar á própria área de marketing?  É uma área chave para o diferencial da empresa.  A área de TI é a mesma coisa.  Tem suas teorias e produtos e serviços básicos, mas deve participar ativamente da criação e diferenciação dos serviços de TI para o novo produto ou serviço da empresa.  Somente com essa diferenciação baseada na agilidade e capacidade de automação da TI que pode-se ter sucesso num mercado tão competitivo.  Quem pode dizer que os Internet Bankings dos bancos brasileiros são iguais?  Em alguns não se consegue fazer operações que podem ser feitas em outros.  E isso, eu garanto, é fator decisivo para manutenção ou atração de clientes.  Eu sou um exemplo vivo disso: acabei de deixar de ser clilente de banco por que o Internet Banking não me permitia fazer certas operações que faço em outro banco…  Bem vindo ao mundo no qual a TI *é* um diferencial de negócio!

O que você acha?  Qual a sua opinião sobre a posição de TI?  TI é uma centro de custo, assim como contabilidade, ou contas a pagar e receber?  Ou TI é uma área chave de diferenciação para o negócio, assim como o marketing? O que achou do caso Internet Banking ou algum outro exemplo de serviço que é fortemente baseado em TI? Tem algo a compartilhar? Deixe o seu comentário…

Abraços e até o próximo post,

Ronaldo Smith Jr.

A ISACA – Information Systems Audit and Control Association, fundada em 1967, é uma associação internacional formada por profissionais que atuam nas áreas de Auditoria de Sistemas, Segurança da Informação e, principalmente, de Governança de TI. Atualmente, os associados da ISACA são mais de 50.000 em todo o Mundo, em mais de 140 países e atuam em diferentes posições relativas à Tecnologia da Informação (Auditores de Sistemas, Consultores, profissionais de Segurança da Informação, CIO’s, Auditores Internos, dentre outros).  A ISACA é patrocinadora, por exemplo, do COBIT – Control Objectives for Information and related Technology.

O EXIN – Examination Institute for Information Science é um instituto global independente que tem como objetivo certificar pessoas e/ou instituições em áreas de TI através de exames. Tem em sua missão melhorar a qualidade do setor de TI, dos profissionais de TI e dos usuários.  O EXIN aplica, entre outras, certificação de ITIL, MOF, ISO 20000, ISO 27000, etc…

O DRII — Disaster Recovery Institute International, fundado em 1988, é o maior instituto de capacitação e formação de profissionais em Continuidade de Negócios e Recuperação de Desastres do mundo, com base em Washington — EUA. Atua em mais de 100 países tendo formado cerca de 30 mil profissionais em todo o mundo.

Links sobre o evento:

• http://www.isaca.org.br/boletim/2010/Boletim04-2010-maio.htm 
• http://grc-inter.com/ 

Abraços e até o próximo post,

Ronaldo Smith Jr.

Os envolvidos no planejamento, entrega e operação desses serviços de TI devem ser capazes de:

• Compreender as necessidades operacionais e de negócio para os serviços e criar uma solução que resolva a necessidade de negócio, respeitando a arquitetura corporativa e as necessidades e limitações operacionais;
• Entregar os serviços aos usuários e clientes capazes de prestar o serviço dentro dos níveis de serviço acordados;
• Operar a solução com excelência e qualidade de modo a entregar um serviço no qual os clientes e usuários possam confiar.

A melhor forma de atingir aos objetivos listados acima é garantir que as responsabilidades estejam mapeadas com os papéis e times de trabalho.

Organização em Times de Trabalho

Todos que executam uma tarefa ou atividade associada a um serviço deve ter claramente definido seu papel, entender suas responsabilidades e possuir a capacitação correta para cumprir essas responsabilidades.

Embora algumas responsabilidades possam variar dependendo da área de TIC e da indústria de atuação da organização, existem algumas responsabilidades básicas que podemos mapear, a saber:

• Suporte, que é associada a fase Operar do MOF e responsável pelo atendimento ao usuário e correção de incidentes e problemas dos serviços;
• Operação, que é associada a fase Operar do MOF e responsável pela correta operação da produção e cumprimento dos OLAs acordados;
• Serviço, que é associada a fase Planejar e responsável pela definição dos serviços e seus níveis de entrega;
• Arquitetura, que é associada a fase Panejar do MOF e responsável pela definição da arquitetura de TIC;
• Soluções, que é associada a fase Entregar do MOF e responsável pelo desenvolvimento de novos serviços ou atualização dos existentes;
• Gerenciamento, que é associada a camada Gerenciar do MOF e tem a responsabilidade de garantir a gestão dos times de TIC e controles internos.

A separação do time de trabalho em papéis e responsabilidades é necessária para que todos saibam quem é responsável a fazer o que. Isso ajuda a:

• Evitar erros de entendimento sobre quais tarefas devem ser desempenhadas por quem;
• Evitar tarefas sem alguém para executá-las;
• Clarificar o entendimento sobre papéis e responsabilidades de toda a organização de TI;
• Alinhar responsabilidades; e
• Assinalar tarefas.

Uma correta separação de papéis e responsaabilidades demonstra como construir e manter um time que é:

• Focado em execução: garantindo que as tarefas necessárias são executadas;
• Responsável: tem a responsabilidade de responder pelas tarefas e serviços sob sua coordenação;
• Flexível: construído sobre times físicos e virtuais para responder a determinadas responsabilidades; e
• Escalável: capaz de atender às necessidades dos diferentes serviços e demandas da organização.

Service Level Agreements (SLAs)

Um passo importantíssimo para entregar o valor esperado pelos clientes com os serviços de TI é garantir que exista um acordo de nível de serviço, planejado por todas as áreas de TI bem como com o cliente final. Logicamente não basta existir um SLA, ele deve ser cumprido, mas o fato de existir algum SLA já é o primeiro passo, por que significa que o mesmo foi discutido dentro da área de TI bem como com o cliente.

O SLA é útil para garantir que os serviços entregues atendem às expectativas de negócios, as metas de desempenho e os custos necessários para a entrega de um determinado serviço de TIC a um conjunto de clientes. Um SLA eficaz reflete a comunicação entre os clientes e usuários (os consumidores do serviço) e deverá traduzir-se na tabela de indicadores. Os objetivos de nível de serviço que são identificados, em seguida, serão usados para desenvolver e personalizar o scorecard de aderência para o serviço.

O SLA deve ser balanceado entre ser relevante e factível. Em geral, a disponibilidade desejada por todos é de 100%, mas isso, infelizmente, é irreal. O SLA deve conter um objetivo relevante a ponto de atingir o nível de serviço realmente necessário e exigido pelo negócio, mas também deve ser possível de ser entregue, não pode conter premissas ou promessas irreais.

Um SLA deve possuir a descrição e definição, em linguagem clara para o cliente, de todos os pontos importantes sobre o serviço de TIC. Por exemplo, descrição do serviço, seus requerimentos, necessidades de dados de entrada, saídas esperadas, horários de funcionamento do serviço, tempos de atendimento ao usuário em caso de problema, disponibilidade total esperada, tempo de retorno em caso de indisponibilidade, etc.

Cálculo de Disponibilidade

Um dos pontos mais comuns de ser descrito em um SLA é a disponibilidade esperada do serviço. Um indicador comum usado para medir a disponibilidade é o percentual de tempo que um serviço foi capaz de servir aos seus clientes e usuários.

• Percentagem de disponibilidade = Tempo Total em Serviço / Tempo Total Esperado em Serviço

No caso de um serviço que é esperado que funcione 24 x 7, o tempo total esperado, no ano, é de 24 horas x 365 dias = 8760 horas.

Em geral, a disponibilidade desejada por todos é 100%, mas isso, infelizmente, é irreal. Num caso mais realista, a disponibilidade nos SLAs é medida em “noves”, ou seja, quantos “noves” no percentual são esperados. Um serviço que é esperado “3 noves” deve ter disponibilidade de 99,9%.

A tabela abaixo mostra os cálculos de disponibilidade em relação a um serviço 24x7, com base anual.

% Disponibilidade	Horas Totais no Ano (24x7)	Tempo máximo de indisponibilidade	Horas Totais no Ano (8x5)	Tempo máximo de indisponibilidade
90%	8760 horas	876 horas (36,5 dias)	2086 horas	208.6 horas (26 dias)
95%	8760 horas	438 horas (18,3 dias)	2086 horas	104 horas (13 dias)
99% (2 noves)	8760 horas	87 horas (3,6 dias)	2086 horas	20,86 horas (2,6 dias)
99,9% (3 noves)	8760 horas	8,76 horas	2086 horas	2 horas
99,99% (4 noves)	8760 horas	52,56 minutos	2086 horas	12,5 minutos
99,999% (5 noves)	8760 horas	5,3 minutos	2086 horas	1,25 minutos

Como pode ser reparado na tabela de tempos de indisponibilidade, o tempo máximo aceitável de indisponibilidade é alterado com a alteração do tempo total esperado de serviço (janela de funcionamento do serviço). No caso de um serviço em horário comercial (8x5), uma queda do sistema durante a madrugada, com o serviço voltando a funcionar antes ainda do horário comercial não afeta o cálculo de disponibilidade para efeitos do SLA, por que o serviço não tinha a obrigação de funcionar fora da sua janela estipulada.

O que deve ser considerado para confecção de um SLA?

A Microsoft recomenda considerar os seguintes pontos quando da criação e manutenção de SLAs e medições de disponibilidade:

• Necessidades reais de negócio – Os custos de alcançar maior disponibilidade podem não valer a pena considerando os benefícios reais necessários. Analise a real disponibilidade de serviço de TIC que sua empresa realmente precisa antes de definir metas. Ter sempre meta de 24x7 com 99,999% de disponibilidade pode ser desejável para todos os serviços, mas obriga um enorme investimento em pessoas, processos e tecnologia a fim de atingir esse nível e poucos serviços realmente precisam disso.
• Correta granularidade – Um sistema de TI, seja qual for, tem múltiplas medições e monitorações de disponibilidade, e não simplesmente funcionando e parado. Partes distintas podem estar funcionando enquanto outras podem ter algum problema de disponibilidade. Uma regra simples, clara e justa deve ser alcançada para que o cálculo não seja mais custoso que a informação resultante deste.
• Responsabilidade e Cobrança – uma pessoa ou time deve ser responsável por cada medição, e deve ser garantido poder de decisão necessário para que seja feito o que é necessário para controlar o serviço e respeitar os SLAs.
• Riscos Ordinários e Extraordinários – Falha de disco ou memória, bem como rede e falta de energia são riscos ordinários, previsíveis, que são parte do cotidiano. Você sabe que os enfrentará mais cedo ou mais tarde e deve se planejar para quando isso ocorrer. A maior probabilidade de indisponibilidade pode ser tratada analisando e previnindo riscos ordinários.
  O tipo de planejamento a ser feito para riscos extraordinários é bem diferente e deve inclusive levar em conta risco de perda de pessoal e instalações. São eventos mais raros e especiais, mas que devem ser avaliados se vale a pena prevení-los ou apenas conhecê-los e preparar reação em caso de ocorrência. Isso vai depender do custo da prevenção e também da quantidade e importância dos recursos envolvidos pelo risco.
• Escopo e tolerâncias – métricas rígidas e absolutas podem trazer mais malefícios do que benefícios. Atritos entre áreas, avaliações e auditorias no cálculo do SLA e outros fatores podem ser resultados de intolerâncias. Em geral, recomenda-se trabalhar com médias e desvio padrão para cálculos de indicadores de SLA.
• Mensurabilidade – cada item do SLA deve ter um indicador e meta determinada. O SLA deve ser oficializado em cima de valores trangíveis e objetivos, nunca sobre avaliações pessoais e subjetividade. Termos como “melhor”, “mais disponível”, “total”, etc. devem ser evitados, dando-se preferência para “10% de melhoria a cada ano”, ou ainda, “99% de disponibilidade claculada sobre a fórumula XXX =YYY / ZZZ”.
• Margens de Erro – um outro aspecto da capacidade de medir algo é a margem de erro de medição. Por exemplo, a Microsoft possui dezenas de Active Directory Domain Controllers e Exchange Servers espalhados pelo mundo em diversos datacenters. Sincronização de horário entre todos os serviodres pode levar um certo tempo e ainda assim acontecer com pequenas diferenças de horário. Uma mensagem de ping pode ter o seu horário de chegada, visto por um servidor, milisegundos antes do seu horário de saída. Sabemos que isso é impossível, logo deve-se ao fato de sincronização e outros detalhes inerentes a distribuição e às margens de erro de medição. As objetivos de nível de serviço não devem ser tão pequenos e precisos que sejam da mesma ordem de grandeza que a margem de erro de medição.

Reunião de Revisão de Nível de Serviço

Conduzir uma reunião regular de Revisão de Nível de Serviço é uma forma importante de entender o estado atual do serviço. A revisão frequente dos dados atingidos mantém o foco de trabalho nos mais importantes indicadores de negócio, bem como pode alertar com boa antecedência para eventuais desvios aos objetivos dos SLAs.

Após a documentação e formalização do serviço do SAJ com mapa de serviço, SLAs, OLAs, e a tecnologia totalmente revisada e corretamente configurada, a manutenção dos níveis de serviço requerem criação de:

• Procedimentos operacionais para todos os componentes do serviço, a fim de garantir que todas as engrenagens estão funcionando corretamente, e de suporte, a fim de garantir que o atendimento ao usuário está sendo feito conforme o acordado no SLA;
• Disciplina e comprometimento do time a fim de colocarem em prática uma reunião de Revisão de Nível de Serviço com frequência mínima quinzenal.

Bem, espero que as informações discutidas aqui possam ajudar o entendimento da função de Gerenciamento de Nível de Serviço, possibilitando a área de TI entregar serviços de TI com mais qualidade, agregando valor ao cliente.

Abraços e até o próximo post,

Ronaldo Smith Jr.

No MMS 2010 (Microsoft Management Summit 2010) foi confirmada uma notícia esperada por tantos: o System Center Service Manager (SCSM) 2010 é RTM. E mais, foi confirmada que a data de disponibilização para o público é 1/Jun/2010.

Na verdade, o SCSM já está com a versão RTM fechada a algumas semanas, mas o anúncio oficial desse marco no ciclo de desenvolvimento foi deixado para ser feito no MMS…

Vários usuários e empresas já estão testando o SCSM 2010 em suas versões Beta e RC e, de forma geral, estão entusiasmados com a sua integração e facilidade de implementação.

O que o Service Manager oferece?

O SCSM 2010 se propõe a automatizar os processos de gestão de serviços de TIC, principalmente focado em Gerenciamento de Incidentes, Problemas, Configuração e Mudanças. Ou seja, para quem pergunta como posso automatizar os principais processos de ITIL e MOF?  O SCSM é o caminho!

Através da sua base de dados de configuração (CMDB – Configuration Management Database) e integração de processos, o Service Manager 2010 automaticamente conecta e integra conhecimento e informação do System Center Operations Manager (SCOM), System Center Configuration Manager (SCCM) e Active Directory Domain Services (ADDS).

O Service Manager oferece os seguintes benefícios:

• Suporte com foco no usuário – Através de um portal de Suporte Self-Service, possibilita reduzir custos com suporte enquanto aumenta a agilidade de resposta para os usuários.
• Eficiência de gerenciamento de Datacenter – Reduz o tempo de downtime e aumenta a confiabilidade através da integração do CMDB e Pacotes de Gerenciamento (Management Packs).
• Alinhamento de Negócio – Ajuda a organização a se alinhar com as necessidades de negócio da organização através de gerenciamento de ativos, conformidade e risco, automatizando os relatórios e análises.

Download da versão Trial

O site para download de produtos de avaliação da Família System Center é: http://www.microsoft.com/systemcenter/en/us/default.aspx#download-trials.

Não deixe de conferir a versão de teste do System Center Service Manager 2010, que pode ser acessado diretamente pelo endereço aqui.

Mais Conteúdo…

O site oficial do System Center Service Manager é:
http://www.microsoft.com/systemcenter/en/us/service-manager.aspx

Whitepapers:

• Orchestrating People, Process, and Technology
• Efficient and Responsive Support for End Users
• Driving Efficiency and Reliability in the Data Center

Demos:

• Managing Applications with Service Maps in Service Manager 2010
• Service Manager 2010-Self Service Portal Feature
• Managing Compliance with Service Manager 2010

Blog Oficial do Service Manager 2010:

• Service Manager blog and forum

Eu recomendo a leitura do post do Blog do Brad Anderson entitulado “MMS 2010 Kicks Off in Las Vegas”.

Laboratório Virtual do TechNet (TechNet Virtual Labs):

• Em breve estarão disponíveis labs do SCSM 2010 no seguinte endereço - http://technet.microsoft.com/en-us/systemcenter/bb539977.aspx

Abraços e até o próximo post,

Ronaldo Smith Jr.

No dia 18/jan/2010 coloquei um post sobre o lançamento, na época em Beta, do Guia sobre Revisões de Gerenciamento em MOF (MOF Management Reviews).  Esses documentos fazem parte do conjunto de guias sobre como aplicar os conceitos de MOF no dia a dia das organizações.

Em toda organização, a gerência é responsável por estabelecer metas, avaliar o progresso e garantir os resultados.  O guia “MOF Management Reviews” ajuda as organizações a garantir que seus serviços de TI estejam preparados a entregar o valor esperado pelos clientes.  Esse giua ajuda no estabelecimento de decisões críticas e pontos de avaliação no ciclo de vida de gerenciamento de serviços de TI.

Por todo o ciclo de vida de serviços de TI, as revisões de gerenciamento atuam como controles internos que permitem a gerência verificar desepmenho a fim de garantir que os objetivos estão sendo atingidos de modo apropriado e que o valor final dos serviços estão sendo entregues aos clientes.  Em geral, revisões de gerenciamento, não importando em qual fase do ciclo de vida de serviços elas ocorram, possuem os seguintes objetivos genéricos:

• Permitir visão geral à gerência de serviços
• Atuar como controle interno de desempenho
• Registrar progresso da organização e lições aprendidas (itens a repetir ou evitar)
• Melhorar os processos de entrega e planejamento dos serviços de TI

Faça download do Guia MOF Management Reviews.

Mais sobre MOF v4

Microsoft Operations Framework (MOF) 4.0 engloba em um guia gratuito os principais requerimentos de operação e gerenciamento de serviços de TI, baseado em melhores práticas da indústria e da própria Microsoft para serviços e ambientes baseado nas tecnologias e produtos Microsoft (quem melhor para recomendar modelos de operação para seus próprios produtos?).

O objetivo de MOF é prover um guia para áreas de TI para ajudá-las a criar, operar e suportar serviços de TI, de forma efetiva em custo, enquanto garante também que os investimentos em TI retornem o valor esperado para o negócio (nosso cliente!) com um nível de risco aceitável.

O propósito de MOF é criar um ambiente aonde os negócios e TI possam trabalhar juntos com maturidade operacional, usando um modelo proativo que define processos e procedimentos para ganhar eficiência e efetividade.

Download dos Materiais de MOF v4

Todos os documentos de MOF são públicos e gartuitos, publicados pela Microsoft no link: http://www.microsoft.com/mof.

Outros links específicos e relacionados com o tema desse post:

• MOF Manage Phase Overview: http://technet.microsoft.com/en-us/library/cc539509.aspx)
• Policy SMF http://technet.microsoft.com/en-us/library/cc543348.aspx
• Business/IT Alignment SMF: http://technet.microsoft.com/en-us/library/cc543303.aspx
• IT Compliance Management Guide: http://technet.microsoft.com/en-us/library/dd206732.aspx
• Relevant GRC resources: http://technet.microsoft.com/en-us/regulatorycompliance/default.aspx

Abraços e até o próximo post,

Ronaldo Smith Jr.