PLANEJAMENTO ESTRATÉGICO DE TECNOLOGIA DA INFORMAÇÃO. Unidade II. As principais soluções de TI que atendem a necessidades de negócios.

(1)

1/0

1/1

0 || 2º Revisão: Beatriz / Corr

eção: Már cio - 0 2/0 1/1 0

Unidade II

2 SOLUÇÕES DE TI NO AMBIENTE EMPRESARIAL

• Benefícios decorrentes do uso de TI nos negócios.

• As principais soluções de TI que atendem a necessidades de negócios.

• Características das soluções de infraestrutura.

• Características das soluções de sistemas de informação.

2.1 Necessidades de negócios que requerem TI

No ambiente empresarial, quase todas as ações empreendidas envolvem alguma expectativa de retorno ﬁnanceiro: para gerar e aumentar receitas, ou diminuir e eliminar custos. Tal expectativa se torna mais evidente na medida em que o prazo de retorno se encurta, e vice-versa.

Tomemos como exemplo uma campanha de responsabilidade social corporativa, na qual a empresa oferece diversas formas de assistência à comunidade onde atua, a título de compensação por eventuais impactos causados por ela, por operar naquela região. Sem menosprezar a importância da mudança cultural e do surgimento de uma nova ética empresarial que tais iniciativas representam, não é segredo que tais campanhas trazem em seu bojo a expectativa de:

• criar ambiente favorável à realização de negócios, conquistando a simpatia da sociedade e a boa-vontade

5

10

15

(2)

1/0

1/1

eção: Már

cio - 0

2/0

1/1

0

das autoridades, o que vai reverter no longo prazo em novas oportunidades de negócios;

• evitar a aplicação de sanções pelas autoridades, que aumentam o custo da operação por meio de interdições, multas e processos judiciais;

• gerar clima interno de satisfação por “fazer a coisa certa”, e orgulho por trabalhar numa empresa “política, social e ambientalmente correta”, o que resulta em:

- aumento da produtividade dos funcionários;

- diminuição das demissões voluntárias, reduzindo custos de recrutamento e adaptação dos novos funcionários; - atração de proﬁssionais qualiﬁcados do mercado,

diminuindo custos de contratação para expansão ou substituição.

A tecnologia da informação, pela facilidade que oferece em produzir mudanças, é constantemente colocada a serviço de diversas necessidades de negócios cujo objetivo é, em algum momento, econômico.

Uma forma bastante comum de mascarar um objetivo financeiro é chamá-lo por outro nome, em geral associado a um objetivo mais imediato: eficiência, agilidade, racionalização, produtividade e qualidade, entre outros. Assumi-lo antecipadamente como econômico pode evitar eventuais divergências a respeito da classificação de determinado projeto como “aumento de eficiência” ou “redução de custos”, por exemplo.

Tendo em vista essa orientação econômico-ﬁnanceira das iniciativas de TI, pode-se chamá-los do que se queira: pelos efeitos tecnológicos ou processuais que propõem, ou pelos efeitos pretendidos na forma de se fazer negócios, ou o que se queira destacar na ocasião (nota: a prática mostra que os benefícios invocados à hora de se negociar ou aprovar o orçamento de um

5 10 15 20 25 30

(3)

1/0

1/1

eção: Már

cio - 0

2/0

1/1

0

projeto de TI devem ser cuidadosamente escolhidos, de forma a sensibilizar o patrocinador).

Feitas as devidas considerações quanto à natureza dos objetivos, é apropriado relacionar as principais necessidades às quais as soluções de TI têm condições de satisfazer, e onde se deve investir:

Redução de custos e aumento de eﬁciência • Motivações:

- substituição de serviços caros por serviços baratos; - eliminar documentos físicos, dispensando transporte e

guarda;

- processos mais ágeis para reduzir tempos e antecipar entregas e faturamento;

- descentralizar atividades e centralizar negociações. • Necessidade por TI:

- contratar serviços disponíveis;

- integrar os sistemas da empresa com os sistemas dos fornecedores. • Investimentos em TI : - sistemas de informação; - métodos e processos. Expansão geográﬁca • Motivações:

- atingir novos mercados; - obter vantagem competitiva;

5

10

15

20

(4)

1/0

1/1

eção: Már

cio - 0

2/0

1/1

0

• Necessidade por TI:

- utilizar serviços existentes. • Investimentos de TI:

- infraestrutura local (remota); - infraestrutura centralizada; - telecomunicações;

- hardware e software; - suporte e manutenção.

Novos ou melhores produtos e serviços • Motivações:

- reagir à concorrência; - atender melhor aos clientes; - aumentar a lucratividade. • Necessidade por TI:

- desenvolver serviços de TI que suportem ou viabilizem novos produtos e serviços aos clientes da empresa. • Investimentos de TI:

- infraestrutura centralizada; - sistemas de informação.

2.2 Soluções de TI às necessidades de negócios

Um projeto de TI requer planejamento cuidadoso e controle eﬁciente para ser bem-sucedido. Será necessária a mobilização dos recursos de TI: infraestrutura, sistemas, métodos e processos e pessoas, em graus variados e em momentos especíﬁcos.

5

10

15

(5)

1/0

1/1

eção: Már

