A consultoria Gartner prevê que, até 2012, 20% das empresas não terão ativos de TI e, em quatro anos, a maioria dos projetos de TI vai incluir custos com emissão de carbono, entre outros

Redação da Computerworld
Publicada em 05 de fevereiro de 2010 às 09h05

As novas ferramentas de comunicação e as preocupações com o meio ambiente devem servir como principais motivadores em termos de tendências de TI para os próximos cinco anos. A constatação faz parte de um relatório emitido pela consultoria Gartner e que prevê os nove grandes movimentos que devem acontecer no setor de tecnologia até 2015.

Acompanhe os principais tópicos que devem mudar o mercado de TI, de acordo com o Gartner:

1- 20% das empresas não terão ativos de TI (até 2012)
Virtualização, cloud computing e profissionais usando sistemas de desktops e notebooks em redes corporativas são algumas das inúmeras tendências que vêm impulsionando o movimento de redução dos ativos de TI. A necessidade de equipamentos, seja nos data centers ou nas mesas dos funcionários, não desaparecerá. Mas o Gartner avalia que se a propriedade do hardware passar para terceiros, haverá mudanças em toda a indústria.

A consultoria avalia que os orçamentos de TI das empresas tendem a sofrer reduções ou serão realocados para projetos mais estratégicos. Ao mesmo tempo, a equipe de tecnologia será reduzida ou reeducada para atender a novas exigências.

2- As companhias de serviços de TI da Índia vão representar 20% dos principais agregadores em nuvens do mercado (até 2012)
As empresas indianas vão consquistar posições de mercado e níveis de confiança estabelecidos para explorar modelos de crescimento de receitas não lineares. Essas companhias também direcionarão esforços de pesquisa e desenvolvimento, especialmente na área de computação em nuvem. O trabalho coletivo dos fornecedores centralizados na Índia representa um segmento importante dos agregadores em nuvens do mercado, que oferecerão opções de terceirização que viabilizem a oferta de serviços baseados em cloud computing.

3- O Facebook vai se tornar o hub para integração de redes sociais e socialização Web (até 2014)
Por meio do Facebook Connect e outros mecanismos similares, o Facebook dará suporte e terá papel fundamental no desenvolvimento da web social distribuída e interoperável. Com o contínuo crescimento da rede social, essa interoperabilidade será crítica para o sucesso e a sobrevivência de outras sociais, canais de comunicação e sites de mídia.

Outras redes sociais (incluindo o Twitter) vão continuar a evoluir, mas tendem a se especializar na oferta de comunicação e conteúdo, enquanto o Facebook representará um denominador comum a todas elas.

4- A maioria dos cases de negócios de TI vai incluir os custos da correção do carbono (até 2014)
Virtualização de servidores e gerenciamento da energia de desktops trazem redução de custos com energia e essas economias podem ajudar a justificar os projetos. A incorporação dos custos do carbono aos negócios fornece mais uma medida das economias e prepara a organização em relação ao seu impacto de carbono.

Pressões econômicas e políticas para demonstrar responsabilidade pelas emissões de dióxido de carbono vão forçar mais empresas a quantificar os custos do carbono nos seus negócios e fornecedores terão de fornecer estatísticas sobre o ciclo de vida do carbono de seus produtos ou encarar a erosão de sua participação no mercado. A incorporação dos custos do carbono nos negócios vai apenas acelerar levemente os ciclos de substituição.

Uma estimativa razoável para o custo do carbono em operações típicas de TI seria um ou dois pontos porcentuais dos custos gerais. Portanto, a prestação de contas sobre o carbono vai, provavelmente, alterar o market share, mas não o tamanho do mercado.

5- 60% das emissões de gases estufa na vida total dos PCs terão ocorrido antes que o usuário ligue a máquina pela primeira vez (em 2012)
Durante seu ciclo de vida, um PC típico consome dez vezes seu próprio peso em combustíveis fósseis, mas cerca de 80% do uso energético total de um computador ocorre durante sua produção e transporte. A maior consciência entre os compradores e aqueles que influenciam a compra, a maior pressão dos rótulos ecológicos (eco-labels), as crescentes pressões de custo e a pressão social alertaram a indústria de TI para o problema das emissões de gases estufa. A consciência ambiental e a pressão legislativa vão aumentar o reconhecimento das emissões de dióxido de carbono na produção e nas atividades de uso. Os provedores de tecnologias devem prever que terão de fornecer dados sobre as emissões de dióxido de carbono para um número crescente de clientes.

6- O marketing pela internet será regulamentado, controlando mais de US$250 bilhões em gastos mundialmente (até 2015)
A pressão por uma maior prestação de contas significa que a reação de consumidores incomodados provavelmente vai direcionar a legislação para regulamentar o marketing pela internet. As companhias que focam a internet primariamente com objetivos de marketing deverão se ver impedidas de comercializar com os clientes de forma eficaz, ficando em desvantagem competitiva quando as novas leis entrarem em vigor. Apesar do alto crescimento, os fornecedores que concentram-se unicamente e vendem predominantemente soluções de marketing via internet vão se defrontar com um mercado em declínio, pois as companhias vão dirigir os fundos de marketing a outros canais para compensar.

7- Mais de 3 bilhões de pessoas poderão realizar transações eletronicamente via celulares ou internet (até 2014)
As economias emergentes verão rapidamente o crescimento da adoção de celulares e da internet até 2014. Ao mesmo tempo, progressos em pagamentos, comércio e operações bancárias via dispositivos móveis estão facilitando as transações eletrônicas via celular ou Internet no PC. A combinação dessas duas tendências cria uma situação na qual uma maioria significativa da população adulta do mundo vai poder efetuar transações eletrônicas até 2014.

