iDiv

Archive for the ‘Gestão de TI’ Category

Não há nada mais traumatizante do que o processo de portar uma base de dados legada para um novo sistema de gestão na empresa. Principalmente quando o esquema de banco de dados original foi mal formulado.

Desde que começamos o processo de implantação dos módulos do Protheus na Vertical Engenharia, o calcanhar de Aquiles de todo o processo sempre foi utilizar a base de dados legada. Inúmeros problemas com a importação dos dados vieram à tona, desde a necessidade de se higienizar os dados na origem, até a falta de registros importantes em tabelas que deveriam referenciar dados cruzados.

Em minha opinião, a máxima “cada um no seu quadrado” deveria ser seguida ao pé da letra quando o assunto é portabilidade de dados. Em um novo sistema de gestão, é muito melhor começar do zero do que importar dados. Chega-se ao resultado final mais rapidamente e com muito maior consistência.

O que fazer então com os dados legados? Simples: continue a utilizar o sistema antigo como arquivo-morto. Se o problema for o custo de manutenção do sistema, dê preferência a gerir sua base de dados diretamente com as ferramentas de seu SGBD e crie relatórios com ferramentas apropriadas, tal como o Crystal Reports, por exemplo.

Como nem tudo são flores nesta segunda opção, é claro que isso exigirá ter na equipe pelo menos um usuário-desenvolvedor. Ainda assim, considero uma boa estratégia para se conseguir resultados imediatos e satisfatórios, numa excelente relação entre sistema legado versus novo sistema.

———————-

In English

There is not anything more traumatic than the process of carrying a legacy database for a new administration system in the company. Mainly when the original database schema was badly formulated.

Since we began the process of implantation of the modules of Protheus ERP in the Vertical Engineering, the Achilles‘ heel of whole the process always went to use the legacy database. Countless problems with the import of the data came to up, from the need of data cleanning in the origin, until the lack of important registrations in tables that would owe referral cross data.

In my opinion, the popular dictates ” each one in your square ” should be proceeded literally when the subject is data portability. In a new administration system, it is very better to begin of the zero of what to import data. It is arrived more quickly to the final result and with very larger consistence.

What to do then with the legacy data? Simple: continue to use the old system as file-dead. If the problem goes the cost of maintenance of the system, give preference to manage your database directly with the tools of your DBMS and create reports with appropriate tools, like as Crystal Reports, for example.

As nor everything is flowers in this second option, of course that will demand to have in the team a developer user. Nevertheless, I consider a good strategy to get immediate and satisfactory results, in an excellent relationship among system delegated versus new system.

Pessoas estão sujeitas a todos os tipos de imprevistos e intempéries. Podem ficar indisponíveis por motivos tais como doença, acidente, morte, viagem, mudança de moradia ou de emprego. O incrível é que muitas empresas não se dão conta disso e não avaliam corretamente os riscos que representam a disponibilidade das pessoas em seus departamentos de TI.

Recentemente um analista de negócios amigo meu me relatou um caso passado em uma empresa de Maceió durante a implantação de um sistema ERP. Irei resumí-lo para ilustrar o que estou querendo transmitir neste post.

Tal empresa possuía um funcionário na TI, chamado Beto, que simplesmente sabia tudo e resolvia tudo em TI na empesa. A todo tempo a diretoria da empresa respondia à consultoria com ”Beto sabe disso”, “Beto resolve isso”, “fale com Beto” e coisas do gênero. Enxergando o risco de ter toda a TI concentrada no Beto, o consultor questionou à diretoria: “e se o Beto morrer?”

Embora possa ter sido infeliz o questionamento, por ter usado a macabra palavra morte, soando um pouco agourento, o consultor estava correto. Não se podia conceber a idéia da ausência de Beto durante o processo de implantação do ERP, por qualquer motivo que fosse, diante da fragilidade que era ninguém mais saber o que estava por detrás da TI da empresa.

O assunto não passaria de uma mera discussão estratégica se não fosse pelo lamentável fato de que, uma semana depois, Beto viria a falecer. Dá para imaginar o caos resultante na TI dessa empresa!

Por mais cômodo que pareça ser alguém concentrar todas as operações de TI numa empresa, achando que com isso se garante o emprego do profissional e o baixo investimento de recursos por parte da empresa, uma série de contras pode ser alistada para ambos os lados na relação de trabalho. O profissional não pode:

• tirar férias – seu rendimento pode diminuir com o desgaste;
• viajar a treinamento – seus conhecimentos podem ficar obsoletos mais facilmente;
• adoecer, acidentar-se e, principalmente, morrer – a TI corre o risco de parar;
• cogitar aceitar uma proposta de outra empresa – a gratidão, se é que existe, não permite deixar a empresa na mão deliberadamente! (sei que fui um pouco utópico aqui e deixo margem a várias interpretações).

Está mais do que na hora das empresas adquiriem a consciência de que existem riscos inerentes ao negócio TI e que estes são mais acentuados no aspecto humano. Processos de gestão de TI devem estar amplamente documentados e equipes de trabalho devem ser formadas e treinadas sob esses processos. As peças humanas pode ser manejadas com certo gráu de conforto para a empresa, sem os riscos de verem tudo parar. Por sua vez, os profissionais trabalharão melhor num time, cada qual com suas atribuições, sem se sentirem sobrecarregados como se fossem o slogan de certa marca de palha de aço: “com mil e uma utilidades”.

Enfim, TI é isso: riscos e oportunidades. Gerenciá-la de forma correta favorece estas ao tempo em que minimiza aqueles.