terça-feira, 16 de outubro de 2012

Registros Eletrônicos, Sistemas de Faturamento - Como fazer o melhor de uma conversão de dados


Se você está planejando implementar um novo recorde eletrônico ou sistema de faturamento agora ou em algum momento no futuro próximo, você pode estar preocupado ou interessado em mover dados de seu sistema (legado) atual para o novo sistema. O objetivo deste artigo é compartilhar algumas das coisas que aprendemos que podem ajudá-lo a evitar as armadilhas que são comuns a conversões de dados. A maioria dos problemas de conversão de dados relacionados podem ser evitadas com conhecimento, planejamento de pré-conversão. Há também algumas questões, que se respondidas no início do processo, será uma grande ajuda para o projecto global para implementar o novo software.

Conversões de dados de criar problemas apenas pela sua natureza de mover os itens de dados em um formato para um banco de dados que usa um formato diferente. Pensar em tomar o motor de um Buick e instalá-lo em um Oldsmobile. Isso pode ser feito, mas mesmo que os carros são bastante semelhantes em design e são utilizados para as mesmas funções, isso está longe de um projeto simples e algumas coisas que simplesmente não vai "converter" também.

Vamos discutir apenas alguns dos problemas potenciais.

Primeiro, migração de dados, ou o movimento de dados de um sistema para outro, seja em uma conversão de dados de uma só vez ou de uma interface de banco de dados em curso, deve começar com um plano para manter a integridade dos dados. O novo sistema provavelmente tem melhores regras de integridade de dados construída para ele do que o sistema legado que você tem usado por anos. Isso vai levar a alguns problemas de conversão, como duplicar os números de Seguro Social (SSN) que são permitidos no sistema antigo, mas não o novo. Um novo sistema só é tão bom quanto os dados que são movidos em seus arquivos. Se os dados do sistema legado tem erros ou é menos do que precisa (baseado no controle ou editar os recursos do novo sistema, como não permitir duplicar os números de Segurança Social), os dados não vai ficar melhor quando é movido para o novo sistema. Ele pode, de fato, piorar. Freqüentemente, vendedores que vendem e instalar software não sei as perguntas certas para perguntar que irá ajudar seus clientes a identificar e resolver problemas de integridade de dados em seu sistema legado. Portanto, cabe ao comprador a entender e desenvolver um plano para resolver problemas de integridade de dados antes da conversão começa.

Uma solução é fazer as correções no sistema antigo e trazer todos os dados em um nível consistente de integridade e exatidão, começando assim com o melhor conjunto possível de itens de dados. Isso significa que todos os problemas de fixação de dados conhecidos que existem no sistema legado. Um desafio com esta abordagem é a identificação dos problemas de dados. Isso geralmente ocorre quando alguém no escritório desenvolveu uma maneira de contornar seus problemas em vez de resolvê-los, para que eles não serão necessariamente pensar neles como problemas. No entanto, o novo sistema não terá a mesma facilidade para lidar com um "contornar" como o sistema antigo. Um exemplo é o SSN faltando a ser discutido brevemente.

Outro exemplo é uma situação em que os registos eliminados não são efectivamente removidos do banco de dados. Nós recentemente converteu um sistema de faturamento que era suposto ter 6.000 registros de clientes. Quando informou à agência utilitário que o arquivo de conversão realmente tinha 23.000 registros de clientes, foi uma verdadeira surpresa. Após uma breve discussão perceberam que o banco de dados nunca tinham sido expurgados de registros de clientes antigos. Nós encorajou-os a remover os registros de clientes antigos e registros de história relacionados com base em uma data de sua escolha. O custo de purga foi mínima. O resultado final foi um banco de dados convertido com 12.000 registros de clientes em vez de 6000. Isso deu a organização de um arquivo convertido excelente para começar a usar o novo sistema. O arquivo incluído informações sobre clientes que, sem saber, teria perdido se tivéssemos convertido apenas os 6.000 "ativos" contas.