cio - 0

2/0

1/1

0

A mobilização dos recursos de TI é assimétrica, e só é determinada ao ﬁnal do planejamento.

Exemplos:

• melhorias na infraestrutura podem não afetar sistemas em uso, afetar pouco métodos e processos e requerer envolvimento apenas de pessoal técnico;

• otimizações de sistemas podem não afetar a infraestrutura, afetar pouco ou nada os métodos e processos e requerer apenas o envolvimento de pessoal de desenvolvimento; • novas funcionalidades em sistemas podem não afetar a

infraestrutura, mas podem requerem muitas mudanças em métodos e processos e o envolvimento tanto do pessoal de desenvolvimento como dos usuários;

• uma implantação de um sistema ERP requer alto envolvimento de todos os recursos.

Princípios de gestão de mudanças

A prática demonstra que a necessidade de se introduzir mudanças num sistema surge quase que imediatamente após a implantação dele, senão antes mesmo da implantação. De fato, durante o processo de ajuste e testes que antecede a implantação de qualquer tecnologia, ﬁcam evidentes as limitações do sistema, cujas origens podem ser desde a falta de aderência a uma especiﬁcação à ausência de funcionalidades importantes.

Geralmente, se os problemas encontrados não causam danos signiﬁcativos e os riscos de sua utilização são avaliados como baixos ou “gerenciáveis”, decide-se por implantá-lo da forma como está, para que os reparos sejam realizados posteriormente. Enquanto a mudança deﬁnitiva não é realizada, adotam-se soluções de contorno. 5 10 15 20 25

(6)

1/0

1/1

eção: Már

cio - 0

2/0

1/1

0

Esta atitude de tolerância ao erro, embora incomode a muitos, tem sua utilidade prática: se todo sistema tivesse que ser aperfeiçoado até o ponto de atender a todas as necessidades, poucas implantações seriam bem-sucedidas.

Como discutido anteriormente, qualquer tecnologia pressupõe uma expectativa de benefícios decorrentes de sua utilização. Portanto, quanto mais longa for a espera para a implantação, tanto mais distante será a produção dos benefícios esperados, bem como tanto maior será o custo da tecnologia. Ou seja: quanto mais um sistema demora a ser implantado e produzir resultados, mais a relação-benefício fica desfavorável. Numa analogia fora desse contexto, não implantar um sistema com falhas pouco graves seria o mesmo que uma pessoa se recusar a habitar uma casa enquanto ela não estivesse com todos os detalhes de acabamento devidamente instalados.

Além da preocupação com o custo, os proﬁssionais de TI têm outros motivos para se preocupar com mudanças. O primeiro motivo vem da constatação empírica de que, quando algo que funcionava bem parou de funcionar, algo mudou. Mudanças, sejam intencionais ou fortuitas, trazem riscos - o que, de certa forma, justiﬁca a “resistência à mudança” que atribuímos aos outros (e quase nunca a reconhecemos em nós).

Os riscos inerentes a qualquer mudança são originados por nossa incapacidade de conhecer todos os detalhes das tecnologias afetadas direta ou indiretamente pela mudança pretendida, para que pudéssemos antecipar as consequências que ela acarretará. De fato, as tecnologias e os sistemas que empregamos se mesclam numa complexa rede de dependências de fatores internos e externos, e qualquer movimento imprevisto pode ter consequências desastrosas.

Após essas necessárias considerações, serão apresentados os aspectos principais da gestão de mudanças: justiﬁcativas, riscos

5 10 15 20 25 30

(7)

1/0

1/1

eção: Már

cio - 0

2/0

1/1

0

e condições para seu emprego. Na sequência, como abordar cada tipo de mudança.

Motivação

• Complexidade da intervenção:

- muitas dependências: existem inúmeras condições necessárias anteriores das quais o item que sofrerá intervenção depende;

- muitas decorrências: o item que sofrerá intervenção é condição necessária de itens posteriores;

- diﬁculdade na antecipação de desdobramentos: não se podem prever todas as consequências da intervenção. • Impactos:

- desempenho: atrasos em processos, sejam eles por interrupções ou por lentidão, diﬁcultam o cumprimento de prazos, afetando os negócios em algum grau;

- segurança: intervenções mal-executadas podem causar problemas nos três aspectos de segurança: conﬁdencialidade, integridade e disponibilidade; - ou seja: tempo e dinheiro!

Pré-requisitos

Como quase tudo na vida, fazer a coisa certa não depende somente de boas intenções. A atitude de querer fazer certo é condição necessária, porém insuﬁciente, para que se obtenham bons resultados.

Existem certos pré-requisitos para que intervenções possam ser adequadamente planejadas e, assim, ter seus riscos reduzidos. 5 10 15 20 25

(8)

1/0

1/1

eção: Már cio - 0 2/0 1/1 0 Recursos documentados

• Infraestrutura: sistema de gestão de configuração (CMS), com registro de configurações atuais e anteriores de cada item de configuração;

• sistemas de informação: documentação atualizada, com diagramas e especiﬁcações.

Ambientes de desenvolvimento e homologação Devem existir ambientes separados para as funções de: • desenvolvimento: de uso de analistas de sistemas e

programadores, para validação inicial de funcionalidades a implementar;

