Plano em Foco

Métrica dos processos

Em todas as melhores práticas do nosso conjunto de disciplinas de Gestão de T.I. – Itil, Cobit, Projetos Pmbok, BPM e Gestão da Segurança da Informação – existe a ênfase em controlar os processos. Para que tenhamos noção desse fato, o Pmbok, por exemplo, define todo um grupo de processos – o grupo “Monitoração e Controle” – para basicamente monitorar e controlar (dã!) outros processos do gerenciamento de projetos. Ou seja, são como se fossem “metaprocessos”, se você me permite usar tal termo. Processos que operam sobre outros processos. E o que é monitorar? É o mesmo que supervisionar, observar se os processos estão nos trilhos, é medir.

Então, é importante que os processos sejam monitoráveis, isto é, metrificáveis. No caso do Pmbok, muito superficialmente ele fala sobre as características da metrificação dos processos – embora enfatize a importância do controle propriamente dito. Ou seja, o foco é em “monitorar”, e não em quê métricas usar. Já o Cobit, em contrapartida, define indicadores precisos para a medição dos processos. Ele mede tanto a eficácia de um processo, ou seja, se o mesmo cumpre com o objetivo para o qual foi criado, quanto a eficiência, ou seja, o quão bem o processo cumpre aquilo para o que foi objetivado.

Faz-se necessário, neste ponto, salientar que cada metodologia ou melhor prática tem sua maneira de medir, monitorar e controlar seus processos. Por agora, considere que todo processo é metrificável.

Maturidade

Tanto o Cobit quanto o BPM possuem uma métrica, para cada processo, que mede a maturidade do mesmo. Maturidade? Como assim maturidade? Ora, vamos dizer que maturidade é o grau de especialização do processo. Por exemplo, se você comparar um estudante do curso de Redes de Computadores que está no seu primeiro ano de faculdade com o profissional de TI com 30 anos de experiência em empresas, muito facilmente perceberá que o nível de experiência profissional, ou de maturidade profissional, é maior para o profissional e menor para o estudante. O profissional é mais maduro profissionalmente falando, mais ágil em responder a questionamentos difíceis sobre determinado assunto (de redes, nesse caso), e assim por diante. A maturidade dele é maior, portanto. Da mesma forma, os processos possuem maturidade.

Na verdade, quando eu falo em maturidade de processos, estou olhando de fora do processo, e não de dentro, o que significa que até mesmo processos inexistentes – que, entretanto, sei que deveriam existir – passam a ser considerados quanto a seu grau de maturidade. O grau de maturidade de processos inexistentes é 0. Vamos supor que em sua empresa existam vários processos para tratar de incidentes de T.I. Existem processos que tratam de incidentes na área de software, outros, na área de banco de dados, outros, na área de redes. Mas não existe um processo para tratar incidentes na área de suporte a sistema operacional. Ou seja, se eu sou um consultor e estou avaliando a maturidade da empresa como um todo, sei que para conhecer a maturidade organizacional devo coletar todas as maturidades de processos individuais. Ao analisar os diversos processos, batendo os processos que existem na empresa com os processos anotados em meu caderno de consultor – o caderno de como a empresa deveria funcionar – eu vejo que o processo de suporte a sistemas operacionais não existe na empresa. Então, escreverei, no meu caderno, que o grau de maturidade do mesmo é 0. Maturidade 0 significa que o processo não existe. É tipo assim: “Aqui vende pão?” ; “Sim”. “Então me vê dois”. “Não temos”.

