Segue a descrição do evento:

Introdução:
Atualmente o Gerenciamento de Serviços de TI tornou-se um fator crítico dentro e fora da TI. Ter conhecimento sobre os diversos frameworks, boas práticas e normas, sobre a aplicabilidade de cada um dentro de uma organização e seus benefícios é de extrema importância para os profissionais desta área. Participe deste Webinar e obtenha uma visão geral sobre os mais conhecidos frameworks e normas utilizadas mundialmente nas organizações.

Objetivo:
Apresentar os frameworks e normas mais utilizados ao redor do mundo como: ITIL®, Cobit, CMMI, Green IT, Cloud Computing, Business Information Management (BIM®), Normas ISO/IEC 20000 e 27000), etc, bem como seus benefícios e área de aplicação dentro das organizações.

Público alvo:
Profissionais de TI e fora de TI que já atuam ou queiram atuar na área de Gerenciamento de Serviços de TI e desejam ter uma visão integrada dos principais frameworks disponíveis no mercado.

Palestrante – Marcos Sabino Gomes
Consultor de Governança de TI da High IT que possui certificações como ITIL Expert, ISO 20000, ISO 27002, BIM®, Cloud Computing, que já atuou em diversos segmentos como finanças, manufatura e serviços, efetuando avaliação, desenho e implementação dos processos e normas relacionadas à TI, aplicando diversos treinamentos relacionados ao tema.

Inscrição gratuita: Para garantir a participação no evento clique em Register do lado esquerdo da tela neste site da Exin –  http://bit.ly/JWIgvW

A necessidade de alinhar objetivos e estratégias da organização à execução de portfólios, programas e projetos não é uma tarefa trivial. Comunicar esta estratégia de forma eficiente e torná-la eficaz é um desafio constante para as organizações.

Alinhada a esta demanda organizacional, a implantação de Escritórios de Gerenciamento de Projetos (PMO – Project Management Office) cria mecanismos que irão permitir acompanhar e monitorar se os projetos executados estão alinhados às estratégias das organizações, por exemplo.

Mas seria só este o papel do PMO na organização?

 Definindo um Escritório de Gerenciamento de Projetos (PMO)

Existem várias definições para o Escritório de Gerenciamento de Projetos, que de certa forma se convergem /complementam, tais como:

• Rad & Raghavan (2000) uma entidade organizacional que provê o foco institucional nos procedimentos de gerenciamento de projetos;
• Crawford (2000), como um provedor de serviços e processos completos para gerenciamento de projetos e que o mesmo também atua como centro de excelência em gestão de projetos dentro da organização;
• Cleland & Ireland (2000) como grupo de suporte que provê serviços para os gerentes de projetos, gestores seniores e gerentes funcionais trabalhando em projetos;
• Kate (2000) define o Escritório de Gerenciamento de Projetos como uma unidade do negócio focada na eficiência do gerenciamento de projetos e programas dentro da organização;
• Kerzner  (1992) diz que o time do projeto é uma combinação do Escritório de Gerenciamento de Projetos e os empregados funcionais.

A formalização de Contratos em Papel envolve uma série de custos que podem ser eliminados ou diminuídos com a utilização da Assinatura Digital. Muitas vezes desprezado e, em muitos casos, despercebido, um dos custos mais importantes tidos no processo de formalização de contratos em papel é o transporte destes documentos entre as partes.

Contratos em papel necessitam ter suas vias impressas e encaminhadas para seus signatários, seguindo a ordem estabelecida pelo administrador. Esses documentos são normalmente enviados para a coleta de assinaturas através de mensageiros (Motoboy) ou serviços de correio (por exemplo, o Sedex), dependendo da distância a ser percorrida.

Apenas como exercício, para calcularmos estes custos, consideraremos uma empresa que formaliza 200 Contratos por mês, ou seja, 2400 Contratos por ano. Cada um destes contratos é celebrado entre a empresa emissora e uma outra parte, ou seja, estamos considerando que o contrato possui apenas duas partes. Também estamos considerando que 30% dos documentos serão enviados via Sedex e 70% através de mensageiros. Está sendo considerado um custo médio de R$ 15,00 para o transporte via Motoboy (custo médio para envio de documento a uma distância média de 10 km na cidade de São Paulo) e R$ 11,10 para o envio através do Sedex. Adicionalmente, estamos considerando que as viagens do Motoboy podem ser otimizadas através do envio de mais de um documento em cada viagem. Assim sendo estaremos aplicando um fator de redução de 40% nos custos com Motoboy.

Dentro do cenário apresentado teremos os seguintes custos para encaminhamento dos documentos à outra parte do contrato para coleta de assinaturas:

Uma vez coletadas as assinaturas de todas as partes é necessário o encaminhamento dos Contratos para o reconhecimento de firmas no cartório. Neste momento estarão sendo reconhecidas somente as firmas dos representantes da empresa que emitiu os contratos, pois os mesmos já estão com as assinaturas e firmas reconhecidas pela outra parte. Dentro de um processo otimizado, consideraremos que este serviço será realizado apenas uma vez por dia através de serviço de motoboy, que encaminhará todos os contratos para um mesmo cartório, retornando-os em seguida para a empresa.

Com os contratos devidamente assinados e com as firmar reconhecidas por ambas as partes, faz-se necessário encaminhar uma das vias à outra parte.  Esses custos são calculados da mesma forma que quando do envio para a coleta de assinaturas, ou seja:

Observe que estamos considerando os custos com transporte tidos apenas pela empresa responsável pela emissão do contrato. Os custos decorrentes de transportes ao cartório e retorno dos documentos assinados a o emissor, tidos pela outra parte do contrato, não estão sendo considerados nestes cálculos.

Isto nos leva concluir que, dentro o cenário conservador exposto, cada contrato custa somente no quesito transporte a importância de R$ 20,76.  Este valor pode variar, para mais ou para menos, dependendo do fluxo adotado por cada empresa, mas podemos seguramente afirmar que estes custos são muito maiores que o custo total tido com a formalização de Contratos através da Assinatura Digital. Vale lembrar que no processo de formalização de Contratos através da Assinatura Digital não existem custos de transporte pois o documento permanece sempre no servidor e, quando necessário, é simplesmente exibido e colocado a disposição de seus signatários e/ou outros que acompanham o fluxo de formalização.

Observe que, dentro do cenário apresentado,  foram considerados os custos com transporte tidos apenas pela empresa responsável pela emissão do Contrato. Os custos decorrentes de transportes ao cartório e retorno dos documentos assinados para o emissor tidos pela outra parte do contrato, não estão sendo considerados nestes cálculos.

Em termos de custos globais, podemos afirmar que a adoção da assinatura digital para a formalização de contratos eletrônicos pode significar uma redução, dependendo do cenário analisado, de até 80% dos custos tidos com o processo de formalização de contratos baseados em papel.

O ANS descreve o Serviço, documenta Metas de Nível de Serviço (MNS) e especifica as responsabilidades do Provedor e de seus Clientes. Um único ANS pode cobrir múltiplos Serviços ou múltiplos Clientes.

ANS são suportados por ANO (Acordos de Nível Operacional), os quais são documentos intra-organizacionais que definem os acordos entre as áreas do Provedor. Estes são estruturados de forma a garantir que os objetivos definidos no ANS sejam devidamente entregues.

ANS também são suportados por CA (Contratos de Apoio), os quais são documentos estabelecidos com os respectivos Fornecedores, que contribuem significantemente para a entrega dos Serviços de acordo com os objetivos definidos no ANS.

