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.
I review a lot of Request for Proposals for system implementations – some well-written, some not. But one of the things I see lacking in most RFP’s is sufficient attention paid to the topic of data.
When data is under-addressed in the RFP, in the subsequent negotiations and/or the project itself -- bad things can happen. Even if you are planning a brand new installation without any data to migrate, there should be a well-articulated strategy for data. Likely, the primary reason software you’re getting implementing is so that you can get data into and out of the system reliably. Think of software as the plumbing in your house and your data as the water that will flow through that plumbing system. Unless you want to risk the success of the project, you need to make sure you plan in advance for the planning, coordination, and monitoring of those water pressure tests.
As you are poised, fingers hovering above keyboard, writing your RFP, don’t neglect to include a well-crafted Data Readiness section. Be sure to address the details and the related RACI chart for the sub-topics of Data Cleansing, Mocks, Extraction, Load Programs, Transformation, Data Validation and Data Readiness Metrics.
Making your Data Readiness Strategy as a well-constructed pillar of the project from the very beginning will help you build that comfort you need for when you turn on that data faucet at Go Live!
To learn more about how to plan an effective Data Readiness Strategy that you can build into your RFP or project, attend ValidDatum’s free webinar:
Avoiding A Data Disaster: Planning A Successful Data Readiness Strategy for Your Project