Phone: (888) 389-2250
ValidDatum
  • Home
  • Solutions
  • Team
  • Contact
  • News
  • Blog
  • Stories
  • UK Site

Don’t Neglect Proper Planning and Testing for Data

8/13/2018

 
Picture
Let’s face it. The primary reason for the software you’re implementing is so that you can get data into and out of the system reliably. Think of your software as the plumbing in your house and your data as the water that will flow through that plumbing system. Despite the obvious risks of plumbing a whole enterprise and then testing with fake or insufficient data, I am continually amazed at how little effort most companies expend on managing the Data Readiness and Data Validation aspects of their project. The consequences of that lack of preparation can be disastrous!

Data is fluid. Since many implementations (such as for a new ERP system) take place over an extended period of time while the business is in full operation, it is not unusual for the data to change significantly over the life of the project. Customers, Vendors, Employees and Materials are being created and updated. Customer Pricing is changing and Territories are re-aligned. Therefore, you must plan for sufficient and proper “Mock” Data Conversion Load Cycles to ensure you have handled and validated the latest data available and have addressed all possible variations. Too often, the project team plans only one or two partial data conversions mocks, but this approach is NOT a promising plan for a dry basement after Go Live!

Data is easily contaminated. Without the proper management of activities such as Data Governance, Data Profiling, Data Cleansing, Data Conversion and Data Validation, even small amounts of rotten data present in the legacy system can create a mucky mess in your brand new system. Careful attention must be paid to planning, communication, execution and monitoring of these data related activities to adequately de-risk your ERP Implementation.

You-know-what flows downstream. Small data problems at the beginning can become really big problems as the data moves through your systems, being processed and combined with other data. For example, a missing Sales Territory on a handful of migrated high volume customer records may mean that your combined Sales by Territory reports may be inaccurate. Make sure you plan sufficient time to thoroughly and formally test ALL of your downstream applications, databases, analytics and reporting with migrated real data from your ERP Test instance before you go live, leaving enough time in the project schedule to do upstream corrections and re-testing for any defects found.
​
To boil it down -- Following this advice will make your Data Readiness Strategy a well-constructed pillar of the project from the very start and will help build business confidence in their data. You will be better prepared to turn on that data faucet at Go Live! 

Revenge of the B.L.O.B. & Other Perils in a SuccessFactors Data Migration

10/8/2017

 
Picture
By: Daryl Crockett

​It seems like a straightforward task  - move 300,000 resumes from the existing the legacy recruiting databases into SuccessFactors so recruiters can mine candidates who have applied in the last couple of years from within the SuccessFactors application. But oh, not so fast! 
 
It turns out that many applications (like PeopleSoft) store resumes, letters, images, sound files and other attachments as " B.L.O.B.'s", short for Binary Large Object. To save space and speedup data retrieval, BLOBs are locked up inside the database rather than sitting outside as easily accessible files in a folder.  If an application has your resumes and other attachments stored as BLOBs, you can't just go to a directory and drag them into a SuccessFactors accessible folder.
 
Gaining access to that pot of juicy resumes can give your recruiters a competitive advantage, saving time and effort in searching for prospective candidates. Just because you didn’t hire a candidate the last time they applied doesn’t necessarily mean that rejected candidate (of the past) isn't a good option for a future job opening.  But BLOB extraction requires special coding for extraction, so make sure you plan ahead and get the right technical expertise to write and execute that extraction routine.
 
BLOBs are (as their name implies) big and take up a lot of storage space when they are unlocked and unleashed into the daylight.  Make sure you plan for sufficient online storage to house those extracted resumes and application attachments which is accessible for prepping as part of your SuccessFactors data migration.
 
Stay tuned!  Next in our series:  FileZilla vs. the BLOB
 
Visit www.ValidDatum.com for more insights into Data Migration for SAP SuccessFactors implementations. 

<<Previous
Forward>>

      Subscribe to our blog

    Subscribe

    Categories

    All
    Data Quality
    Serialization
    SuccessFactors

    contact us
Copyright © 2021 ValidDatum All rights reserved.       Phone: 888 - 389 - 2250         Boston ~ London ~ Tampa