O uso correto de indicadores tem sido preocupação de muitos estudiosos. Este texto aborda alguns aspectos e possibilidades de uso de indicadores com a contextualização de notícias veiculadas na imprensa.
No ano passado (2006), o Bando do Brasil (BB) obteve "o maior lucro da história" com R$ 6.044bi [1] e, algumas semanas antes, informou o recorde em transações eletrônicas com 1,7bi pela Internet (21%) [2]. Logo, o total de transações foi de 7,8bi e o lucro líquido por transações foi de R$ 0,77. Acreditando-se que estes números sejam corretos e verdadeiros [3], o valor do lucro líquido por transação é fabuloso.
Assim, o ganho por transação pode ser um forte candidato a indicador. Como todo indicador, presta-se como sinalizador de que algo está bem, ou não, e necessita de estudos mais detalhados para investigar causas e conseqüências. Em uma analogia com automóveis, quando a luz do freio está ligada, dificilmente se consegue sair do lugar. Porém, se a luz de "superaquecimento" estiver ligada, as causas podem ser diversas.
No exemplo do BB, para formar um indicador de lucro por transação entraram duas variáveis: quantidade de transações e lucro líquido anunciado. O primeiro passo é saber como essas duas variáveis foram obtidas e "limpá-las" ou ter seus detalhes. Deve-se estabelecer uma metodologia de apuração que mude pouco e, se mudar, que haja a possibilidade de ajustar a série histórica pelos mesmos critérios. Senão, uma das mais importantes contribuições dos indicadores, comparação entre períodos, torna-se pouco confiável, ou inútil.
É importante que cada variável esteja bem conceituada. Em TI e em negócios, uma transação pode ter diversos entendimentos. Por exemplo, em negócios, quando o cliente faz um saque bancário se considera uma transação e em TI, dependendo do conceito, podem ser diversas. Portanto, é necessário que se promova o entendimento dos termos em detalhes, ou exemplos, do que é e o que não é, mesmo que essa explicação seja usual apenas na empresa.
Voltando ao exemplo, se no primeiro semestre de 2007, o BB tiver um lucro de R$ 3bi e a quantidade de transações for de 3,9bi, o lucro líquido por transação será o mesmo que o do ano anterior. Porém, vamos imaginar uma situação hipotética de um lucro de R$ 2bi e a quantidade de transação ficar em 4bi, então, o lucro por transação será de R$ 0,50. Este número, por si só, não significa nada e não têm utilidade alguma para qualquer prática de gestão, tanto na contabilidade, quanto em TI.
No entanto, as implicações de ter e divulgar dados corretos referentes ao processamento podem ser um "indicador" de que a empresa tem controle de seus processos. Se o indicador de lucro por transação é confiável, então, pode-se começar a investigar:
* Porque se usou mais processamento sem que isso gerasse mais resultado para a organização?
* Os negócios ou interações com os clientes são lucrativos?
* Mudou-se alguma característica da infra-estrutura que causou passos a mais de processamento (por exemplo, nova políticas de segurança ou acesso)?
* Houve mudança de hábitos dos clientes com a migração para canais mais "dispendiosos" em processamento?
* Existem outros indicadores que nos auxiliem a explicar este indicador?
Essa investigação é o que realmente pode trazer ganhos de produtividade e melhoria de processos. Talvez seja o que justifique o esforço de se obter, calcular e manter indicadores.
A única ação desaconselhável, em nosso exemplo imaginado, é alterar a forma de cálculo do indicador para que fique "mais coerente", sem que a regra seja aplicada para a série histórica. Quando isso acontece, os indicadores são apenas para esconder os problemas, não evidenciá-los, e assim, perder a oportunidade de promover melhorias de processos.
1. Gazeta Mercantil - 28.02.2007
2. Executivos financeiros 16.02.2007 (quantidades), B2B Magazine de 22.02.07 (valores)
3. No caso do lucro, há 2,3bi em receitas com reversão de impostos e fundo de pensão (1o semestre) e, no caso das transações, há dúvidas quanto a serem quantidade de transações ou valores transacionados.
Obrigado e até a próxima!
http://imasters.uol.com.br/artigo/6614
Publicado em: Terça-feira, 17 de julho de 2007 às 10h00
segunda-feira, 12 de abril de 2010
Priorização de tarefas em TI
A priorização e a seqüência de atividades a serem executadas sempre foram preocupação de qualquer organização que se propõe a um objetivo. A seqüência é essencial para que algo aconteça da maneira correta, como deveria acontecer. A maioria das tarefas diárias das pessoas é uma seqüência "programada" de passos.
Em informática, a seqüência fica evidente nos roteiros para processamento de dados e para programação dos computadores. Esta última só é possível utilizando-se lógica de programação que significa uma seqüência de passos encadeados para um determinado fim desejável.
A priorização é a arte de escolher entre duas possibilidades aquela que deve ser a primeira. É uma tarefa difícil e, quanto mais pessoas forem consultadas, mais opiniões divergentes aparecem. Porém, sem a escolha não se sabe por onde começar.
A informática é famosa pelo backlog, ou, a lista de tarefas que deveriam ter sido feitas, mas ainda não foram. Como também, atualmente, a lista de projetos que deveriam iniciar, ou continuarem em execução, mas não se sabe a importância dos mesmos.
A tentativa mais recente de se por "ordem na casa" vem das teorias de Governança de TI que prega, entre outras coisas, a necessidade de uma entidade (pessoa/cargo, grupo, departamento, comitê, etc) para priorizar e decidir sobre os recursos de TI[1].
Priorizar um projeto, por exemplo, deveria indicar para a organização qual é seu número na fila de importância. Assim, o projeto número 1, é mais importante que o 2, o 2 mais importante que o 3 e assim sucessivamente. Parece óbvio, mas para quê decidir sobre a importância de um projeto de TI? Afinal, tudo é importante.
Tudo é importante, mas os recursos são sempre limitados, por isso, aquilo que é mais importante deve ter prioridade, na alocação de recursos, sobre os menos prioritários. Por exemplo, se um projeto for considerado de prioridade 1 significa que terá mais e melhores técnicos que o número 2.
Isso também significa que a empresa terá de manter, no mínimo, duas informações atualizadas: quem são os melhores técnicos para determinada tarefa[2], ou projeto, e quando estarão disponíveis. A primeira informação pode ser gerida com o auxílio de avaliações por competências. A segunda, dependendo do número de funcionários, pode ser resolvida com uma planilha Excel.
Para decidir os projetos mais importantes, um dos indicadores possíveis e muito valorizados pelo mercado, é o financeiro. Ou seja, o que, ou quanto vamos gastar e ganhar com isso? Respondida esta pergunta, um ranking inicial pode ser estabelecido. Depois, é necessário fazer ajustes para que visões de longo prazo não fiquem no backlog até se tornarem assuntos urgentíssimos do presente.
Enfim, resumindo:
1. É necessário priorizar por algum critério;
2. É necessário saber as competências dos técnicos;
3. É necessário saber quando estes técnicos terminarão o que estão fazendo.
[1] Weil and Ross - Governança de TI.
[2] Procure pelos textos: "Dicas para o escritório de projetos ser um sucesso" e "Amplitude de controle e produtividade em TI".
http://imasters.uol.com.br/artigo/6391
Publicado em: Terça-feira, 12 de junho de 2007 às 09h10
Em informática, a seqüência fica evidente nos roteiros para processamento de dados e para programação dos computadores. Esta última só é possível utilizando-se lógica de programação que significa uma seqüência de passos encadeados para um determinado fim desejável.
A priorização é a arte de escolher entre duas possibilidades aquela que deve ser a primeira. É uma tarefa difícil e, quanto mais pessoas forem consultadas, mais opiniões divergentes aparecem. Porém, sem a escolha não se sabe por onde começar.
A informática é famosa pelo backlog, ou, a lista de tarefas que deveriam ter sido feitas, mas ainda não foram. Como também, atualmente, a lista de projetos que deveriam iniciar, ou continuarem em execução, mas não se sabe a importância dos mesmos.
A tentativa mais recente de se por "ordem na casa" vem das teorias de Governança de TI que prega, entre outras coisas, a necessidade de uma entidade (pessoa/cargo, grupo, departamento, comitê, etc) para priorizar e decidir sobre os recursos de TI[1].
Priorizar um projeto, por exemplo, deveria indicar para a organização qual é seu número na fila de importância. Assim, o projeto número 1, é mais importante que o 2, o 2 mais importante que o 3 e assim sucessivamente. Parece óbvio, mas para quê decidir sobre a importância de um projeto de TI? Afinal, tudo é importante.
Tudo é importante, mas os recursos são sempre limitados, por isso, aquilo que é mais importante deve ter prioridade, na alocação de recursos, sobre os menos prioritários. Por exemplo, se um projeto for considerado de prioridade 1 significa que terá mais e melhores técnicos que o número 2.
Isso também significa que a empresa terá de manter, no mínimo, duas informações atualizadas: quem são os melhores técnicos para determinada tarefa[2], ou projeto, e quando estarão disponíveis. A primeira informação pode ser gerida com o auxílio de avaliações por competências. A segunda, dependendo do número de funcionários, pode ser resolvida com uma planilha Excel.
Para decidir os projetos mais importantes, um dos indicadores possíveis e muito valorizados pelo mercado, é o financeiro. Ou seja, o que, ou quanto vamos gastar e ganhar com isso? Respondida esta pergunta, um ranking inicial pode ser estabelecido. Depois, é necessário fazer ajustes para que visões de longo prazo não fiquem no backlog até se tornarem assuntos urgentíssimos do presente.
Enfim, resumindo:
1. É necessário priorizar por algum critério;
2. É necessário saber as competências dos técnicos;
3. É necessário saber quando estes técnicos terminarão o que estão fazendo.
[1] Weil and Ross - Governança de TI.
[2] Procure pelos textos: "Dicas para o escritório de projetos ser um sucesso" e "Amplitude de controle e produtividade em TI".
http://imasters.uol.com.br/artigo/6391
Publicado em: Terça-feira, 12 de junho de 2007 às 09h10
Confie na moda, e não na média, para prazos em desenvolvimento de sistemas
Calma! O assunto aqui não é corte e costura e nem modismos da administração. Estamos falando da moda e de média em estatística. Estatística que utilizamos em todo momento que nos perguntam em quanto tempo determinada atividade é executada e respondemos "na média em...". Pois é, a média é a preferida em detrimento da moda.
Em TI, segundo Luftman (2004), devemos utilizar de forma correta mais de 80 indicadores, ou métricas, para continuarmos tendo os péssimos resultados de que a área é acusada. Dentre estes resultados estão 90% de projetos que não ficam no orçamento e no prazo prometidos.
Durante o planejamento de um projeto de TI qualquer, mesmo usando todas as técnicas e metodologias mais modernas as possibilidades de erros são infinitas. Entre todos os erros possíveis, um é comum em quase todos os tipos de projeto, o uso da média ao invés da moda para estimar prazos.
Não explicarei os conceitos de média e moda, demonstrarei a diferença numa situação/problema:
Uma grande empresa definiu que todos seus projetos de desenvolvimento de sistemas não deveriam ultrapassar prazos de 6 meses para conclusão. Após 1 ano, trabalhando com esta regra, ela conseguiu desenvolver diversos sistemas e colheu uma amostra dos últimos 10. Os prazos, em meses, ficaram assim: 2, 3, 4, 5, 6, 6, 7, 7, 7, 7.
Neste exato momento alguém está negociando com a área de TI e faz a famosa pergunta: em quanto tempo vocês concluem este projeto?
Se utilizada a média, a área de TI dirá que em cinco meses e meio entrega o sistema. Ou seja, abaixo do compromisso de fazer projetos em seis meses. Fará uma promessa, antes de fazer o trabalho, parecendo eficiente e impressionando seus clientes.
Se utilizada a moda, a área de TI dirá que em SETE meses entregará o sistema. Ou seja, acima do compromisso já conhecido pela organização. A moda indica aquilo que mais se repete dentro de uma série, assim, de 10 projetos, 4 foram realizados em 7 meses e apenas 2 foram cumpridos no prazo pretendido.
Por mais que se utilizem boas práticas, metodologias, esperança e otimismo, é melhor confiar na moda do que na média. Mesmo que a média possa propiciar erros de estimativa menores isso não será vantagem nenhuma se o prazo não for cumprido. Por exemplo, se o projeto for concluído em 4 meses o erro, pela média, será de 1,5 meses e, pela moda, será de 3 meses. Porém, se o projeto for concluído em 8 meses, pela média, o erro será de 2,5 meses, enquanto que pela moda será de 1 mês.
Agora responda a duas perguntas incômodas. Será que o cliente ficará mais feliz se você entregar o projeto com 45 dias de antecedência ou com 90? Será que ele ficará mais aborrecido se você entregar o projeto com 30 dias de atraso ou com DOIS MESES E MEIO?
Líderes e gerentes de projetos, uni-vos! Andem na e pela MODA.
Managing the Information Technology Resource: Chapter 13: Measuring, Reporting and Controling - Jerry N. Luftman 2004.
http://imasters.uol.com.br/artigo/6246
Publicado em: Terça-feira, 22 de maio de 2007 às 10h00
Em TI, segundo Luftman (2004), devemos utilizar de forma correta mais de 80 indicadores, ou métricas, para continuarmos tendo os péssimos resultados de que a área é acusada. Dentre estes resultados estão 90% de projetos que não ficam no orçamento e no prazo prometidos.
Durante o planejamento de um projeto de TI qualquer, mesmo usando todas as técnicas e metodologias mais modernas as possibilidades de erros são infinitas. Entre todos os erros possíveis, um é comum em quase todos os tipos de projeto, o uso da média ao invés da moda para estimar prazos.
Não explicarei os conceitos de média e moda, demonstrarei a diferença numa situação/problema:
Uma grande empresa definiu que todos seus projetos de desenvolvimento de sistemas não deveriam ultrapassar prazos de 6 meses para conclusão. Após 1 ano, trabalhando com esta regra, ela conseguiu desenvolver diversos sistemas e colheu uma amostra dos últimos 10. Os prazos, em meses, ficaram assim: 2, 3, 4, 5, 6, 6, 7, 7, 7, 7.
Neste exato momento alguém está negociando com a área de TI e faz a famosa pergunta: em quanto tempo vocês concluem este projeto?
Se utilizada a média, a área de TI dirá que em cinco meses e meio entrega o sistema. Ou seja, abaixo do compromisso de fazer projetos em seis meses. Fará uma promessa, antes de fazer o trabalho, parecendo eficiente e impressionando seus clientes.
Se utilizada a moda, a área de TI dirá que em SETE meses entregará o sistema. Ou seja, acima do compromisso já conhecido pela organização. A moda indica aquilo que mais se repete dentro de uma série, assim, de 10 projetos, 4 foram realizados em 7 meses e apenas 2 foram cumpridos no prazo pretendido.
Por mais que se utilizem boas práticas, metodologias, esperança e otimismo, é melhor confiar na moda do que na média. Mesmo que a média possa propiciar erros de estimativa menores isso não será vantagem nenhuma se o prazo não for cumprido. Por exemplo, se o projeto for concluído em 4 meses o erro, pela média, será de 1,5 meses e, pela moda, será de 3 meses. Porém, se o projeto for concluído em 8 meses, pela média, o erro será de 2,5 meses, enquanto que pela moda será de 1 mês.
Agora responda a duas perguntas incômodas. Será que o cliente ficará mais feliz se você entregar o projeto com 45 dias de antecedência ou com 90? Será que ele ficará mais aborrecido se você entregar o projeto com 30 dias de atraso ou com DOIS MESES E MEIO?
Líderes e gerentes de projetos, uni-vos! Andem na e pela MODA.
Managing the Information Technology Resource: Chapter 13: Measuring, Reporting and Controling - Jerry N. Luftman 2004.
http://imasters.uol.com.br/artigo/6246
Publicado em: Terça-feira, 22 de maio de 2007 às 10h00
Reflexões sobre manutenção de sistemas legados
Os sistemas legados respondem pela maior parte do processamento de dados mundial, ou, dependendo de entendimentos, por todo. Isto porque, para SEACORD (2003) qualquer sistema em produção pode ser considerado como legado. Entre 60% e 70% dos sistemas estão em COBOL, estima-se em 200 milhões de linhas (SEACORD et al, 2003 e ULRICH, 2002).
A participação do custo de manutenção no custo total de um sistema tem crescido de 40%, nos anos 70, até 90%, atualmente (PIGOSKI, 1996). Destes custos, cerca de 20% são consumidos com correções e 80% com melhorias diversas (Martin apud ULRICH, 2002).
Segundo a ISO/IEC 14764 (1999), podemos distinguir quatro modalidades de manutenção de software: CORRETIVA, para corrigir problemas depois que aconteceram; ADAPTATIVA, para adequá-los a novos ambientes e mantê-los úteis nestes; PERFECTIVA, melhorias no desempenho e manutenibilidade; PREVENTIVA, corrigir falhas antes que aconteçam. Para Pressman (1995, p. 878), a manutenção perfectiva é que consome mais recursos e é resultante do software estar em uso e ser "bem-sucedido". Este tipo de manutenção é responsável pela agregação de novas capacidades, alterações em funções existentes e ampliações gerais solicitadas pelos usuários.
Sistemas de informação "legados" devem ter equipes permanentes para manutenções corretivas, adaptativas e preventivas. Ou seja, alguns analistas, dependendo do tamanho do sistema, devem conhecê-lo profundamente, estarem preparados e em permanente trabalho de alteração (manutenção) do mesmo. Quando a área de TI vive em sobressaltos devido a erros nos seus SIs, ou vive "apagando incêndios", é de se concluir que a organização tem um "gerenciamento" nulo, falho, imprudente ou inábil em algumas destas três categorias de manutenção.
A manutenção perfectiva pode ser mais flexível quanto à alocação de pessoal pois o atendimento às necessidades dos clientes, usuários e controladores pode ser "negociado". Porém, o adiamento repetitivo neste atendimento e, juntando-se a falta de pessoal qualificado para as outras manutenções, certamente causará a "morte" do sistema. Ou, na melhor das hipóteses, um "pico" de esforço/custo em um determinado momento de "crise". Estes "picos" podem consumir muito mais recursos do que o de uma equipe permanente e reduzida. Além de, na maioria das vezes, já terem causado "estresse" ou estragos na imagem e credibilidade da área de informática, e da empresa, junto a seus stakeholders e opinião pública.
Algumas organizações estão pouco preparadas para entender a importância da manutenção. Isso se constata pela falta de processos específicos para tratar do assunto ou, colocam analistas e programadores inexperientes e sem supervisão para fazerem as manutenções corretivas e acabam transformando o sistema em "uma colcha de retalhos" ou "macarrônico". Em alguns casos tratam o processo de manutenção perfectiva como projetos de sistemas novos sem distinguirem a enorme diferença entre ambos. Outras vezes, fazem esforços monumentais, alocando grande soma de recursos para a condução de novos projetos que duram de um a dois anos e esquecem que, ao final, existirá um produto que precisará de manutenção, às vezes, por mais de 20 anos.
Enfim, a disciplina de manutenção de software precisa ser melhor desenvolvida, entendida e valorizada pelas organizações. Até que isso aconteça, a TI continuará a ser um "buraco sem fundo" de recursos e "mil novas idéias" de se atacarem as conseqüências continuarão surgindo.
(ISO/IEC 14764, 1999) ISO/IEC 14764. "Information technology - Software Maintenance",1999.
(PIGOSKI,1996) Thomas.M., "Practical Software Maintenance", John Wiley & Sons, Inc., 1996.
(PRESSMAN, 1995) ROGER, Pressman, "Engenharia de software", Makron Books, 1995.|
(SEACORD et al, 2003) Seacord, Robert C., Plakosh, Daniel, Lewis, Grace A.|
"Modernizing Legacy Systems: Software Technologies, Engineering Processes, and|
Business Practices", Addison-Wesley, 2003.
(ULRICH, 2002) Ulrich, William M., "Legacy Systems: Transformation Strategies", 2002 Prentice-Hall PTR, 2002.
http://imasters.uol.com.br/artigo/5919
Publicado em: Terça-feira, 17 de abril de 2007 às 09h00
A participação do custo de manutenção no custo total de um sistema tem crescido de 40%, nos anos 70, até 90%, atualmente (PIGOSKI, 1996). Destes custos, cerca de 20% são consumidos com correções e 80% com melhorias diversas (Martin apud ULRICH, 2002).
Segundo a ISO/IEC 14764 (1999), podemos distinguir quatro modalidades de manutenção de software: CORRETIVA, para corrigir problemas depois que aconteceram; ADAPTATIVA, para adequá-los a novos ambientes e mantê-los úteis nestes; PERFECTIVA, melhorias no desempenho e manutenibilidade; PREVENTIVA, corrigir falhas antes que aconteçam. Para Pressman (1995, p. 878), a manutenção perfectiva é que consome mais recursos e é resultante do software estar em uso e ser "bem-sucedido". Este tipo de manutenção é responsável pela agregação de novas capacidades, alterações em funções existentes e ampliações gerais solicitadas pelos usuários.
Sistemas de informação "legados" devem ter equipes permanentes para manutenções corretivas, adaptativas e preventivas. Ou seja, alguns analistas, dependendo do tamanho do sistema, devem conhecê-lo profundamente, estarem preparados e em permanente trabalho de alteração (manutenção) do mesmo. Quando a área de TI vive em sobressaltos devido a erros nos seus SIs, ou vive "apagando incêndios", é de se concluir que a organização tem um "gerenciamento" nulo, falho, imprudente ou inábil em algumas destas três categorias de manutenção.
A manutenção perfectiva pode ser mais flexível quanto à alocação de pessoal pois o atendimento às necessidades dos clientes, usuários e controladores pode ser "negociado". Porém, o adiamento repetitivo neste atendimento e, juntando-se a falta de pessoal qualificado para as outras manutenções, certamente causará a "morte" do sistema. Ou, na melhor das hipóteses, um "pico" de esforço/custo em um determinado momento de "crise". Estes "picos" podem consumir muito mais recursos do que o de uma equipe permanente e reduzida. Além de, na maioria das vezes, já terem causado "estresse" ou estragos na imagem e credibilidade da área de informática, e da empresa, junto a seus stakeholders e opinião pública.
Algumas organizações estão pouco preparadas para entender a importância da manutenção. Isso se constata pela falta de processos específicos para tratar do assunto ou, colocam analistas e programadores inexperientes e sem supervisão para fazerem as manutenções corretivas e acabam transformando o sistema em "uma colcha de retalhos" ou "macarrônico". Em alguns casos tratam o processo de manutenção perfectiva como projetos de sistemas novos sem distinguirem a enorme diferença entre ambos. Outras vezes, fazem esforços monumentais, alocando grande soma de recursos para a condução de novos projetos que duram de um a dois anos e esquecem que, ao final, existirá um produto que precisará de manutenção, às vezes, por mais de 20 anos.
Enfim, a disciplina de manutenção de software precisa ser melhor desenvolvida, entendida e valorizada pelas organizações. Até que isso aconteça, a TI continuará a ser um "buraco sem fundo" de recursos e "mil novas idéias" de se atacarem as conseqüências continuarão surgindo.
(ISO/IEC 14764, 1999) ISO/IEC 14764. "Information technology - Software Maintenance",1999.
(PIGOSKI,1996) Thomas.M., "Practical Software Maintenance", John Wiley & Sons, Inc., 1996.
(PRESSMAN, 1995) ROGER, Pressman, "Engenharia de software", Makron Books, 1995.|
(SEACORD et al, 2003) Seacord, Robert C., Plakosh, Daniel, Lewis, Grace A.|
"Modernizing Legacy Systems: Software Technologies, Engineering Processes, and|
Business Practices", Addison-Wesley, 2003.
(ULRICH, 2002) Ulrich, William M., "Legacy Systems: Transformation Strategies", 2002 Prentice-Hall PTR, 2002.
http://imasters.uol.com.br/artigo/5919
Publicado em: Terça-feira, 17 de abril de 2007 às 09h00
Bancos são birôs modernos
Os birôs de serviços, populares nos anos 70, ofereciam processamento de dados para empresas. Era um tipo de terceirização de serviços que as empresas eram "obrigadas" a fazer devido a completa falta de profissionais de informática e custos proibitivos para aquisição de hardware e software. Óbvio, custava mais barato pagar pelo processamento, por exemplo, da folha de pagamento e contabilidade do que fazê-la manualmente na própria organização.
Do final dos anos 70 até hoje, com o advento do microcomputador e outra montanha de inovações e possibilidades tecnológicas, os birôs, como conhecidos anteriormente, foram desaparecendo. Porém, ainda existem alguns que podem se ofender ao chamá-los de birôs como o Serpro, a Dataprev e os bancos. Bancos?
Sim! Bancos. Aquele lugar onde, aproximadamente, 70 milhões de brasileiros têm conta corrente ou poupança. É o lugar onde se contratam seguros, previdência, cartão de crédito e uma lista de mais de 100 produtos (serviços). Pelo serviço de manutenção de conta-corrente o cliente pode pagar, em média, R$ 20,00. Pois bem, este serviço e seus subjacentes, emissão de saldo e extrato, depósitos e saques, são quase que exclusivamente prestados por serviços de informática. Com exceção de algumas pequenas partes dos processos de abertura da conta corrente e do depósito e saque que lidam com numerário o restante é eletrônico.
Aos mais céticos que não querem concordar com essa semelhança, pode-se oferecer uma sutil diferença. Os birôs dos anos 70 serviam apenas a grandes e médias empresas e governo enquanto que os birôs/bancos atuais, prestam serviços de processamento de dados para qualquer um disposto a pagar uma "tarifazinha" e que o banco queira como cliente.
Alguns outros serviços podem ter quantidades ainda maiores de processamento de dados. Por exemplo, o serviço de cobrança para pessoas jurídicas pode ser algo puramente eletrônico, ou seja, o banco atua totalmente como birô recebendo, processando e devolvendo informações sem qualquer intervenção de atendimento a clientes.
Contudo, outros serviços, como custódia de valores pode ter boa parte do trabalho manual e usar mais características de banco do que de birô de serviços eletrônicos.
Enfim, a visão "romântica" dos bancos como empresas aonde clientes entravam e saiam com dinheiro (numerário) e bancários anotavam, recebiam e pagavam está morrendo. Agora são "birôs de serviços" que fazem isso com seus digitadores, conferentes e vendedores de soluções informatizadas, programadores de remessas de arquivos, analistas de sistemas, consultores de como se servir melhor da Internet, só está faltando trocar o nome para Birô do Brasil, Birô Brasileiro de Descontos, Birô Itaú.
http://imasters.uol.com.br/artigo/5750
Publicado em: Segunda-feira, 19 de março de 2007 às 09h10
Do final dos anos 70 até hoje, com o advento do microcomputador e outra montanha de inovações e possibilidades tecnológicas, os birôs, como conhecidos anteriormente, foram desaparecendo. Porém, ainda existem alguns que podem se ofender ao chamá-los de birôs como o Serpro, a Dataprev e os bancos. Bancos?
Sim! Bancos. Aquele lugar onde, aproximadamente, 70 milhões de brasileiros têm conta corrente ou poupança. É o lugar onde se contratam seguros, previdência, cartão de crédito e uma lista de mais de 100 produtos (serviços). Pelo serviço de manutenção de conta-corrente o cliente pode pagar, em média, R$ 20,00. Pois bem, este serviço e seus subjacentes, emissão de saldo e extrato, depósitos e saques, são quase que exclusivamente prestados por serviços de informática. Com exceção de algumas pequenas partes dos processos de abertura da conta corrente e do depósito e saque que lidam com numerário o restante é eletrônico.
Aos mais céticos que não querem concordar com essa semelhança, pode-se oferecer uma sutil diferença. Os birôs dos anos 70 serviam apenas a grandes e médias empresas e governo enquanto que os birôs/bancos atuais, prestam serviços de processamento de dados para qualquer um disposto a pagar uma "tarifazinha" e que o banco queira como cliente.
Alguns outros serviços podem ter quantidades ainda maiores de processamento de dados. Por exemplo, o serviço de cobrança para pessoas jurídicas pode ser algo puramente eletrônico, ou seja, o banco atua totalmente como birô recebendo, processando e devolvendo informações sem qualquer intervenção de atendimento a clientes.
Contudo, outros serviços, como custódia de valores pode ter boa parte do trabalho manual e usar mais características de banco do que de birô de serviços eletrônicos.
Enfim, a visão "romântica" dos bancos como empresas aonde clientes entravam e saiam com dinheiro (numerário) e bancários anotavam, recebiam e pagavam está morrendo. Agora são "birôs de serviços" que fazem isso com seus digitadores, conferentes e vendedores de soluções informatizadas, programadores de remessas de arquivos, analistas de sistemas, consultores de como se servir melhor da Internet, só está faltando trocar o nome para Birô do Brasil, Birô Brasileiro de Descontos, Birô Itaú.
http://imasters.uol.com.br/artigo/5750
Publicado em: Segunda-feira, 19 de março de 2007 às 09h10
Gerenciamento ou Governança de TI?
"Que COBIT que nada!"
Seguindo a escola do CIO da Rodhia mundial Xavir Rambaud, que "desdenhou" do ITIL(1), para todo mundo ouvir, este texto faz uma reflexão sobre Governança de TI.
Uma vez que Gerenciamento de TI está focado no presente e no interno e a Governança de TI está no externo e no futuro(2), os problemas das áreas de TI "bagunçadas" devem ser resolvidos com Gerenciamento enquanto problemas com gestores, ou demandantes, que "não sabem o que querem" devem ser resolvidos com Governança de TI.
No uso do COBIT 4.0 com seus 34 processos, a Organização poderia se concentrar em alguns deles e resolver de vez a questão de quem decide o que em relação a TI. Os processos que efetivamente podem lidar com os custos envolvidos para as soluções (sistemas) são:
* PO 1.1 Gestão do Valor da TI
* PO 4 Processos, Organização e Relacionamento
* O Verificar quase todos os Fatores Críticos de Sucesso (FCS).
* PO 5 Investimentos em TI
* DS 1 Definição e gestão dos níveis de serviços.
* O Verificar o FCS A organização de TI pode identificar as fontes de discordâncias de custos.
* DS 6 Identificar e alocar Custos de TI.
* ME 4.4 Gerenciamento de Recursos
Atualmente, os centros de TI têm seus custos rateados pelo total com todas as demais unidades, tudo é um bolo só. Ou, o orçamento de TI é definido pelo histórico e desejos dos executivos da área, costuma ser um dos maiores causando espanto, indignação e um sentimento de que o pessoal da TI custa muito caro, ou é improdutivo, ou desperdiça demais (3).
Se a organização conseguir mapear e distribuir os custos que cada produto gera para a área de TI (Gerenciamento) pode-se resolver o problema dos orçamentos e de quem manda nas aquisições, ou desenvolvimentos (Governança).
Por exemplo, a partir do momento que a área de RH começar a pagar, e ter noção do custo, pelo processamento e manutenção da folha de pagamento e seus aderentes, mais da metade das preocupações da teoria da Governança de TI se resolverão. O problema de se atribuir custo aos processos de TI, do ponto de vista técnico, são muito mais fáceis do que do ponto de vista político.
Quando a organização perceber que algumas áreas que não trazem contribuição (o que não é o caso da RH), ou não se justificam, para os negócios, o ônus de explicar custos e orçamentos recai sobre as mesmas. Isso pode ser muito pedagógico evitando que essas áreas demandem coisas pouco sustentáveis em comparação com outras áreas.
Até que a empresa resolva encarar para valer o gerenciamento global de custos de processamento, uma dica sustentada pela Governança de TI em seu modelo Federalista(4), é criar os comitês gestores com a participação de todos os executivos corporativos. Pessimismos à parte, o máximo que pode acontecer com um grupo destes é que aqueles que choram ou esperneiam mais consigam convencer os outros sobre SUAS necessidades e não as necessidades da organização.
Enfim, o Gerenciamento de TI, que só a área de TI sabe, ou pode fazer, poderia sugerir à Governança de TI, que ainda não se sabe quem entende disso, adote como premissa básica ter os custos envolvidos com o processamento dos sistemas de cada stakeholder muito bem definido. E, se a Governança conseguisse que os demandantes de TI comprovassem o quanto cada sistema sob sua responsabilidade traz de retorno para a organização, teríamos menos discussões, conflitos e aborrecimento entre as áreas em relação a TI. Talvez tivéssemos mais gente triste, mas por outros motivos.
Concluindo, não há novidade alguma em administrar recursos sob o ponto de vista de custo e retorno. Isso é uma preocupação antiga, tão antiga quanto as Teorias Gerais de Administração (TGA). A maneira mais eficiente de se fazer com que atores desempenhem com responsabilidade, interesse, eficiência, etc., seus papéis é forçá-los a pagar por isso. Alguém duvida? Então, num esforço transdiciplinar, aproveite e estude um pouco sobre Responsabilidade Socioambiental, especificamente a legislação ambiental sobre o Princípio do Pagador Poluidor que "obrigaria" os poluidores a pagarem pelos estragos ao meio ambiente.
Fonte
* Reportagem "Que ITIL que nada", revista Info Corporate, Dez/2006, p.82
* Van Grembergen, W. Strategies for information technology governance. Hershey: Idea Group Pub., 2003 cap. 2 de Ryan R. Peterson.
* Mattos A.C.M. Sistemas de Informação uma visão executiva. Ed. Saraiva, 2005, pág. 159-164.
* Weill Ross. Governança de TI: São Paulo: M.Books do Brasil, 2006, pág. 60-61.
http://imasters.uol.com.br/artigo/5734
Publicado pela primeira vez em Quinta-feira, 15 de março de 2007 às 09h00
Seguindo a escola do CIO da Rodhia mundial Xavir Rambaud, que "desdenhou" do ITIL(1), para todo mundo ouvir, este texto faz uma reflexão sobre Governança de TI.
Uma vez que Gerenciamento de TI está focado no presente e no interno e a Governança de TI está no externo e no futuro(2), os problemas das áreas de TI "bagunçadas" devem ser resolvidos com Gerenciamento enquanto problemas com gestores, ou demandantes, que "não sabem o que querem" devem ser resolvidos com Governança de TI.
No uso do COBIT 4.0 com seus 34 processos, a Organização poderia se concentrar em alguns deles e resolver de vez a questão de quem decide o que em relação a TI. Os processos que efetivamente podem lidar com os custos envolvidos para as soluções (sistemas) são:
* PO 1.1 Gestão do Valor da TI
* PO 4 Processos, Organização e Relacionamento
* O Verificar quase todos os Fatores Críticos de Sucesso (FCS).
* PO 5 Investimentos em TI
* DS 1 Definição e gestão dos níveis de serviços.
* O Verificar o FCS A organização de TI pode identificar as fontes de discordâncias de custos.
* DS 6 Identificar e alocar Custos de TI.
* ME 4.4 Gerenciamento de Recursos
Atualmente, os centros de TI têm seus custos rateados pelo total com todas as demais unidades, tudo é um bolo só. Ou, o orçamento de TI é definido pelo histórico e desejos dos executivos da área, costuma ser um dos maiores causando espanto, indignação e um sentimento de que o pessoal da TI custa muito caro, ou é improdutivo, ou desperdiça demais (3).
Se a organização conseguir mapear e distribuir os custos que cada produto gera para a área de TI (Gerenciamento) pode-se resolver o problema dos orçamentos e de quem manda nas aquisições, ou desenvolvimentos (Governança).
Por exemplo, a partir do momento que a área de RH começar a pagar, e ter noção do custo, pelo processamento e manutenção da folha de pagamento e seus aderentes, mais da metade das preocupações da teoria da Governança de TI se resolverão. O problema de se atribuir custo aos processos de TI, do ponto de vista técnico, são muito mais fáceis do que do ponto de vista político.
Quando a organização perceber que algumas áreas que não trazem contribuição (o que não é o caso da RH), ou não se justificam, para os negócios, o ônus de explicar custos e orçamentos recai sobre as mesmas. Isso pode ser muito pedagógico evitando que essas áreas demandem coisas pouco sustentáveis em comparação com outras áreas.
Até que a empresa resolva encarar para valer o gerenciamento global de custos de processamento, uma dica sustentada pela Governança de TI em seu modelo Federalista(4), é criar os comitês gestores com a participação de todos os executivos corporativos. Pessimismos à parte, o máximo que pode acontecer com um grupo destes é que aqueles que choram ou esperneiam mais consigam convencer os outros sobre SUAS necessidades e não as necessidades da organização.
Enfim, o Gerenciamento de TI, que só a área de TI sabe, ou pode fazer, poderia sugerir à Governança de TI, que ainda não se sabe quem entende disso, adote como premissa básica ter os custos envolvidos com o processamento dos sistemas de cada stakeholder muito bem definido. E, se a Governança conseguisse que os demandantes de TI comprovassem o quanto cada sistema sob sua responsabilidade traz de retorno para a organização, teríamos menos discussões, conflitos e aborrecimento entre as áreas em relação a TI. Talvez tivéssemos mais gente triste, mas por outros motivos.
Concluindo, não há novidade alguma em administrar recursos sob o ponto de vista de custo e retorno. Isso é uma preocupação antiga, tão antiga quanto as Teorias Gerais de Administração (TGA). A maneira mais eficiente de se fazer com que atores desempenhem com responsabilidade, interesse, eficiência, etc., seus papéis é forçá-los a pagar por isso. Alguém duvida? Então, num esforço transdiciplinar, aproveite e estude um pouco sobre Responsabilidade Socioambiental, especificamente a legislação ambiental sobre o Princípio do Pagador Poluidor que "obrigaria" os poluidores a pagarem pelos estragos ao meio ambiente.
Fonte
* Reportagem "Que ITIL que nada", revista Info Corporate, Dez/2006, p.82
* Van Grembergen, W. Strategies for information technology governance. Hershey: Idea Group Pub., 2003 cap. 2 de Ryan R. Peterson.
* Mattos A.C.M. Sistemas de Informação uma visão executiva. Ed. Saraiva, 2005, pág. 159-164.
* Weill Ross. Governança de TI: São Paulo: M.Books do Brasil, 2006, pág. 60-61.
http://imasters.uol.com.br/artigo/5734
Publicado pela primeira vez em Quinta-feira, 15 de março de 2007 às 09h00
Produtividade em centros de TI - O que é?
Centros de TI, até então chamados CPDs, são caros, porém, quase ninguém tem dúvidas de que processos informatizados são mais baratos que seus similares não assistidos por computador. No entanto, nos últimos anos a informática tem consumido mais e mais do orçamento das empresas.
Assim, são muitos os estudos que buscam reduzir os custos ou aumentar os benefícios, ou o valor percebido, do processamento de dados nas empresas. Este texto coloca a questões da produtividade para reflexão de gerentes, usuários e profissionais da área de TI.
Produtividade, para o Aurélio, é "a relação entre a quantidade ou valor produzido e a quantidade ou valor dos insumos aplicados à produção"1. Ou seja, é produtivo aquilo que consegue gerar produtos com valor maior do que o custo de produzi-los. Mas o que é que um CPD produz?
Uma resposta evasiva comum, porém utilizada nas placas de missão em algumas empresas, começa com "ser a solução em serviços de TI..." e termina dizendo alguns dos processos ou produtos oferecidos aos seus usuários. Percebe-se, então, que a missão de muitos CPDs não é ser produtivo, com a re-salva de que isso pode ser óbvio e estar subentendido.
Muitos teóricos já cansaram em alertar que computadores não produzem informação. Informação, assim como conhecimento, é algo que só existe e têm sentido na mente humana2. Computadores processam dados que são úteis na medida em que irão se tornar informação e conhecimento para alguém. Os dados são manipulados, formatados, ordenados, comparados, armazenados, compactados, mostrados, impressos, transmitidos, entre outras ações, por meio de programas.
Os programas são seqüências de instruções lógicas que dizem ao computador o que fazer para manipular os dados. Programas são feitos por programadores e analistas de sistemas e os dados são obtidos por diversas formas, a mais comum ainda é por digitação em teclados feitas por funcionários, clientes e fornecedores da empresa.
Uma medida de produtividade, mas também de ineficiência, pode ser obtida pela quantidade de dados originais, digitados, e a quantidade de dados de saída gerados pelos programas de um sistema em um período de tempo. Assim, podemos afirmar que, se um CPD recebe 1 Gb de dados originais e gera 1,5 Gb de dados de saída (processados, armazenados, transmitidos, etc) em 24 horas, ele é mais produtivo que este mesmo CPD, se o processamento demorasse 25 horas. Isso quer dizer que no segundo caso, terá de se melhorar o desempenho (lógica) dos programas ou redimensionar para mais o computador.
A ineficiência, na hipótese acima, pode ser identificada analisando-se os arquivos intermediários e finais gerados no processo. Os arquivos intermediários podem estar sendo usados por processos mal formulados e os arquivos finais devem conter os dados úteis, ou seja, aqueles que se transformam em informação ou são essenciais para o processamento no dia seguinte ou futuro. Dados que são gerados para controle de processamento ou que não se sabe para que servem denotam o desperdício no uso da máquina e, novamente, programas ou sistemas mal escritos ou desnecessários.
Medir produtividade pela capacidade de processamento é só um ensaio, é fácil, pois dependem quase que exclusivamente de métricas quantitativas. No próximo texto, abordaremos a produtividade envolvendo o que há de mais importante em qualquer organização, as pessoas.
http://imasters.uol.com.br/artigo/5409
Publicado em Segunda-feira, 05 de março de 2007 às 09h00
Assim, são muitos os estudos que buscam reduzir os custos ou aumentar os benefícios, ou o valor percebido, do processamento de dados nas empresas. Este texto coloca a questões da produtividade para reflexão de gerentes, usuários e profissionais da área de TI.
Produtividade, para o Aurélio, é "a relação entre a quantidade ou valor produzido e a quantidade ou valor dos insumos aplicados à produção"1. Ou seja, é produtivo aquilo que consegue gerar produtos com valor maior do que o custo de produzi-los. Mas o que é que um CPD produz?
Uma resposta evasiva comum, porém utilizada nas placas de missão em algumas empresas, começa com "ser a solução em serviços de TI..." e termina dizendo alguns dos processos ou produtos oferecidos aos seus usuários. Percebe-se, então, que a missão de muitos CPDs não é ser produtivo, com a re-salva de que isso pode ser óbvio e estar subentendido.
Muitos teóricos já cansaram em alertar que computadores não produzem informação. Informação, assim como conhecimento, é algo que só existe e têm sentido na mente humana2. Computadores processam dados que são úteis na medida em que irão se tornar informação e conhecimento para alguém. Os dados são manipulados, formatados, ordenados, comparados, armazenados, compactados, mostrados, impressos, transmitidos, entre outras ações, por meio de programas.
Os programas são seqüências de instruções lógicas que dizem ao computador o que fazer para manipular os dados. Programas são feitos por programadores e analistas de sistemas e os dados são obtidos por diversas formas, a mais comum ainda é por digitação em teclados feitas por funcionários, clientes e fornecedores da empresa.
Uma medida de produtividade, mas também de ineficiência, pode ser obtida pela quantidade de dados originais, digitados, e a quantidade de dados de saída gerados pelos programas de um sistema em um período de tempo. Assim, podemos afirmar que, se um CPD recebe 1 Gb de dados originais e gera 1,5 Gb de dados de saída (processados, armazenados, transmitidos, etc) em 24 horas, ele é mais produtivo que este mesmo CPD, se o processamento demorasse 25 horas. Isso quer dizer que no segundo caso, terá de se melhorar o desempenho (lógica) dos programas ou redimensionar para mais o computador.
A ineficiência, na hipótese acima, pode ser identificada analisando-se os arquivos intermediários e finais gerados no processo. Os arquivos intermediários podem estar sendo usados por processos mal formulados e os arquivos finais devem conter os dados úteis, ou seja, aqueles que se transformam em informação ou são essenciais para o processamento no dia seguinte ou futuro. Dados que são gerados para controle de processamento ou que não se sabe para que servem denotam o desperdício no uso da máquina e, novamente, programas ou sistemas mal escritos ou desnecessários.
Medir produtividade pela capacidade de processamento é só um ensaio, é fácil, pois dependem quase que exclusivamente de métricas quantitativas. No próximo texto, abordaremos a produtividade envolvendo o que há de mais importante em qualquer organização, as pessoas.
http://imasters.uol.com.br/artigo/5409
Publicado em Segunda-feira, 05 de março de 2007 às 09h00
Assinar:
Postagens (Atom)