Na prática, e o BPM bate bem nesta tecla, a maturidade dos processos começa em 1 e vai até 5. O BPM é bem genérico nisso, deixando a avaliação bem subjetiva. Já o Cobit é mais objetivo, definido o que cada processo deve possuir para atingir uma determinada maturidade. Por exemplo, quando a empresa começa a se conscientizar de que há a necessidade de um processo para gerenciar incidentes de suporte de sistemas operacionais, e inicia os primeiros esforços para implantar este processo, temos o nível 1 de maturidade do processo. Quando o processo é repetível, ou seja, consegue-se repetir, contudo com a ajuda da intuição, temos o nível 2. Quando o processo é devidamente documentado, passando, também, a ser formalmente gerenciado na organização – não está mais na mente de uma pessoa específica, mas é de conhecimento do corpo funcional, e as pessoas o fazem da maneira como está documentado – então, temos o nível 3. Então, nível 3 é o chamado “nível gerenciado”. Nível 2 é o nível em que o processo é repetível. Nível 1 é o nível de conscientização. Lembre-se desses conceitos-chave quando estiver fazendo algum concurso por aí.

O nível 3 está bom, mas podemos melhorar. Sim, o processo está definido, documentado, é gerenciável, existe de maneira formal, se um funcionário for embora da empresa a mesma não para. Isso é bom. Mas não é ótimo, pois mesmo com essas características, os processos podem ser voltados mais para uma mentalidade reativa (em vez de proativa), podem ocorrer da maneira não-ótima, podem demorar, ter certos entraves, certos gargalos e assim por diante. Então, é possível otimizar o processo – olha a palavra-chave aí! Um processo atinge o nível 4 quando é otimizado. É um processo executado de forma ágil. Está muito bem entranhado na empresa. Além de ser documentado é de “fácil” execução, ou de execução rápida. É um processo ótimo.

O nível 5 é a perfeição. Indica pleno alinhamento do processo com os objetivos do negócio. A empresa cujos processos estão no nível 5 é um exemplo para outras empresas – ou melhor, os processos nível 5 de determinada organização são exemplos para outros processos de outras organizações. Sim, claro! Pois é muito difícil uma organização ter todos os seus processos em nível 5. Na vida real, uma organização tem diversos processos, cada qual com seu nível distinto de maturidade.

Então, é por aí. Vamos continuar com nossas séries de artigos introdutórios ao gerenciamento de T.I. Um bom fim de semana a todos, e em caso de erros no texto, comentem.

Continuando nossa série sobre Gestão de T.I., veremos o que é um processo.

1. A importância da gestão de T.I.
2. O que é um processo?
3. Características de um processo (Métricas e maturidade)
4. Estruturas empresariais: Funcional x Por processo
5. Estruturas empresariais: Funcional x Por projetos

Introdução

Se você clicar na imagem a seguir, verá em tamanho ampliado um processo, desenhado seguindo as regras de uma metodologia chamada BPMN. Em outras palavras, assim como para desenhar plantas baixas (de casas) você tem símbolos próprios, regras próprias, como também acontece para desenhar esquemas elétricos, topologias de redes de computadores e assim por diante, da mesma forma você tem um conjunto de símbolos e regras para desenhar um processo. O BPMN é a principal metodologia usada para se desenhar os processo. Antes de prosseguirmos, portanto, clique na imagem a seguir.

Conjunto de atividades

O processo que modelei é bem simples, para fins didáticos. Ele é um conjunto de atividades, ou tarefas a serem feitas, objetivando alcançar um objetivo. Ou seja, este processo, que poderia ser chamado “Processo de estudo para concurso”, possui quatro atividades. Como você deve ter observado, as atividades são ligadas por setas, que indicam que atividade vem após a outra. O processo começa quando do “lançamento do edital” do concurso. Ou seja, existe um evento que inicia um processo. E quando termina? Bom, termina após a última atividade “fazer resumo”, o que me leva ao evento da “prova”.

Sim, isso mesmo. Um processo pode ser definido como um conjunto de atividades. Porém, um processo é mais do que isso…

Entradas e saídas

