Objective:

To manage change and enhancement activities of IT for ERP System. This procedure clearly identifies the responsibility and accountability of each and every party involved in the process. With the proper checks and balances, it also fosters the quality that is required for business process and automation.

Category of Change:

The following activities fall into the category of ‘Changes and Enhancement’ :

• Application problem resolution
• Changes to existing process / reports
• New addition of process and reports

Procedure protocol :

To streamline the process of change control, a single procedure is devised to cover all the above categories of changes. Depending on the scope of the change, some steps within the procedure may be tokenized or waived. Even so, the necessary signatures must be obtained to meet the checks and balances of the process.

Change Procedure :

Pre Change request activity :

1. User experiences inconvenience or inadequacy on information process
2. User discuss & consult with business process section for consultation
3. Business process people consult with IT to brainstorm possible & sensible solutions.

* At this point of time, no CR has been written yet. All activity/time incurred must be charged to system-consultation category.

** If the consultation activity appears to be taking too long ( > 4 hours), then the IT staff should advise the user/business analyst to write up a research CR so the time spent can be tracked properly.

Change request :

• If so decided, business analyst will write up and submit a change request to IT. If such request is an automation request of significant magnitude, additional requirement document will be needed and attached to the change request.
• A HelpDesk ticket must also be opened (either by business analyst or IT staff) and the filled-out CR form must be attached to the eHelpDesk.

User requirement document :

User requirement document is part of the overall project/task document. It describes, in business terms, the user needs for information automation. This information is generally authored by the project initiating party. In this stage of procedure implementation in Shanghai, IT department will assist users in the brainstorming and definition of the user requirements.

• Requirement signoff

When the requirement is reviewed and agreed upon, both the user and IT will sign off the requirement document.

User committee and prioritization :

• Key user committee is comprised of business analysts and key users from major functional areas such as FA, logistics, purchasing, warehouse, HR, planning, etc..
• This committee will hold meeting every month. IT department will send representative to the meeting on a regular basis. Usually this will be IT’s ERP application support team leader as long as he/she is available.
• All Change Requests will be discussed and prioritized in the key user committee. This priority will need to be rectified by the company information automation board, which consists of senior functional managers in Company.
• IT will based on the finalized priority of the requests in queue, the scope of work and resource availability to determine the execution sequence of these requests.

Execution :

Once a change request is decided to be implemented, an IT project lead will be assigned. If the project is managed by user community, the IT project lead will act as co-project manager to assist the project manager on day to day project execution.

Design Phase

• IT project lead, project manager, and the consultant (if any) will work as a team to explore the options and devise the change architecture for each option. Design review session will be arranged by PM and it can repeat as needed.
• Design sign-off

The following persons must sign off the design before any technical work can proceed.

–  Project manager
–  IT management (tentatively both the application team lead and IT director. )
–  Key user ( optional )

Coding/customization phase

Code review

• Code review can be conducted any time after the satisfactory unit test, and before the UAT test.
• Objective:

–  Ensure standard adherence

–  Validate code structure

–  Another pair of eyes for logic flaw ( optional, depending on the experience of the reviewer. )

• Code Review signoff :

–  Designated reviewer

–  Application team leader

Integration Test phase

• Business analyst, users, and IT people will work as a team to devise a set of integration test scenarios / scripts.
• For simple change, the integration test will include a regression test. This regression test should be a pre-defined test script that runs through all the major functions in the system. Every step in the test script should be executed and exception noted.
• Integration test sign-off

–  An integration sign-off is required regardless of the size of the change.

–  The Integration test needs to be signed off by

•                IT project leader
•                Project manager
•                IT application team leader (If different from IT project leader).

User acceptance test

• User acceptance must have a pre-defined scope and it is to be executed based on a written script.
• Test script is to be done by users, business analyst, and IT coordinator ( optional) and must be approved by project manager.
• Test script must also include expected results so the actual test can be compared against the expected results.
• Sign-off : UAT must be signed off by the following :

–  Key users (or key user management)
–  Project owner
–  Project manger

• Migration (production move ) Rules and guidelines :

Production migration must be done by designated person responsible for application infrastructure support.

–  Schedule :

Migration is to be done on a fixed schedule basis. Tentatively this can be set to once per month. To avoid the month-end crunch, the migration date is set to the Wednesday that is closest to the middle of the month (the 15^th of the month).

–  Log :

A log must be maintained for all migrations. In the log the following information must be provided :

• Reason for migration.(reference to change request/project number)
• Requestor – This can be the programmer or project leader/manager.
• Programs, modules, script, and parameters that are being requested to be moved to production.
• Back-out contingency method
• Migration responsible person
• System manager signature
• Date and time the migration to occur.
• Notes

–   Back out contingency :

Migration must have a back out contingency in case of problem with the new release/software.

Back out contingency needs to be able to revert to the state before the changes were made. This process cannot take more than 1 hour to execute.