MERGER AND ACQUISITION DATA VALIDATION

Abstract

Systems and methods are provided that perform data validation in real time. By uploading the source data from spreadsheets or entering the data directly into an application, the required validations can be run and reported in real time. Users can then either extract the data back into spreadsheets for manipulation, and then re-upload it, or correct the data directly within the application. Once the data set has passed all validations, it is then passed to the technical team for upload into the transactional system.

Description

FIELD OF THE INVENTION

One embodiment is directed generally to data validation, and more particularly to validating data before migration.

BACKGROUND INFORMATION

The phrase mergers and acquisitions (“M&A”) refers to the aspect of corporate strategy, corporate finance and management dealing with the buying, selling and combining of different companies that can aid, finance, or help a growing company in a given industry grow rapidly without having to create another business entity. When companies are acquired or merged, it is often the case that data from one company needs to be transferred to the platform of the acquiring company. However, the platform of the company being acquired may be different from the platform of the acquiring company. For example, the acquired company may use SAP® business software, whereas the acquiring company uses Oracle® business software. In such a case, the data must be migrated from one platform to another.

In a typical data migration, the data would be compiled for loading, a load would be attempted into the destination system, rejected records would be analyzed and corrected, and then another attempt would be made to load them. Once in the system, the data would be tested and any which were incorrect would be deleted and reloaded, or more likely would need to be corrected and retested by loading on a new environment.

SUMMARY OF THE INVENTION

One embodiment is a method for validating data before migration from a first platform to a second platform. The method comprises receiving data to be validated from the first platform, validating the data at a third platform, and sending validated data the second platform.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a system for data validation and migration in accordance with an embodiment;

FIG. 2 is an example environment of a system for data validation and migration in accordance with an embodiment;

FIG. 3 is a flow diagram depicting a method for validating data for migration in accordance with an embodiment;

FIG. 4 is an example main menu user interface (“UI”) in accordance with an embodiment;

FIG. 5 is an example products list UI in accordance with an embodiment;

FIG. 6 is an example products list popup window UI in accordance with an embodiment;

FIG. 7 is an example customers list UI in accordance with an embodiment;

FIG. 8 is an example customers list popup window UI in accordance with an embodiment;

FIG. 9 is an example addresses list UI in accordance with an embodiment;

FIG. 10 is an example addresses list popup window UI in accordance with an embodiment;

FIG. 11 is an example contacts list UI in accordance with an embodiment;

FIG. 12 is an example contacts list popup window UI in accordance with an embodiment;

FIG. 13 is an example licenses and support list UI in accordance with an embodiment; and

FIG. 14 is an example licenses and support list popup window UI in accordance with an embodiment.

DETAILED DESCRIPTION

The migration of data into a transactional system such as Oracle E-Business Suite requires that the source data, whether extracted from one or more source systems or manually entered into spreadsheets, is complete and correct. Multiple entities may reference each other, and each entity must have all required fields populated according to the validation rules the destination system enforces. Additionally, any mappings or references to existing destination system data must also be validated as must any validations required to ensure that the data conforms to the business processes within the company. Failure to correctly reference associated entities or to correctly populate a field will result in the system application program interfaces or Open Interface tables rejecting the record for loading.

Typically in a large migration project, such as those taking place as part of a merger and acquisition, there is a long lead time in the validation process due to the number of iterations of loading, error reporting, error resolution, and re-loading for each record. This can account for as much as 80% of the project duration and 60% of the effort. An example would be the load of support licenses and their associated data, such as customer, address, contacts and parts. Each license references one of more parts, customers, addresses and contacts. Thus, to load the license into a new platform the associated data must also be provided. A number of fields need to be populated and in the correct format for each of these entities. A failure to populate a required field or reference will cause the record to be rejected. For example, if the license references a particular combination of customer, address and contact then the customer data provided must include that customer, address and contact and in the correct combination.

The process of ensuring the extracted data is complete and correct and will pass all the required system validations is lengthy, complex, and time consuming. This process requires multiple iterations of data extracts being passed between the teams extracting the data, the business analysts determining the transformation of the source data, and the team that finally loads the data into the destination system and reports on the validation failures.