O Gartner prevê que, até 2014, haverá uma taxa de penetração de dispositivos móveis de 90% e 6,5 bilhões de conexões móveis. A penetração não será uniforme, pois continentes como a Ásia (excluindo-se o Japão) verão uma penetração de 68% e a África, 56%. Embora nem todas as pessoas que tenham um celular ou acesso à internet vão efetuar transações eletrônicas, cada uma delas poderá fazer isso. As transações em dinheiro continuarão a ser dominantes nos mercados emergentes até 2014, mas as bases para as transações eletrônicas estão em andamento para a maioria do mundo adulto.

8- O contexto será tão influente para serviços móveis de consumo e relacionamento quanto mecanismos de busca são para a web (até 2014)
Enquanto a busca fornece a “chave” para organizar informações e serviços para a web, o contexto será a “chave” para oferecer experiências personalizadas por meio de smartphones ou qualquer interação que um usuário final tenha com a tecnologia da informação. Os sistemas de busca são centrados na criação de conteúdo que chame a atenção e possa ser analisado. O contexto vai se concentrar em padrões de observação, particularmente localização, presença e interações sociais. Embora a busca tenha sido baseada em um conjunto de informações da web, os serviços enriquecidos com contexto vão, em muitos casos, pré-propagar ou extrair informações para os usuários.

A posição mais poderosa no modelo de negócios de contexto será a de provedor de contexto. Provedores de Web, dispositivos, plataformas sociais, serviços de telecomunicação, fornecedores de software e de infraestrutura de comunicação vão competir para serem provedores de contextos significativos nos próximos três anos. Qualquer fornecedor da web que não se torne um provedor de contexto arrisca-se a ceder a propriedade efetiva do cliente a outro provedor de contexto, o que vai impactar os negócios clássicos e móveis dos fornecedores.

9- Os telefones celulares vão ultrapassar os PCs como dispositivo mais comum para acesso à web (até 2013)
De acordo com as estimativas do Gartner, o número total de PCs em uso chegará a 1,78 bilhão de unidades em 2013. Até 2013, a base instalada combinada de smartphones e telefones equipados com navegadores vai ultrapassar 1,82 bilhão de unidades e, dali em diante, será maior do que a base instalada de PCs. Tipicamente, os usuários de dispositivos móveis estão preparados para dar menos cliques em um site web do que os usuários que acessam em um PC. Embora um número crescente de sites e aplicações baseadas na web ofereça suporte para dispositivos móveis pequenos, muitos ainda não o fazem. Os sites que não forem otimizados para formatos de tela menores vão se tornar uma barreira de mercado para seus proprietários – muito conteúdo e muitos sites terão que ser reformatados/reconstruídos.

Fonte: CIO

De acordo com relatório, por uma pressão das empresas, os CIOs deverão ter 40% de suas equipes provenientes de outras áreas da companhia ou sem experiência em tecnologia

Redação da CIO Brasil
Publicada em 20 de janeiro de 2010 às 08h00

Por conta de um envolvimento cada vez maior da TI com questões relacionadas ao negócio, o CIO precisará diversificar sua atual equipe. A constatação faz parte de um relatório divulgado pela consultoria Gartner e no qual são identificados quatro novos perfis de profissionais que devem ser incorporados à área de tecnologia da informação, mas que não têm conhecimentos técnicos.

O relatório do Gartner faz uma previsão de que, até o final de 2010, 40% das pessoas que se reportam à área de TI – seja de forma direta ou indireta – terão um foco bastante direcionado ao negócio ou não apresentarão um perfil tecnológico.

Focados em questões legais
Segundo o Gartner, 20% das duas mil maiores companhias do mundo devem incorporar a seus organogramas a função de gestor de suporte legal. O número fica bem acima dos 5% registrados em 2005.

As atribuições desse profissional contemplam a criação de políticas para a estruturar parcerias, a adequação operacional a normas regulatórias e a mediação das relações entre as áreas de TI e departamento jurídico. Em vez da contratação desses profissionais, as empresas podem optar pelo treinamento de executivos de segurança da informação em legislação.

Focados em arquivos digitais
Arquivistas digitais serão necessários para organizar e preservar arquivos digitais corporativos para fins legais e regulatórios. De acordo com as expectativas do Gartner, até 2012, 15% das empresas terão em seus quadros de pessoal funcionários responsáveis pelo arquivamento eletrônico de documentos. Em 2009, a presença desses profissionais não foi detectada em nem 1% das companhias.

Quanto ao perfil de quem pode ocupar essa posição, estão pessoas com formação em biblioteconomia ou antigos funcionários já em fase de aposentadoria.

Focados em gestão das informações de negócio
Com base em pesquisa realizada pelo Gartner de junho a agosto de 2009, 20% dos gestores de negócios classificaram como “pobres” as informações que recebem dos departamentos de TI. Assim, os CIOs cada vez mais serão cobrados por, dentro de suas equipes, criar uma área específica para gestão de dados.

Ainda de acordo com a consultoria, até 2013, 20% das organizações já devem ter criado essa função.

