I need to establish a software change control procedure for the release of Lawson process flows into Production. Unfortunately, a Lawson process flow could consist of customized triggers written through Design Studio or COBOL, the enabling of services, creation of tasks, and the upload of a PF into the server. The idea of creating a second process flow that will act as the Installer for the first process flow could create the tasks and service criteria but still can’t release the entire PF package. I was also thinking to develop an Installation Qualification document (IQ), detailing all the steps to follow in Production prior to uploading the xml into the server, this way it could meet auditing requirements. Could you please advice on how to release process flows into production, under Change Control, where the PF developer can’t release his/her process flows?.
Thank you,
Gaston
Mark,
That is a good idea to speed up the approval process for low-level Change Controls based on the impact to the Production system with minimum risk.
A Change Control for a process flow could consist of xml, task, services, HTML inbox view, custom triggers …etc. Do you allow the Process Flow developer releasing the Change into production, or do you have somebody else do it to avoid any conflict of interest? We are considering having the System Administrator in charge of releasing process flows into production and not the process flow developer. Also, are your process flow developers connecting to the production system with the security role assigned of Process Flow Administrator?