PRODUCTION ENVIRONMENT CHANGES
An Insequence a Change Authorization form can be submitted here. Change Authorizations will have to be submitted on Insequence.Online prior to making changes in the production environment. All changes to a production system outside of emergency support for line stoppage fall under this policy. Changes required for a line stoppage will require a written communication at the time of the event from an authorized contact for your facility.
Insequence has added the Change Authorization process along with specific policies and procedures for Live Production System changes. Insequence has taken the initiative to make your life better by avoiding miscommunication and the consequential mistakes that go along with that. We may have a number of employees that have never stepped foot into your particular facility and we want to educate them to avoid any controllable critical mistakes.
Test Environments
Insequence encourages all customers to have test systems available for testing process and programming changes prior to being implemented in a live environment. Insequence will provide free of charge SPD Pro licensing and configuration for test environments that are customer provided. Insequence will not supply the hardware or third party software such as OS or SQL free of charge. A large portion of our customer base provides low end VM environments for test systems to assist in reducing costs for test environments. If you are interested in a test environment, please contact Technical Support via phone or email for more information.
Testing of Programming & Process Changes
Insequence requires that adequate testing is performed on new programming or process changes within the limitations of the customer site. If a test environment exists, this will mean testing with the customer data in a controlled environment. If a test environment does not exist, testing will be performed in a controlled way within the production environment dependent on the change requested. This could mean running a new version of application on one station, setting up test profiles as needed, or making changes during a downtime for testing. All testing requires both Insequence personnel and the customer to be involved. All customers will be given a reasonable opportunity to evaluate the changes and feel comfortable with said changes prior to them being implemented in the production environment after test environment testing, or fully implemented into production when no test environment exists if possible.
During the testing phase, Insequence personnel will create an implementation checklist to ensure the proper steps are taken when moving the change or programming to the production environment. Once both Insequence and site personnel agree that the update/change has been thoroughly tested with a positive outcome, the Checklist should be signed off on for testing to be considered complete. This sign-off is to be completed by both the Insequence employee that tested with onsite personnel and the onsite personnel
Change Requests for Programming & Process Changes
Once we determine the test system update is complete and signed off on or that we do not have a Test environment to test on, we can proceed toward updating a live, in-production system. To do this we must receive a submitted Insequence Change Authorization Form. Once the form has been submitted you can proceed with the next phase of moving the change or programming to the production environment.
Updating a live, in production server must be accompanied by a written checklist provided by the Insequence Tester who updated the test server. If no test environment was present, a check list will be provided with programmer input as to the proper steps needed for the update, or if process changes by Field Service personnel with the changes required. There will be items needed and procedures followed to make the changes. Please see the listing below:
The first thing we have to look for is an acceptable window of opportunity to implement that includes more than adequate time for the following items to be completed:
- Back up the system prior to doing anything, for a viable back-out strategy.
- Perform the update scripts as required for the change.
- Follow-up verification that everything appears correct.
- Provide enough time to roll back if the follow up verification leads to the conclusion that the update was not successful. This time frame is dependent on many factors. It is Insequence responsibility to determine how much time is going to be necessary, this can be derived from testing on the test server with the customer’s actual data. It is absolutely essential that enough time is allotted by the customer to make the changes and run through a set of test parts prior to resuming production. If the update was not tested in a test environment first, then the customer would need to provide more time for testing in the production environment to ensure there would be no impact during a production run time.
Both Insequence and the customer should be present for the move into a production environment. The checklist created during testing should be followed to ensure a successful move to production. This should have been created while testing to ensure a successful move to production. There should be no deviation from the check list that was previously created while testing. If testing was not performed on a test environment and you are implementing for testing on a production environment, make sure a check list was created in advance and that this is followed.
If there is an issue with a customer providing adequate downtime for the changes to occur, Insequence can and will decline making the changes until an appropriate time can be allotted to ensure a successful implementation, minimizing unacceptable risk to production. The only exception to the previously stated statement would be if the customer is truly in imminent danger of serious malfunction.