Outros problemas ocorrem quando o usuário deixa de comunicar as informações necessárias à equipe de conversão. Frequentemente isso acontece porque a informação que é óbvio para o usuário e, portanto, um dado adquirido, não é óbvio para um estranho. Um exemplo pode ser um dos seguintes: não há o nome da cidade entrou porque todas as entradas do banco de dados estão na mesma cidade. Outro exemplo é a substituição de 999-99-9999 para um número de segurança social quando o SSN real é desconhecida.

A solução é o planejamento avançado.

Como Stephen R. Covey ensina, é importante "começar com o fim em mente". Para uma conversão de dados, isso significa identificar o que você espera da conversão e para documentar como você vai saber suas expectativas foram atendidas.

Equilibrar as operações financeiras no novo sistema contra o sistema antigo é um passo óbvio e importante, mas muitas vezes não é bem planejado. Não são muitas vezes equilibrar as diferenças como um resultado da conversão (lembre-se o motor Buick indo para o Oldsmobile) por isso é preciso identificá-los e decidir como será resolvido. Por exemplo, um sistema que não contém transações sanções final no arquivo de história, mas não incluem as taxas dos saldos de contas individuais, cria um pesadelo de equilíbrio para a equipe desavisados ​​conversão de dados. Uma solução é decidir de antemão que todas as multas atrasados ​​do sistema antigo será aglomeradas em uma transação de reconciliação por cliente. O processo é determinar o que essa quantia será para cada cliente e um total de todas as contas. Em seguida, determinar e documentar o erro resultante no arquivo de história e como ele será tratado. Quando chega a hora de equilibrar a conversão, esta informação irá salvar suas horas de conversão da equipe de trabalho desnecessário e aumentar drasticamente a confiança na precisão da conversão.

Algumas perguntas que você pode obter respostas para, em preparação para a sua queda conversão em uma das duas categorias, técnico e de dados.

Questões técnicas:
Quais são as especificações do sistema de legado, incluindo o número da versão e data?
O que é o motor de banco de dados?
Pode ser produzido um relatório com dados relevantes e salvos em um arquivo, em vez de papel?
É o fornecedor legado disponível para ajudar com o extrato de dados?
Há vários arquivos de origem e / ou bancos de dados?

Perguntas de dados:
Quantos registros primários estão no sistema legado? Há muitos arquivos e registros de muitos em cada arquivo. Procuramos um tipo de registro comum, como "cliente". O número de registos de clientes fornece um tamanho relativo da conversão, porque o número de registos na maioria, se não todos, os outros tipos de registo estão correlacionados com os registos do cliente.
Há itens de dados que você não quer convertido?
Existem registros que você não deseja converter?
Você tem um relatório estatístico para uso na validação da conversão? Estatísticas poderia incluir contagens de registros por tipo de registro de informações sobre o equilíbrio, financeiros e outros de sua escolha.
O que é a linha do tempo previsto para ir ao vivo?
Quanto tempo você pode manter registros em papel de dados que devem ser inseridos no sistema de registro, enquanto a conversão de dados final está sendo concluída e validada?

Estes representam uma amostra das perguntas cujas respostas vão fornecer boas informações para definir o cenário para uma conversão bem-sucedida.

Outras questões e exemplos poderiam ser citados, mas o ponto é claro. Planejamento e coleta de informações irá percorrer um longo caminho na preparação para uma conversão que vai suave e demorar menos tempo.

Para aqueles que estão preocupados em levar um tempo extra para este trabalho de planejamento e preparação, deixe-me feito pesquisa de referência sobre este assunto há algum tempo. Este estudo analisou o custo de uma mudança na concepção de um sistema de computador antes ou depois do trabalho de programação actual tinha começado. Os resultados do estudo demonstrou claramente que, quando é feita uma alteração no projeto após foi iniciada a programação, o custo será várias vezes maior que para as alterações que são feitas durante a fase de projeto e antes da programação começar. Da mesma forma, o trabalho de design para conversões vai resolver os problemas em uma fração do custo de encontrar e corrigir problemas durante a conversão.

Planejar, preparar e saber o final antes de começar, definir expectativas e considerar o outsourcing de seu projeto de conversão de dados.

KW Norris...

Nenhum comentário:

Postar um comentário