Um processo recebe uma ou mais entradas e uma ou mais saídas. “Uma ou mais saídas?”, pergunta você, de TI, surpreso. Sim, uma ou mais saídas, pois estamos falando de processos, e não de funções matemáticas ou métodos de linguagens de programação. Por agora, é importante destacar que, conforme mostra figura a seguir, a entrada de um processo é, ao mesmo tempo, entrada para a primeira atividade do processo. E a saída do processo é a saída da última atividade executada dentro do processo. Essa definição “executada” é importante, visto que as atividades, dentro do processo, nem sempre são executadas linearmente; elas podem seguir caminhos diferentes, e o processo pode terminar de maneiras diferentes. Assim, a última atividade executada será aquela que proverá a saída do processo. No futuro, quando estivermos tratando sobre BPMN, veremos como modelar processos mais complexos.

Voltemos ao nosso exemplo do processo “estudar para concurso”. Observe que o evento que inicia o processo chama-se “lançamento do edital”. Em outras palavras, podeíamos dizer que a entrada deste processo é o edital do concurso. E, veja que, como foi dito, esta entrada no processo será também a entrada na primeira atividade, que se chama “conferir ementa”. Você concorda que essa atividade precisará da ementa? Então, é isso.

Permita-me ser pragmático agora, e fazer uma abstração para conceitos de computação. O processo não é nada sem as atividades. Um processo, por si só, não possui “fila de entrada” ou “buffer”. Não tem como uma entrada de processo ficar vagando dentro do processo, solta, até encontrar uma atividade. Não! Um processo é um conjunto de atividades ordenadas de certo modo, e, quando uma informação entra no processo,  está automaticamente entrando na primeira atividade.

Processos e gestão de T.I.

No próximo post, como previsto, estudaremos algumas outras características de processos. Mas tenho algo a acrescentar: nas disciplinas que fazem parte do grupo de gestão, falado em post anterior (Itil, Cobit, PMP e BPM), muita coisa de processo é vista, e os processos são a base dessas disciplinas, como se fosse um terreno comum. Se você pegar, por exemplo, o Itil v3, verá diversos processos, como requisição de mudança, tratamento de incidente, assim por diante. Se você pegar o Cobit, verá 34 processos de T.I., cada qual com suas características. PMP também tem seus processos e BPM define e trata de mapeamento, execução e monitoração de processos. E as características abordadas até agora são compartilhadas por essas disciplinas. No próximo post falaremos sobre métricas de processo e maturidade dos mesmos, assunto importante em Cobit, BPM e ITIL (PMP não tem foco em maturidade, porém tem algo de métricas).

Vamos iniciar uma série sobre gestão de T.I.

1. A importância da gestão de T.I.
2. O que é um processo?
3. Características de um processo (Métricas e maturidade)

A importância da gestão de T.I.

Mesmo que você não seja um gerente de T.I., e nem pretenda ser, o conhecimento de gestão é indispensável em um plenata populoso como o nosso, onde todo mundo fala de processos, mapeamento, projetos, sendo que grande maioria dessas pessoas nem sabe sobre o que estão falando. Já ouvi isso em algum lugar e transcrevo aqui: existem “gestores” que simplesmente decoraram todas as frases da sorte (aquelas dos biscoitos) que viram na vida. “Vamos definir uma baseline”, “vamos adotar uma nova estratégia”, “vamos melhorar a integração dos processos” são frases feitas que aparentemente cabem em quaisquer circunstâncias e ninguém questiona seu real significa no contexto. E você, meu amigo, tendo um conhecimento básico de gestão, poderá – ou não – questionar ao gestor se ele realmente deseja mapear processos sem fazer um levantamento por meio de entrevista pessoal com o corpo funcional da empresa. Irei entrar nisso em mais detalhes posteriormente, porém, já tenha isso em mente: mapeamento de processos não se faz sentado em uma sala fechada com duas ou três pessoas engravatadas recém saídas da universidade ou recém aprovadas em concurso público. Não. O mapeamento visa documentar como a empresa trabalha, a fim de melhorar esse modo de trabalho, ou processo, e exige que os gestores saiam e entrevistem, façam levantamento, enfim, que vão ao campo.