Focados na arquitetura de dados corporativos
Assim como acontece na TI, as áreas de negócios também precisarão de profissionais responsáveis por questões como taxonomia, modelos de documentos e templates de apresentação. No entanto, a principal atribuição desse colaborador será de desenvolver maneiras para a utilização dos dados – estruturados ou não – armazenados nos data centers da companhia. Em alguns casos, o arquiteto de informação pode ser a mesma pessoa que assumiu a gestão dos dados.

Fonte: CIO

Matthew Hotle
27 de julho de 2009

Transformar uma empresa em uma organização de projetos e uma organização de suporte não é incomum. Existem várias razões para que isso aconteça, mas essa mudança definitivamente não é a solução para orçamentos restritos.

Considerações básicas
- Modificar a estrutura da sua empresa deve ser a última opção a se levar em conta.
- Habilidades e disposição são mais importantes do que uma estrutura teoricamente perfeita.

Recomendações
- Não faça mudanças organizacionais para resolver falhas de processo. Foque no procedimento antes de tudo.
- Alterne tarefas, por exemplo, para estimular a disposição dos funcionários caso opte por um modelo de segmentação.
- Verifique se os contratos entre provedor e clientes (em inglês service-level agreements – SLAs) continuam válidos antes de dar início à mudança organizacional.

O que você precisa saber

Os clientes normalmente perguntam se deveriam dividir sua equipe em projetos (a que normalmente se referem como desenvolvimento, mas na verdade são estratégias de aperfeiçoamento e para obter novos contatos) e suporte.

Empresas que já seguem esse modelo de estrutura questionam se esta é a melhor escolha ou se deveriam retornar a um estilo de organização mais diversificado. Essa é uma decisão do tipo “será que a grama do vizinho é mais verde?”. A maioria das companhias que consideram a possibilidade de organizar sua estrutura dessa maneira estão na verdade tentando solucionar um de diversos problemas de processo.

- Os projetos estão atrasados (embora nunca estourem o orçamento) porque os recursos destinados a eles acabam sendo gastos com suporte.

- Funções de suporte exigem habilidade para lidar com múltiplas tarefas ao mesmo tempo.

- Recursos de suporte costumam ser fragmentados.

- Habilidades de suporte ou estão indisponíveis ou deixarão de existir em breve devido à transferencias ou a aposentarias.

- Relações disfuncionais entre grupos levam a conflitos morais e de gerenciamento.

Apenas modificar a estrutura da empresa não vai resolver nenhum desses problemas. Ao contrário, se esta for a única mudança da situação, eles ficarão mais graves em seis a 18 meses, simplesmente porque além de apresentar processos falhos a empresa terá de lidar com a ruptura de um padrão. Há bons motivos para alterar o modelo estrutural de uma companhia (esta não é uma pesquisa sobre quando mudar, mas sim sobre como mudar), porém essa decisão deve ser tomada cautelosamente, se levando em conta o potencial de solucionar problemas com novos processos.

ANÁLISE

A primeira regra para mudar o design de uma organização: não faça isso!

Nem sempre isso é verdade, obviamente. Entretanto, mexer constantemente nas relações hierárquicas essenciais ao bom funcionamento da companhia é um dos erros corporativos mais comuns. Essa é uma saída relativamente fácil porque os gerentes influenciam diretamente essas estruturas. Além disso, é um tipo de mudança que rapidamente se pode notar. Mas há dois inconvenientes:

- Mudar a estrutura de uma empresa implicará de seis a 18 meses de adaptação. Alguns funcionários se sentirão bem com seus novos chefes, outros nem tanto. Quando essas hierarquias são modificadas, há sempre um período posterior de familiarização. Haverá ainda uma fase na qual as tarefas deverão se encaixar ao novo modelo estrutural.

- Os processos falhos permanecem ineficazes. Esse é o ponto crucial. Muitas companhias tentam alterar sua estrutura porque precisam resolver problemas de processo, mas isso não funciona. Primeiro solucione a falha no procedimento, depois avalie se vale a pena implementar uma mudança estrutural.

Grande parte da atividade em que se fundamenta uma organização se origina de relacões informais e processos implícitos. As estruturas atribuem status ou poder a determinados cargos. Muitas empresas não estão cientes desse elemento subliminar e normalmente os prejudicam ou destroem durante restruturações. Justamente as estruturas e processos que precisam ser eliminados costumam sobreviver às mudanças. Várias empresas almejam solucionar problemas de planejamento e de recursos humanos segmentando suas estruturas. Vamos supor que essa separação é válida. Como ela deve acontecer?

Fundamentos de uma separação de projetos e suporte

Se você pretende segmentar sua empresa, precisa seguir os seguintes passos:

- Definir claramente o que é um “projeto” e quais atividades estão relacionadas com o “suporte”. Isso pode parecer simples, mas as empresas costumam chamar de projeto conjuntos amorfos de tarefas ou qualquer atividade que precise ser coordenada. Suponhamos que um projeto é uma tarefa que exige no mínimo 320 horas. Há uma explicação para isso. Baseando-se nas oito horas do plano de tarefas do Instituto de Gerenciamento de Projetos, chegamos a conclusão de que um projeto inclui cinco fases (demanda, avaliação/planejamento, organização, testes e implementação), e cada fase implica três atividades. Cada atividade envolve três tarefas (cinco fases: três atividades por fase e três tarefas por atividade), o que nos leva a um total de 320 horas. Todo o restante é suporte. Normalmente, há três tipos de suporte: reparação de falhas, pequenas mudanças ou aperfeiçoamento e questões relacionadas com as SLAs. Temas regulatórios entram em ambas as categorías. Caso a demanda por pequenas mudanças seja constante, deve ser incluída em suporte; senão devem ser classificadas como projetos e receber prioridade máxima.