ANS devem ser revistos regularmente, a fim de garantir um desempenho em conformidade com os Níveis de Serviço acordados, e estão totalmente sujeitos ao Processo de Gerenciamento de Mudanças/Liberações.

Desta forma, fica sob responsabilidade do Gerente de Nível de Serviço, com o apoio dos respectivos Analistas (inclui-se Gerente de Fornecedores e Contratos quanto aos CA), que o nível de suporte e os objetivos de desempenho acordados nos ANS sejam suportados e atingidos. Tais papéis devem identificar falhas para que os ANS sejam prontamente renegociados, se necessário.

Objetivos

• Formalizar Níveis de Serviço acordados entre Provedor e Cliente, possibilitando que os Serviços sejam entregues com excelência;
• Definir papéis e responsabilidades das partes para que suportem todo o Processo;
• Melhorar a comunicação e relacionamento entre as partes;
• Definir e monitorar o desempenho contra as MNS definidas, medindo a conformidade dos objetivos acordados, bem como o desenvolvimento contínuo de Programas de Melhoria de Serviço (PMS);
• Fornecer um mecanismo de revisão dos Serviços, o qual deve ser utilizado para definir ações de melhoria, sempre que necessárias;
• Alinhar e definir a expectativa do Cliente quanto ao Serviço provisionado, buscando melhorar continuamente a respectiva satisfação. Note-se que a “SATISFAÇÃO DO CLIENTE = PERCEPÇÃO – EXPECTATIVA (onde a pontuação positiva ou zero indica CLIENTE SATISFEITO)”.

Informações que poderiam estar contidas nos SLA / ANS (should)

1) Informações Básicas
ID
Identificação do ANS.

Nome / Título
Nome / Título do ANS.

Data
Data do acordo / atualização do ANS.

Versão
Versão do ANS.

Prazo
Prazo do ANS.

Descrição do Serviço
Descrever com detalhes o Serviço acordado.

Escopo do Serviço
Descrever com detalhes o escopo e funcionalidades acordadas.

Objetivos
Objetivos detalhados do ANS.

Comunicação
Descrição de todos os meios e pontos de contato entre o Provedor e o Cliente (Nomes e Funções, Números de Telefone, Endereços de e-mail, Dias/horários de disponibilidade dos contatos).

Horário do Serviço
Horário de disponibilidade do Serviço.

Horário de Suporte, Especiais e Críticos
Horário em que o suporte ao Serviço está disponível, bem como eventuais horários especiais e críticos.

Níveis de Suporte e Escalação
Onde os níveis de Serviço, procedimentos de escalação e qualidade do Serviço são detalhados.

Este também deve incluir os meios possíveis para formalizar queixas/reclamações quanto ao Serviço provisionado, bem como quais são os procedimentos para gerenciá-las.

Papéis e Responsabilidades
Papéis e Responsabilidades detalhados quanto às duas partes, os quais devem ser seguidos conforme estabelecido (Provedor e Cliente).

Obrigações
Descrição de todas as obrigações de ambas as partes. O Provedor e o Cliente devem estar totalmente comprometidos com tais atividades.

Pré-requisitos
Pré-requisitos que devem ser preenchidos por ambas às partes.

Restrições
Qualquer limitação ou restrição do ANS.

Análise Crítica do ANS
O ANS deve mostrar como o acordo é revisado. Ambas as partes devem estar de acordo com o proposto. Ex: Talvez seja necessária uma revisão de 04 a 06 meses ou deve ser revisado pelo menos anualmente. (Selecionar de acordo com o Tipo do Cliente: Quadrimestral, Semestral ou Anual).

Análise de Desempenho do Serviço (Relatórios)
O que será medido, como isso será medido, e como os relatórios devem ser gerados, distribuídos e analisados. Ambas as partes devem estar de acordo com o proposto. (Selecionar de acordo com o Tipo do Cliente: Quadrimestral, Semestral ou Anual).

Plano de Ação
É necessário incluir o que o Provedor fará no caso do não cumprimento do ANS por um determinado período. Ex: 02 meses consecutivos.

Programa de Melhoria de Serviço (PMS)
Procedimentos utilizados para ajustes e melhoria contínua dos Serviços provisionados.

Termos de Pagamento (Cobrança)
Fórmula e método de pagamento (Cobrança).

Reajustes
Informações detalhadas quanto aos reajustes do Serviço (índice de correção, prazo de aplicação etc.).

Preço
Informações detalhadas quanto ao preço do Serviço.

Descontos
Informações detalhadas quanto aos descontos do Serviço.

Penalidades
Penalidades as quais devem ser exercidas em eventual quebra de nível de Serviço.

Término / Rescisão
Informações detalhadas quanto ao termino / rescisão do ANS.

2) Informações Adicionais
Contrato Jurídico
Descrever os Contratos Jurídicos que suportam este ANS.

CA que o Suporta
Descrever os CA (Contratos de apoio) que suportam este ANS.

ANO que o Suporta
Descrever os ANO (Acordos de nível operacional) que suportam este ANS.

Demais ANS Suportados
Descrever os demais ANS (Acordos de nível de Serviço) que são suportados por este ANS.

 Treinamento
Qualquer tipo de treinamento necessário ao Cliente ou ao Provedor.

Incidentes
Descrição de que forma eventuais Incidentes devem ser resolvidos, o mais rapidamente possível.

Problemas
Descrição de que forma eventuais Problemas devem ser investigados e solucionados.

Mudanças
Descrição de que forma eventuais Mudanças devem ser conduzidas, vide janelas acordadas entre as partes.

Segurança
Os requisitos de segurança física e lógica para o Serviço.

Confidencialidade e Integridade
Definição do que é considerada confidencialidade e integridade do Serviço.

Disponibilidade e Confiabilidade
Definição do que é considerada disponibilidade e confiabilidade do Serviço, incluindo conceitos como MTRS, MTBF, MTBSI.

Desempenho
Detalhes do desempenho do Serviço e tempos de resposta.

Capacidade
Detalhes dos requisitos de capacidade do Serviço.

Continuidade
Detalhes dos níveis mínimos e qualidade do Serviço em caso de desastres / incidentes gravíssimos, e como o plano de continuidade é abordado.

Glossário
Explicação de quaisquer abreviações ou terminologias utilizadas, para ajudar no entendimento dos termos contidos no ANS.

Controle de Alterações e Melhorias
Registro detalhado de todas as alterações acordadas, datas e signatários. Deve conter também detalhes sobre o histórico do documento e suas revisões.

Concluindo…
Você acredita ser viável este detalhamento com “N informações”, de acordo com a cultura das empresas brasileiras?

Como esta estrutura atua como o primeiro nível de suporte e tem forte interação com os usuários, seu desempenho define a percepção que as áreas de negócio têm do serviço de TI. É como se o Service Desk fosse a “vitrine da TI” exercendo um papel significante e que irá moldar a reputação da organização de TI por inteiro. A expectativa dos usuários vai além da resolução de suas questões e esperam que estas questões sejam resolvidas de forma rápida e eficaz, buscando maximizar a sua satisfação no serviço. Para gerenciar estas expectativas de forma equilibrada e a custos justificáveis, você deve operar um Service Desk buscando melhorar as taxas de resolução no primeiro contato e minimizar os escalonamentos para segundo e terceiro níveis de suporte. Para tanto, o Service Desk deve estar bem capacitado e munido de ferramentas apropriadas que proporcionem agilidade e precisão no atendimento. Vamos a algumas questões-chave relacionadas a pessoas, processos e investimentos em tecnologia que os gestores de TI precisam fazer para melhorar a eficácia do Service Desk.