Por falar em concurso, vocês devem observar que ultimamente, em todo concurso de T.I., a parte de gestão está sendo cobrada radicalmente. Não importa se o cargo é suporte técnico, software básico, desenvolvimento, faxina etc: sempre está caindo as quatro matérias fundamentais da gestão de T.I., a saber:

• Gerenciamento de serviços de TI com base no ITIL v3
• Governança de TI com base no Cobit 4.1
• Análise de negócios com base no BABOK, incluindo mapeamento BPM e uso do BPMN
• Gerenciamento de Projetos baseando-se no PMBOK

Então, gestão é importante. Importante para você que quer melhorar profissionalmente na empresa onde já trabalha, importante para você que quer evoluir, importante para concurso, importante para jogar na cara de pseudo-gestores o quão bossais eles são, mas muito indireta e educadamente e com embasamento técnico, enfim, importante para você dominar o mundo. Então, em nosso próximo post, falaremos sobre… sobre o quê? Sobre o segredo da vida, do universo e de tudo o mais? Não, pois já sabemos a resposta (42). Falaremos sobre o que é um processo. Penso que esse é um bom tópico para começar: conceitos de processos, visto que esse assunto é o coração do BPM, ITIL e COBIT se baseiam em processos, e o PMBOK toca nesse assunto algumas vezes.

Até mais.

Olá, caros leitores. Faz algum tempo que não posto nada neste blog, e isso deveu-se a algumas situações que me exigiram bastante atenção, além de não me sentir capacitado a escrever algo produtivo.

CCNA: Não mais

Vocês não sabem, porque presumo que não tenham bola de cristal e, mesmo se tivessem, não acreditariam nessa baboseira, mas eu perdi a certificação CCNA – ela expirou. Ou seja, agora sou um simples empurrador de mouse (mas não tanto). Pretendo recuperá-la este ano ainda, antes de Junho, se algum imprevisto não ocorrer.

Gestão de T.I. na veia

Entretanto, tirei outras certificações. A primeira foi a ITILv3 Foundations. Essa certificação deu-me uma boa noção de gestão de T.I. Depois, fiz um curso e certifiquei-me Cobit 4.1 no fim do ano passado. Gostei muito do assunto de gestão, e, realmente, se as empresas seguissem as melhores práticas, menos acionistas suicidariam-se. Mês passado fiz um curso de análise de negócio, preparatório para a certificação OMG-OCEB Foundations, mas… não consegui passar no exame. Decepção! A autoanálise que faço é: tinha um conhecimento razoável da matéria, saí do curso confiante, todavia não pratiquei os conceitos em inglês, lascando-me na prova. Agora tentarei fazê-la no mês de março, porém desta vez estudarei profundamente as diferenças entre GOALS e OBJECTIVES, lendo bastante material em inglês.

Ainda sou técnico!

Não, meus caros, não estou estagnado na parte tecnológica. Continuo seguindo minha vida técnica. No fim de Janeiro, por exemplo, realizei o exame LPI 117-101, sendo aprovado, e pretendo realizar o LPI 117-102 no fim deste mês, após o carnaval, objetivando obter a certificação LPIC-1. E também, como já disse, a recuperação do CCNA e a obtenção do CCNP estão entre meus objetivos primários, ou primordiais. Caso contrário, minha pós-graduação preparatória para o CCNP terá sido um belo gasto de dinheiro, tal qual ocorre em algumas obras na Cidade Maravilhosa.

Novo colaborador

Temos um novo colaborador neste blog. Chama-se Diogo V. T. Cardozo. Ele é certificado DLink e Cobit 4.1, e também está se preparando para a certificação CCNA/CCNP. Possui larga experiência com equipamentos Cisco, Juniper, Huawei e Dlink empresariais. Você, leitor que acompanha este blog, pode esperar posts sobre Linux, Cisco, e é claro, gestão de T.I.

Olá meus amigos.

Venho aqui desejar um feliz ano novo para todos vocês! Espero que o que desejam – que com certeza é BOM – se realize este ano: seja a obtenção de um novo emprego, seja sua nova casa etc.

É isso.