- Para cada demanda, crie uma SLA. Recapitulando: suporte é solução de problemas, aperfeiçoamentos simples e outras atividades relacionadas com SLAs (responder a dúvidas de clientes, analisar possibilidades e assim por diante). Essas demandas precisam ser claramente definidas e traduzidas para uma SLA que eficazmente permita que a empresa ofereça o nível de serviço a que se propõe.

- Com base nas SLAs e na demanda, classifique a organização. Infelizmente a maioria das empresas que querem segmentar sua força de trabalho começam por essa etapa. Saber quantas pessoas devem ficar no setor de suporte é impossível antes de: 1 perceber a gravidade e a frequência das falhas dos projetos 2 quantas pessoas a empresa pretende pagar para implementar melhorias 3 quais outros serviços devem ser oferecidos, quando e como. Pode ser que tudo isso pareça simples. Mas agora devemos prestar atenção no principal desafio da mudança: as pessoas envolvidas nesse processo. Reparação de erros é uma atividade que exige profissionais que se sentem confortáveis trabalhando sob pressão e que são pragmáticos. Essas habilidades podem não ser raras, mas é comum haver pessoas dispostas a trabalhar no setor de suporte que não possuem essas habilidades básicas. O principal problema, entretanto, é que a maioria dos profissionais de TI não quer realizar apenas tarefas de suporte. Eles interpretam essa atividade como algo sem futuro e limitado. Além disso, os profissionais de desenvolvimento tendem a se considerar superiores aos do setor de suporte. Quando uma empresa segmenta sua estrutura, precisa pensar em como fazer com que seus funcionários se sintam confortáveis com tarefas de suporte e inclusive queiram realizá-las. Existem alguns truques para isso:

- Pague bônus à equipe de suporte. Muitas empresas rejeitam essa ideia, principalmente porque subvalorizam o trabalho que esses profissinais desempenham.

- Crie o hábito de delegar tarefas diferentes ou mais complexas a membros da equipe de suporte por um período, seguindo um rodízio. Tipicamente, esses períodos duram de 12 a 18 meses. Não deixe que sejas mais longos. Quando isso acontece, se perde toda a credibilidade do processo de rodízio. Com o tempo, esses períodos podem se tornar mais curtos.

- Convença profissionais a desempenharem funções de suporte dizendo a eles que após concluírem o rodízio poderão se aperfeiçoar em tarefas que lhe interessam.

Faça a mudança acontecer

Uma empresa não precisa ser completamente segmentada. Há ocasiões em que apenas alguns setores precisam adotar esse modelo estrutural:

- Quando um único projeto grande tem uma trajetória de implementação dividida em fases e a empresa quer estabelecer sua estrutura logo no início para conseguir alcançar seus objetivos a longo prazo. Nesse caso, se a estrutura de longo prazo for segmentada, é melhor começar o processo criando um grupo de suporte separado logo após a instalação. Esse grupo deve ser formado por membros da equipe de desenvolvimento que realizam diferentes tarefas seguindo um esquema de rodízio.

- Desenvolvimentos rápidos ou repetitivos podem resultar em diferentes mesclas de recursos. Projetos rápidos normalmente exigem tarefas de tempo integral e monopolizam os recursos; não é aconselhável que esses mesmos recursos atendam às atividades de produção. Portanto, a equipe de desenvolvimento poderia lidar com falhas e aperfeiçoamentos simples enquanto um outro grupo seria responsável por necessidades de suporte críticas.

- Em algumas empresas, há certas atividades nas quais a demanda de recursos para suporte é mínima. Ou seja, normalmente uma única pessoa é responsável por essa tarefa. Treinar outros profissionais parece desnecessário e às vezes acabam utilizando recursos externos.

- Em muitas companhias, a necessidade de dar suporte a aplicações ERP exige segmentação, porém o modelo segmentado se baseia em escalas, independentemente de elas serem suficientes ou não.

Em seguida, é preciso organizar o tempo disponível. Mudanças impactantes têm consequências impactantes. Tente implementá-la por partes. Também é necessário tomar uma decisão de recursos muitas vezes difícil: em alguns casos, as empresas optam por terceirizar completamente o setor de suporte, e fazem isso por motivos realmente válidos. Embora essa decisão esteja fora da abrangência desta discussão, externalizar os processos é algo a ser analisado, planejado e executado cuidadosamente.

Conclusão

Separar uma empresa em uma de projetos e outra de suporte não otimiza recursos e atividades. Se essa mudança é implementada sem que se leve em consideração as questões aqui expostas, as falhas de recursos permanecerão e serão agravadas pela ruptura do fluxo de trabalho e de relações hierárquicas. Frequentemente, os problemas de planejamento de recursos podem ser resolvidos sem uma mudança estrutural. No caso de a separação ser a melhor alternativa, o planejamento e a execução detalhados serão a diferença entre obter um bom resultado ou apenas criar um novo conjunto de padrões ineficazes.

Fonte: Info Corporate

Publicada a versão 2009 do Gartner Magic Quadrant for IT Project and Portfolio Management.

O Magic Quadrant é a representação gráfica de um mercado durante um período de tempo específico.

Ele descreve a análise da Gartner de como determinados fabricantes são avaliados com base em critérios definidos pela própria empresa para esse mercado. A Gartner não endossa nenhum fornecedor, produto ou serviço descrito no Magic Quadrant nem recomenda que os usuários de tecnologia selecionem apenas os fornecedores dispostos no Quadrante dos “Líderes”.

