Ever had a Webex where the support person jumped into your Production system and changed some ini file settings and you don’t recall what they changed? And now the problem is worse? We had that experience more than a year ago and admittedly that support person is no longer working for Readsoft and I should have refused to let him touch the Production system; however, I did learn a valuable lesson.
We needed better change control for our ini and xml (ie Invoice Rules and ScanInfo plugins) files. The ini and xml files contain the configuration settings that drive system behaviour. Installing the Invoices software is simple, getting the right settings in the ini files is the hard bit.
Whether you are in IT or otherwise, here are the conversations you need to be having with the relevant personnel in your company:
1. Make a copy of your ini files (eiglobal, eilocal, and eiglobalextra); as well as eicc (for SAP interfaces) and Collector (if you have email integration). Note we are on SAP so I am only familiar with EICC, which is the integration software between Invoices and Process Director.
2. Make a copy of any xml plugin files like Invoice Rules and ScanInfo
3. Store the files in a different location, say have a backup copy on a client PC as well as on the Readsoft server
4. Add some text to the file, such as the date and “baseline copy” prefixed by ; to denote it’s just a description not a configuration setting
5. If you have a working test environment, always try and replicate the problem in Test first before contacting an external support person. Only allow the support person to touch your test environment! Test the changes and if working okay, have an internal person reproduce them in Production.
6. If you don’t have a working test environment (it is recommended that you do) then make a copy of your ini and xml files before allowing changes to your configuration settings in PRD.
7. If you are in IT, involve Accounts Payable in testing and only make changes to the PRD configuration files if they approve the change upon successful testing.
8. Document all changes to your ini files by editing the PRD files in Notepad. For example, it is recommended to put the IT ticket number and a brief description of the change in your PRD ini file.
9. If you make any changes to the PRD ini or xml files, then make new copies of your baseline and remember to change the header date. Keep the old copies, do not overwrite them so you have a history of your changes.
10. Don’t be impulsive and jump straight into solving any PRD outages/major issues by allowing ini or xml changes directly into your PRD system. Take a deep breath, pause, and work out how you are going to mitigate any risk, before working out how you are going to solve the problem.