SAP Ariba is considered to have one of the best solutions for Contract Management. Ariba Contract Management is an end-to-end solution designed to eliminate paper and ink from creation, execution, and management of any type of contractual agreement. It has the following benefits:
- Automate and accelerate the entire life cycle with controlled processes
- Collaboration with stakeholders that includes document sharing, editing and e-signatures
- Complete visibility with automatic alerts, dashboards and configurable reports
- Stronger compliance with automated tracking and full audit trail
(SAP Ariba n.d.)
While all the above would satisfy the needs of a customer / client requiring a robust contract management solution, there is not much information out there around migration of contracts to Ariba for an implementation. I have been recently involved in a Major Business Transformation project for a client who implemented S/4 HANA and SAP Ariba. As data migration is part of any implementation, we were tasked with migrating existing contracts to Ariba for Go-Live. I share my experiences below on the issues faced, methods adopted to resolve issues / restrictions and automation of the migration process.
Import Legacy Contracts
One should use the legacy contract import feature to load existing contracts or legacy contracts from any other contract repository to Ariba. This enables to keep a record of previous contracts and provide a starting point for future contracts. To upload legacy contracts into Ariba, one must provide information about existing contracts in CSV format. Because of the wide variety of possible current formatting of legacy contracts, SAP Ariba does not supply a tool to explicitly format existing contracts, nor does it provide more than general instructions on converting the specific formats of your contracts to the required format.
General instructions on how to import contracts
When importing legacy contracts, one must submit a ZIP file that contains the following CSV files.
- ImportProjectParameters.csv
- Contracts.csv
- ContractTeams.csv
- ContractDocuments.csv
- ContractContentDocuments.csv if importing contract line items / documents
Step 1: Assemble a ZIP file containing information about the contracts to load.
Step 2: In Ariba, Click Manage → Administration
Step 3: Click Project Manager → Import Legacy Contracts
Step 4: Browse the ZIP file that is required to be imported and click Import
Step 5: Click Project Manager → Import Legacy Contracts Status to check the status of the load. Once the status is ‘Completed’, the contract load is finished. Click View Details for details on the load and any errors that occurred.
(SAP Ariba 2019)
No specific instructions and no tools?! Where to from here?
So how did we do it?
My client had no repository of contracts, they were scattered across emails, excel sheets and physical documents. We started with collection of existing contracts in an excel spreadsheet which ended up becoming a maintainable contract register for my client up to Go-Live.
We used JavaScript code that
- Read information from the excel register
- Transform data
- Write to csv file(s)
- And then ZIP the files
Selenium was then used to automate the clicks on Ariba (steps 2 to 4 listed above). From start to finish of import, it could take anywhere between a couple of minutes to half an hour depending upon the number of contracts loaded in one ZIP file. We will have to introduce a wait time to pause the automation and then read import status, which might be too soon or late based on the processing time of the ZIP file. Hence, this was not part of the automation.
Once the entire load was imported using automated clicks, we provided the Ariba consultants with the contract ID numbers that were loaded. They were able to query the backend of the system and confirm if the contracts were loaded successfully. Any contract IDs that were not confirmed were assumed to have failed load. This was the alternative for Step 5.
Some key restrictions to be considered
- The maximum size for the input ZIP file is 100 MB. If the contracts to load do not fit in a ZIP file that is smaller than 100 MB, then divide and create multiple ZIP files
- SAP Ariba evaluates each entry in the load attributes file (Contracts.csv) one line at a time. For each line, SAP Ariba creates one contract workspace and then the information specified for documents and team members is used to populate the workspace. If the load fails on any line of the Contracts.csv file during the contract workspace creation, the bulk load fails and terminates. If the load fails during the document or team members population of the load, an error is logged, and the load continues
- If a legacy contract import operation fails and we want to reuse the ZIP file to retry the import operation, view the log file to determine which contracts loaded successfully. Remove entries for successfully loaded contracts from the ZIP file before retrying the import operation
- Successfully loaded contracts should be removed from the ZIP before retrying because this feature should not be used to reload contract workspaces that are already loaded
- Do not nest folders within the ZIP file, all CSV files must be at the top level of the ZIP file
- Loading legacy contract workspaces is a time-consuming process. For example, an upload of 7500 contract workspaces with no added documents or team members through a moderately complicated template takes approximately 16 hours. Because of the time involved, be sure to verify all data before loading
(SAP Ariba 2019)
How did get around the above restrictions?
We decided to create one ZIP file for one contract. This approach meant that
- The ZIP file size will always be less than 100 MB. The client did not opt to migrate PDF / Word attachments for Go-Live; this meant that we only had information as text in the CSV files to migrate.
- If the load goes into error / terminates, we corrected the ZIP file and re-imported it. We did not face the issue of identifying the line at which the load failed or removing successfully loaded contracts from the ZIP before retrying.
- Processing time to read one contract information is very fast compared to multiple contracts in a ZIP file.
By following this approach, yes we did end up with 1000 ZIP files for 1000 contracts! This did not seem to be a huge problem J
We automated the creation of ZIP files, which made sure there was no nesting. Time consumption was dependent on a number of factors like – template structure, contract information loaded (like documents, team members), processing time, etc. There is no alternative to reduce the processing time. We tested a full volume and noted the time taken for the end-to-end load process. We made sure this time was allocated during the cutover for this process to be completed successfully.
Lastly, by automating the assembly and import of contracts to Ariba, we made sure manual effort was spent on analysing errors / correcting them.
Additional Information:
While researching possible options for this project, I picked up that NTTDATA has a Legacy Contract Migration tool that automatically converts all legacy contracts – paper, PDF, scanned images and more to a ZIP format and size compatible with SAP Ariba. The tool is platform agnostic and will support any OCR tool. It validates contract attributes against SAP Ariba master data during the ZIP file creation process, not during import. It sends any detected errors into a log for correction, without the need for recreating and reloading contracts. The result: accurate, streamlined contract migration to SAP Ariba in one-third less time.
(NTT DATA 2016)
Unfortunately, I did not have the opportunity to use this tool for my project. However, this would be absolute magic for any project!
Final thoughts
Due to restrictions and lack of detailed guidance, contract migration is not easy until you work out a pattern / process that works for you. The recommendation from Ariba team is to schedule contract migration as early as possible as it is a time consuming process. That being said, it would be great if SAP could develop further guidance / instructions for migrating contracts in the future.