• homologação: de uso exclusivo do pessoal de qualidade (QA ou Quality Assurance), para validação extensiva por meio de análise de aderência às especiﬁcações;

• produção: onde estão os dados reais usados pelos sistemas. O acesso dos desenvolvedores a esse ambiente é limitado a casos de exceção.

Tipos de mudanças

Existem tipos diferentes de mudanças quando se consideram as circunstâncias que as demandam. Este fato é bastante evidenciado no ITIL v. 3, que as classifica como normal, padrão e emergencial. Para efeitos deste estudo, elas serão chamadas de rotineira, comum e emergencial.

Mudança rotineira

Este tipo agrupa mudanças de impacto baixo ou localizado, e sua ocorrência é esperada, embora nem sempre possa ser antecipada. Sua execução é pré-aprovada quando se veriﬁca a ocorrência de determinados eventos.

5

10

15

20

(9)

1/0

1/1

eção: Már

cio - 0

2/0

1/1

0

Mudanças deste tipo incluem:

• atualizações de segurança de sistema operacional, liberadas regularmente;

• atualizações de certos sistemas aplicativos, cujo fato gerador é sua liberação pelo autor/produtor;

• manutenções preventivas, programadas segundo cronograma anual;

• certas mudanças na composição de grupos de usuários e direitos de acesso, quando solicitadas por usuários autorizadas;

• instalação de softwares aprovados, quando requisitados pelos usuários.

O ciclo de vida de uma mudança normal compreende as etapas de:

• fato gerador (requisição, liberação, calendário); • análise;

• execução; • avaliação; • documentação. Mudança comum

Este tipo agrupa mudanças que requerem análise de riscos e aprovação de acordo com o impacto esperado.

• distribuição de software aplicativo às estações de trabalho; 5 10 15 20 25

(10)

1/0

1/1

eção: Már cio - 0 2/0 1/1 0 • manutenções corretivas;

• movimentação física de equipamentos de infraestrutura. O ciclo de vida de uma mudança padrão compreende as etapas de:

• requisição;

• análise funcional e técnica:

- entendimento da necessidade de negócios;

- determinação do melhor momento de fazer a mudança;

- análise de viabilidade econômica e tecnológica; • análise de risco:

- complexidade da intervenção a realizar;

- impacto em processos de negócios e tecnológicos; - abrangência geográﬁca;

- aprovação; - planejamento; - execução; - avaliação;

- determinar se a intervenção cumpriu os objetivos; - decidir por manter ou voltar à situação anterior; • documentação.

Mudança emergencial

Este tipo agrupa mudanças prioritárias devido ao impacto real ou potencial nos negócios. As intervenções

5

10

15

(11)

1/0

1/1

eção: Már

cio - 0

2/0

1/1

0

que restaurarão as funcionalidades interrompidas ou ameaçadas devem ser realizadas de imediato.

• equipamentos de infraestrutura inoperantes ou intermitentes;

• canais de comunicação inoperantes ou intermitentes; • ocorrência ou ameaça de danos físicos à infraestrutura:

- causas ambientais (ex: energia, umidade, temperatura); - desastres naturais;

- acidentes (ex: quedas, incêndios, vazamentos, roubos). O ciclo de vida de uma mudança emergencial compreende as etapas de: • controle de danos; • planejamento; • execução; • avaliação; • documentação. Controle de danos

Este conceito se originou no transporte marítimo, onde signiﬁca o conjunto de ações emergenciais tomadas para impedir o naufrágio de uma embarcação. Mais recentemente, tem sido empregada em relações públicas, geralmente para conter a proliferação de informação que possa ser danosa à imagem pública ou reputação de alguém ou de alguma empresa. Apesar de não ser chamado assim, é o que se faz em clínicas de pronto-atendimento para evitar que o paciente morra ou sofra

5

10

15

20

(12)

1/0

1/1

eção: Már

cio - 0

2/0

1/1

0

danos irreversíveis até que um tratamento mais eﬁcaz possa ser realizado.

Aparentemente, o conceito de contenção de danos não é empregado nos modelos de referência de gestão de TI, ao menos formalmente. Assim sendo, será apresentada a seguir uma proposta de incorporação dessa prática ao ciclo de vida das mudanças emergenciais, que o autor se sente justiﬁcado em fazer por conta da experiência adquirida na resolução de incontáveis situações de interrupção de serviços de TI (que lhe custaram, ainda, apreciável quantidade de ﬁos de cabelo grisalhos).

No contexto da gestão de mudanças, controle de danos é o conjunto de ações emergenciais (e possivelmente temporárias) que visa garantir a continuidade de negócios, mesmo que parcialmente, num nível de risco aceitável. Noutras palavras, o objetivo é manter os negócios funcionando, desde que essa continuidade não cause o agravamento do problema, ou crie mais problemas graves. Obviamente, isto só é necessário em incidentes de impacto de larga escala.

A história prova que o pior às vezes acontece, e a psicologia explica que isso quase sempre nos surpreende – em geral, ocorre quando o sucesso se torna rotineiro e cremos estar seguros com as medidas em vigor, como se o futuro fosse uma repetição inﬁndável de eventos já vivenciados. Algumas das situações mais comuns que permitem a ocorrência de falhas de grande abrangência são:

