Sabedoria da estratégia de conversão de dados

estratégia de conversão de dados
Conversão de dados no projeto SAP & # 8211; conversão do sistema herdado para SAP ECC.
Gostaria de compartilhar minha experiência no processo de conversão de dados com a comunidade SAP. A conversão de dados é um dos processos mais críticos em projetos de implementação de SAP bem-sucedidos. Este processo é uma parte da etapa de realização no & # 8220; ASAP & # 8221; metodologia (etapa 1: preparação do projeto, etapa 2: plano. etapa 3: realização. Etapa 4: preparação final. Etapa 5: ir ao vivo). Os consultores SAP e implementadores locais geralmente são responsáveis ​​por realizar a conversão de dados do sistema herdado para o SAP ECC. Também ouvi falar de projetos SAP em que a equipe Basis realizou esse processo.
Os dados convertidos são usados ​​apenas para configurar dados mestre no ECC. não é usado para configurar os dados transacionais históricos do sistema herdado.
Existem diferentes ferramentas que convertem dados: 1. SAP ECC construído na ferramenta via código de transação LSMW. 2. Ferramenta externa chamada Corredor de processo que se comunica facilmente com o ECC. Eu usei o Runner Process que foi comprado pela minha empresa.
Duas das qualidades mais importantes que são necessárias para ter sucesso nesse processo são: 1. Absorção 2. Comunicando & amp; entendendo as necessidades do seu Cliente.
Como mencionado acima, o processo de conversão de dados faz parte do passo de realização. O passo de realização começa depois que os conselheiros (ou implementadores locais) terminaram de escrever e enviando os documentos do modelo para a aprovação do cliente. Após a aprovação, os implementadores começam a personalizar e anotar documentos de especificação para novos desenvolvimentos na área de Desenvolvimento na ECC. Só então, é possível iniciar o processo de conversão de dados.
Existem sub passos nas conversões de dados:
1. Mapeando os campos necessários no objeto ECC que será preenchido com dados (I. E: objeto do equipamento no módulo PM)
Aqui você precisa estar bem ciente do que está escrito nos documentos do modelo em relação aos seus objetos SAP.
É recomendável diferenciar entre campos obrigatórios de valor deste objeto e valor de campos não obrigatórios. Algumas vezes a classificação do objeto é necessária. Isso acontece quando os campos regulares do objeto não são suficientes para armazenar dados inteiros do sistema antigo. Eu usei classificação em equipamento objeto que representava geradores elétricos.
O objetivo deste passo é verificar se o implementador é capaz de criar dados mestre manualmente antes de realizar a gravação.
3. Gravando dados mestre configurados através do Process Runner (ou LSMW).
Caso a gravação não seja precisa, ou as mudanças na configuração dos dados mestre devem ser feitas após a gravação, a gravação deve começar tudo de novo. Assim, é importante para você ter certeza de como configurar os dados mestre dos objetos corretamente. No caso de a gravação ser precisa e você salvou, o Runner de processo cria um arquivo EXCEL com as colunas apropriadas a serem preenchidas (de acordo com os campos que você inseriu na gravação) para configurar várias instâncias automaticamente.
Por exemplo: Você gravou a configuração de dados mestre de uma peça de equipamento com determinados dados. Depois de salvar a gravação, o corretor de processo criará a estrutura adequada em EXCEL para futuras gravações. Então, você poderá preencher as colunas corretas do arquivo EXCEL com tantas peças de dados do equipamento, conforme necessário, e executar a gravação novamente quando desejar configurar essas peças. Desta forma, múltiplos equipamentos serão criados através do Process Runner.
4. Criando programa de extração para extrair dados do sistema antigo.
Nesta etapa você precisa especificar para o administrador do sistema legado (ele geralmente é um programador MF) de maneira precisa quais os campos e quais tabelas você precisa dos dados. A segunda coisa que você precisa considerar: qual é a população de dados a ser extraída (I. E: somente peças / equipamentos ativos que foram criados após determinada data. Seu cliente saberá as respostas para esta questão). O administrador do sistema deve então preparar o programa no sistema herdado para uso futuro. No meu projeto, o sistema legado era o sistema MF que estava escrito em ADABAS NATURAL. Enviei documentos de especificação ao administrador especificando campos para extrair e qual a população de dados a extrair.
Se houver necessidade de fazer algum tipo de manipulação de dados (IE: 1. O tipo de equipamento no legado contém valores: A, B, C, enquanto o tipo de equipamento ECC foi personalizado para conter valores AA, BB, CC, respectivamente 2. alteração do formato dos valores da data etc.), o administrador deve codificá-lo no programa.
É muito aconselhável que este programa classifique as colunas de saída de forma idêntica à ordem das colunas no arquivo EXCEL da etapa anterior. O administrador deve classificar as colunas da maneira correta. Eventualmente, o programa de extração cria o arquivo EXCEL cheio de dados de extração que se encaixa na estrutura de arquivos EXCEL e no formato da etapa anterior.
5. Analisando arquivos de log de erros e fixando o programa de extração.
Nesta etapa, o arquivo EXCEL está cheio de dados a serem carregados no SAP ECC. tente carregar 50% de todas as linhas no arquivo. Runner de processo criará resultados de saída. Se houver algum erro enquanto o programa está tentando criar dados mestres, ele indicará os motivos para isso. Você deve analisar e corrigir o programa, respectivamente.
6. Preparando o programa de eliminação e arquivamento no SAP ECC.
Eventualmente, há uma chance de você precisar excluir qualquer um dos dados que foram carregados por qualquer motivo. Então, primeiro, você precisará distinguir os dados que foram convertidos e carregados na área SAP ECC de outros dados criados manualmente pelos usuários. A melhor maneira de fazê-lo é usar o relatório padrão SAP e especificar na tela de seleção do relatório o usuário SAP que criou os dados. Por exemplo, no meu projeto, um determinado programador estava usando o Runner de processo para carregar os dados. Todos os dados que ele carregou foram criados sob seu código de usuário. Assim, foi fácil distinguir os dados. Depois que o relatório extraiu esses dados, marque o que é necessário para a exclusão e use o código SARA para arquivar os dados (publicarei um guia específico separado para arquivar dados em SAP usando o tato SARA).
Espero que esta informação o ajude a trabalhar com o SAP. Para qualquer dúvida sobre este processo preencha-me para me perguntar.
4 Comentários.
Você deve estar conectado para comentar ou responder a uma postagem.
Nunca compartilhe suas informações pessoais no fórum público. Se você quiser compartilhar suas informações pessoais, fique visível em seu perfil e diga ao outro usuário que leve as informações do seu perfil.
Nunca publique essas informações em discussão / blog / documento.
Daniel Gontar Post author 16 de agosto de 2017 às 13h40.
Cheguei a bordo de um projeto bastante ad-hoc durante uma fase de conversão e devo dizer que esta publicação no blog foi uma introdução muito boa às conversões.