1. Discipline os usuários a utilizarem o Service Desk como canal de suporte. É muito comum que os usuários, por conveniência ou por conhecer o especialista que pode resolver seu problema com mais rapidez, acaba não acionando o suporte através do Service Desk. Nesta situação também é muito comum que este atendimento, digamos fora do processo, não seja registrado e portanto perde-se uma informação histórica dos acionamentos de TI. Além disso, a questão endereçada ao especialista muitas vezes poderia ter sido resolvida pelo Service Desk por ser algo simples e tira o foco de atividades que poderiam agregar mais valor ao serviço, como a identificação da causa-raiz de problemas. Segundo pesquisa do Forrester Research o custo de um chamado ao Service Desk fica entre 18 e 23 dólares. Quando um chamado é transferido para o segundo nível o custo passa a 35 dólares ou mais. Caso ainda seja necessário escalar para o terceiro nível o custo do ticket pode chegar a 100 dólares. Além do custo, a escalação aumenta o tempo de atendimento e diminui a satisfação do usuário. Por isso, os líderes de TI devem entender os custos por chamado de todos os níveis de suporte e criar a cultura de que todos os acionamentos devem ser realizados ao Service Desk.

2. Aumente as taxas de resolução no primeiro contato (FCR – First Call Resolution). A taxa de resolução no primeiro contato é um importante indicador da eficiência de um Service Desk, pois quanto maior o percentual, maior sua capacidade de resolver as questões. Com a equipe capacitada, habilidades e ferramentas apropriadas para dar suporte ao processo, podemos aumentar a resolução dos chamados no primeiro contato e,  consequentemente, contribuir para aumentar a satisfação. Pesquisas de mercado apontam que uma boa taxa esteja entre 65% e 75%, contudo, esse indicador deve ser interpretado dentro do cenário e realidade da TI, principalmente com relação à tecnologia utilizada, tipo de indústria e cultura organizacional. Para o aumento desta taxa, algumas ações podem ser consideradas para o aumento desta taxa tais como: capacitação continuada, estruturação de bases de conhecimento (scripts de atendimento, manuais, checklists etc.) e ferramentas que permitam acessar remotamente a estação de trabalho do usuário. Também vale considerar dar mais autonomia ao Service Desk nas ferramentas administrativas de infraestrutura.

3. Tenha no Service Desk pessoas especialistas em atender pessoas, não em tecnologia. A maior parte dos chamados realizados ao Service Desk é de baixa complexidade técnica e portanto não exige conhecimento especializado do profissional que irá atuar na equipe. Busque ter no grupo pessoas que tenham habilidades interpessoais e foco no atendimento ao cliente. Estes profissionais precisam ter a capacidade de se relacionar com os usuários sem utilizar jargões nebulosos, termos complicados e acrônimos como VPN, DBA, SaaS, LAN, WAN, VoiP, IP e outros que as vezes sem a ajuda do Google fica difícil saber o que é. Outros aspectos relevantes são: empatia com o usuário, observando as questões sob a perspectiva dele; entendimento e aceitação de que o problema do usuário afeta o negócio; consciência de que sem o usuário não haveria Service Desk; entender que o usuário é especialista em sua área de atuação, não em TI.

O TI Especialistas firmou uma parceria com a High IT Consulting e estamos levando os profissionais que acompanham nosso portal ao evento: Novas tendências de Gestão de Negócio e Gestão de TI. São somente 20 convites.