An embodiment refines the above process by performing the data validation in real time. By uploading the source data from spreadsheets or entering the data directly into an application, the required validations can be run and reported in real time. The application can highlight rows in the spreadsheets that have data validation issues. Users can then either extract the data back into spreadsheets for manipulation, and then re-upload it, or correct the data directly within the application. Once the data set has passed all validations, it is then uploaded into the transactional system.

FIG. 1 is a block diagram of a system 10 that can implement an embodiment that validates data for migration from one platform to another. System 10 includes a bus 12 or other communication mechanism for communicating information, and a processor 22 coupled to bus 12 for processing information. Processor 22 may be any type of general or specific purpose processor. System 10 further includes a memory 14 for storing information and instructions to be executed by processor 22. Memory 14 can be comprised of any combination of random access memory (“RAM”), read only memory (“ROM”), static storage such as a magnetic or optical disk, or any other type of computer readable media. System 10 further includes a communication device 20, such as a network interface card, to provide access to a network. Therefore, a user may interface with system 10 directly, or remotely through a network or any other method.

Computer readable media may be any available media that can be accessed by processor 22 and includes both volatile and nonvolatile media, removable and non-removable media, and communication media. Communication media may include computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media.

Processor 22 is further coupled via bus 12 to a display 24, such as a Liquid Crystal Display (“LCD”), for displaying information to a user. A keyboard 26 and a cursor control device 28, such as a computer mouse, is further coupled to bus 12 to enable a user to interface with system 10.

In one embodiment, memory 14 stores software modules that provide functionality when executed by processor 22. The modules include an operating system 15 that provides operating system functionality for system 10. The modules further include a data validation module 123. These modules are described in greater detail below. Additional, fewer, and/or different modules 18 may also be included in system 10.

FIG. 2 illustrates an example environment where the data validation module may be utilized. In this example, data from a company being acquired is to be migrated to the system of the company making the acquisition. Acquired company system 201 includes the data to be migrated, and acquiring company system 203 is the destination of the migration. Information technology (“IT”) staff at the acquired company establishes a connection between acquired company system 201 and data validation system 10, such as by a virtual private network “(VPN”), and upload data from the acquired company system 201 to data validation system 10. The uploaded data is validated and errors are reported by the IT staff. Validation may include checking for missing values, checking for duplicate values, detecting orphaned records, inspecting the integrity of internal mappings in the data (such as mapping customers to addresses), and validating a mapping of the data to a schema provided by the IT staff of the acquiring company. The IT staff of the acquired company may choose to correct the errors directly in the data validation system 10, or download the data back to the acquired company system 201 and correct it there. This process is iterated until there are no more errors to report. The data from acquired company system 201 is then migrated to the acquired company system 203.

FIG. 3 illustrates a flow diagram of the functionality of data validation module 123 in accordance with an embodiment when validating data for migration from one platform to another. In one embodiment, the functionality of the flow diagram of FIG. 3 is implemented by software stored in memory and executed by a processor. In other embodiments, the functionality can be performed by hardware, or any combination of hardware and software. Data to be validated is first received from the acquired company system 201 (300). The data is then validated, which may include checking for missing values, checking for duplicate values, detecting orphaned records, inspecting the integrity of internal mappings in the data (such as mapping customers to addresses), and validating a mapping of the data to a schema provided by the IT staff of the acquiring company (310). If there errors in the data (320), the errors are reported to the IT staff of the acquired company (330). Updated data is then received (340), and the data is validated again (310). This process iterates until no errors are detected (320), at which point the data is migrated to the acquiring company system 203 (350).

FIG. 4 illustrates an example main menu user interface (“UI”) 400 of the data validation module 123. Main menu UI 400 includes a Validate section 401 comprising links relating to the validation of parts information (e.g., software products), trade community architecture (“TCA”) information (e.g., customer contact information), and license and support information. Parts information links include a Product list link 403 linking to a page for validating software product information, and a Products link 405 linking to an administrative page for adding products to the product list. TCA information links include a Customers link 407 linking to a page for validating customer information, an Addresses link 409 linking to a page for validating customer address information, and a Contacts link 411 linking to a page for validating contact information for individuals within the customer organizations. License and support link 413 links to a page for validating license and support information. Main menu UI 400 further includes a Reports section 415 comprising links to reports about the validation process, and a System Administration section 417 comprising links for administering users, projects, parameters, validation errors, error lookups, and scripts.

