LINKS
ABOUT

Contact:John Lowe

E: enquiries@datamc.com.au

T: (07) 5391 3868

Address: Level 4, 55 Plaza Parade, Maroochydore QLD 4558

ABN: 19 610 291 926

SOCIAL
  • White LinkedIn Icon

Data

Data migration may impact business operations when it creates extended downtime, compatibility and performance issues. Data MC has proven, tried and tested methodologies in place to mitigate risks associated with,

DATA:

  • Migration

  • Quality Assessments and Cleansing

  • Reconciliation and Verification

  • Integration

  • Warehousing, Reporting and Business Intelligence

At Data MC we have worked long enough with business and company data to understand the criticality of ensuring the completeness and correctness of a company’s data. Whether you are going through a full ERP implementation, business transformation program, or simply looking to clean up known data defects, DMC has many years of collective experience dealing with just about any conceivable business data scenario. It is what we do for a living!

DMC’s expert consultants are not restricted by the type of legacy system, platform, or data type. Some of the most common types of data we deal with on a day to day basis are:

  • Finance data

  • Human Resource and Payroll (HRP)

  • Customer Relationship Management (CRM)

  • Supply Chain and Inventory Management

  • Heavy Equipment and Servicing

  • Electronic Document Management

Data can be categorised into three distinct types:

Reference and Configuration Data

The Reference or Configuration data, is the underlying ‘static’ data within a system, usually found in ‘drop-down’ selection boxes. This data is normally added by Functional or Business Consultants during a software setup or configuration exercise, and is often added to over time, as the business needs change. Unlikely to suffer much in the way of data quality issues, it could still have duplication and/or redundant data as business operations evolve. Often needs rationalisation and refinement.

The Master and Transactional data will utilise the Reference data, so if this is to be changed and updated, these same updates would need to be applied throughout the data. This would require careful mapping by the business, ‘old-to-new’ mapping, and recorded in Translational Mapping Matrices.

Master Data

These are the ‘business objects’, such as Customer or Vendor records, which are used by the whole organisation. Transactions are applied to the Master data, and although this data is relatively static, it is very important to ensure this data is maintained and kept up-to-date to ensure legitimacy and correctness. Often, Master Data Management (MDM) plans and governance guidelines are in place to maintain this data, but duplication and missing data can still be a major issue facing many organisations, especially if two or more systems are to be merged together. Frequently there is a need for de-duplication by way of identifying a ‘survivor’ or ‘primary’ record, remembering that there could be significant transactional data tagged against the records to be removed. This requires a whole remapping exercise to ensure there are no ‘orphan’ transactional records left behind afterwards.

Cleansing of Master data can take many months to complete, is costly, and can involve a significant amount of business time. It is generally a good idea to begin early, before any planned program of works might be requiring the data. Tools can be used to assist in this cleansing, nonetheless the business effort cannot be understated.

Transactional

Transactional data records ‘events’, the actual business or operational transaction records. These records are related directly to Master data records, and will often have references to the Reference data. Examples could be, invoices and invoice lines, sales orders and sale order lines, purchase orders and purchase order lines, or salary payments made during a payroll run. The transactional data can go back many years depending on the age of the legacy source system. It may not be necessary to move such volumes of transactional data for day to day operational use. Often transactional data is added to a data warehouse where trending and analysis can be conducted over the data. Transferring masses of transactional data can apply unnecessary strain on a new system, and often there is a need to apply purging techniques to maintain speed and efficiency within the operational system.