Os 20 primeiros que enviarem um email para augusto@tiespecialistas.com.br com o título “Quero ir ao evento Novas tendências de Gestão de Negócio e Gestão de TI ” e que curtem as páginas do TI Especialistas ( www.facebook.com/fan.tiespecialistas ) e da High IT Consulting ( http://www.facebook.com/highit ) conquistarão a oportunidade de conhecer o que há de mais novo na América Latina em Gestão de Negócio e Gestão de TI.

Segue o convite oficial:

No dia 19/04 às 17 horas a High IT Consulting convida os profissionais da área de TI para o lançamento de novos frameworks que vão mudar a forma como as organizações fazem a gestão do seu negócio. O evento será realizado em uma das mansões mais cobiçadas de São Paulo e irá contar com especialistas no assunto, além de sorteio de 6 exames (lançamentos) do EXIN para os participantes.

• Gerenciamento de Informação do Negócio (BiM) e Executive Cockpit (A3S Serviços): Conheça o novo framework que irá agregar valor as informações do negócio de maneira integrada com o ITIL®.

• Air Watch (A3S Serviços): Efetuar a gestão de dispositivos móveis (tablets e smartphones) tornaram-se uma necessidade dentro das organizações. Conheça a solução que irá garantir a correta gestão.

Agenda(19/04):
17:00h – Check-in
17:30h – Coquetel de abertura
18:30h – Início das palestras/lançamentos:

• Gerenciamento de Informação do Negócio (BiM) e Executive Cockpit. Conheça o novo framework que irá agregar valor as informações do negócio de maneira integrada com o ITIL®.
• Cloud Computing. Saiba como gerenciar e desenvolver estratégias de implementação de Cloud Computing dentro das organizações.
• Green IT. Sustentabilidade nos negócios é um dos temas em alta atualmente no mercado. Entenda como a TI poderá agregar valor ao negócio utilizando de estratégias verdes.
• Air Watch. Efetuar a gestão de dispositivos móveis (tablets e smartphones) tornaram-se uma necessidade dentro das organizações. Conheça a solução que irá garantir a correta gestão.

20:00h – Apresentação e entrega dos certificados dos primeiros profissionais certificados da américa latina em BiM, Cloud Computing e Green IT
20:15h – Coquetel de Encerramento, networking e sorteio de brindes

Documentar e manter atualizado todo e qualquer procedimento operacional necessário à continuidade de negócios da empresa ou cliente, caso seja o prestador de serviços, é, obrigatoriamente, pilar para a construção de uma área de TI forte e associação direta na relação de confiança da empresa e para com a empresa. Quanto mais documentado o processo, mais flexível torna-se a necessidade de manter o mesmo profissional focado em um único projeto, podendo expandir os horizontes profissionais e comerciais. Gerencialmente, é garantir as rédeas de sua gestão e, principalmente, a tão sonhada qualidade nas entregas de TI, hoje tão mencionadas e que não chegam ao nível desejado pelos seus clientes na maioria das vezes.

Além da documentação, devemos também divulgar a mesma e garantir que todos conheçam e tenham fácil acesso a cópias digitais e impressas, sendo esta última uma cópia departamental e outra operacional para cada colaborador. Apesar de parecer óbvio, o processo de restauração dos sistemas em caso de desastre ou perda deve ser impresso… De nada vai adiantar todos os documentos estarem armazenados no backup, mas ninguém operar o processo de restauração por falta de procedimento ou conhecimento de como fazê-lo! Novamente, parece básico, mas acontece. E muito, para ser sincero.

Outro ponto também que deve ser levado em conta é o trabalho em par de seus profissionais. Independente do budget da sua empresa é sabido que, por mais cuidado que se tenha em reter talentos, em um determinado momento este profissional irá ausentar-se, seja férias, licença médica ou “alçar novos horizontes”. Garantir que o par esteja familiarizado com os procedimentos operacionais realizados pelo seu profissional irá certificar que não se demonstre qualquer fragilidade e que operacionalmente tanto você quanto seus clientes não são reféns de um único profissional.

Este artigo visa apresentar os motivos pelos quais não se utiliza a técnica APF (Análise por Ponto de Função) nos processos e projetos relacionados à implementação, suporte e melhorias de ERPs.

2 – ERP

2.1 – Definição

Sistemas Integrados de Gestão Empresarial (SIGE ou SIG), em inglês Enterprise Resource Planning (ERP), são sistemas de informação que integram todos os dados e processos de uma organização em um único sistema. A integração pode ser vista sob a perspectiva funcional (sistemas de: finanças, contabilidade, recursos humanos, fabricação, marketing, vendas, compras, etc.) e sob a perspectiva sistêmica (sistema de processamento de transações, sistemas de informações gerenciais, sistemas de apoio à decisão, etc.). Os ERPs, em termos gerais, são uma plataforma de software desenvolvida para integrar os diversos departamentos de uma empresa, possibilitando a automação e armazenamento de todas as informações de negócios.

2.2 – Objetivo

O objetivo do ERP é a gestão integrada dos negócios das Empresas.

2.3 – Tarefas Envolvidas

A seguir descrevemos sucintamente as tarefas envolvidas no ciclo de vida de um ERP numa Empresa.

2.3.1 – Implementação

As tarefas a seguir estão relacionadas com o ciclo de Implementação, ou Instalação, do ERP na Empresa usuária.

2.3.1.1 – Levantamento das Necessidades

Esta tarefa consiste em obter todas as informações necessárias à Implementação correta do ERP na Empresa usuária de forma que o mesmo cubra a maior parte das necessidades de negócio da Empresa que estejam no escopo previsto na contratação do ERP.

Este levantamento é realizado através de entrevistas com os Usuários Chave da Empresa usuária e a definição do escopo detalhado deve ser validada tanto pela fornecedora do ERP, quanto pela Direção da Empresa usuária a fim de alinhar todas as expectativas que envolvem a Implementação do ERP.

Esta tarefa se inicia durante o processo de pré-venda do ERP em um nível superficial e vai, passo a passo, sendo aprofundado durante o processo técnico-comercial e chega a seu ponto de maior profundidade no início do Projeto de Implementação do ERP.

Esta tarefa envolve tanto o conhecimento do negócio por parte dos Usuários Chave da Empresa usuária, quanto o conhecimento das melhores práticas de mercado e das funcionalidades fornecidas pelo ERP por parte dos Consultores do Fornecedor do ERP, para que possam ser definidos, ao final desta tarefa, qual será a abrangência das demais tarefas no Projeto de Implementação, isto é, Parametrização/Configuração, Customização, Capacitação, Testes Unitários e Testes Integrados.

Esta tarefa pode utilizar até 10% (dez por cento) dos esforços envolvidos no Projeto de Implementação.

2.3.1.2 – Parametrização/Configuração

Esta tarefa consiste em Parametrizar/Configurar o ERP para atender às Necessidades de Negócio da Empresa usuária conforme resultado da tarefa Levantamento das Necessidades anteriormente executada.

Parametrizar/Configurar consiste em imputar valores nos parâmetros disponíveis no ERP a fim de que este se comporte da maneira pretendida pelo Fornecedor do ERP e desejada pela Empresa usuária.

Parametrizar/Configurar NÃO envolve qualquer tipo de programação/codificação, uma vez que toda Parametrização/Configuração se restringe às funcionalidades oferecidas como padrão pelo ERP.

Esta tarefa pode utilizar até 50% (cinquenta por cento) dos esforços envolvidos no Projeto de Implementação.

2.3.1.3 – Customização

Esta tarefa consiste em ajustar, através de programação/codificação, as funcionalidades oferecidas como padrão pelo ERP a fim de atender às Necessidades de Negócio da Empresa usuária que não possam ser atendidas através de Parametrização/Customização das funcionalidades oferecidas como padrão pelo ERP conforme resultado da tarefa Levantamento das Necessidades anteriormente executada.

Esta tarefa consiste, ainda, em desenvolver, através de programação/codificação, novas funcionalidades, originalmente não oferecidas como padrão pelo ERP, a fim de atender às Necessidades de Negócio da Empresa usuária que não possam ser atendidas através de Parametrização/Customização das funcionalidades oferecidas como padrão pelo ERP conforme resultado da tarefa Levantamento das Necessidades anteriormente executada.

Esta tarefa pode utilizar até 20% (vinte por cento) dos esforços envolvidos no Projeto de Implementação.

2.3.1.4 – Capacitação

Esta tarefa consiste em capacitar os Usuários, Chave e/ou Finais, da Empresa usuária nas funcionalidades padrão do ERP Parametrizadas/Configuradas, bem como nas funcionalidades padrão do ERP Customizadas e nas funcionalidades Desenvolvidas, para o atendimento às Necessidades de Negócio da Empresa usuária conforme resultado da tarefa Levantamento das Necessidades anteriormente executada.

Esta tarefa pode utilizar até 5% (cinco por cento) dos esforços envolvidos no Projeto de Implementação, e, proporcionalmente, até 1% (um por cento) deste esforço, especificamente para a Capacitação nas Customizações.

2.3.1.5 – Testes Unitários

Esta tarefa consiste em testar, de forma unitária, cada uma das funcionalidades Parametrizadas/Configuradas ou Customizadas nas tarefas anteriores a fim de garantir sua aderência individual em relação ao resultado da tarefa Levantamento das Necessidades anteriormente executada.

Esta tarefa pode utilizar até 10% (dez por cento) dos esforços envolvidos no Projeto de Implementação, e, proporcionalmente, até 2% (dois por cento) deste esforço, especificamente para a Capacitação nas Customizações.

2.3.1.6 – Testes Integrados

Esta tarefa consiste em testar, de forma integrada, todas as funcionalidades Parametrizadas/Configuradas e Customizadas nas tarefas anteriores a fim de garantir sua aderência, como conjunto, em relação ao resultado da tarefa Levantamento das Necessidades anteriormente executada.

Esta tarefa pode utilizar até 20% (vinte por cento) dos esforços envolvidos no Projeto de Implementação, e, proporcionalmente, até 4% (quatro por cento) deste esforço, especificamente para a Capacitação nas Customizações.

2.3.2 – Suporte Pós-Implementação

As tarefas a seguir estão relacionadas com o ciclo de vida que ocorre após a Implementação, ou Instalação, do ERP na Empresa usuária.

2.3.2.1 – Software

As tarefas a seguir estão relacionadas com o ERP propriamente dito enquanto conjunto de programas de computador que oferece uma miríade de funcionalidades que visam atender, de forma padrão, às Necessidades de Negócio das Empresas usuárias.

Estas tarefas são de responsabilidade exclusiva do fornecedor do ERP e são cobertas pelo contrato de Manutenção e Suporte firmado entre o fornecedor do ERP e as Empresas usuárias.

2.3.2.1.1 – Correção

Esta tarefa consiste em corrigir comportamentos diferentes do previsto/definido por algum dos programas que compõe o ERP e consiste em ajustar, através de programação/codificação, a funcionalidade em desalinho.

2.3.2.1.2 – Melhoria

Esta tarefa consiste em ampliar o espectro de abrangência de uma funcionalidade já disponibilizada no ERP, ou incluir uma nova funcionalidade na lista das já oferecidas às Empresas usuárias.

Esta tarefa consiste em ajustar, ou desenvolver, através de programação/codificação, a funcionalidade a ser aprimorada ou incluída.

2.3.2.2 – Parametrização/Configuração

As tarefas a seguir estão relacionadas com o Projeto de Implementação do ERP na Empresa usuária e depende de alterações no cenário em que esta Empresa atua, quer por motivos internos (aumento de vendas, mudanças de processo, etc.), quer por motivos externos (ruptura tecnológica, mudanças em seu mercado de atuação, alterações legais ou fiscais, etc.), ou é consequência de incorretude na execução das tarefas Teste Unitário e Teste Integrado descritas acima.

Parametrizar/Configurar NÃO envolve qualquer tipo de programação/codificação, uma vez que toda Parametrização/Configuração se restringe às funcionalidades oferecidas como padrão pelo ERP.

2.3.2.2.1 – Correção

Esta tarefa consiste em corrigir comportamentos diferentes do previsto/definido por alguma das parametrizações/configurações das funcionalidades padrão do ERP e consiste em ajustar, através de configuração/parametrização a funcionalidade em desalinho.

2.3.2.2.2 – Melhoria

Esta tarefa consiste em ajustar às novas necessidades de negócio da Empresa usuária os comportamentos diferentes dos atualmente necessários, por alguma alteração no cenário em que esta Empresa atua, as parametrizações/configurações das funcionalidades padrão do ERP em desalinho.

2.3.3 – Customização

As tarefas a seguir estão relacionadas com o Projeto de Implementação do ERP na Empresa usuária e depende de alterações no cenário em que esta Empresa atua, quer por motivos internos (aumento de vendas, mudanças de processo, etc.), quer por motivos externos (ruptura tecnológica, mudanças em seu mercado de atuação, alterações legais ou fiscais, etc.), ou é consequência de incorretude na execução das tarefas Teste Unitário e Teste Integrado descritas acima.

2.3.3.1.1 – Correção

Esta tarefa consiste em corrigir comportamentos diferentes do previsto/definido por alguma das customizações e consiste em ajustar, através de programação/codificação, a funcionalidade em desalinho.

2.3.3.1.2 – Melhoria

Esta tarefa consiste em ajustar às novas necessidades de negócio da Empresa usuária os comportamentos diferentes dos atualmente necessários, por alguma alteração no cenário em que esta Empresa atua, as customizações e consiste em ajustar, através de programação/codificação, a funcionalidade em desalinho.

2.3.4 – Elucidação de Dúvidas de Usuários

Esta tarefa consiste em elucidar dúvidas dos Usuários, Chave ou Finais, da Empresa usuária em relação ao pleno uso das funcionalidades do ERP implementadas nesta Empresa, quer através de Parametrização/Configuração, quer através de Customização, bem como elucidar dúvidas destes Usuários quanto à possibilidade de incremento destas funcionalidades a fim de efetivar todo o potencial que é oferecido pelo ERP.

Esta tarefa NÃO envolve qualquer tipo de Programação/Codificação ou Parametrização/Configuração. 

3 – APF (Análise por Ponto de Função)

3.1 – Definição

Método Padrão para medir Software do ponto de vista do Usuário através da quantificação da funcionalidade fornecida e prevê que estas medidas são “afinadas” pela repetição de projetos equivalentes.

3.2 – Objetivo

Medir o desenvolvimento e melhoria/manutenção de SOFTWARE de forma independente da tecnologia utilizada para sua implementação.

3.3 – Resultados

A APF é uma técnica eficaz na geração de indicadores para a gerência de projetos de software[1].

4 – Conclusão

Em função da APF (Análise por Ponto de Função) ser um Método cujo objetivo é a medição prévia e a gestão de Projetos de Software, e os Projetos de Implementação e Pós-Implementação de ERP não poderem ser caracterizados como Projetos de Software uma vez que não são intrinsecamente ligados à codificação/programação, os Projetos de Implementação e de Pós-Implementação não podem ser metrificados e/ou gerenciados pela APF.

No limite, apenas 27% (vinte e sete por cento) de um Projeto de Implementação de ERP estão intrinsecamente ligados à codificação/programação, conforme lista de tarefas a seguir:

• Customização
• Capacitação (no que tange às Customizações)
• Testes Unitários (no que tange às Customizações)
• Testes Integrados (no que tange às Customizações)

Este percentual não é suficientemente relevante para que todo o Projeto de Implementação de ERP seja metrificado e/ou gerenciado pela APF.

Os Projetos de Implementação de ERP não possuem repetição em relação aos itens de Customização, uma vez que se estes itens passarem a se repetir a funcionalidade inerente a estes deve passar a ser fornecida de maneira padrão pelo ERP e deixará de ser Customização, passando a se tratar de uma Parametrização/Configuração e, novamente, não podendo ser metrificada e/ou gerenciada pela APF.

Em se tratando de Projetos de Pós-Implementação, das seguintes tarefas, apenas as duas últimas estão relacionadas com as Empresas usuárias do ERP, e são de volume estatisticamente pouco representativo, cerca de 25% (vinte e cinco por cento), o que não as torna suficientemente relevante para que todo o Projeto de Pós-Implementação de ERP seja metrificado e/ou gerenciado pela APF.

• Correções de Software (de responsabilidade e visibilidade restritas ao fornecedor do ERP)
• Melhorias de Software (de responsabilidade e visibilidade restritas ao fornecedor do ERP)
• Correções de Customizações
• Melhorias de Customizações

Assim, pelas razões expostas acima, o APF não se aplica a Projetos de Implementação e Pós-Implementação de ERPs.

Devemos também entender a diferença entre “risco” e “exposição ao risco”. Medir o risco mede simplesmente a variância dos possíveis resultados de um evento, enquanto exposição ao risco mede as consequências dos diversos resultados possíveis do evento. Um evento pode ter um resultado muito incerto (alto risco) porém suas consequências são de baixo impacto para a empresa (baixa exposição ao risco). Mitigar o risco não é tão importante nas decisões de investimento quanto mitigar a exposição ao risco.

Normalmente a minimização do risco traz custos elevadíssimos para as empresas. Portanto, não é possível analisar somente o aspecto de minimização do risco, mas qual é o investimento necessário para cada nível de exposição ao risco. Assim estamos introduzindo mais uma variável ao modelo. Há um trade-off entre menor exposição ao risco e investimentos necessários.

Risco e retorno andam juntos. Quanto maior o risco, maior o retorno exigido pelos investidores. Se um investidor não quisesse correr riscos, ele aplicaria seus recursos em ativos livres de risco e não nas empresas. Risco faz parte do negócio de qualquer empresa. A questão então é qual é o retorno esperado para cada nível de risco. Dizemos que há uma “clientela” para qualquer nível de risco. Há quem invista em uma empresa de prospecção de petróleo. Embora seja de altíssimo risco, o retorno esperado também é elevado. Há empresas que têm níveis mínimos de riscos, porém oferecem baixo retorno para seus investidores. Há clientelas para todos os níveis de risco/retorno. O histórico da empresa é o melhor indicador de qual é a clientela de investidores dela. Não se deve esquecer, contudo, que nenhum investidor está propenso a correr riscos que não tragam o correspondente retorno.

Existem metodologias que permitem estas avaliações para a correta avaliação de retornos sobre os investimentos, entre elas a “Programação Linear”, “Método por Opções Reais” e “Simulação de Monte Carlo”. Assim, avaliar riscos não é simplesmente minimizar ou eliminar o risco ou a exposição ao risco e sim adequar o retorno sobre o investimento para o nível de risco do projeto.

Refletindo profundamente sobre o assunto, chegamos á conclusão que a briga ainda levará anos para ter uma solução plausível, e que acima de tudo não infrinja o direto da criatividade.

Patentes são afinal um bem necessário, ou mais uma faca de dois gumes? Pensem na seguinte conjectura: Se em meados do século XVIII houvesse a guerra das patentes, hoje, teríamos apenas alguns modelos de carros e  um único fabricante.

Ao mesmo tempo que fecho a minha tecnologia afim de protegê-la, dou direto que outros inventos também fiquem nas sombras, portanto está ai a faca de dois gumes.

Voltando ao exemplo anterior, imaginem se tivessem criado patentes sobre o motor a combustão, na descoberta da penicilina? Como seria o hoje o nosso mundo?

As descobertas atuais e até mesmo as mais antigas, reutilizam conceitos afim de recriar inovações quase que diariamente, e como criar um bloqueio para isso? É como dizer que em 1880 o  uso de trens á vapor, estava afetando a industria de ferraduras.

Não dá para bloquear o que não se pode mensurar. Será que estamos com tecnologias do século XXI, mas com a mentalidade do século XV? Fingir que as patentes vão criar um escudo, é o mesmo que achar que tirar coelho da cartola será uma mágica revolucionará pelos próximos 20 séculos.

A busca por inovação surge de grandes empresas, ou mesmo de garotos nas suas garagens.

Busquem se afugentar destas batalhas, o mundo nunca ficará preso a uma única visão de negócio.

O que estou dizendo prova-se na história do mundo em diversas áreas, como na época dos romanos que achavam ser o maior império da terra e ainda assim, tiveram que provar o gosto amargo de Genghis Khan criando um território 4x maior com outras fórmulas de conquista.

O mundo se prova sempre flexível quando há bloqueios, mas enfrentamos uma nova onda, e as impressões e soluções para este caso são muitas, mas resta a criatividade de muitos determinar se realmente faz sentido utilizar de um método injusto, para provar que receitas devem ser guardadas no fundo do “baú da vovó”.

Como apresentado no título deste artigo, a única fórmula que tem se consolidado durante os últimos 50 anos, tem sido á da COCA-COLA, e é justamente isso que a tecnologia tem tentando se equalizar, mas vejamos como é incrédula essa fórmula. Enquanto a primeira nunca muda sua fórmula, a evolução da tecnologia é praticamente diária.

Mesmo assim deveríamos entender que fórmula é diferente de patente (enquanto á fórmula é relacionada á quais ingredientes são utilizados, tempo de cozimento, graus para fervura –  as patentes estão diretamente focadas no produto final).

Então onde está a vantagem em termos patentes? A resposta para essa pergunta tem sido uma incógnita para mim, mas para a MICROSOFT, INTEL, APPLE e outras mais, aparentemente tem algum sentido, sentido esse que vão até mesmo contra os preceitos inicias da maioria delas, criadas dentro de garagens e sobretudo revisando produtos de grandes empresas e criando novos produtos.

Ao final de tudo Lavoisier estava certo: Nada se cria, nada se perde , tudo se transforma.

Sempre que é proposto um novo projeto em qualquer empresa duas das primeiras questões que surgem são:

• Quanto vamos ganhar com isto?
• Onde está o ROI?

E neste momento se inicia o calvário de quem sabe que este projeto é bom e será útil para a empresa, pois ou o ROI é óbvio e muito simples de se obter a partir da coleta de algumas poucas informações facilmente acessíveis e ninguém teria feito as perguntas acima, ou é praticamente impossível mensurá-lo, quer por estar ligado a aspectos abstratos e/ou intangíveis, quer por estar ligado a processos complexos e não documentados da empresa, que normalmente perpassam diversas áreas pouco afeitas à divulgação de seus métodos, processos e informações. Vamos iniciar nossa análise pelo segundo caso, o dos processos complexos e não documentados.

Muito se fala em termos de BPM (Business Process Management), e algumas empresas adquirem ferramentas de BPM e seus gestores deitam tranquilamente a cabeça em seus travesseiros à noite certos de que possuem BPM, embora não tenham certeza das razões que os leva a possuí-lo. Entretanto, posso afirmar categoricamente que a quase totalidade das empresas não possui seus processos de negócio devidamente documentados, que é o alicerce do BPM. Devidamente documentados significa, em primeiro lugar, possuir o fluxo das atividades atualizado e graficamente demonstrado, onde a granularidade destas atividades atenda às necessidades da empresa e da(s) área(s) especificamente envolvida(s), isto é, de nada adianta existir uma atividade denominada “Contas a Pagar”, por exemplo, ela deve estar detalhada a ponto de se saber quais são as atividades que compõe o “Contas a Pagar”. Devidamente documentados inclui, também, uma rápida e atualizada descrição de cada uma das atividades descritas graficamente, bem como os riscos envolvidos em cada atividade e como mitiga-los, e ainda o que fazer em caso de serem observados erros na execução da atividade. Devidamente documentados significa, ainda, a apresentação do custo atualizado de execução de cada atividade, algo que, se alguma empresa possuir, é a exceção. E, a partir deste quadro, lhes pergunto: “Sem esta documentação, como é possível fazer o Gerenciamento dos Processos de Negócio da empresa?”

A falta destes processos, devidamente documentados conforme descrito acima, dificulta, quando não impede, a correta previsão do ROI dos projetos e/ou a observação de oportunidades de aumentar a eficiência destes processos (melhoria contínua), ou até a substituição dos processos atuais por outros mais adequados às necessidades de negócio da empresa (inovação).

Assim, antes de buscar as informações apenas para demonstrar o ROI de cada projeto específico, o que demanda grande esforço e tempo (que se traduzem por custo) e que muitas vezes passa pelos mesmos processos de negócio e fontes de informação inúmeras vezes, conclamo as empresas a documentar devidamente todos seus processos de negócio, e a manter esta documentação atualizada, de modo que o investimento envolvido na análise de cada projeto proposto será minimizado e o calvário descrito anteriormente para o caso dos processos complexos e não documentados simplesmente deixa de existir.

Mas alguns me perguntarão depois do exposto: “Só é possível prever o ROI baseado na redução dos custos?”.

A resposta é NÃO, podemos e devemos prever o ROI também com o incremento do faturamento de forma percentualmente maior que o incremento correspondente no custo envolvido, ou seja, o aumento da rentabilidade/lucro, o que, de qualquer forma, envolve o conhecimento e documentação devida dos processos envolvidos, caso contrário, se pode basear o ROI na previsão de incremento do faturamento, mas sem se atentar para o consequente incremento nos custos do processo, o que, finalmente resultada em redução da rentabilidade/lucro.

Mas aí se inicia a discussão do primeiro caso levantado no início deste artigo, os aspectos abstratos e/ou intangíveis, pois “Quem garante que o faturamento será incrementado?”, uma vez que o faturamento depende de uma importantíssima variável externa muitíssimo sensível e, na maior parte dos casos, fora de nosso controle: o Cliente. Pois:

• Quem garante que os Clientes comprarão a produção extra que estaremos colocando no mercado com nosso ganho de produtividade?
• Quem garante que os Clientes aceitarão pagar mais por um produto/serviço similar ao anterior em função das novidades apresentadas?
• Quem garante que os Clientes trocarão seus fornecedores atuais por sua empresa em função de sua oferta?
• Quem garante…?

Resposta: NINGUÉM GARANTE NADA!

E aí reside o risco inerente a qualquer projeto de inovação, pois a inovação se baseia em fazer algo que não foi feito ainda, portanto que não possui histórico registrado, apenas expectativa de resultado. E, sendo avesso ao risco, muitos “gestores” encerram o projeto proposto antes mesmo de inicia-lo.

Neste momento formulo nova questão: “Qual o custo de não desenvolver o projeto?”

A resposta simples, para não dizer simplória (ops, já disse…), é que “não há custo uma vez que o projeto não será desenvolvido!”.

Daí surgem algumas questões relacionadas à variável externa fora de nosso controle citada anteriormente:

• Quem garante que os Clientes se manterão fiéis ao nosso produto/serviço se nossos concorrentes apresentarem preço menor por um produto/serviço equivalente ao nosso devido ganho de produtividade que eles conseguiram?
• Quem garante que os Clientes se manterão fiéis ao nosso produto/serviço se nossos concorrentes apresentarem um produto/serviço similar ao nosso com alguns diferenciais ou melhorias?
• Quem garante que os Clientes se manterão fiéis ao nosso produto/serviço se nossos concorrentes apresentarem uma oferta similar?
• Quem garante…?

E a resposta, novamente, é: NINGUÉM GARANTE NADA!

O que resulta na questão final: “Você prefere correr o risco de investir em inovação, ou o risco de perder seus Clientes?”

Ou, simplificando: “Você está pronto a contabilizar o custo de não fazer nada?”

A Green Hat foi adquirida pela IBM no início de 2012 com o objetivo de integrar o portfólio de produtos RATIONAL voltados à qualidade de software e assim fortalecer a estratégia da IBM em oferecer soluções que favorecem o desenvolvimento ágil.

Um dos princípios da metodologia ágil é “satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado” e isto pode ser alcançado com as soluções Green Hat, que permitem aos desenvolvedores conduzir testes durante a fase de desenvolvimento, através de um ambiente virtualizado, o qual tem a capacidade de simular serviços dependentes e aplicações inteiras, proporcionando testes de integração com outros sistemas sem a necessidade de se construir um laboratório de testes, com todos os artefatos de hardware e software que compõem o ambiente de produção.

Imagine o desenvolvimento de uma aplicação que se comunica com muitos outros sistemas e com os mais diversos protocolos e tecnologias como HTTP, web services, SOA, JMS, TIBCO, IBM WebSphere MQ e SAP. Nestes casos, construir uma infraestrutura física ou instâncias na nuvem para fins de teste vai demandar tempo dos desenvolvedores além de ser caro para a empresa. Com as soluções Green Hat é possível a criação de “serviços virtuais” que simulam o comportamento de um aplicativo inteiro. Estes “serviços virtuais” podem rodar em um hardware commodity, em uma nuvem privada ou pública e assim, cada desenvolvedor e analista de testes, pode facilmente ter seu próprio ambiente de teste.

Utilizar o tempo dos desenvolvedores para garantir produtos de alta qualidade, minimizar o custo de desenvolvimento e entregar produtos com maior agilidade é primordial em todos os mercados.

Considerando a atual demanda de mercados em expansão como smartphones e tablets, que requerem cada vez mais aplicações, estes requisitos são ainda mais evidentes, pois os consumidores esperam produtos que atendam totalmente as suas expectativas, de maneira segura e sem bugs. Neste cenário, ao utilizar as soluções Green Hat, um ambiente de teste virtual pode ser configurado numa questão de minutos versus semanas, e também, por uma fração do custo que seria montar este ambiente físico.

Sintetizando, as soluções Green Hat promovem:

• Redução do Custo de Testes de Software:
  • Custos de infraestrutura na construção do laboratório de testes podem ser reduzidos em até 90%;
  • O trabalho envolvido na criação de ambientes de teste pode ser reduzido em até 80%;
  • O custo atrelado a testes envolvendo tecnologias de terceiros e taxas de serviço podem ser diminuídos  ou eliminados.
• Redução do Ciclo de Desenvolvimento do Software:
  • Ambientes de teste podem ser configurados em minutos versus semanas;
  • Os analistas de testes podem focar sua atuação nos testes, ao invés de usarem seu tempo na configuração dos ambientes de teste;
  • Mais testes de regressão podem ser feitos durante o desenvolvimento, ou seja, haverá maior garantia que não surgirão novos defeitos em componentes já testados.
• Aumento da Qualidade do Software:
  • Os desenvolvedores possuem recursos para testar o software durante o desenvolvimento, ainda na camada API (Application Programming Interface).
  • Grandes equipes que trabalham em diferentes partes de um aplicativo podem efetivamente fazer desenvolvimento paralelo por meio da virtualização de diferentes partes do sistema, promovendo a colaboração.

Acompanhe os próximos artigos e saiba mais sobre a solução Green Hat, pois falaremos sobre casos reais e como empresas nos Estados Unidos, Europa e Austrália estão se beneficiando destas soluções.

Para mais informações, contate arodacki@br.ibm.com

Desde sempre, o hardware sempre foi o alicerce para criação e utilização do Sistema Operacional (seja ele UNIX ou outros mais). Em meados dos anos 80/90 com a criação do HPUX, AIX essa mesma visão se tornou ainda mais evidente, afinal só se conseguia utilizar um destes SO´s com a aquisição de hardware especifico.

Imaginem só, em 2004 uma máquina SUN tinha um custo aproximado de 250 mil dólares, necessitava de uma equipe  altamente especializada, ou seja, o custo era somatizado entre hardware, sistema operacional e a uma time de analistas para gerenciá-la, e por causa de um ambiente estável, nosso custo quase que triplicava (eramos obrigados á engolir a solução indicada pela empresas de hardware e software, e que neste caso eram a mesma).

Já no ano 2007 com a entrada do LINUX no ambiente de  produção das grandes comparações, este fato começou a se inverter, gerando assim o “EFEITO LINUX”.

Mas afinal, o que é o efeito LINUX?

Com o LINUX entrando para brigar diretamente com esses Sistemas Operacionais e a famosa Lei de Moore (que dobra-se a capacidade do sistema computacional á cada 2 anos), começamos a notar  que o mundo INTEL tem se mostrado superior até mesmo á maquinas RISC.

Junta-se portanto a capacidade do LINUX e máquinas INTEL para criar uma nova revolução no modelo de negócios destas grandes empresas (como é o caso de IBM, HP e SUN), e seus SO´s (AIX,HPUX e SOLARIS respectivamente).

Vamos á um exemplo:

Hoje temos máquinas INTEL com 32 processadores e 512 Gb de RAM ao mesmo custo de máquinas HPUX com capacidade 10x inferior, porém em máquinas INTEL temos a elasticidade sobre o S.O que queremos, além é claro da gerência e performance destes novos equipamentos.

Todos estes efeitos vieram do novo foco dado pelas principais empresas do ramo (HP e DELL), que  que até então criavam máquinas para médias empresas, estão nos últimos 5 anos focadas em grandes empresas, e mais ainda, criando um hardware cada vez mais robusto para aplicações cada vez mais exigentes.

Tenho visto em grandes empresas que a morte do RISC é cada dia mais certa, e automaticamente do UNIX (HPUX, AIX e SOLARIS), afinal o hardware tem se tornado cada dia mais um coadjuvante por conta da equalização das arquiteturas.

Quem imaginaria em meados de 2000/2005 termos uma máquina INTEL que se equiparasse á uma máquina RISC? Quem imaginaria ter um sistema operacional gratuito que tivesse os mesmas funções de estabilidade/escalabilidade e segurança de sistemas operacionais UNIX (AIX, SOLARIS)?

É justamente nestes comparativos de evolução que temos visto a verdadeira faceta do LINUX.

Mas o que nos resta hoje para chegarmos a uma decisão factível de migração total do RISC para INTEL? Acredito que falte apenas que todos refaçam seus cálculos quanto ás migrações dos legados e comecem a viver mais para o LINUX e a arquitetura INTEL.

Pensem no parágrafo abaixo, e tirem suas próprias conclusões.

Se até mesmo á IBM que antigamente vendia HARDWARE e o AIX, e que  nos últimos anos tem sido uma das principais apoiadoras do modelo LINUX e INTEL, o então será da arquitetura RISC?

Alguém ainda duvida desta evolução?

Projetos mirabolantes, soluções incríveis diante das necessidades apresentadas pelos clientes. Isto entra nos ouvidos dos necessitados como música, um alívio. Reuniões, conversas informais e formais internas até decidir investir na contratação da empresa que conseguirá concretizar os sonhos que pareciam impossíveis. Pronto, venda concluída com sucesso. E depois? É só entregar para a área de operações dá o jeito dela, para tudo acontecer. Surge a briga entre a área comercial e a área de operações. Aquele velho discurso, se o Comercial não vender nós fechamos e a Operação sempre consegue fazer acontecer.

Bem, para bem de todas essas empresas estão indo para o “ralo”, fechando. Antigamente somente as indústrias ou empresas que vendiam produtos tangíveis, possuíam uma área de Pós-venda, onde a maior preocupação é fidelizar o cliente. Bem as empresas de serviços estão acordando, ainda que de maneira bem acanhada, para esta realidade: de acompanhar todo o processo de implementação, on-going (dia-a-dia) e melhorias. Buscando a venda na base, isto é, vender mais serviços o que não deixa de ser uma espécie de fidelização. Os nomes mudam em algumas empresas, tais como gerencia de serviço, executivo de serviço enfim o nome pode ser outro, mas o objetivo sempre será o mesmo.

Mostrar resultados sempre foi a direção do mercado. Saiu em uma revista de grande circulação, que até nosso “gênio” de negócios, Eike Batista, terá de mostrar aos investidores que aporte feito em seus projetos valeu a pena. Ninguém escapa desta lei mercadológica. Parece até óbvio isso tudo, mas você que não é novo nesta “praia”, acredite ainda hoje há empresas e profissionais que a negligenciam. Neste caso o final deles é sempre o mesmo: morrem aos poucos.

Já falei isso em um dos meus artigos, mas creio que é bom repetir para se tornar uma boa prática: quando contratamos algum tipo de serviço temos que saber onde estamos e onde queremos chegar para então tração nosso planejamento estratégico.

Muitas empresas após a contratação de prestadores de serviço dizem que não estão gostando do que está sendo feito, mas quando se faz uma análise mais profunda, verifica-se que não forem criados indicadores de desempenho para avaliar a contratada. Existe uma ideia errônea que apenas o estabelecimento e cumprimento de SLAs são suficientes para comprovar a eficiência de uma empresa de prestação de serviços.

E você que está lendo, já contratou um empresa de prestação de serviços sem definir aonde quer chegar e ainda nem sequer saber onde está? Se você é empregado, já viu este cenário alguma vez? Se não viu, sorte a sua!

As principais soluções de firmas e poderes disponíveis no mercado possuem funcionalidades que nos permitem administrar o ciclo de vida de documentos que outorgam ou não poderes (pasta do cliente), assim como as imagens das assinaturas (firmas) e documentos, além de informações cadastrais estruturadas dos representantes e das pessoas, físicas ou jurídicas, que estes representam. Afora o aspecto de controle de poderes, que é a parte mais complexa, as soluções de firmas e poderes muito se assemelham aos tradicionais sistemas de gerenciamento eletrônico de documentos (GED), seja pelo aspecto de manipulação de imagens, seja pelos mecanismos de indexação destas informações.

Podemos dizer com tranqüilidade que as transformações esperadas nas soluções de Firmas & Poderes estão diretamente relacionadas às tendências irreversíveis de desmaterialização dos documentos físicos.

Nos dias de hoje, embora a quase totalidade dos documentos seja criado eletronicamente, estes ainda são impressos (transformados em documentos físicos) para que possam ser assinados e posteriormente retransformados (digitalizados) em documentos eletrônicos para que possam então ser mais facilmente controlados e compartilhados.

Através das tecnologias de certificação e assinatura digital as assinaturas físicas (de próprio punho) tendem a ser substituídas por assinaturas digitais que, assim como as físicas, estarão vinculadas ao documento, agora eletrônico.

Com os processos de geração, assinatura e administração realizados de forma totalmente eletrônica, isto abre uma série de outras oportunidades de otimização de processos e redução de custos através de novos aplicativos 100% web, tais como a descentralização de processos de captura e análise de documentos. Observe que primeira mudança diz respeito ao tipo de documento que será administrado pelos sistemas. As soluções de Firmas e Poderes passarão a administrar documentos eletrônicos originais, gerados a partir de qualquer software e em qualquer formato, devendo ainda ter a capacidade de verificar a autenticidade e integridade dos documentos eletrônicos assinados digitalmente, identificando e controlando de forma objetiva a validade, seus representantes e poderes.

Um exemplo desta tendência é a Procuração Eletrônica, solução inovadora que foi formalmente apresentada pela QualiSoft ao mercado financeiro mundial no CIAB FEBRABAN (Congresso Internacional de Automação Bancária – São Paulo – Brasil) em Junho de 2005.

De uma maneira simplista, podemos dizer que uma Procuração Eletrônica nada mais é que um documento eletrônico assinado digitalmente por um Certificado Digital válido. Porém, dentro da concepção e modelo introduzidos pela QualiSoft, a Procuração Eletrônica é uma solução de software que foi concebida para possibilitar a criação, assinatura, armazenamento, administração e consultas de Procurações Eletrônicas confiáveis, de maneira eficiente, rápida e segura, através da utilização de tecnologias de assinatura digital. Como elemento absolutamente inovador, a Procuração Eletrônica permite a criação e consulta de procurações de forma totalmente orientada e eletrônica, aproveitando-se das vantagens da certificação digital e das garantias legais existentes, agilizando o processo de formalização das transações eletrônicas e minimizando a necessidade de intervenção humana.

Observe que a Procuração Eletrônica é apenas um exemplo da evolução e tendência esperada para sistemas de Firmas & Poderes. O que se espera na realidade é que estas soluções, atuais e futuras, permitam otimizar processos e reduzir custos através da integração e compartilhamento de informações com canais eletrônicos, sistemas legados, contratos eletrônicos, repositórios seguros de documentos eletrônicos. A evolução será gradativa e os sistemas deverão ser capazes de conviver com modelo atual, representado pelos documentos físicos e assinaturas de próprio punho, suportando também o modelo futuro, representados pelos documentos eletrônicos e assinatura digital. Isto já é uma realidade. O Portal Nacional do Documento Eletrônico (www.documentoeletronico.com.br) provê, dentro de um mesmo ambiente integrado, as soluções de Firmas & Poderes, Procuração Eletrônica, Contratos Eletrônicos, além do Repositório Seguro de Documentos Eletrônicos (Arquivo Digital).