Governança de TI
Comentar
Estratégia de TI
Infraestrutura de TI
Planejamento Estratégico sem Gestão de Projetos. Esqueça.
Alterar o desempenho de uma organização quase sempre implica em formular e implementar estratégias.
Formular a estratégia é o processo de planejamento que visa definir os caminhos que a organização deve trilhar para tornar real sua visão de futuro, a partir da identificação de forças restritivas e impulsionadoras, externas e internas, decorrentes de uma análise ambiental. Estes caminhos devem ser traduzidos em objetivos estratégicos. O processo de formulação da estratégia, geralmente, inicia com a análise ambiental e termina com as estratégias definidas. Convenciona-se chamar esta etapa de planejamento estratégico.
Implementar a estratégia inclui a definição das ações, indicadores e metas necessárias, utilizando-se de informações, requisitos de partes interessadas, alocação de recursos, assim como os processos para a comunicação e o monitoramento dos resultados. Boa parte das vezes, a implementação utiliza como instrumento o Balanced Scorecard (BSC), um sistema para gerenciamento da estratégia surgido na década de 1990.
O BSC foi desenvolvido por Robert Kaplan e David Norton, nos Estados Unidos. Reconhecendo algumas fraquezas e incertezas da abordagem comum de gestão da época, focada só nos resultados financeiros, mas muito longe da execução e de outras perspectivas além da financeira, a abordagem do BSC corrige essa distorção e propõe uma nova forma de “medir” a organização.
O BSC tem como premissa que a estratégia de uma organização é uma hipótese. Ele revela o movimento de uma organização que está em uma posição atual e pretende estar em uma posição futura desejável, mas incerta. Os autores do BSC, reforçam que, como a organização nunca esteve nessa posição futura, a trajetória almejada envolve uma série de hipóteses interligadas. Ele permite a descrição das hipóteses como um conjunto de relações de causa e efeito explícitas (mapa estratégico) e sujeitas a testes que ganham vida com a proposta de ações bem definidas.
E daí?
Não acontece nada, quase sempre. Na prática as ações propostas pelo BSC se tornam figurativas. É como se o planejamento estratégico acabasse com a proposta das ações e dos projetos estratégicos. Fica todo mundo esperando a mágica. O mágico falta. Os projetos deveriam por si só acontecer e permitir a virada da organização. Inúmeros casos, conhecidos no Brasil e no exterior, ilustram o planejamento estratégico como um esforço, caro, que não consegue dar os resultados esperados e que acaba ficando só no papel.
Onde está o problema?
As consultorias que elaboram o planejamento estratégico, geralmente, atuam só até a fase que propõe as ações ou em outros casos, não sabem ou não acham importante gerenciar as ações propostas como projetos. Parece que o planejamento estratégico acaba com a proposta das ações. Não acontece. As técnicas de gerenciamento de projetos é que permitem dar vida ao planejamento estratégico. Projetos possuem início, meio e fim e podem ser alterados em função das mudanças do ambiente e dos objetivos estratégicos. Indicadores de projetos devem ser alinhados dinamicamente com indicadores estratégicos. Esta é a saída para o planejamento estratégico deixar de ser uma utopia.
Uma saída
O Life Cycle Canvas (LCC) , um canvas que permite a gestão de projetos ao longo do ciclo de vida é o instrumento natural para gerenciar os projetos estratégicos. Sua estrutura baseada em uma tela, canvas, e pelo fato de permitir o gerenciamento ao longo de todo o ciclo de vida, incorporando a mudança, como uma situação normal, torna a tarefa de gerenciar as ações oriundas do planejamento estratégico uma realidade. O LCC permite gerenciar projetos do portfólio estratégico de uma mesma forma. A empresa agora pode comparar projetos e saber exatamente em que fase está cada um deles. Melhor, indicadores de projetos que servem ao controle são automaticamente registrados e permitem a alteração do projeto a qualquer momento, dando vida ao planejamento estratégico.
Google for Entrepreuners
Organização da Operação de Serviço de TI
A organização da operação de serviço de TI deve considerar algumas funções importantes:
- Uma central de serviços que é o ponto único de contato (SPOC) para os usuários, a fim de lidar com incidentes, requisições de mudanças e requisições de serviço.
- O gerenciamento técnico que permite o gerenciamento da infraestrutura de TI.
- O gerenciamento operacional que executa atividades diárias necessárias para gerenciar a infraestrutura de TI
- O gerenciamento de aplicativos que é responsável por gerenciar aplicativos em seu ciclo de vida.
A forma de organizar as funções da operação de TI deve ser feita de acordo com a realidade de cada empresa e envolve tamanho, geografia e cultura.
Boas práticas
Boas práticas é uma expressão derivada do inglês best practice, a qual denomina técnicas identificadas como as melhores para realizar determinada tarefa. Por exemplo, as boas práticas para se calcular uma equação são as melhores formas para se atingir um melhor resultado, e por isso, é sempre recomendável seguir as boas práticas. Em diversas profissões têm sido criadas normas de boas práticas que definem a forma correta de atuar dos respectivos profissionais (wikipédia)
Em TI, o ITIL é um exemplo de boa prática. O ITIL é o modelo de referência para Gestão de Serviços de TI mais aceito em todo o mundo, o ITIL (Information Technology Infrastructure Library) é um conjunto de boas práticas para infraestrutura, operação e manutenção de serviços de TI criada na década de 1980, a partir de pesquisas com consultores, especialistas e doutores da área.
Life Cycle Canvas (LCC) : Gerente de Projeto ou Operador de Tarefas ?
por Manoel Veras.
Historicamente, a gestão de projetos passou por diversas mudanças em relação às boas práticas desde que se tem registro. Dentro das empresas, o uso dessas práticas se tornou mais efetivo entre os anos de 1950 e 1960, em meio a projetos de grande complexidade nas áreas militar e espacial. Até a década de 1980, boa parte destes projetos era gerenciada considerando os processos e técnicas de gerenciamento tradicionais ligados a custos, escopo, tempo e qualidade. Gerentes de projetos se confundiam com operadores de tarefa.
Agora a coisa mudou. Kerzner reforça que as restrições em projetos foram alteradas (não só tempo, custo e escopo) para definir o sucesso ou o fracasso do projeto. Fazer compensações entre tempo, custo e escopo era natural. Hoje existem muitas outras restrições concorrentes, como, por exemplo, aceitação de riscos, manter reputação, satisfação do cliente, etc. O mais complicado é que a importância de cada restrição pode ser alterada durante o projeto, pois o ambiente de projetos é cada vez mais dinâmico. Assim, tais restrições precisam ser monitoradas e até controladas. Precisa-se pensar o tempo todo em restrições estratégicas. Nesse nível, constata-se que boa parte delas são restrições de negócio – e, portanto, os gerentes de projetos devem virar gerentes de negócio. Como ser gerente de projeto de negócio estando focando só em tarefas? Impossível.
Operadores de tarefa, de uma forma geral, ficam surpresos quando observam as novas atribuições de um gerente de projetos. Eles, em geral, não gostam de gerenciar equipes e muito menos partes interessadas. Pensar no negócio, então, nem se fala. Considerar riscos e atuar para mitiga-los é outra atribuição que incomoda. Comunicação é outro aspecto considerado difícil e falar com partes interessadas é considerada uma tarefa chata. Baixar a cabeça e continuar operando tarefas utilizando ferramentas diversas, por sinal muitas de excelente qualidade, não é a melhor maneira de resolver isto.
Se observarmos a evolução do próprio guia PMBOK, podemos notar que as mudanças nas últimas versões se dão em aspectos até então não considerados como importantes para o operador de tarefas. A introdução da área de conhecimento “stakeholders” na quinta versão sintetiza este aspecto. Metodologias como PRINCE2 calibram as atribuições do gestor de projeto de forma inteligente entre o gerente especialista e o diretor executivo de projetos, facilitando e definindo claramente as atribuições de cada um. O PRINCE2 facilita entender o papel atual do gerente de projetos. Mesmo assim, muita gente na área trabalha na camada de baixo, sendo uma espécie de gerente da equipe especialista e suporte do projeto, mesmo sabendo que existem outras demandas importantes para o gerente de projetos.
O que fazer?
A utilização de ferramentas visuais como o Life Cycle Canvas (LCC) seriam uma saída natural para operadores de tarefa que desejam se tornar gerentes de projeto. Pois são excelentes para comunicar e integrar o projeto, considerando os diversos aspectos subjetivos do gerenciamento, mas não abrem mão dos aspectos técnicos e do controle das tarefas envolvidas. A comunicação é facilitada considerando que os principais aspectos do projeto a serem comunicados às partes interessadas, podem ser resumidos em uma única tela. Além disso, permitem a gestão dinâmica do projeto em todo o seu ciclo de vida. A integração é outro aspecto facilitado, pois as áreas envolvidas e suas relações no gerenciamento com o uso de uma única tela tornam-se mais simples. Ferramentas e técnicas podem ser facilmente agregadas a tela principal do LCC, permitindo a operação das tarefas vinculadas ao verdadeiro gerenciamento do projeto.
Gestão Ágil de Projetos com Life Cycle Canvas (LCC)
por Manoel Veras.
Os métodos ágeis são recomendados para cenários complexos onde existem incertezas diversas relacionadas aos projetos. Eles reforçam que a utilização de ciclos adaptativos que permitem mudanças no plano de gerenciamento (linha de base) combinado com entregas iterativas e incrementais ajudam a reduzir os riscos envolvidos em certos tipos de projetos. A ideia de utilizar o ciclo de vida iterativo e incremental já foi mencionada na última versão do guia PMBOK e é contemplada pelo Life Cycle Canvas (LCC).
A gestão ágil é baseada no manifesto ágil lançado no início da década passada. O manifesto ágil prega os quatro valores relacionados abaixo:
- Indivíduos e interação entre eles mais que processos e ferramentas;
- Software em funcionamento mais que documentação abrangente;
- Colaboração com o cliente mais que negociação de contratos;
- Responder a mudanças mais que seguir um plano.
O LCC é uma ferramenta para gestão de projetos baseada no canvas e no ciclo de vida do projeto. O LCC é um canvas dinâmico que essencialmente acompanha o projeto em cada uma das suas fases, desde a iniciação até o encerramento. Ele cria um padrão de gerenciamento que possibilita gerenciar todas as fases, processos e áreas de conhecimento sugeridas pelo guia PMBOK de forma simples.
O LCC é aderente ao manifesto ágil pois essencialmente privilegia a interação entre indivíduos, permite focar na essência do projeto, colaborar com o cliente e responde a mudanças de forma fácil. Aspectos de comunicação, integração e gestão da mudança, essenciais aos projetos ágeis, são características essências da ferramenta. Quase que naturalmente o LCC permite a gestão ágil de forma simples, além de permitir, com a documentação gerada, contar toda a história do projeto.
Para explicar como o LCC é aderente a gestão ágil de projetos imaginemos o projeto de um produto que é gerenciado utilizando o método ágil. O seu gerenciamento, mesmo que ágil, deve ser feito em cinco fases do ciclo de vida ( iniciação (IN), planejamento (PL), execução (EX) e monitoramento e controle (M&C), encerramento (EN)) conforme sugere o LCC.
O roadmap do produto, uma espécie de panorama visual dos lançamentos (releases) do produto e suas funcionalidades ao longo do tempo. Ele define o backlog do produto que por sua vez é composto pelos requisitos. No LCC o backlog do produto pode ser representado no campo requisitos.
Os requisitos previstos no backlog podem ser escritos em post-its na forma de user stories (textos simples que descrevem uma funcionalidade). Os requisitos devem orientar as releases (lançamentos ou entregas) do produto.
É necessário então pensar como os requisitos do produto serão atendidos por cada uma das releases. Por sua vez as releases devem ser construídas baseadas em iterações. As iterações são os incrementos do produto em cada uma das releases. Uma iteração envolve as atividades de desenvolvimento que levam ao release de um produto. No LCC as iterações podem ser representadas por versões com ciclos de planejamento e execução específicos. Cada iteração deve atender determinadas funcionalidades e é composta por tarefas. O produto final será formado pelas releases (entregas) baseadas em iterações que por sua vez são baseadas em tarefas. Retrospectivas são registradas como Lições Aprendidas no LCC.
A figura a seguir mostra a release 1 (iteração 1 + iteração 2 + iteração 3) do produto baseada em três iterações. Cada iteração dá origem a uma versão do LCC.
A figura a seguir mostra a release 2 (iteração 1 + iteração 2) do produto baseada em duas iterações.
O produto, neste caso, é formado pelos duas releases cada uma com seu respectivo LCC aderentes ao LCC do produto. O produto final é baseado em duas releases cada uma delas baseadas em iterações e documentadas no formato canvas do LCC.
O LCC para o exemplo citado seria utilizado nos três casos (produto – release 1 – release 2). Ele facilita o gerenciamento do projeto agregando o gerenciamento de outras áreas de conhecimento também necessárias nos projetos ágeis para o projeto do produto e de cada uma das releases e traz a interface gráfica para o centro do gerenciamento o que facilita a integração e a comunicação do projeto.
Referência.
Gerenciamento Ágil de Projetos, Vitor L. Massari, Brasport, 2014.
ISO 27002 – Código de Prática para a Gestão da Segurança da Informação
CONHEÇA A NBR ISO/IEC 27002 – PARTES 1 e 2 (Site Profissionais de TI)
O objetivo da norma é “estabelecer diretrizes e princípios gerais para iniciar, implementar, manter e melhorar a gestão de segurança da informação em uma organização”. Segurança da Informação trata proteger as informações consideradas importantes para a continuidade e manutenção dos objetivos de negócio da organização.
A parte principal da norma se encontra distribuída em 11 seções, que correspondem a controles de segurança da informação descritas a seguir.
Seção 5 – Política de Segurança da Informação
Deve ser criado um documento sobre a política de segurança da informação da organização, que deveria conter, entre outros, os conceitos de segurança da informação, o comprometimento da direção com a política, uma estrutura para estabelecer os objetivos de controle e os controles, a estrutura de análise e avaliação e gerenciamento de riscos, as políticas, princípios, normas e requisitos de conformidade de segurança da informação específicos para a organização. Essa política também deve ser comunicada a todos, bem como analisada e revisada criticamente, em intervalos regulares ou quando mudanças se fizerem necessárias.
Seção 6 – Organizando a Segurança da Informação
Para implementar a SI em uma organização, é necessária que seja estabelecida uma estrutura para gerenciá-la. Para isso, as atividades de segurança da informação devem ser coordenadas por representantes de diversas partes da organização, com funções e papéis relevantes. Todas as responsabilidades pela segurança da informação também devem estar claramente definidas. É importante ainda que sejam estabelecidos acordos de confidencialidade para proteger as informações de caráter sigiloso, bem como as informações que são acessadas, comunicadas, processadas ou gerenciadas por partes externas, tais como terceiros e clientes.
Seção 7 – Gestão de Ativos
Ativo, de acordo com a norma, “é qualquer coisa que tenha valor para a organização”. Gestão de Ativos, portanto, significa proteger e manter os ativos da organização. Para que eles sejam devidamente protegidos, devem ser primeiramente identificados e levantados, com proprietários também identificados e designados, de tal forma que um inventário de ativos possa ser estruturado e posteriormente mantido. As informações e os ativos ainda devem ser classificados, conforme o nível de proteção recomendado para cada um deles, e seguir regras documentadas, que definem qual o tipo de uso é permitido fazer com esses ativos.
Seção 8 – Segurança em Recursos Humanos
Antes de realizar a contratação de um funcionário ou mesmo de fornecedores e terceiros, é importante que cada um deles entenda suas responsabilidades e esteja de acordo com o papel que desempenhará. Portanto, as descrições de cargo e os termos e condições de contratação devem ser explícitos, especialmente no que tange às responsabilidades de segurança da informação. É importante também que quaisquer candidatos sejam devidamente analisados, principalmente se forem lidar com informações de caráter sigiloso. A intenção aqui é mitigar o risco de roubo, fraude ou mau uso dos recursos.
Seção 9 – Segurança Física e do Ambiente
As instalações de processamento de informação críticas ou sensíveis devem ser mantidas em áreas seguras, com níveis e controles de acesso apropriados, incluindo proteção física. Essa proteção deve ser compatível com os riscos previamente identificados. Os equipamentos também devem ser protegidos contra ameaças físicas e ambientais, incluindo aqueles utilizados fora do local.
Seção 10 – Gestão das Operações e Comunicações
É importante que estejam definidos os procedimentos e responsabilidades pela gestão e operação de todos os recursos de processamento das informações. Além disso, deve-se utilizar sempre que necessária a segregação de funções (recomenda-se que uma pessoa realize uma ou algumas partes de um processo, mas não todas), visando reduzir o risco de mau uso ou uso indevido dos sistemas.Para o gerenciamento de serviços terceirizados, deve-se implementar e manter o nível apropriado de segurança da informação e em conformidade com acordos de entrega de serviços terceirizados. É fundamental planejar e preparar a disponibilidade e os recursos do sistemas para minimizar o risco de falhas, bem como prever a capacidade futura dos sistemas, de forma a reduzir os riscos de sobrecarga. Também deve-se prevenir e detectar a introdução de códigos maliciosos e os usuários devem estar conscientes sobre isso. Procedimentos para a geração de cópias de segurança e sua recuperação também devem ser estabelecidos.Deve-se garantir ainda o gerenciamento seguro de redes. Controles adicionais podem até mesmo ser necessários para proteger informações confidenciais que trafegam em redes pública. As trocas de informações entre organizações devem ser baseadas em uma política formal específica, devendo ser efetuadas a partir de acordos entre as partes e sempre em conformidade com toda a legislação pertinente. Deve-se ainda implementar mecanismos de monitoração de atividades não autorizadas de processamento da informação. Os eventos de segurança da informação devem ser registrados, lembrando que as organizações devem estar aderentes aos requisitos legais aplicáveis para suas atividades de registro e monitoramento.
Seção 11 – Controle de Acesso
O acesso à informação, aos recursos de processamento das informações e aos processos de negócios devem ser controlados com base nos requisitos de negócio e na segurança da informação. Portanto, deve ser assegurado o acesso de usuário autorizado e prevenido o acesso não autorizado a sistemas de informação. Para isso, deve haver procedimentos que englobem desde o cadastro inicial de um novo usuário até o cancelamento final do seu registro, garantindo assim que já não possuem mais acesso a sistemas de informação e serviços. Os usuários sempre devem estar conscientes de suas responsabilidades, particularmente no que se refere ao uso de senhas e de segurança dos equipamentos de usuários. Nesse sentido, sugere-se ainda a adoção da “política de mesa e tela limpa”, para reduzir o risco de acessos não autorizados ou danos a documentos, papéis, mídias e recursos de processamento da informação que estejam ao alcance de qualquer um.
Seção 12 – Aquisição, Desenvolvimento e Manutenção de Sistemas de Informação
Segundo a norma, “Sistemas de informação incluem sistemas operacionais, infra-estrutura, aplicações de negócios, produtos de prateleira, serviços e aplicações desenvolvidas pelo usuário”. Por essa razão, os requisitos de segurança de sistemas de informação devem ser identificados e acordados antes do seu desenvolvimento e/ou de sua implementação. As informações devem ser protegidas visando a manutenção de sua confidencialidade, autenticidade ou integridade por meios criptográficos.
Seção 13 – Gestão de Incidentes de Segurança da Informação
Deve-se assegurar que eventos de segurança da informação sejam o mais rápido possível comunicados, de tal forma que a tomada de ação corretiva ocorra em tempo hábil. Para isso, devem ser estabelecidos procedimentos formais de registro e escalonamento, bem como todos os funcionários, fornecedores e terceiros devem estar conscientes sobre os procedimentos para notificação dos diferentes tipos de eventos.
Seção 14 – Gestão da Continuidade do Negócio
Deve-se impedir a interrupção das atividades do negócio e proteger os processos críticos contra efeitos de falhas ou desastres significativos, e assegurar que a sua retomada ocorra em tempo hábil.Para isso, planos de continuidade do negócio, incluindo controles para identificar e reduzir riscos, devem ser desenvolvidos e implementados, visando assegurar que as operações essenciais sejam rapidamente recuperadas.
Seção 15 – Conformidade
Deve-se garantir e evitar a violação de qualquer lei criminal ou civil, estatutos, regulamentações ou obrigações contratuais e de quaisquer requisitos de segurança da informação.
Referência Bibliográfica:
ABNT – Associação Brasileira de Normas Técnicas. ABNT NBR ISO/IEC 27002 – Tecnologia da informação – Técnicas de segurança – Código de prática para a gestão de segurança da informação. ABNT, 2005.