• sequência de improbabilidades: uma conjunção de fatores tidos como pouco prováveis ocorrem simultaneamente, vencendo consecutivamente as medidas de salvaguarda em vigor. Por exemplo, muito se falou que uma empresa sediada numa das torres do World Trade Center tinha um sistema de redundância para continuidade de negócios instalado na outra torre. Se isso for verdade, é lícito supor

5 10 15 20 25 30

(13)

1/0

1/1

eção: Már

cio - 0

2/0

1/1

0

que, durante a análise de risco, as pessoas chegaram a conclusão de que “vá lá, talvez aconteça algo muito grave numa das torres, mas jamais ocorrerá simultaneamente nas duas”;

• proteção parcial: as medidas de salvaguarda, mesmo aquelas com redundâncias e áreas de superposição de funções, não cobrem todos os riscos. Por exemplo, um e-mail malicioso que chega à caixa-postal de um usuário ultrapassou diversas defesas, às vezes mais de uma na mesma camada de vulnerabilidade: na camada de rede, ultrapassou o roteador e o firewall; na camada de host, driblou o anti-spam e o antivírus; na camada de aplicação, passou ileso pelo servidor de mensagens; na camada de dados, penetrou no repositório de mensagens;

• ineditismo: ocorrência de um incidente nunca antes concebido, para o qual, obviamente, não há provisão de contingência;

• controle ineﬁcaz: falhas na detecção de incidentes, ou de diagnóstico de situações, numa área supostamente sob controle;

• desrespeito aos procedimentos: os procedimentos são ignorados ou mal-executados.

Se, para nossa perplexidade, aviões ainda colidem em pleno voo (apesar dos controladores, dos radares, dos transponders, dos computadores de voo e das melhores práticas de segurança aérea), por que supomos que algo assim não possa acontecer em TI? Para nosso constrangimento, acontece sim.

Um exemplo histórico de incidente em larga escala nos domínios de TI foi a infecção mundial do worm “I Love You”, no ano 2000, que afetou dezenas de milhões de computadores. As grandes redes corporativas, supunha-se,

5 10 15 20 25 30

(14)

1/0

1/1

eção: Már

cio - 0

2/0

1/1

0

estavam protegidas por várias camadas de segurança: roteadores, firewalls, sistemas de combate a vírus instalados e atualizados nos servidores e nas estações, e políticas de segurança de informação em vigor. A nova praga foi eficaz na superação de todos esses obstáculos. As características que a fizeram bem-sucedida foram:

• ineditismo: empregou uma combinação de técnicas nunca antes tentadas: engenharia social (quando executado pelo usuário, enviava uma cópia de si a todos os contatos do usuário; os destinatários julgavam receber uma mensagem de pessoas conhecidas, cujo assunto era “I Love You”, e repetiam o erro do usuário anterior); infecção por arquivos de script do Windows disfarçados de texto comum;

• proteção parcial: ultrapassou a proteção de todas as camadas de vulnerabilidade;

• desrespeito aos procedimentos: mesmo em empresas com políticas de segurança da informação em vigor, os usuários sucumbiram à tentação de abrir um anexo não solicitado e não relacionado aos negócios legítimos da empresa, pelo seu presumido conteúdo emocional.

Nesse caso, iniciar o planejamento da mudança emergencial simplesmente não foi eficaz na maioria dos casos, uma vez que a extensão dos danos era imensa e crescente, e não se conheciam meios de interromper a propagação da praga. O retorno à normalidade foi gradativo e repleto de retrocessos. As empresas que aceitaram o retorno gradual dos serviços, ao invés de tentar produzir uma solução universal e definitiva, puderam priorizar ações nos recursos afeitos aos processos mais importantes, mitigando as consequências da crise.

É importante notar que soluções temporárias e retorno gradual não implicam em abandono das melhores práticas:

5 10 15 20 25 30

(15)

1/0

1/1

eção: Már

cio - 0

2/0

1/1

0

não se deve confundir “senso de urgência” com “pressa”. Essas são as situações que mais exigem capacidade de priorização e planejamento dos proﬁssionais de TI. Se não formos capazes de restaurar as funcionalidades vitais antes de restabelecermos a normalidade, poderemos estar falhando em nossa missão de atender aos interesses legítimos da empresa.

Plano de execução

Os itens que devem ser considerados no plano de execução de mudanças são:

• determinação dos recursos necessários; • elaboração do calendário das atividades; • comunicação com áreas envolvidas e afetadas;

• teste e liberação das novas funcionalidades e dos novos recursos no ambiente de homologação;

• deﬁnição de medidas de sucesso da mudança:

- determinar condições a ser verificadas para que a mudança seja considerada bem-sucedida. É fundamental analisar a cadeia de dependências e decorrências dos pontos modificados pela intervenção, para assegurar que a mudança introduzida não prejudicou itens de configuração no seu entorno; • procedimentos de contingência (Plano B) definidos e

testados:

- em caso de mudança mal-sucedida, deve haver um procedimento de retorno à situação anterior, que se supõe mais estável ou, ao menos, conhecida e previsível;

• aprovação da área de negócios da área de TI.

5

10

15

20