estratégia de conversão de dados
Este documento fornece um procedimento para ajudá-lo a organizar e executar a transferência de dados do sistema herdado.
Ele descreve uma metodologia para migração de dados que usei com sucesso em diferentes implementações. Baseia-se nas minhas experiências anteriores. Não há garantia sobre o conteúdo ou sobre os resultados. Este guia oferece sugestões. Cabe a você seguir as dicas e criar sua própria metodologia.
Terminologia comum e abreviaturas em projetos de migração:
Nota: Os termos SAP e R / 3 são ambos utilizados de forma intercambiável para se referir ao sistema SAP R / 3.
Big Five: quando se refere aos Big Five, significa Mestre de Materiais, Mestre de Clientes, Mestre de Fornecedores, Lista de Materiais (BOM) e Roteiros.
Objetos comerciais: para ajudar no processo de análise e transferência, os dados não são tratados como tabelas ou conteúdo de campo, mas sim como objetos em termos de negócios operacionais. Estes são chamados Business Objects.
Business Object DC responsável: responsável pelo processo de conversão (fonte de dados legados e integridade, mapeamento, regras de conversão, etc.) e pelo respeito da programação planejada para o objeto comercial.
Proprietário do objeto de negócios: aquele que possui a informação no negócio do cotidiano. Esta é a pessoa que irá fazer as escolhas estratégicas sobre requisitos funcionais para o objeto de negócios e que fará a validação final dos dados convertidos. Pode ser identificado ao encontrar a pessoa hierárquica mais alta que será diretamente e principalmente afetada se o objeto de negócios não funcionar & rdquo;
Conversão de dados e amp; Migração de dados: o processo de conversão de dados. & # 8220; Conversão de dados & rdquo; e & # 8220; Data Migration & rdquo; Os termos são usados ​​indistintamente no documento.
DC: Abreviação do processo de conversão de dados.
Domínio: domínio funcional dentro do projeto, como Finanças, Vendas, Produção, etc.
Arquivo plano: um formato de arquivo usado para importar dados para o SAP. O arquivo plano é um arquivo de texto simples com um separador de separadores entre campos. Pode ser facilmente gerado a partir do Excel ou Acesso.
Arquivo intermediário: um Excel, acesso ou outro tipo de arquivo, que é manipulado manualmente em um processo entre a extração LS e a geração de arquivos planos.
LSMW: Legacy System Migration Workbench. É uma ferramenta SAP para conversão que permite o carregamento de dados usando arquivos planos extraídos do Sistema Legado.
Tabela de referência cruzada ou tabela X-Ref: uma tabela que mostra a relação entre campos quando um valor está relacionado a um campo pai. Por exemplo, a & # 8220; Organização de vendas & # 8221; será configurado de acordo com o tipo de material.
WBS: estrutura de repartição do trabalho.
Implementar o SAP é um desafio importante, tanto em termos de recursos (pessoas, dinheiro, tempo) como em processos comerciais. Muito está em jogo e, para a maioria de vocês, o fracasso não é uma opção que você pode pagar. Para colocar todas as probabilidades do seu lado, você precisa de uma boa metodologia. Um que irá fornecer-lhe um planejamento realista, uma organização sólida, uma maneira de gerenciar o processo e ferramentas de controle para detectar e corrigir o deslizamento antes que ele se torne um problema.
Antes mesmo de começar a trabalhar em especificações, você deve primeiro se organizar. Obter uma boa estrutura de planejamento e organização leva cerca de duas semanas para o primeiro rascunho, o que o deixará com algumas questões sobre a organização do projeto. Obter um planejamento completo e final levará pelo menos mais uma semana. Qualquer problema não resolvido sobre estes irá assombrá-lo durante todo o projeto, então termine isso completamente antes de indicar qualquer outro passo.
A conversão de dados requer recursos funcionais e técnicos da maioria dos departamentos. Estes mesmos recursos provavelmente estarão envolvidos em outra parte do projeto. Por esta razão, o risco de uma tarefa conflitante é alto e pode levar rapidamente a um gargalo onde os povos-chave estão sobrecarregados. Por esse motivo, você deve considerar a conversão de dados como um projeto dentro do projeto. Isso se traduz na preparação de um plano de conversão completo que o ajudará a passar pelo processo e permitirá prever e resolver o uso de recursos em conflito antes do gargalo que já ocorreu.
Os principais passos da conversão de dados são:
Organização da conversão de dados (Gerente de projeto e coordenador de conversão de dados)
Plano de conversão de dados O WBS com estimativa de carga de trabalho O planejamento do calendário com o carregamento de recursos.
Iniciando com a conversão de dados do Business Objects (O recurso responsável pelo Business Object DC)
Data Purging and Cleansing Mapeamento e regras de conversão Extrair e carregar programas de regras Adaptação de dados e regras (regras de ajuste e programas após o teste) Teste de unidade de carga (teste unitário e pequeno volume de dados manuais) Extração e carga Testes de tamanho completo (dados teste e validação / grande volume com dados extraídos de verdade) carregamento de dados completos no sistema de aceitação carregamento completo de dados no sistema de produção prévia Validação de dados convertidos e Key User + Business Objects Inscrição do proprietário Conversão completa em SYSTEME DE PRODUÇÃO e sinalização final.
Plano de conversão de dados.
Objetos empresariais.
Um objeto de negócios é uma categoria geral para dados que define algo como mestre de material, mestre de fornecedores, ações, pedidos, requisições de compra ou unidades organizacionais. O primeiro passo é identificar quais objetos comerciais (Objetos) são necessários na sua implementação SAP.
Existem três tipos de dados envolvidos em um sistema SAP: dados mestre, dados transacionais e dados históricos.
Dados mestre. Os dados mestre de aplicativos tendem a ser mais estáticos, uma vez definidos. A maioria dos dados mestre pode ser conduzida pelas aplicações legadas. Os exemplos incluem fornecedores, clientes, gráficos de contas, ativos, contas de materiais, mestres de materiais, registros de informações, e assim por diante. Dados Transacionais. Os dados transacionais são dados de transações atuais e pendentes que precisam ser capturados pelo sistema antigo e definidos para os aplicativos SAP R / 3 para a conclusão do processo comercial. Exemplos incluem documentos contábeis, ordens de compra abertas, ordens de vendas abertas, pedidos atrasados ​​e assim por diante. Data histórica. Os dados históricos precisam ser transferidos do sistema herdado para o sistema SAP R / 3 para fins de referência. Os exemplos incluem pedidos de compra fechados, ordens de vendas fechadas, informações gerais do resumo, e assim por diante.
Informações para completar o plano de conversão.
O que objetos de negócios serão convertidos do sistema herdado para o SAP. Onde onde estão os dados, quais sistemas Legacy estão envolvidos para a extração. Quanto estimar o número de registros a serem carregados no SAP. Como há dois aspectos a serem considerados: a forma como os dados são extraídos do Sistema Legado Extraído automaticamente do sistema Legacy sem intervenção manual. Folha de cálculo preenchida manualmente Combinação de uma extração automática do sistema Legacy + Entrada manual em uma planilha A forma como os dados são injetados no SAP: Transferência automática de dados a partir de um arquivo plano para o SAP Inserção manual de dados com transações online para SAP Combinação de ambos.
O método de transferência de dados que você escolherá determinará os tipos de recursos que você precisa. Por exemplo, você pode precisar de funcionários temporários para a entrada manual de dados e programadores para escrever seus próprios programas de extração. Você precisa saber quais são os dados no seu sistema legado e quais aplicativos SAP correspondem aos objetos de negócios que serão transferidos. Uma pessoa não precisa saber tudo isso, mas as pessoas que conhecem essa informação devem trabalhar em estreita colaboração.
Quem é envolvido em cada Objeto de Negócios: Usuário-chave (responsável funcional da conversão BO: Regras, correções de dados manuais, teste, validações) Consultor Responsável pela limpeza e purga de dados no Sistema Legado Responsável pela extração Responsável pelo carregamento de dados no SAP Business Gerenciador de objetos (proprietário hierárquico responsável pelo uso do dia-a-dia e integridade da informação e aquele que será assinado para aceitação de dados)
Main Business Objects seqüência de conversão:
CONVERSANDO UM OBJETO DE NEGÓCIO:
Data Purging and Cleansing.
A purga e limpeza do sistema Legacy irá poupar muito tempo e esforço nas seguintes etapas da conversão. Comece assim o mais rápido possível e faça o máximo possível. Isso pode ser feito sem conhecimento específico do SAP.
Antes de transferir dados do seu sistema antigo, exclua todos os dados antigos e obsoletos. Por exemplo, você pode excluir todos os clientes únicos ou aqueles para os quais não houve transação nos últimos dois anos, também excluir materiais não utilizados.
Este processo corrige inconsistências de dados e garante a integridade dos dados existentes durante o processo de migração. Por exemplo, muitas vezes há muitas inconsistências nos campos de endereços do cliente e do fornecedor. Você encontrará rapidamente que o SAP não permitirá que você carregue nenhum campo de endereço, a menos que você os limpe.
Regras de mapeamento e conversão.
A documentação de cada objeto comercial conterá as regras (ou especificações) de conversão de dados, que incluem:
* Fontes legadas e procedimentos de extração.
De qual sistema (s) Legacy estamos extraindo os dados e como. Documente aqui as etapas específicas que precisam ser tomadas.
Quais são as etapas de limpeza a serem tomadas e os filtros de extração a serem usados.
Diretrizes para aplicar ou regras que são usadas por muitos campos (evitando assim reescrevê-lo e tornar a atualização mais fácil, pois é apenas em um só lugar).
Quais campos SAP usar e como podemos obter o valor final para cada campo SAP.
As regras gerais são aquelas que não se destinam diretamente a um valor de campo. Por exemplo, a forma como diferenciamos os tipos de material no Sistema Legado é uma regra. As regras de campo são aquelas que dão um valor para um campo específico.
Isso é crucial. Ao discutir ou escrever notas, SEMPRE se referir a um campo no formato TABLE-FIELD. Você perceberá rapidamente que, à medida que o projeto vai, diferentes pessoas começarão a usar nomes diferentes para o mesmo campo. Além disso, eles podem começar a usar o mesmo nome para diferentes campos.
Além disso, alguns campos existem em diferentes visualizações nos dados mestre SAP. Algum tempo é o mesmo campo que é mostrado em dois lugares, enquanto outras vezes são realmente dois campos diferentes. A melhor maneira de saber que caso se aplica é ter a informação TABLE + FIELD.
Em Material Master, o campo & # 171; Verificação de disponibilidade & raquo; existe no & # 8220; MRP2 & # 8221; e o & # 8220; Sales Gen & # 8221; pontos de vista. Se você olhar para a TABELA-CAMPO de cada visualização, você obtém:
Sales Gen: MARC-MTVFP.
Em ambos os casos, o nome do TABLE-FIELD é o mesmo, então é o mesmo campo.
Em Customer Master, o campo & # 8221; Termos de pagamento e # 8217; existe em & # 8220; Transações de pagamento & # 8221; e & # 8220; Faturamento & # 8221; pontos de vista. Se você olhar para a TABELA-CAMPO de cada visualização, você obtém:
Transações de pagamento: KNVV-ZTERM.
Exibições de faturamento: KNB1- ZTERM.
Não é o mesmo campo. Na visualização de pagamento, o campo está vinculado ao Código da Empresa, enquanto que para a visualização de Faturamento está vinculado à Organização de Vendas (você encontra isso observando as teclas de tabelas). Portanto, esses dois campos podem ter valores diferentes.
Metodologia Técnica.
Um caso especial para Material Master.
O Mestre de Materiais envolve todos os domínios e pode exigir em qualquer lugar de 20 campos para algumas centenas dependendo da complexidade de sua implementação. Alguns campos serão usados ​​por diferentes domínios, enquanto outros serão usados ​​por um único domínio, mas seu valor terá um impacto na funcionalidade usada por outro domínio.
Este é o Objeto de Negócios mais complexo para documentar e, ao mesmo tempo, é aquele com o qual você deve começar com o processo de conversão.
1º passo: seleção dos campos por cada domínio.
Obtenha cada domínio com seus consultores para passar pelo arquivo de mapeamento e veja os campos para cada tipo de material. O objetivo aqui é ver todos os campos importantes e fazer perguntas para compreendê-los. Isso é feito separadamente por cada domínio e documentado em diferentes arquivos de mapeamento. Nesses pontos, não nos interessa a respeito de onde os valores virão e como os obteremos. APENAS CONSIGUE O MAPEAMENTO E façam a compreensão do que é o mestre do material. Cada vez que um domínio seleciona um campo para um tipo de material específico, eles devem inserir seu tipo de domínio na lista. Aqui estão alguns exemplos (teóricos) de mapeamento de MM, PP e SD.
No Material Master, alguns campos podem ser inseridos / modificados em diferentes visualizações. Por exemplo, o campo & # 8220; Tempo de processamento de recebimento de mercadorias em dias (MARC-WEBAZ) & rdquo; existe em opiniões Compras, MRP2 e gerenciamento de qualidade. Ao fazer as regras e o programa de carregamento, o mesmo campo pode estar em diferentes visualizações. Para resolver isso, proceda da seguinte forma:
Veja com todos os domínios implicados que são o líder do campo e decida em qual exibição o campo deve ser incluído.
Tomando o exemplo do campo # 8220; Tempo de processamento de recebimento de mercadorias em dias (MARC-WEBAZ) & rdquo ;, pode ser decidido entre os domínios para colocá-lo na visão de Compras (e em nenhum outro lugar).
Conversão mestre de material:
Design de processo de alto nível.
Estas são todas as principais visualizações envolvidas no Material Master Object:
Dados básicos alternativos UOM Inspeção Classificação de texto Organização de vendas Vendas Geral Compra de plantas Comércio externo Importar & amp; Exportar dados mestre APO MRP1 & amp; 2 Contabilidade de gerenciamento de qualidade.
Normalmente, a especificação da função Os proprietários farão o método de gravação para capturar todos os campos nas visualizações acima e preparar a lógica de mapeamento.
O projeto mais complexo envolve a fusão e mesclagem da planta. (Referir documento de processo de alto nível)
Um grupo de membros do grupo de segmento de clientes de tipo é uma coleção de usuários, conforme definido pelo Vendedor ou comerciante, que compartilham um interesse comum.
Por exemplo: Uma empresa de mineração tem CSG & # 8217; s como Cerro Matoso (CMSA), Met Coal (MTCO), Base Metals (BASE) etc.,
Com base nos dados CSG & # 8217; s, os dados precisam ser divididos antes de serem carregados através do LSMW para avaliação.
A lógica de divisão pode ser feita por Loop Component em Business Objects Data Services.
Obtenha os CSG e # 8217; s distintos em um fluxo de dados. Atribua uma variável para o número de sequência para o valor máximo e o loop a partir da inicial.
Outros Negócios Conversão de objetos:
Para os outros BO, porque são mais simples do que o Material Master e envolvem menos pessoas, começaremos diretamente com o documento de regras de conversão. É neste documento que ambos vamos decidir quais os campos que precisamos e, em uma segunda etapa, começar a trabalhar nas regras.
Aqui estão algumas amostras de regras de conversão BO.
Exemplo de regras de conversão da lista técnica.
Abra a amostra de regras de conversão de contas a receber.
Exemplo de regras de conversão do Fornecedor Master.
Observe que o termo SAP & # 8220; depósito de segurança & rdquo; igual & # 8220; Retenção & rdquo; no PRMS.
Tipo de transação.
Campo TYPE no PRMS:
Qualquer outro tipo é um erro.
Validação para aplicar tanto na extração quanto na carga.
Parcial PMT & hellip; & hellip; & hellip ;. deve ser negativo no PRMS, se não ERROR.
Credit Memo & hellip; & hellip; & hellip; deve ser negativo no PRMS, se não ERROR.
Debit Memo & hellip; & hellip; & hellip;. Devem ser positivos no PRMS, se não ERROR.
Qualquer outro tipo é um ERRO.
LSM Load parameters.
KTOPL & # 8211; Gráfico de conta: CA00.
BUKRS & # 8211; Código da empresa: 0070.
GSBER & # 8211; Área de negócios: 0040.
BUDAT & # 8211; Data de lançamento: & # 8220; 05-31-02 & rdquo; ou último dia do último período fechado.
OFFSET & # 8211; Conta (2): REPRODUÍDO.
SKPERR & # 8211; Skip err: X.
W orkbench M igration de L e Igualdade (LSMW):
O LSMW é usado para migrar dados de um sistema herdado para o sistema SAP, ou de um sistema SAP para outro.
Além das entradas e gravações padrão de lote / direto, BAPI e IDocs estão disponíveis como métodos de importação adicionais para processar os dados legados.
O LSMW compreende as seguintes etapas principais:
Leia dados (dados legados em tabelas de planilhas e / ou arquivos seqüenciais). Converta dados (da fonte para o formato de destino). Importar dados (para o banco de dados usado pelo aplicativo R / 3.
Mas, antes destas etapas, você precisa executar as seguintes etapas:
Definir estrutura de origem: estrutura de dados no arquivo de origem. Definir estrutura de destino: estrutura do SAP que recebe dados. Mapeamento de campo: Mapeamento entre a estrutura de origem e destino com as conversões, se houver. Especificar arquivo: local do arquivo de origem.
Métodos utilizados para migração de dados, como BDC, LSMW e Call Transaction.
Todos os 3 métodos são usados ​​para migrar dados. A seleção desses métodos depende do cenário, a quantidade de dados precisa ser transferida. LSMW é uma ferramenta pronta fornecida pela SAP e você deve seguir algumas 17 etapas para migrar dados mestre. Enquanto no método de sessão BDCs é a melhor escolha devido a algumas vantagens sobre a transação de chamada. Mas a transação de chamadas também é muito útil para atualizar imediatamente uma pequena quantidade de dados. (O desenvolvedor de transações de chamadas deve lidar com erros).
SO Bottom line é fazer a escolha desses métodos com base em requisitos de tempo real.
Esses métodos são escolhidos completamente com base na situação em que você está. O método de entrada direta não está disponível para todos os outros cenários, eles são os mais simples. No método de entrada em lote, você precisa fazer a gravação para a transação em questão. Da mesma forma, o IDoc e a BAPI estão lá, e o uso destes deve ser decidido com base no requisito.
Tente passar por algum material sobre esses quatro métodos e implemente-os. Você terá uma idéia justa sobre quando usar o qual.
BDC & # 8211; É a comunicação de dados em lote. É usado para conversão de dados do sistema antigo para o sistema SAP. Somente pessoas técnicas podem fazê-lo. O Tcode é SHDB.
LSMW & # 8211; É o banco de trabalho de migração do sistema legado. Também é usado para conversão de dados do sistema herdado para o sistema SAP. Mas é um papel de consultor funcional.
Existem 14 passos no LSMW. Assim que você completar um passo, automaticamente ele irá para o próximo passo.
Em geral, você pode usar LSMW. Mas se você deseja transferir mais de 40.000 dados, então não é possível no LSMW. Naquele momento você pode ajudar com o BDC.
Migração de dados LSMW para cliente de cliente VA01 / XD01.
8 Comentários.
Você deve estar conectado para comentar ou responder a uma postagem.
A SAP oferece conteúdo gratuito para ajudar a migrar dados em SAP (ERP, CRM, etc.). Veja websmp103.sap-ag. de/rds-dm2erpcrm.
Esta é realmente uma boa explicação para o processo de migração de dados.
Artigo muito informativo (provavelmente o melhor). Continue postando.
Um documento bom, estruturado e bem escrito.
Grande literatura.
Obrigado por compartilhar o conhecimento.
bom artigo Johnpaul!
Wow Johnpaul este é um ótimo artigo! É muito informativo e passa por um monte de requisitos para uma migração bem-sucedida. No Method360, percebemos que muitas pessoas não gastam a quantidade necessária de planejamento de tempo para as migrações e acabam tendo que voltar atrás e gastar muito tempo re-fazer coisas que deveriam ter sido feitas muito mais cedo, especialmente em as etapas de purga e limpeza de dados. Os clientes pensam que, uma vez que são transferidos para o sistema mais novo, tudo será consertado, mas acabará com um sistema lento com muitos erros. Passar o tempo para rever seus dados históricos e mestre que podem ter mudado ou não é mais necessário pode realmente acelerar seus sistemas. Para ajudar os clientes a entender tudo o que precisam para ser bem-sucedidos, criamos uma oficina gratuita. Sinta-se à vontade para dar uma olhada!

JDE - SAP Conversion Strategy.
Interesses relacionados.
Classificação e Estatísticas.
Opções de compartilhamento.
Ações de documentos.
As páginas 2 a 9 não são mostradas nesta pré-visualização.
Documentos recomendados.
Documentos semelhantes à JDE - SAP Conversion Strategy.
Documentos Sobre Débitos e Créditos.
Documentos sobre computação.
Menu de Rodapé.
Legal.
Mídia social.
Direitos autorais e cópia; 2018 Scribd Inc. Procure livros. Site móvel. Diretório do site. Idioma do site:
Você tem certeza?
Esta ação pode não ser possível desfazer. Você tem certeza que quer continuar?
Tem certeza de que deseja excluir esta lista?
Tudo o que você selecionou também será removido de suas listas.
Este livro também será removido de todas as suas listas.
Nós temos títulos com curadoria que achamos que você adorará.
O resto deste título estará disponível em breve.
JDE - Estratégia de conversão SAP estará disponível em.

Lista de verificação do projeto de migração de dados: um modelo para o planejamento efetivo da migração de dados.
Lista de verificação de migração de dados: planejador para migração de dados.
Lista de verificação de migração de dados: o guia definitivo para planejar sua próxima migração de dados.
Começando com uma migração de dados c hecklist para o seu projeto de migração de dados é uma das tarefas mais desafiadoras, particularmente para os não iniciados.
Para ajudar, compilei uma lista de atividades 'must-do' que eu achei essenciais para migrações bem-sucedidas.
Não é uma lista definitiva, você quase certamente precisará adicionar mais pontos, mas é um ótimo ponto de partida.
Por favor, critique isso, estenda-o usando os comentários abaixo, compartilhe-o, mas, acima de tudo, use-o para garantir que você esteja totalmente preparado para a desafiadora estrada à frente.
DICA: a qualidade dos dados desempenha um papel fundamental nesta lista de verificação, por isso certifique-se de verificar o Data Quality Pro, o nosso site da irmã com a maior coleção de tutoriais práticos, guias de qualidade de dados e suporte especializado para qualidade de dados na internet.
Obtenha um kit de lista de verificação gratuito: planilha de planejamento do projeto + MindMap.
Serio sobre a entrega de uma migração de dados bem sucedida?
Baixe o mesmo kit de lista de verificação que uso em compromissos de clientes e aprendo táticas avançadas para planejamento de migração de dados.
Planilha de planejamento de projeto (para Excel / Google Sheets) MindMap online interativo (ótimo para navegação)
Baixe o kit.
Nós nunca enviamos spam ou vendemos seus detalhes.
Fase 1: Planejamento pré-migração.
Você avaliou a viabilidade da sua migração com uma avaliação de impacto pré-migração?
A maioria dos projetos de migração de dados se encaminham para o projeto principal sem considerar se a migração é viável, quanto tempo demorará, qual a tecnologia necessária e quais os perigos futuros.
É aconselhável realizar uma avaliação de impacto pré-migração para verificar o custo e o resultado provável da migração. Quanto mais tarde você planeja fazer isso, maior será o risco para marcar de acordo.
Você baseou as estimativas do projeto em adivinhação ou uma avaliação mais precisa?
Não se preocupe, você não está sozinho, a maioria dos projetos baseia-se em estimativas de projetos anteriores, na melhor das hipóteses, ou otimistas, na melhor das hipóteses.
Mais uma vez, sua avaliação de impacto pré-migração deve fornecer uma análise muito mais precisa dos requisitos de custo e recursos, então, se você tiver prazos apertados, uma migração complexa e recursos limitados, certifique-se de que você realize uma avaliação de impacto de migração o mais cedo possível.
Você fez as empresas e as comunidades de TI conscientes de seu envolvimento?
Faz todo o sentido informar os interessados ​​de dados relevantes e as equipes técnicas dos seus compromissos futuros antes da partida da migração.
Pode ser muito difícil arrastar um especialista em assuntos do seu dia de trabalho para uma sessão de análise de 2-3 horas, uma vez por semana, se seus idosos não estiverem a bordo, além de identificar quais recursos são necessários antecipadamente, você eliminará o risco de ter lacunas no seu legado ou no alvo.
Além disso, existem inúmeros aspectos da migração que exigem assinatura e compromisso empresarial. Obtenha antecipadamente os patrocinadores e as partes interessadas e assegurem que compreendam e concordam com o envolvimento deles.
Você concordou formalmente com as restrições de segurança para o seu projeto?
Eu tenho lembranças maravilhosas de uma migração onde pensamos que tudo estava em vigor, então nós começamos o projeto e logo foi encerrado no primeiro dia.
Assumimos que as medidas de segurança que tínhamos concordado com o gerente de projeto do cliente eram suficientes, no entanto, não consideramos a equipe de segurança corporativa entrar em ação e exigir um conjunto de controles muito mais rigorosos que causaram 8 semanas de atraso no projeto.
Não cometer o mesmo erro, obter um acordo formal das equipes relevantes de governança de segurança com antecedência. Basta colocar sua cabeça na areia e, na esperança de que você não seja pego, não é profissional e altamente arriscado, dada a recente perda de dados em muitas organizações.
Você identificou seus principais recursos de projeto de migração de dados e quando eles são necessários?
Não comece seu projeto na expectativa de que a Jobserve forneça magicamente os recursos que faltava, você precisa.
Conheci uma empresa há vários meses que decidiu que não exigiam um analista de migração de dados, porque o "plano do projeto estava tão bem definido". Basta dizer que agora estão indo para problemas à medida que o projeto gira fora de controle, então certifique-se de entender exatamente quais são as funções necessárias para uma migração de dados.
Certifique-se também de ter um plano para trazer esses papéis no projeto no momento certo.
Por exemplo, há uma tendência para lançar um projeto com um contingente completo de desenvolvedores armados com ferramentas e raring para ir. Isso é caro e desnecessário. Um pequeno grupo de migração de dados, qualidade de dados e analistas de negócios podem realizar a maior parte da descoberta e mapeamento de migração bem antes que os desenvolvedores se envolvam, muitas vezes criando uma migração muito mais bem-sucedida.
Então, a lição é entender as principais atividades e dependências de migração, então planeja ter os recursos adequados disponíveis quando necessário.
Você determinou a estrutura ideal de entrega do projeto?
Data migrations do not suit a waterfall approach yet the vast majority of data migration plans I have witnessed nearly always resemble a classic waterfall design.
Agile, iterative project planning with highly focused delivery drops are far more effective so ensure that your overall plan is flexible enough to cope with the likely change events that will occur.
In addition, does your project plan have sufficient contingency? 84% of migrations fail or experience delay, are you confident that yours won’t suffer the same consequences?
Ensure you have sufficient capacity in your plan to cope with the highly likely occurrence of delay.
Do you have a well defined set of job descriptions so each member will understand their roles?
Project initiation will be coming at you like a freight train soon so ensure that all your resources know what is expected of them.
If you don’t have an accurate set of tasks and responsibilities already defined it means that you don’t know what your team is expected to deliver and in what order. Clearly not an ideal situation.
Map out the sequence of tasks, deliverables and dependencies you expect to be required and then assign roles to each activity. Check your resource list, do you have the right resources to complete those tasks?
This is an area that most projects struggle with so by clearly understanding what your resources need to accomplish will help you be fully prepared for the project initiation phase.
Have you created a structured task workflow so each member will understand what tasks are expected and in which sequence?
This is an extension of the previous point but is extremely important.
Most project plans will have some vague drop dates or timelines indicating when the business or technical teams require a specific release or activity to be completed.
What this will not show you is the precise workflow that will get you to those points. This needs to be ideally defined before project inception so that there is no confusion as you move into the initiation phase.
It will also help you identify gaps in your resourcing model where the necessary skills or budgets are lacking.
Have you created the appropriate training documentation and designed a training plan?
Data migration projects typically require a lot of additional tools and project support platforms to function smoothly.
Ensure that all your training materials and education tools are tested and in place prior to project inception.
Ideally you would want all the resources to be fully trained in advance of the project but if this isn’t possible at least ensure that training and education is factored into the plan.
Do you have a configuration management policy and software in place?
Data migration projects create a lot of resource materials. Profiling results, data quality issues, mapping specifications, interface specifications – the list is endless.
Ensure that you have a well defined and tested configuration management approach in place before project inception, you don’t want to be stumbling through project initiation trying to make things work, test them in advance first and create the necessary training materials.
Have you planned for a secure, collaborative working environment to be in place?
If your project is likely to involve 3rd parties and cross-organisational support it pays to use a dedicated product for managing all the communications, materials, planning and coordination on the project.
It will also make your project run smoother if this is configured and ready prior to project initiation.
Have you created an agreed set of data migration policy documents?
How will project staff be expected to handle data securely? Who will be responsible for signing off data quality rules? What escalation procedures will be in place?
There are a multitude of different policies required for a typical migration to run smoothly, it pays to agree these in advance of the migration so that the project initiation phase runs effortlessly.
Phase 2: Project Initiation.
Have you created a stakeholder communication plan and stakeholder register?
During this phase you need to formalise how each stakeholder will be informed. We may well have created an overall policy beforehand but now we need to instantiate it with each individual stakeholder.
Don’t create an anxiety gap in your project, determine what level of reporting you will deliver for each type of stakeholder and get agreement with them on the format and frequency. Dropping them an email six months into the project that you’re headed for a 8 week delay will not win you any favours.
To communicate with stakeholders obviously assumes you know who they are and how to contact them! Record all the stakeholder types and individuals who will require contact throughout the project.
Have you tweaked and published your project policies?
Now is the time to get your policies completed and circulated across the team and new recruits.
Any policies that define how the business will be involved during the project also need to be circulated and signed off.
Don’t assume that everyone knows what is expected of them so get people used to learning about and signing off project policies early in the lifecycle.
Have you created a high-level first-cut project plan?
If you have followed best-practice and implemented a pre-migration impact assessment you should have a reasonable level of detail for your project plan. If not then simply complete as much as possible with an agreed caveat that the data will drive the project. I would still recommend carrying out a migration impact assessment during the initiation phase irrespective of the analysis activities which will take place in the next phase.
You cannot create accurate timelines for your project plan until you have analysed the data.
For example, simply creating an arbitrary 8 week window for “data cleansing activities” is meaningless if the data is found to be truly abysmal. It is also vital that you understand the dependencies in a data migration project, you can’t code the mappings until you have discovered the relationships and you can’t do that until the analysis and discovery phase has completed.
Also, don’t simply rely on a carbon copy of a previous data migration project plan, your plan will be dictated by the conditions found on the ground and the wider programme commitments that your particular project dictates.
Have you set up your project collaboration platform?
This should ideally have been created before project initiation but if it hasn’t now is the time to get it in place.
There are some great examples of these tools listed over at our sister community site here:
Have you created your standard project documents?
During this phase you must create your typical project documentation such as risk register, issue register, acceptance criteria, project controls, job descriptions, project progress report, change management report, RACI etc.
They do not need to be complete but they do need to be formalised with a process that everyone is aware of.
Have you defined and formalised your 3rd Party supplier agreements and requirements?
Project initiation is a great starting point to determine what additional expertise is required.
Don’t leave assumptions when engaging with external resources, there should be clear instructions on what exactly needs to be delivered, don’t leave this too late.
Have you scheduled your next phase tasks adequately?
At this phase you should be meticulously planning your next phase activities so ensure that the business and IT communities are aware of the workshops they will be involved in.
Have you resolved any security issues and gained approved access to the legacy datasets?
Don’t assume that because your project has been signed off you will automatically be granted access to the data.
Get approvals from security representatives (before this phase if possible) and consult with IT on how you will be able to analyse the legacy and source systems without impacting the business. Full extracts of data on a secure, independent analysis platform is the best option but you may have to compromise.
It is advisable to create a security policy for the project so that everyone is aware of their responsibilities and the professional approach you will be taking on the project.
Have you defined the hardware and software requirements for the later phases?
What machines will the team run on? What software will they need? What licenses will you require at each phase? Sounds obvious, not for one recent project manager who completely forgot to put the order in and had to watch 7 members of his team sitting idly by as the purchase order crawled through procurement. Don’t make the same mistake, look at each phase of the project and determine what will be required.
Model re-engineering tools? Data quality profiling tools? Data cleansing tools? Project management software? Presentation software? Reporting software? Issue tracking software? ETL tools?
You will also need to determine what operating systems, hardware and licensing is required to build your analysis, test, QA and production servers. It can often take weeks to procure this kind of equipment so you ideally need to have done this even before project initiation.
Phase 3: Landscape Analysis.
Have you created a detailed data dictionary?
A data dictionary can mean many things to many people but it is advisable to create a simple catalogue of all the information you have retrieved on the data under assessment. Make this tool easy to search, accessible but with role-based security in place where required. A project wiki is a useful tool in this respect.
Have you created a high-level source to target mapping specification?
At this stage you will not have a complete source-to-target specification but you should have identified the high-level objects and relationships that will be linked during the migration. These will be further analysed in the later design phase.
Have you determined high-level volumetrics and created a high-level scoping report?
It is important that you do not fall foul of the load-rate bottleneck problem so to prevent this situation ensure that you fully assess the scope and volume of data to be migrated.
Focus on pruning data that is historical or surplus to requirements (see here for advice). Create a final scoping report detailing what will be in scope for the migration and get the business to sign this off.
Has the risk management process been shared with the team and have they updated the risk register?
There will be many risks discovered during this phase so make it easy for risks to be recorded. Create a simple online form where anyone can add risks during their analysis, you can also filter them out later but for now we need to gather as many as possible and see where any major issues are coming from.
Have you created a data quality management process and impact report?
If you’ve been following our online coaching calls you will know that without a robust data quality rules management process your project will almost certainly fail or experience delays.
Understand the concept of data quality rules discovery, management and resolution so you deliver a migration that is fit for purpose.
The data quality process is not a one-stop effort, it will continue throughout the project but at this phase we are concerned with discovering the impact of the data so decisions can be made that could affect project timescales, deliverables, budget, resourcing etc.
Have you created and shared a first-cut system retirement strategy?
Now is the time to begin warming up the business to the fact that their beloved systems will be decommissioned post-migration. Ensure that they are briefed on the aims of the project and start the process of discovering what is required to terminate the legacy systems. Better to approach this now than to leave it until later in the project when politics may prevent progress.
Have you created conceptual/logical/physical and common models?
These models are incredibly important for communicating and defining the structure of the legacy and target environments.
The reason we have so many modelling layers is so that we understand all aspects of the migration from the deeply technical through to how the business community run operations today and how they wish to run operations in the future. We will be discussing the project with various business and IT groups so the different models help us to convey meaning for the appropriate community.
Creating conceptual and logical models also help us to identify gaps in thinking or design between the source and target environments far earlier in the project so we can make corrections to the solution design.
Have you refined your project estimates?
Most projects start with some vague notion of how long each phase will take. Use your landscape analysis phase to determine the likely timescales based on data quality, complexity, resources available, technology constraints and a host of other factors that will help you determine how to estimate the project timelines.
Phase 4: Solution Design.
Have you created a detailed mapping design specification?
By the end of this phase you should have a thorough specification of how the source and target objects will be mapped, down to attribute level. This needs to be at a sufficient level to be passed to a developer for implementation in a data migration tool.
Note that we do not progress immediately into build following landscape analysis. It is far more cost-effective to map out the migration using specifications as opposed to coding which can prove expensive and more complex to re-design if issues are discovered.
Have you created an interface design specification?
At the end of this stage you should have a firm design for any interface designs that are required to extract the data from your legacy systems or to load the data into the target systems. For example, some migrations require change data capture functionality so this needs to be designed and prototyped during this phase.
Have you created a data quality management specification?
This will define how you plan to manage the various data quality issues discovered during the landscape analysis phase. These may fall into certain categories such as:
Ignore Cleanse in source Cleanse in staging process Cleanse in-flight using coding logic Cleanse on target.
Have you defined your production hardware requirements?
At this stage you should have a much firmer idea of what technology will be required in the production environment.
The volumetrics and interface throughput performance should be known so you should be able to specify the appropriate equipment, RAID configurations, operating system etc.
Have you agreed the service level agreements for the migration?
At this phase it is advisable to agree with the business sponsors what your migration will deliver, by when and to what quality.
Quality, cost and time are variables that need to be agreed upon prior to the build phase so ensure that your sponsors are aware of the design limitations of the migration and exactly what that will mean to the business services they plan to launch on the target platform.
Phase 5: Build & Teste.
Has your build team documented the migration logic?
The team managing the migration execution may not be the team responsible for coding the migration logic.
It is therefore essential that the transformations and rules that were used to map the legacy and target environments are accurately published. This will allow the execution team to analyse the root-cause of any subsequent issues discovered.
Have you tested the migration with a mirror of the live environment?
It is advisable to test the migration with data from the production environment, not a smaller sample set. By limiting your test data sample you will almost certainly run into conditions within the live data that cause a defect in your migration at runtime.
Have you developed an independent migration validation engine?
Many projects base the success of migration on how many “fall-outs” they witness during the process. This is typically where an item of data cannot be migrated due to some constraint or rule violation in the target or transformation data stores. They then go on to resolve these fall-outs and when no more loading issues are found carry out some basic volumetric testing.
“We had 10,000 customers in our legacy system and we now have 10,000 customers in our target, job done”.
We recently took a call community member based in Oman. Their hospital had subcontracted a data migration to a company who had since completed the project. Several months after the migration project they discovered that many thousands of patients now had incomplete records, missing attributes and generally sub-standard data quality.
It is advisable to devise a solution that will independently assess the success of the execution phase. Do not rely on the reports and stats coming back from your migration tool as a basis for how successful the migration was.
I advise clients to vet the migration independently, using a completely different supplier where budgets permit. Once the migration project has officially terminated and those specialist resources have left for new projects it can be incredibly difficult to resolve serious issues so start to build a method of validating the migration during this phase, don’t leave it until project execution, it will be too late.
Have you defined your reporting strategy and associated technology?
Following on from the previous point, you need to create a robust reporting strategy so that the various roles involved in the project execution can see progress in a format that suits them.
For example, a migration manager may wish to see daily statistics, a migration operator will need to see runtime statistics and a business sponsor may wish to see weekly performance etc.
If you have created service level agreements for migration success these need to be incorporated into the reporting strategy so that you can track and verify progress against each SLA.
Have you defined an ongoing data quality monitoring solution?
Data quality is continuous and it should certainly not cease when the migration has been delivered as there can be a range of insidious data defects lurking in the migrated data previously undetected.
In addition, the new users of the system may well introduce errors through inexperience so plan for this now by building an ongoing data quality monitoring environment for the target platform.
A useful tool here is any data quality product that can allow you to create specific data quality rules, possesses matching functionality and also has a dashboard element.
Have you created a migration fallback policy?
What if the migration fails? How will you rollback? What needs to be done to facilitate this?
Hope for the best but plan for the worst case scenario which is an failed migration. This can often be incredibly complex and require cross-organisation support so plan well in advance of execution.
Have you confirmed your legacy decommission strategy?
By now you should have a clear approach, with full agreement, of how you will decommission the legacy environment following the migration execution.
Have you completed any relevant execution training?
The team running the execution phase may differ to those on the build phase, it goes without saying that the migration execution can be complex so ensure that the relevant training materials are planned for and delivered by the end of this phase.
Have you obtained sign-off for anticipated data quality levels in the target?
It is rare that all data defects can be resolved but at this stage you should certainly know what they are and what impact they will cause.
The data is not your responsibility however, it belongs to the business so ensure they sign off any anticipated issues so that they are fully aware of the limitations the data presents.
Have you defined the data migration execution strategy?
Some migrations can take a few hours, some can run into years.
You will need to create a very detailed plan for how the migration execution will take place. This will include sections such as what data will be moved, who will sign-off each phase, what tests will be carried out, what data quality levels are anticipated, when will the business be able to use the data, what transition measures need to be taken.
This can become quite a considerable activity so as ever, plan well in advance.
Have you created a gap-analysis process for measuring actual vs current progress?
This is particularly appropriate on larger scale migrations.
If you have indicated to the business that you will be executing the migration over an 8 week period and that specific deliverables will be created you can then map that out in an excel chart with time points and anticipated volumetrics.
As your migration executes you can then chart actual vs estimated so you can identify any gaps.
Phase 6: Execute & Validar.
Have you kept an accurate log of SLA progress?
You will need to demonstrate to the business sponsors and independent auditors that your migration has been compliant. How you will do this varies but if you have agreed SLA’s in advance these need to be reported against.
Have you independently validated the migration?
Already covered this but worth stressing again that you cannot rely on your migration architecture to validate the migration. An independent process must be taken to ensure that the migration process has delivered the data to a sufficient quality level to support the target services.
Phase 7: Decommission & Monitor.
Have you completed your system retirement validation?
There will typically be a number of pre-conditions that need to be met before a system can be terminated.
Ensure that these are fully documented and agreed (this should have been done earlier) so you can begin confirming that the migration has met these conditions.
Have you handed over ownership of the data quality monitoring environment?
Close down your project by passing over the process and technology adopted to measure data quality during the project.
Please note that this list is not exhaustive, there are many more activities that could be added here but it should provide you with a reasonable starting point.
You may also find that many of these activities are not required for your type of migration but are included for clarity, as ever, your migration is unique so will require specific actions to be taken that are not on this list.
Why not add your suggestions for additional activities using the comments below so we can extend this list into a best-practice booklet for download?
Get a 50+ data migration checklist for planning your project.
 Dylan Jones (Editor)  3rd December 2008  Data Migration Methodology.
Posts Relacionados.
Creating a Successful Healthcare Data Migration: Expert Interview with Ali McGuckin.
Migrating to SAP SuccessFactors: Practical Advice for an On-Time, On-Budget Data Migration, featuring Miles Davies.
Tech Briefing: Migrating Data – How do you know you are ready to go?
Data Migration Best Practices for your Next Project.
Comentários estão fechados.
To help you create a successful data migration career, project or business.

IT Challenge: conversão de dados ERP para uma atualização ERP.
Neste Desafio de TI do Mês, faremos um brainstorming de maneiras de realizar uma conversão de dados ERP bem sucedida ao passar de um sistema ERP legado para um sistema ERP baseado em SQL.
Este artigo abrange.
Integração ERP.
TÓPICOS RELACIONADOS.
Procurando por algo mais?
Compartilhe este item com sua rede:
Tutoriais de treinamento de software de fabricação e guias & ndash; Diretório do software SearchERP ERP para fabricantes & ndash; SearchERP IT Challenge: Integração do WMS com M2M & ndash; SearchERP.
O Desafio de TI SearchManufacturingERP IT do mês de novembro de 2018 é:
O meu negócio é atualizar de um sistema antigo para um novo sistema ERP baseado em SQL. Como posso garantir que os dados do antigo sistema ERP - que é todo tipo alfa ou numérico básico - podem ser convertidos em tipos de dados SQL apropriados sem corrupção de arquivos ou perda de dados?
Você tem uma solução para este desafio? Você encontrou um problema semelhante em sua empresa? Se assim for, entre em contato com os editores do SearchManufacturingERP e compartilhe suas sugestões ou experiências.
E certifique-se de verificar aqui todo este mês - vamos publicar soluções de especialistas e leitores à medida que os recebermos.
Do ERP e do especialista em indústria de fabricação Steve Phillips:
Quando se trata de gerenciamento de projetos ERP, menos programas de conversão de dados devem ser escritos, melhor. No entanto, para as conversões que são justificadas, é primeiro importante chegar a um consenso sobre como os dados serão usados ​​no novo sistema.
Depois de conhecer esses requisitos, você pode desenvolver uma especificação clara para cada conversão. Isso ajuda a evitar o retrabalho e define os resultados esperados, que são a base para testes e verificação. A maioria dos fornecedores e consultores de software possui modelos de mapeamento de dados que iniciam o processo de especificação.
Em seguida, você precisa testar cargas de dados. Aqui estão algumas dicas::
1.) O número de registros no arquivo de extração do sistema antigo deve corresponder ao número de registros carregados no novo arquivo do sistema.
2.) A maioria dos programas de importação de dados que são fornecidos com o software ERP reforçam a integridade dos dados com relatórios de erros listando dados que não foram carregados e o motivo. Verifique os relatórios, corrija o problema de dados e execute novamente a conversão.
3.) Visualmente compare o conteúdo do campo de uma amostra de tamanho bom que cobre a maioria dos cenários de dados principais. Use a especificação original para verificar os valores nos campos.
4.) Quando grandes quantidades de dados estão envolvidos, escreva algumas consultas baseadas em exceções simples contra os arquivos no novo sistema para destacar anomalias de dados, como valores que não são iguais a valores especificados, dados conflitantes ou problemas de formatação.
5.) Teste todas as aplicações principais usando os dados convertidos. Se existir um problema no formato de dados, as mensagens de erro do aplicativo ocorrerão.
Dig Mais aprofundado na integração ERP.
A National Grid processa a Wipro sobre uma suposta implementação SAP frustrada.
Verdades difíceis que você precisa saber sobre o ERP personalizado.
Por que a personalização do software ERP geralmente é uma má idéia.
Proliferação das integrações ERP melhor abordadas pela consolidação de dados.
A National Grid processa a Wipro sobre uma suposta implementação SAP frustrada.
Epicor CFO assume desafios ERP e futuro da nuvem.
As implantações do ERP dependem do gerenciamento de dados mestre, diz o painel do revendedor.
A Infor encontrou o truque para a integração ERP?
Como selecionar um parceiro de integração ERP.
Consolidação e integração de ERP.
Teste o seu know-how de integração e consolidação ERP.
Por que as empresas devem considerar a consolidação ERP?
Múltiplos sistemas, novas tecnologias aumentam os desafios de integração ERP.
Consolidação e integração de ERP.
Teste o seu know-how de integração e consolidação ERP.
Proliferação das integrações ERP melhor abordadas pela consolidação de dados.
As ferramentas de integração em nuvem podem ser uma solução universal para o antigo problema de TI.
Superando os desafios de um ambiente ERP complexo.
Como selecionar um parceiro de integração ERP.
Verdades difíceis que você precisa saber sobre o ERP personalizado.
Por que a personalização do software ERP geralmente é uma má idéia.
Obtenção de gerenciamento sênior a bordo com projetos ERP.
As tendências globais da gestão da cadeia de suprimentos promovem visibilidade, flexibilidade.
Encontre mais ofertas do PRO + e outros membros apenas, aqui.
E-Handbook.
Comece a conversa.
0 comentários.
Sua senha foi enviada para:
Ao enviar você concorda em receber e-mails da TechTarget e seus parceiros. Se você reside fora dos Estados Unidos, você concorda em transferir e processar seus dados pessoais nos Estados Unidos. Privacidade.
Crie um nome de usuário para comentar.
-ANÚNCIOS DO GOOGLE.
Últimos recursos TechTarget.
Pesquisar Oracle.
Usando o Oracle 12c Unified Auditing para definir políticas de auditoria de banco de dados.
O recurso de auditoria unificada incorporado do Oracle Database 12c simplifica o processo de auditoria de banco de dados, incluindo criação e.
Principais dicas e truques do Oracle de 2017, você não vai querer esquecer.
Reunimos cinco dos artigos de dicas mais notáveis ​​que publicamos em 2017, com conselhos que podem ajudar a fazer projetos da Oracle.
O Big Data Cloud Service simplifica as implantações do Oracle Hadoop.
Como parte de seu Big Data Cloud Service, a Oracle fornece um conjunto de ferramentas internas e externas projetadas para ajudar os usuários de forma eficiente.
Pesquisar CRM.
Atendendo aos regulamentos de marketing por e-mail da GDPR uma prioridade máxima.
Entre os novos regulamentos de marketing de e-mail do GDPR e perguntas sobre AI, as tendências de automação de marketing para assistir podem incluir uma IA.
Adicionando voz, canais de texto no CRM para aplicativos.
Quando o SpotHero queria criar canais de texto e de voz para permitir que os agentes ajudem os usuários do aplicativo a estacionar seus carros, a Ujet era o.
Língua natural que impulsiona a proliferação do FB Messenger.
As empresas estão incorporando chatbots com recursos de linguagem natural para ajudar a melhorar as experiências dos clientes, e eles são.
Procure SAP.
Desenvolvedores de cidadãos da Enexis habilitados pela plataforma Mendix RAD.
Quando um provedor de rede de energia holandês precisava desenvolver novos aplicativos de negócios em cima do SAP ERP, ele se virou para a plataforma Mendix RAD.
O Timo Elliott da SAP na tecnologia de conversação corporativa da AI.
O evangelista de inovação global da SAP espera que a IA afete as empresas de três maneiras: interação homem-computador, automação de.
SAP Leonardo, SAP Cloud Platform liderou o caminho para a SAP em 2017.
Aqui está um resumo de tendências e histórias interessantes no mundo da SAP em 2017, incluindo o envio da SAP às tecnologias de ponta.
Pesquisar Business Analytics.
Cinco etapas para construir melhores aplicativos de análise preditiva.
Consultant David Loshin outlines an approach to plan and manage predictive analytics initiatives to help ensure that they don't .
As ferramentas e as técnicas da AI serão mais invasivas, diz tech exec.
O ano passado foi a primeira vez que as ferramentas da AI tiveram um impacto real nas empresas. Essa tendência continuará em 2018, diz o.
A análise preditiva para negócios requer os dados certos.
Mais dados nem sempre beneficiam projetos de análise preditiva. As fontes de dados devem ser examinadas e compreendidas antes de serem usadas.
Pesquisar no SQL Server.
Cinco tendências do banco de dados SQL Server a serem preparadas para 2018.
Aqui está uma lista de tendências notáveis ​​relacionadas ao SQL Server, cujas equipes de TI devem estar prontas nos próximos 12 meses. Entre eles: .
Como os contêineres do SQL Server podem ajudar a facilitar a implantação do banco de dados.
Os recipientes Docker podem tornar o processo de implantação do SQL Server mais eficiente e flexível. Aqui estão o que são e como obter.
A atividade do banco de dados da nuvem Microsoft Azure decola no Connect ();
Microsoft Connect (); 2017 viu a adição da MariaDB e Cassandra à programação da base de dados da nuvem Azure. Também discutido: Um conjunto de.
Pesquisar Gerenciamento de Conteúdo.
Principais práticas de integração e implementação do SharePoint.
Aqui estão alguns conselhos e dicas de especialistas, bem como definições comuns, para ajudar a tornar sua integração e implementação do SharePoint a.
As capacidades de branding do SharePoint recebem um facelift.
Desde a Microsoft Ignite em setembro passado, o SharePoint Online está obtendo novos recursos de branding nas listas de desejos.
O próximo passo no ECM: a plataforma de serviços de conteúdo.
A necessidade de uma estratégia de gerenciamento de conteúdo coesa está afastando os vendedores do ECM tradicional e do conteúdo compatível com API.
Procure software de RH.
Em 2018, o mercado de tecnologia de RH permanece quente e competitivo.
Os sistemas de rastreamento de candidatos podem ver crescimento de investimento de dois dígitos no próximo ano. O investimento da VC em 2017 é inferior a metade do 2018.
Muitas razões para manter um processo formal de revisão do desempenho.
A bênção no gerenciamento de desempenho contínuo e no software de engajamento de funcionários não justifica a substituição de comentários por informações informais.
Uma revisão das tendências em software de RH durante 2017.
As principais tendências em tecnologia de RH de 2017 foram a AI e aplicações baseadas em aprendizagem de máquinas de fornecedores importantes, a aquisição de novos talentos.
All Rights Reserved, Copyright 2017 - 2018, TechTarget.