O Magic Quadrant é meramente uma ferramenta de pesquisa e não tem como objetivo ser um guia específico de decisões estratégicas.

Os fabricantes são classificados em quatro quadrantes como: “Líderes”, “Desafiadores”, “Visionários” ou “Fornecedores de nicho”.

• Líderes. São aquelas empresas que têm uma atuação consistente no mercado, assim como uma visão clara de direcionamento de marketing. Essas empresas devem, ainda, manter um desenvolvimento de competências para sustentar sua posição de liderança no mercado.
• Desafiadores. Os desafiadores executam bem, mas ainda não demonstram uma visão particular neste mercado.
• Visionários. Estes fornecedores já demonstraram inovação neste mercado, mas ainda terão que apresentar o mix da viabilidade global, dimensão funcional, execução de vendas, e acompanhamento dos registos para passarem para o quadrante dos líderes.
• Fornecedores de nicho. Os fornecedores que se encontram neste quadrante tendem a ter pontos fortes em muitos aspectos do mercado, sem disponibilizarem um suporte mais abrangente. Alternativamente, tendem a ter uma experiência mais limitada em termos geográficos, através da falta de enfoque neste mercado, ou porque são novos no mercado.

Veja na integra em: http://mediaproducts.gartner.com/reprints/microsoft/vol6/article11/article11.html

Fonte: Twitter do Ricardo Vargas

Para Ione Coco, ao contrário do que acontece na maior parte dos casos, as áreas de negócio – e não o CIO – precisam decidir quais projetos de tecnologia da informação devem ser implementados primeiro na organização

Tatiana Americano, da CIO Brasil
Publicada em 08 de junho de 2009 às 17h09

A priorização dos projetos de TI sempre foi uma questão polêmica para as organizações e, de forma geral, representa um ponto de conflito entre os responsáveis pela tecnologia da informação e as áreas de negócio. No entanto, Ione Coco, vice-presidente do Gartner para América Latina, considera que a origem do problema está na falta de entendimento sobre as responsabilidades por esse tipo de decisão.

“Existe uma distorção nas empresas, uma vez que a área de TI assume um papel de definir quais os projetos são prioritários para a companhia”, afirma Ione, que explica: “Mas essa responsabilidade não pode ser do CIO e, sim, do negócio, que deve analisar quais as iniciativas são estratégicas e devem ser implementadas primeiro.”

Ainda de acordo com Ione, o papel da área de TI deve ser o de prover as informações necessárias para a construção do escopo do projeto. “Só que quem precisa defender o investimento como prioritário para a companhia é o dono da iniciativa”, complementa a vice-presidente.

Uma das formas apontadas pela especialista para solucionar esse problema é a criação de uma área voltada exclusivamente a gerenciar os projetos da organização – não só da área de TI – e que esteja ligada ao presidente ou ao CEO da companhia.

Fonte: CIO

Matthew Hotle
8 de maio de 2009

Descobertas chave

• Mudar sua estrutura organizacional deveria ser o último recurso.
• Recursos humanos qualificados e determinação são mais importantes do que uma melhor estrutura organizacional.

Recomendações

• Não faça mudanças organizacionais para solucionar problemas nos processos. Foque primeiro o próprio processo.
• Use atribuições rotativas de tarefas e outros incentivos para gerar determinação se a segmentação for sua opção.
• Assegure-se de que os acordos de nível de serviço (SLAs) tenham sido implementados antes de realizar a mudança organizacional.

O QUE VOCÊ PRECISA SABER
Os clientes costumam perguntar se deveriam dividir seu pessoal entre projetos (geralmente associados a desenvolvimento, na verdade se referem a trabalho líquido e novo, e a projetos de aperfeiçoamento) e suporte. As empresas que já se encontram nessa situação perguntam se seria melhor dividir o pessoal ou se deveriam voltar a ser uma empresa de estilo misto. Se isso soar mais como um estilo de tomada de decisões do tipo “será que a grama está mais verde”, então é mesmo. A maioria das empresas que cogita dividir suas estruturas organizacionais seguindo esses preceitos está na verdade tentando solucionar uma de várias questões relativas a seus processos:

• Os projetos estão atrasados (embora sem ultrapassar o orçamento) porque os recursos alocados para eles foram transferidos para a área de suporte.
• As qualificações da área de suporte estão totalmente unificadas, sem nenhum backup ou contingência.
• Os requisitos de recursos para suporte estão fragmentados.
• O pessoal qualificado para a área de suporte ou não está disponível, ou logo não estará mais disponível devido a aposentadorias ou transferências.
• Relacionamentos problemáticos entre os diferentes grupos geram problemas significativos de gestão e estado de espírito.

Mudar simplesmente a estrutura organizacional não irá solucionar nenhum desses problemas. De fato, mudar a empresa irá, todas as outras coisas mantendo-se as mesmas, tornar os problemas ainda piores durante seis a 18 meses, simplesmente porque, além de possuir processos problemáticos, a empresa enfrentará a distração de um novo quadro organizacional. Há bons motivos para mudar um empresa (esta pesquisa não se refere a quando mudar, mas a como mudar), mas fazer isso deve ser algo cuidadosamente avaliado e ponderado com o potencial das mudanças nos processos de solucionarem efetivamente os problemas, e não apenas mudarem o pessoal de lugar.

ANÁLISE
A primeiro regra para mudar um desenho organizacional: Não faça isso!