(16)

1/0

1/1

eção: Már cio - 0 2/0 1/1 0 2.3 Soluções de infraestrutura Deﬁnição

A infraestrutura é a base tecnológica sobre a qual os sistemas de aplicação serão executados. Seus componentes e características mais importantes são:

1. redes:

• meios de transmissão: - terrestre/cabeado; - aéreo/sem ﬁo;

• equipamentos de comunicação de dados: - modem: transmissão em meio analógico; - roteador: conexão entre redes de dados; - ﬁrewall: segurança da rede;

- switch: concentrador de segmentos físicos; 2. servidores:

• banco de dados;

• compartilhamento de recursos (arquivos e dispositivos); • serviços Web;

• telefonia;

• serviços de suporte de rede (segurança, controle).

As características fundamentais da infraestrutura que devem ser gerenciadas são:

5

10

15

(17)

1/0

1/1

eção: Már cio - 0 2/0 1/1 0 Desempenho e capacidade

Dizem respeito aos níveis de serviço acordados, que devem ser planejados para suportar os negócios a longo prazo. Segurança

É a capacidade de resistir a ameaças que possam comprometer a execução normal dos serviços, protegendo os ativos físicos e informacionais da empresa.

Conﬁabilidade

É a capacidade de executar os serviços programados de forma ininterrupta e dentro do desempenho esperado por tempo indeterminado, ou entre os períodos de parada programados.

A partir deles, busca-se projetar soluções de infraestrutura com os seguintes atributos:

Escalabilidade

É o potencial de expansão de desempenho e capacidade de um recurso tecnológico antes de necessitar ser substituído por um recurso de maior potencial.

É uma forma eﬁcaz de:

• preservar o investimento realizado, pois melhorias são mais baratas que substituições;

• diminuir a complexidade da mudança, pois a adição de componentes é simples de executar e de reverter; • aumentar a chance de êxito da mudança, pois envolve

tecnologias já conhecidas pelos proﬁssionais de TI.

5

10

15

20

(18)

1/0

1/1

eção: Már cio - 0 2/0 1/1 0 Resiliência

É a capacidade de se adaptar a situações incomuns de sobrecarga e indisponibilidade de recursos mantendo um desempenho aceitável. É a forma mais ousada de garantir a continuidade de negócios.

Esse atributo, em particular, só pode ser conseguido pela redundância de recursos: os recursos disponibilizados devem dedicar parte da capacidade e do desempenho à garantia de continuidade. Obviamente, a infraestrutura é projetada para jamais ultrapassar determinado nível de carga, pois parte da capacidade deve ser reservada para as situações em que um recurso vai ter que assumir as funções de outro. A resiliência deve ser buscada pela combinação eﬁcaz das diversas tecnologias disponíveis de redundância e balanceamento de carga, como:

• processamento distribuído: os clusters – grupo de servidores que são solidários no processamento de serviços ou aplicações – são capazes de detectar a falha de um dos membros do grupo e distribuir as tarefas dele entre os membros funcionais;

• meios de comunicação redundantes: canais de dados contratados de provedores distintos, e preferencialmente de meios de transmissão diferentes (terrestres e aéreos) com balanceamento ou roteamento automático de tráfego;

• meios redundantes de armazenamento de dados: conjunto de discos rígidos operando em conjunto (RAID – Redundant Array of Inexpensive Disks), com gravação de informação redundante distribuída uniformemente entre os discos, de modo que a falha de um ou dois discos do conjunto permita aos restantes calcular a informação indisponível por meio de algoritmos de recuperação aplicados sobre a

5 10 15 20 25 30

(19)

1/0

1/1

eção: Már

cio - 0

2/0

1/1

0

• abastecimento de energia redundante: por meio do uso de dispositivos UPS (Uninterruptible Power Supply, vulgo no-break no Brasil) associados a geradores. Equipamentos mais críticos, como servidores, também devem possuir fontes internas redundantes.

2.4 Soluções de sistemas de informação

Os sistemas de informação formam a camada de processamento de mais alto nível, pois as necessidades de negócio são formuladas e resolvidas nela. A existência da infraestrutura e dos serviços básicos de TI se justiﬁca pela existência dos sistemas de informação que atendem às necessidades do negócio.

Tipos de sistemas de informação

Os sistemas de informação suportam necessidades empresariais de todos os níveis de responsabilidade. Como discutido no capítulo anterior, a cada nível de responsabilidade se associa um grau de síntese de informação, que corresponde ao maior ou menor nível de detalhe requerido para o desempenho das funções. É possível estender essa correlação aos tipos de sistemas de informação: sendo os tipos de sistemas destinados a determinado nível de responsabilidade, consequentemente, devem trabalhar os mesmos graus de síntese de informação associados a cada nível de responsabilidade.

sintético + agregação coletivo estatística analítico + detalhe individual granular Estratégico Tático Operacional Inteligência corporativa - OLAP - Mineração de dados Gestão - ERP - Sistemas integrados Automação - Frente de loja 5 10 15 20

(20)

1/0

1/1

eção: Már cio - 0 2/0 1/1 0 Sistemas de automação

Também conhecidos como sistemas transacionais, são aqueles onde a informação se origina. Seu objetivo é automatizar rotinas operacionais, onde se registram transações individuais, como, por exemplo:

• uma venda, num sistema de automação de loja;

• uma unidade produzida, num sistema de chão de fábrica; • um contato realizado, num sistema de central de

atendimento (call center);

• um incidente relatado, num sistema de service desk. Sistemas de gestão

São destinados ao nível tático, ou seja, à supervisão e média gerência. As soluções de mercado, geralmente, “empacotam” sistemas de automação e de gestão sob o título de Sistema Integrado ou Sistema ERP (Enterprise Resource Planning). O objetivo desse tipo de sistema é o controle das transações e operações, fornecendo informação classiﬁcada, agrupada e totalizada às lideranças da empresa.

Inteligência de negócios

Também conhecido como Sistema de BI (Business Intelligence), este tipo de sistema é destinado à tomada de decisão estratégica, e processa dados mais sintéticos que no nível anterior.

Existem duas categorias de soluções neste tipo:

• OLAP (On-Line Analytical Processing): propõem-se a consolidar a informação por múltiplos atributos, e

5

10

15

20

(21)

1/0

1/1

eção: Már

cio - 0

2/0

1/1

0

fornecer respostas a questões baseadas em critérios que combinem os atributos de consolidação. A estrutura de dados gerada para este ﬁm é chamada de Cubo OLAP, a os critérios que combinam os atributos isolam uma fração do cubo, onde estarão os dados que são as respostas das questões formuladas;

• mineração de dados (data mining): propõem-se a descobrir relacionamentos ocultos entre atributos independentes num grande volume de dados. Existem vários algoritmos de mineração de dados, cada um deles especíﬁco para um grupo de casos de uso. A informação descoberta por estas técnicas quase sempre não poderia ter sido obtida de outra forma, pois se tratam de associações não triviais, não percebidas pela experiência cotidiana, por exemplo:

- o relacionamento entre os produtos cerveja e fralda descartável às sextas-feiras na rede de supermercados Wal-Mart nos Estados Unidos;

- mulheres jovens que trabalham, quando aprovadas com boas notas no vestibular da PUC-RJ, tendem a não se matricular nesta universidade.

Ciclo de vida de um sistema de informação

Os sistemas de informação em uso numa empresa podem ter, basicamente, duas origens:

• são sistemas prontos, criados por terceiros, que foram adquiridos ou licenciados para uso na empresa;

• são sistemas próprios, criados por iniciativa da empresa, por equipe interna ou por empresa especializada.

Com algumas variações que são dependentes da origem do sistema, o ciclo de vida de um sistema é basicamente o mesmo.

5

10

15

20

(22)

1/0

1/1

eção: Már

cio - 0

2/0

1/1

0

Obviamente, embora cada fase comum as duas formas tenha suas especiﬁdades, de acordo com cada caso especíﬁco, o objetivo delas é o mesmo.

Fase comum Fase de desenvolvimento Fase de aquisição Homologação Implantação Manutenção Avaliação de soluções Adaptação Arquitetura Construção Estudo de viabilidade Especiﬁcação

Figura 5: Fases do ciclo de vida de um sistema de informação

Convém notar que a decisão entre se desenvolver um sistema ou adquirir um sistema pronto deve ser tomada nas fases iniciais. Às vezes, isto não é uma decisão, e sim uma premissa.

A despeito de várias metodologias de desenvolvimento de sistemas com ampla aceitação no mercado, as quais dividem as fases do ciclo de vida de forma diferente e até o consideram um processo cíclico em espiral, a abordagem adotada nesta obra é mais linear e um tanto didática. É importante notar que não importa como as atividades se agrupam em fases nem como as fases são nomeadas, e sim como são geradas as informações que baseiam as decisões, e como o processo evolui em direção ao objetivo ﬁnal, que é ter o sistema em funcionamento pleno.

5

10

(23)

1/0

1/1

eção: Már

cio - 0

2/0

1/1

0

Fases do ciclo de vida de um sistema de informação Estudo de viabilidade

Nesta fase inicial, é importante explicitar as necessidades de negócios que a empresa persegue, e quais são as expectativas que o sistema deverá atender.

Além de determinar os objetivos principais, é importante deﬁnir o escopo do sistema. O escopo delimita a abrangência do sistema em termos de funções, usuários, áreas geográﬁcas e pontos de contato com outros sistemas. Recomenda-se deixar bastante claro, desde o início, que o que estiver fora do escopo simplesmente não será realizado, sob pena de inviabilizar as metas de prazo e custo estipuladas.

A partir das estimativas de recursos, prazos e custos, torna-se viável a decisão bem-fundamentada a respeito de se prosseguir com o projeto ou não.

Especiﬁcação

Nesta fase, os processos são mapeados e as funcionalidades são detalhadas ao ponto que se julgar necessário, o que signiﬁca que algumas poderão descrever minúcias de procedimentos, enquanto outras serão descritas sucintamente.

Além de diagramas e modelos de telas e relatórios, alguns protótipos podem ser construídos para facilitar o entendimento sobre as funcionalidades, tanto da parte funcional (usuários) como da parte tecnológica, que possuem barreiras naturais de comunicação que nem sempre são fáceis de superar.