When a user clicks on Products List link 403, a Products List UI 500 (FIG. 5) is presented. Products List UI 500 includes a Project section 501 that allows the user to select a company from which product information needs to be validated, and an environment in which that data needs to be validated. Project section 501 further allows the user to browse for a tabular data file, such as a comma separated value (“CSV”) file or an extensible Markup Language (“XML”) file, containing product information for upload. When a project is selected, the products list data is displayed in Table 503. Each row in Table 503 represents a product, as provided in a CSV file from the acquired entity. Information regarding the products can be edited directly in the table, or by clicking the icon in the row edit column 505. Clicking this icon displays a popup window 600 (FIG. 6) that allows the user to edit information such as the product name, a company-specific product metric, terms associated with the product, a legacy part number for the product, and a license price for the product. The user can apply those changes, cancel the changes, or delete the product from the list. The data edited in popup window 600 is displayed in Table 503. Table 503 further includes locked column 507 indicating whether the row is editable, and validated column 509 indicating whether the row has passed validation. Changes made directly in the table may be applied using the submit button 511, or canceled using the cancel button 513. Individual or groups of rows may be deleted using check box column 515 and delete button 517, and rows may be added using add row button 519. Individual or groups of rows may be validated using check box column 515 and validate button 521. If rows fail validation, the errors are displayed in Table 503, which will be illustrated later. If the user wants to make changes to the data in a different application, the user may download the data (including error information) using the CSV download link 523. Products List UI further comprises a Search section 525 that allows the user to narrow the products list displayed in Table 503. The user may search for products by product name, company-specific product metrics, terms associated with the product, and the product part number.

Turning back to main menu UI 400, when a user clicks on Customers link 407, a Customers List UI 700 (FIG. 7) is presented. Customers List UI 700 includes a Projects section 701, Table section 703, and Search section 725 that are similar in function and operation to Projects section 501, Table section 503, and Search section 525, respectively, in FIG. 5, so for the sake of brevity only the differences are now described. Table section 703 displays customer information of the acquired company, for example, customer reference numbers, customer company names, tax registration numbers, customer URLs, legacy entity names, etc. As with table 503, this information can be edited directly in Table 703, or by clicking the icon in the row edit column 605 to edit the information in popup window 800 (FIG. 8). Also like Table 503, Table 703 displays whether rows are locked, validated, and described errors found during validation. Search section 725 is similar to Search section 525, but allows the user to search customers by customer reference numbers, customer company names, customer URLs, etc.

Turning back to main menu UI 400, when a user clicks on Addresses link 409, an Addresses List UI 900 (FIG. 9) is presented. Addresses List UI 900 includes a Projects section 901, Table section 903, and Search section 925 that are similar in function and operation to Projects section 501, Table section 503, and Search section 525, respectively, in FIG. 5, so for the sake of brevity only the differences are now described. Table section 903 displays address information of the acquired company, for example, an address reference number, a customer reference number, multiple address lines for precise locations, a city, a state, a province, a county, and country of the address. As with table 503, this information can be edited directly in Table 903, or by clicking the icon in the row edit column 905 to edit the information in popup window 1000 (FIG. 10). Also like Table 503, Table 903 displays whether rows are locked, validated, and described errors found during validation. Search section 925 is similar to Search section 525, but allows the user to search for an address by address and customer reference numbers, an address line, city, state, province, etc.

Turning back to main menu UI 400, when a user clicks on Contacts link 411, a Contacts List UI 1100 (FIG. 11) is presented. Contacts List UI 1100 includes a Projects section 1101, Table section 1103, and Search section 1125 that are similar in function and operation to Projects section 501, Table section 503, and Search section 525, respectively, in FIG. 5, so for the sake of brevity only the differences are now described. Table section 1103 displays contact information of the acquired company, for example, a contact reference number, a customer reference number, an address reference number, the name of the contact, the job title of the contact, the phone and fax numbers of the contact, the email address of the contact, etc. As with table 503, this information can be edited directly in Table 1103, or by clicking the icon in the row edit column 1105 to edit the information in popup window 1200 (FIG. 12). Also like Table 503, Table 1103 displays whether rows are locked, validated, and described errors found during validation. Search section 1125 is similar to Search section 525, but allows the user to search for a contact by name, job title, email address, etc.

