Pamahalaan ang isang Pagbabago sa Engineering

Magbukas ng management-of-change record para sa iminumungkahing pagbabago at sabihin nang malinaw kung ano ang nagbabago, bakit, at ang risk sa kaligtasan, operasyon, at disenyo na taglay nito. I-route ito para sa review bago galawin ninuman ang trabaho.

Bakit: Ang mga pagbabago sa engineering na lumalaktaw ng control step ang dahilan kung bakit isang mabuting-hangaring ayos ay natatapos na hindi ligtas o hindi compliant. Ang rekord ang patunay na sinuri ang risk at pinahintulutan ang pagbabago, hindi lang basta ginawa.

Magtaas ng RFI para sa bawat bukas na tanong teknikal na binubuksan ng pagbabago, dimensyon, interface, specification, at hilingin sa designer na sumagot nang nakasulat bago ma-fix ang detalye. Panatilihing nakatali ang bawat RFI pabalik sa pagbabago.

Bakit: Ang pagbabagong binuo sa isang assumption ay rework na naghihintay lang mangyari. Ang pagkuha ng sagot sa rekord, mula sa taong responsable sa disenyo, ang pumipigil sa parehong tanong na muling pagtalunan sa site.

Kung igagalaw ng pagbabago ang gastos o oras, magtaas ng change order na kumukuha sa napresyuhang epekto at epekto sa programa, na naka-link pabalik sa rekord ng pagbabago. Kung talagang walang epekto, itala rin iyon.

Bakit: Ang engineering side ay maaaring maisara at maiwan pa rin bukas ang pera. Ang change order ang gumagawang napagkasunduang gastos at ginalaw na petsa mula sa isang authorized na pagbabago, bago ito tahimik na maging problema mo.