É claro, isso nem sempre é verdade. Porém, modificar os relacionamentos de reporte e o lugar das pessoal com certa freqüência é um dos principais problemas que as divisões de aplicações enfrentam. É relativamente fácil porque os relacionamentos e a dimensão do controle são algo sobre os quais os gestores têm controle direto, e o mais importante, é fácil ver que uma mudança está sendo feita. Porém, há dois problemas aqui:

• Mudar a estrutura de uma empresa resultará entre 6 a 18 meses de ruptura. Alguns se associam a seus chefes; enquanto outros não se sentem à vontade com eles. Independente disso, quando os relacionamentos de reporte organizacional forem modificados, haverá um período de acomodação entre os novos associados e sua gestão. Haverá também um período de tempo em que as partes da empresa sujeitas às modificações deverão se realinhar para que o trabalho possa fluir novamente pela nova estrutura de gestão.
• Os maus processos continuam sendo maus. Isso é realmente fundamental aqui. Muitas empresas tentam mudar seus quadros organizacionais para solucionar um problema dos processos, mas isso não funciona. Solucione o problema primeiro, e então escolha uma estrutura organizacional que funcione.

Grande parte das atividades nas empresas tem origem em relacionamentos informais e em processos implícitos. Status ou poder já foram atribuídos nas estruturas já existentes. Muitas empresas têm muito pouca consciência desses aspectos, e os danificam ou destroem durante os processos de reorganização. Infelizmente, algumas das estruturas e processos que deveriam ter sido modificados sobrevivem ao processo de reorganização.

Para colocar isso tudo no contexto desta discussão, muitas empresas estão de problemas de RH e de planejamento através da segmentação de suas estruturas organizacionais. Vamos presumir que haja bons motivos para dividir a empresa, incluindo aqueles citados acima. Qual é a mecânica dessa separação?

Aspectos Fundamentais de uma Divisão das Áreas de Projetos/Suporte
Se você estiver prestes a segmentar sua empresa, então o seguinte conjunto de passos será crucial ao fazer isso:

• Defina claramente o que é um projeto e quais atividades serão atribuídas à área de suporte. Isso poderá parecer fácil, mas muitas empresas referem-se a um projeto como alguma espécie de massa amorfa de trabalho, ou como qualquer coisa que precise ser administrada. Para os fins desta discussão, vamos presumir que um projeto é algo que contenha um mínimo de 320 horas. Há algum sentido nisso: usando o mínimo necessário de oito horas para o planejamento de tarefas estabelecido pelo Project Management Institute (PMI), vamos presumir que um projeto possua cinco fases (requisitos, análise/design, código, teste e implementação), e que cada uma dessas fases possua apenas três atividades. Cada atividade possui três tarefas associadas a ela. Temos agora um total de 15 tarefas (cinco fases: três atividades por fase e três tarefas por atividade), o que gera um total de 320 horas. Tudo o mais fica a cargo da área de suporte. Geralmente, há três tipos de atividades de suporte: reparo de defeitos, pequenas mudanças ou aperfeiçoamentos, e outros trabalhos necessários para atender aos SLAs. O trabalho de conformidade ou observância regulatória poderá na verdade entrar em qualquer uma das categorias de projetos ou suporte. Se houver uma necessidade consistente de pessoal para realizar essas mudanças, então essas mudanças poderão ir para a área de manutenção. Se a demanda for esporádica, então será melhor lidar com elas como se fossem projetos, colocando-as no topo da cadeia de prioridades.
• Para cada aplicação ou grupo de aplicações, crie um SLA. Ou seja: Suporte consiste no reparo de defeitos, pequenos aperfeiçoamentos, e outros trabalhos necessários para prover suporte aos SLAs (resposta a questões corporativas, realização de análises conjunturais e assim por diante). Aqueles serviços devem ser claramente definidos e codificados em um SLA que proveja à empresa e à divisão de aplicações um mecanismo para atender aos níveis de serviços desejados pela empresa. Isso proverá também um mecanismo para dimensionar a divisão de suporte.
• Com base nos requisitos dos SLAs e de trabalho, dimensione a estrutura organizacional. Infelizmente, é daqui que parte a maioria das empresas que desejam segmentar seu pessoal. Determinar quantas pessoas devem estar na divisão de suporte é um terreno desconhecido até que você determine: (1) a taxa de contratação segundo a gravidade dos defeitos; (2) quantas pessoas a empresa está disposta a pagar para realizar os pequenos aperfeiçoamentos; e (3) quais outros serviços devem ser realizados, quando e como (veja “Administrando a Inexorável Demanda por Trabalho em Aplicações”).

Até agora, tudo isso é razoavelmente simples. Agora, porém, chegamos ao que é talvez o maior impedimento para a realização de uma segmentação: os próprios associados. O reparo de defeitos requer pessoas que estejam acostumadas e dispostas a trabalhar sob pressão, e que sejam muito bons solucionadores de problemas. Geralmente não há pouca oferta de tais recursos humanos, mas é algo que vale a pena observar porque poderá haver pessoas dispostas a realizar o trabalho de suporte e que não possuam as qualificações básicas. O maior problema, porém, é que muitos profissionais de TI simplesmente não desejam realizar somente o trabalho de suporte. Eles consideram uma tarefa de suporte como uma via sem saída, um predecessor da terceirização ou uma mudança que limitará suas perspectivas. Por outro lado, os que pertencem à comunidade de desenvolvedores poderão vir a ver a si mesmos como superiores aos profissionais da divisão de suporte. Ao realizar o trabalho de segmentação, as empresas precisam pensar em como poderão fazer com que seu pessoal se sinta confortável realizando uma tarefa de suporte e disposto a aceitá-la. Há um alguns mecanismos chave para fazer isso:

• Pague um bônus ao pessoal de suporte. Muitas empresas recusam-se a fazer isso, pois consideram que o trabalho de suporte não possui valor agregado.

Fonte: Info Corporate

Stewart Buchanan, do Gartner
22 de dezembro de 2008

Para o Gartner, a administração dos investimentos em TI deve ser contável, completa, atual, competitiva e atrativa. Saiba como atingir e mensurar os bons resultados

Tratar os investimentos em ativos de TI e os contratos de vendedores com a abordagem “ajuste e esqueça” é inadequado. O ideal é tornar todo o gasto em TI mais confiável através da medição e do aperfeiçoamento dos gastos levando em conta os objetivos do negócio e os ciclos de vida de ativos e contratos.

Descobertas chave

• A confiança no investimento em TI depende muito do sucesso nos projetos iniciais. Após entrar em produção, um projeto requer uma gestão, relatórios e aperfeiçoamento contínuos.
• Aquisições de novos projetos e ativos de TI resultam em relações de longo prazo com vendedores e comprometimentos de custos contínuos que prosseguem no decorrer de todo o ciclo de vida do contrato e dos ativos.
• A pressão para a obtenção de fundos ou para o alcance de economias de baixo custo tende a aumentar os custos gerais de TI, prejudicando a confiança dos negócios em TI
• As organizações que aliam sistematicamente os custos de TI com objetivos de negócios podem melhorar de maneira significativa seu acesso a fundos e sucesso em investimentos de ativos.

Recomendações

• Envolva especialistas em compras de TI e gestão de ativos para assegurar que as projeções de custo do projeto inicial e os estudos de viabilidade sejam realistas e precisos.
• Direcione os estudos de viabilidade e métricas para a produção, para que sejam mantidas e medidas levando em conta os indicadores chave de custo e os indicadores chave de risco. Não apenas indicadores chave de desempenho.
• Mantenha e atualize o estudo de viabilidade para cada projeto, trabalhando com acionistas e titulares de orçamento para aperfeiçoar suas posições de ativos em resposta às diferentes condições e objetivos de negócios.
• Reporte todos os ativos de TI e seus custos, e não apenas investimentos em projetos. Os indicadores chave são mais efetivos quando possibilitam aos gestores aliarem custos de ativos com métricas de desempenho relacionadas.

Cinco Princípios de Medição

Administrar os custos com relação aos objetivos requer fatores que sejam contáveis, completos, atuais, competitivos e atrativos.

• Contável é uma suposição — assumimos que os custos são contados. A maior parte das organizações conta seu gasto, mas não seus custos. Isto requer preparação e planejamento cuidadosos. Seu orçamento operacional ou modelos de custo podem não refletir o que cada ativo realmente custa.
• Completo é o princípio mais importante na contribuição para a confiança nos negócios ao se evitar custos não orçados. A metodologia de custo total de propriedade (TCO) do Gartner proporciona um modo compreensivo de se capturar os custos totais dos ciclos de vida.
• Dados Atuais são necessários. Atual se refere ao trabalho com acionistas e titulares de orçamento para atualizar os estudos de viabilidade e objetivos em relação aos quais os investimentos de ativos são medidos.
• Competitivo é um princípio chave, pois a organização de TI freqüentemente compete por fundos e orçamentos operacionais limitados. A competitividade também é um importante objetivo de negócio, mesmo no setor público, no qual as organizações são contabilizáveis por gastar dinheiro público.
• Atrativo significa que seus números e métricas devem ser claros e sem ambigüidade. Suposições, margens de erro e riscos também devem ser contabilizados em modos verificáveis, com indicadores chave de custo e de risco, assim como KPIs.

Fonte: INFO Corporate

INFO Corporate
15 de dezembro de 2008

O uso adequado de incentivos e penalidades em contratos de terceirização é fundamental para o sucesso das transações com provedores de serviços

Como os incentivos e penalidades costumam ser usados incorretamente, frequentemente as seguintes perguntas são feitas ao Gartner:

• “O que são incentivos e penalidades?”
• “Como devem funcionar?”
• “Eles são eficazes?”
• “Quais são as melhores práticas para usá-los?”
• “Quais cláusulas do contrato eu deveria usar?”
• “Como deveria usar as cláusulas do contrato?”
• “Qual efeito elas terão sobre o relacionamento?”

Neste estudo, responderemos essas perguntas e proporcionaremos um modelo básico para ter sucesso numa terceirização

Descobertas Chave

• As empresas que usam penalidades muito altas ou muito baixas ou que não usam penalidades descobrem que não conseguem influenciar o comportamento do provedor externo de serviços (ESP). Isso resulta em transações que correm o risco de fracassar.
• As empresas que usam os incentivos para contrabalançar as penalidades, freqüentemente pagam incentivos altos que produzem um valor corporativo menor do que a quantia desembolsada como incentivo.
• As empresas que não proporcionam oportunidades de compensação para seus ESPs por falhas no nível dos serviços geralmente criam insatisfação e desconfiança no relacionamento em ambas as partes.

Recomendações