Turning back to main menu UI 400, when a user clicks on License and Support link 413, a License and Support UI 1300 (FIG. 13) is presented. Licenses and Support UI 1300 includes a Projects section 1301, Table section 1303, and Search section 1325 that are similar in function and operation to Projects section 501, Table section 503, and Search section 525, respectively, in FIG. 5, so for the sake of brevity only the differences are now described. Table section 1303 displays license and support information of the acquired company, for example, a customer ID, customer name, customer address, billing ID, etc., for a particular license. If the customer is also a customer of the acquiring company, the same data may be included for the acquiring company. As with table 503, this information can be edited directly in Table 1303, or by clicking the icon in the row edit column 1305 to edit the information in popup window 1400 (FIG. 14). Also like Table 503, Table 1303 displays whether rows are locked, validated, and described errors found during validation. Search section 1325 is similar to Search section 525, but allows the user to search for licenses by customer reference number, customer name, customer address, billing information, shipping information, etc.

By allowing the users to perform real-time validation prior to data-loading the overall effort of the migration may be reduced as much as 70%, and the duration of the project may be reduced as much as 40%. An advantage of this solution is that the business analysts or administrators involved in compiling the source data can ensure that the data set is complete and correct in advance of loading, and without the involvement of the information technology staff responsible for the destination system. Therefore it is not necessary to load the data into the transactional destination system in order to ensure it is correct.

Some embodiments of the invention have been described as computer-implemented processes. It is important to note, however, that those skilled in the art will appreciate that the mechanisms of the invention are capable of being distributed as a program product in a variety of forms. The foregoing description of example embodiments is provided for the purpose of illustrating the principles of the invention, and not in limitation thereof, since the scope of the invention is defined solely by the appended claims.

Claims

1. A method for validating data before migration from a first platform to a second platform, comprising:

receiving data to be validated from the first platform;

validating the data at a third platform; and

sending validated data the second platform.

2. The method of claim 1, further comprising:

generating a report of errors in the data to be validated;

receiving updated data to be validated; and

validating the updated data.

3. The method of claim 1, wherein validating includes determining whether values are missing.

4. The method of claim 1, wherein validating include determining whether orphaned records are present.

5. The method of claim 1, wherein validating includes mapping a first subset of the data to be validated to a second subset of the data to be validated.

6. The method of claim 1, wherein validating includes mapping the data to be validated to a schema.

7. The method of claim 1, wherein the data to be validated is not sent to the second platform until the data to be validated passes validation.

8. The method of claim 1, wherein first platform is of an acquired company and the second platform is of an acquiring company.

9. A computer-readable medium having instructions stored thereon that, when executed by a processor, cause the processor to validate data before migration from a first platform to a second platform by:

receiving data to be validated from the first platform;

validating the data at a third platform; and

sending validated data the second platform.

10. The computer-readable medium of claim 9, further comprising:

generating a report of errors in the data to be validated;

receiving updated data to be validated; and

validating the updated data.

11. The computer-readable medium of claim 9, wherein the data to be validated is not sent to the second platform until the data to be validated passes validation.

12. A system for validating data before migration from a first platform to a second platform, comprising:

a memory having stored thereon instructions that cause the system to receive data to be validated from the first platform, validate the data at a third platform, generate a report of errors in the data to be validated, receive updated data to be validated, validate the updated data, and send validated data the second platform; and

a processor that executes the instructions.

13. A system for validating data before migration from a first platform to a second platform, comprising:

means for receiving data to be validated from the first platform;

means for validating the data at a third platform; and

means for sending validated data the second platform.

14. The system of claim 13, further comprising:

means for generating a report of errors in the data to be validated;

means for receiving updated data to be validated; and

means for validating the updated data.

15. The system of claim 1, wherein the data to be validated is not sent to the second platform until the data to be validated passes validation.

16. The system of claim 1, wherein first platform is of an acquired company and the second platform is of an acquiring company.