Convém veriﬁcar se as funcionalidades deﬁnidas são

5

10

15

20

(24)

1/0

1/1

eção: Már cio - 0 2/0 1/1 0 Arquitetura

Quando a opção é pelo desenvolvimento, esta é a fase de desenho da solução. As funcionalidades são transformadas em diagramas e especiﬁcações técnicas, o que inclui as atividades de modelagem de dados e modelagem de processos.

Avaliação de soluções

Quando a opção é pela aquisição, deve-se realizar uma avaliação das soluções existentes.

A principal delas é a análise de aderência, na qual se verificam quão bem as funcionalidades requeridas se adaptam às funcionalidades oferecidas em cada sistema. Uma das características mais importantes dos sistemas em avaliação é sua capacidade de se adequar às especificações definidas caso não as atenda nativamente. Existem duas formas básicas de adaptação: a customização e a parametrização. Das duas, a parametrização é sempre preferível, pois não agrega ao sistema soluções que não serão suportadas diretamente pelo fornecedor.

Também de grande importância, a análise dos fornecedores avalia a reputação e a capacidade de atender às necessidades da empresa por tempo indeterminado. Construção

Quando a opção é pelo desenvolvimento, essa é a fase na qual as especiﬁcações técnicas são implementadas. As atividades fundamentais são a criação das estruturas de dados e codiﬁcação de programas. Também ocorrem testes localizados, de forma a assegurar que os programas tenham um nível adequado de qualidade que os capacite

5

10

15

20

(25)

1/0

1/1

eção: Már

cio - 0

2/0

1/1

0

Como a implementação depende do ambiente computacional, nessa fase, as providências relativas à adequação da infraestrutura devem ser executadas.

Adaptação

Quando a opção é pela aquisição, essa é a fase em que a adequação do sistema às especificações é realizada. É comum que os procedimentos dos usuários sejam revistos e redefinidos na busca de uma situação que atenda às necessidades de negócios especificadas e o que o sistema realmente pode oferecer com as opções de adaptação existente.

Também ocorrem testes localizados, de forma a assegurar que as funcionalidades adaptadas tenham um nível adequado de qualidade que os capacite para os testes mais extensivos da próxima fase.

Como a adaptação depende do ambiente computacional, nessa fase, as providências relativas à adequação da infraestrutura devem ser executadas.

Homologação

Uma vez vencida a fase de construção (no caso do desenvolvimento) ou de adaptação (no caso da aquisição), testes extensivos são executados de forma a verificar o funcionamento integrado do sistema. A aderência às especificações é reverificada e, em caso de problemas, a correção demandada poderá retroceder até à especificação das funcionalidades afetadas.

Implantação

A preparação do ambiente tecnológico é pré-requisito para essa fase. Toda a infraestrutura deve estar pronta

5

10

15

20

(26)

1/0

1/1

eção: Már

cio - 0

2/0

1/1

0

É importante a elaboração de um plano de implantação cobrindo as atividades de:

• comunicação: para dar ciência e engajar os proﬁssionais envolvidos na implantação e no uso do sistema, informando o cronograma das atividades a desenvolver;

• recrutamento: contratação de proﬁssionais que tenham as competências necessárias, caso não seja possível capacitar proﬁssionais em atividade;

• treinamento: a capacitação do pessoal envolvido, ou a contratação de proﬁssionais que tenham as competências necessárias. A capacitação será:

- tecnológica: para o pessoal de suporte à infraestrutura, e para o pessoal de suporte funcional;

- funcional: para os usuários e operadores do sistema; • estratégia de implantação.

Com relação à estratégia de implantação, os seguintes enfoques são possíveis:

Quanto à qualidade: • aspectos de risco:

- divergência de resultados; - situações imprevistas;

- adaptação aos procedimentos; • aderência dos procedimentos; • execução em paralelo: - na substituição de sistemas; 5 10 15 20 25

(27)

1/0

1/1

eção: Már

cio - 0

2/0

1/1

0

- operação simultânea do sistema novo junto com o vigente;

- comparação de resultados para assegurar qualidade. Quanto à abrangência:

• aspectos de risco:

- impacto geral x localizado; - capacidade de suporte;

- capacidade de correção de erros; • implantação total: - impacto geral; - sobrecarga em suporte; - sobrecarga em correção; • implantação parcial: - projeto piloto; - por módulo/função; - por região;

- por volume de atividades; - por diversiﬁcação de atividades; - impacto localizado;

-reﬁnamento progressivo do sistema sem sobrecargas. Quanto à continuidade: • aspectos de risco: - perda de negócios; 5 10 15 20

(28)

1/0

1/1

eção: Már cio - 0 2/0 1/1 0 - perda de mercado; - prejuízo ﬁnanceiro; • planos de contingência: - funcionamento paralelo; - procedimentos manuais; - retorno ao sistema anterior; - equipamentos redundantes. Operação inicial

É a primeira tentativa de operar o sistema de informação. O evento que marca a entrada em produção também é conhecido como Go Live.

É quando todos os erros do projeto se tornam evidentes. Riscos da operação inicial:

Fatores geradores: a. choque da mudança:

• funcional:

- inﬂuência do paradigma antigo; - inaptidão inicial do usuário; • técnico:

- inaptidão inicial do suporte aos usuários; - inaptidão inicial do suporte à base de dados; - inaptidão inicial do suporte à infraestrutura; - indisponibilidade do sistema.

5

10

15

(29)

1/0

1/1

eção: Már cio - 0 2/0 1/1 0 b. complexidade:

• funcionalidades suportadas de forma inadequada; • inadequação do sistema aos demais procedimentos. Fatores agravantes:

a. carga de trabalho:

• retrabalho do usuário pelos erros ocorridos e pela execução em paralelo.

b. entendimento dos resultados: • diﬁculdade de conciliação; • esgotamento da equipe; • ocorrência de conﬂitos. c. volume de erros:

• problemas não corrigidos continuam gerando erros no ambiente de produção;

• erros no ambiente de produção demandam medidas corretivas pelo suporte;

• diﬁculdade de priorização. d. pressão por prazos e resultados:

• antes da implantação: - testes inadequados; - funcionalidades reduzidas; • durante a implantação;

- necessidade de respostas rápidas do suporte e do desenvolvimento;

5

10

15

(30)

1/0

1/1

eção: Már

cio - 0

2/0

1/1

0

- necessidade de atender ao negócio;

- necessidade de cumprir metas e prazos do projeto. e. disputa por recursos:

• usuários disputam pessoal técnico para resolução de seus problemas.

f. caça às bruxas:

• quando algo dá muito errado, cada um quer salvar o próprio pescoço.

Manutenção

O objetivo dessa fase é manter o sistema em funcionamento, constantemente atendendo às necessidades dos usuários, da empresa e da lei.

O sistema entra nessa fase após a conclusão bem-sucedida da implantação. Nela, o sistema sofre intervenções para correções e melhorias.

Custo das intervenções num sistema

O custo da correção de erros quando o sistema se encontra em produção é o mais alto de todos.

Com o sistema em funcionamento, a correção da funcionalidade deve vir acompanhada da reparação adequada dos dados erroneamente produzidos e das suas consequências – que, no caso de produzirem dados errados para órgãos ﬁscalizadores e autoridades, podem incluir multas e processos judiciais, entre outros malefícios.

5

10

15

(31)

1/0

1/1

eção: Már

cio - 0

2/0

1/1

0

Sob o aspecto de custo, é melhor investir mais recursos nas fases anteriores à implantação para garantir um baixo índice de erros na implantação.

O investimento na especiﬁcação correta e na homologação adequada é interessante sob os aspectos de:

• qualidade e aderência do sistema; • melhor experiência para o usuário;

• melhoria da imagem e credibilidade da área de sistemas • menores custos de manutenção.

Quanto ao investimento na especiﬁcação, não apenas traz as melhorias citadas, mas pode signiﬁcar o sucesso ou fracasso de um sistema de informação. É o que será visto na sequência.

Sucesso e fracasso de um projeto de tecnologia da informação

Um estudo feito em 2008 pela IAG Consulting, com 109 empresas norte-americanas, analisou os fatores que levam os projetos de TI serem bem-sucedidos ou não. Os projetos estudados foram executados por empresas de grande porte, e o custo médio deles é de US$ 3 milhões. O objetivo do estudo é veriﬁcar a importância de se ter os requisitos de negócios bem-deﬁnidos no sucesso dos projetos de TI.

A conclusão surpreendente e preocupante é que 68% das empresas fracassaram na implementação dos projetos, pois não conseguiram executá-los dentro do custo e do prazo planejados. Destes, metade dos projetos estava simplesmente fora do controle, signiﬁcando que apresentavam ao menos duas das três situações: 5 10 15 20 25

(32)

1/0

1/1

eção: Már

cio - 0

2/0

1/1

0

• excederam o prazo em mais de 180%; • ultrapassaram os custos em mais de 160%;

• entregaram menos de 70% das funcionalidades requeridas.

Segundo o autor da pesquisa, a principal causa do fracasso dos projetos de TI é a baixa qualidade dos requisitos levantados durante a fase de especiﬁcação. É interessante notar que, entre as empresas que foram bem-sucedidas, apenas 50% delas conseguiram entregar o sistema dentro do custo e do prazo planejados, sendo que, neste grupo, o custo dos projetos excedeu, na média, apenas 20% do custo.

O custo pago pela especificação inadequada pode ser constatado no gráfico a seguir, que quantifica o custo e a demora adicionais resultantes.

*Average increase in the overrun on time or cost versus projects that used high quality requirements

Business requirements premium*

Premium paid in cost and time required for project relative to projects with High Quality requirements High quality

requirements requirementsLow quality

70% 60% 50% 40% 30% 20% 10% 0% Time Budget

Figura 6: Custo e demora adicionais em projetos mal-especiﬁcados

Em resumo: iniciar o projeto corretamente, ou seja, investindo na especiﬁcação adequada do que deve ser feito, pode determinar o seu sucesso ou fracasso.

5

10

(33)

1/0

1/1

eção: Már

cio - 0

2/0

1/1

0

O estudo da IAG Consulting mencionado pode ser acessado pelo site: <http://www.iag.biz/images/resources/iag%20bus iness%20analysis%20benchmark%20-%20full%20report. pdf> (em inglês).