• Use as penalidades para influenciar o comportamento dos provedores, em vez de reduzir o custo do envolvimento.
• Estabeleça penalidades entre 10% e 20% do preço da torre de TI (tal como serviço de atendimento a clientes, área de trabalho ou centro de dados).
• Nunca dissemine as penalidades entre vários níveis de serviço em uma torre — use uma abordagem tipo “perca um nível de serviço em uma torre, perca todos”.
• Sempre estabeleça uma cláusula de compensação para níveis de serviço falhos quando as penalidades forem invocadas.
• Use incentivos somente quando o valor corporativo for maior do que, ou igual ao desembolso do incentivo.

O Que Você Precisa Saber
Incentivos e penalidades são declarações contratuais de medições de desempenho que recompensam os ESPs por um desempenho excepcional ou os penalizam pelo mau desempenho. Eles são especificados no contrato e deveriam ser projetados para promover o comportamento desejado por parte dos ESP’s, assim como permitir que a empresa e o ESP administrem seu relacionamento de forma eficaz. Sua ausência reduzirá a probabilidade de sucesso de uma transação.

Se usados adequadamente, incentivos e penalidades podem ser eficazes, e seu uso adequado poderá produzir uma relação positiva entre uma empresa e seu ESP. Se usados incorretamente, porém, incentivos e penalidades poderão gerar significativos problemas de relacionamento, incluindo perdas financeiras, menor confiança e lealdade, e, em último caso, o fim do relacionamento.

Data de publicação 02 de dezembro de 2008

Fonte: INFO Corporate

Esse cenário pode ser positivo para o principal executivo de TI, na medida em que representa uma barreira de proteção, mas, por outro lado, gera problemas, como a baixa participação em projetos fora da área de tecnologia.

Fabio Barros, do COMPUTERWORLD
Publicada em 27 de novembro de 2008 às 08h05

Um recente estudo do Gartner – divulgado nesta semana – aponta para o crescimento no número de CIOs que passaram a se reportar para CFOs (Chief Financial Officer). “Em 2003, eram 18% e, neste ano, já são 28%”, detalha Ione Coco, vice-presidente regional do instituto para o Programa para Executivos América Latina.

De acordo com Ione, os números indicam que muitos CIOs deixaram de se reportar diretamente aos CEOs. O que muitos consideram negativo, mas que pode ter suas vantagens. “Por exemplo, o executivo deixa de se expor para a alta gestão e passa a ter na figura do CFO uma barreira de proteção”, analisa a vice-presidente.

Já sobre as desvantagens de ter um líder com perfil financeiro, a especialista cita que, com isso, o CIO tem menos chance de participar de projetos fora da área de TI. Para comprovar essa percepção, Ione cita que, no levantamento, detectou-se que 45% dos executivos que se reportam aos CFOs apresentam posição de liderança fora da área de tecnologia. E esse índice salta para 65% no caso dos profissionais que respondem ao CEO.

“O fato de o CIO reportar-se ao CFO ou ao CEO também é fortemente influenciado pelo segmento de atuação da companhia”, pontua a executivo, que afirma: “Em setores como telecomunicações e mídia, por exemplo, eles se reportam diretamente aos CEOs. Em outros, como manufatura e varejo, eles se reportam aos CFOs e isso não deve mudar tão cedo”.

Fonte: CIO

Levantamento do instituto aponta que 85% das empresas já são usuárias de software open source e os 15% restantes vão adotar em 2009.

Por Computerworld/Reino Unido
20 de novembro de 2008 – 07h00

Uma nova pesquisa do Gartner mostrou o ritmo de adoção do software de código aberto no ambiente empresarial. Segundo os dados do instituto, 85% das empresas estão usando código aberto e os 15% restantes devem adotar a tecnologia em um ano.

O levantamento foi feito entre os meses de maio a junho de 2008, ouvindo 274 organizações na região Ásia/Pacifico, Europa e América do Norte.

No entanto, o Gartner disse que 69% das empresas pesquisadas não possuem uma política formal para avaliar e catalogar a utilização de open source. Isso tem “um grande potencial de criar violações de propriedade intelectual”, alerta o instituto.

“Apenas por algo ser gratuito, isso não significa que não tenha custo,” disse Laurie Wurster, diretor do Gartner.

“As empresas precisam ter políticas para aplicações em código aberto, decidindo quais áreas terão open source e identificando quais são os riscos associados com propriedade intelectual ao usar o open source. Quando as políticas estiverem estabelecidas, é preciso ter um processo de governança para garanti-las.”

De acordo com o Gartner, o código aberto está sendo instalado de maneira equivalente tanto em ambientes de missão crítica quanto nos que não são críticos. No data center, o open source funciona?

Razões para adotar open source
As três principais razões para adota open source estão relacionadas com o custo total de propriedade (TCO), custo menor para o desenvolvimento e maior facilidade para começar novas iniciativas usando uma base de código aberto.

“Alguns dos entrevistados disseram que eles também utilizam open source para se protegerem de ter apenas um fornecedor que é ‘dono’ de todo o seu departamento de TI,” ressaltou o Gartner.

Outros entrevistados disseram que a principal razão de negócios para adotar código aberto estava em um time to market mais rápido para novos produtos e a capacidade de evitar procedimentos e regras de vendas complexas.

Contudo, ter governança no ambiente aberto é o maior desafio para as empresas, seguido pelos termos conflitantes ao ter vários tipos de licenças e formulários.

“Entender quando e como a alternativa aberta deve ser usada é um processo frustrante. Mas essas questões vão ser resolvidas lentamente. A maior popularidade do código aberto vai gerar as mudanças,” disse Wurster.

Fonte: Computerworld