Predecessors/Before You BeginBefore you begin, you will need some form of change management, so that procedures can be ratified. Stakeholders need to agree on how procedures are approved. Also, consider creating a "procedure procedure" that defines how procedures are created, modified, and removed. For example you may wish to have a step where procedures are reviewed for style, before they are approved. Writing ProceduresITSM best practices are predicated around written processes. These written procedures allow IT departments to have a standard, defined method of performing tasks. However, when it comes to the actual act of writing procedures, there's not much material available. Another challenge in procedure writing is that there are various levels of processes and procedure granularity. A higher-level, "value chain" view of a department can be decomposed into several processes and sub-processes. Wake Forest University's Information Systems department has created a procedure template that we use internally. Several versions of this template are attached below; "FV2" is the latest version. Please feel free to modify and use this template as needed when writing procedures. If the people writing a procedure are not going to maintain the procedure over time, the procedure authors should take care to fill out the template's "procedure owner" section. There should be a clear hand-off of the procedure to its operational owner after the procedure is ratified. Contacts and ResourcesITIL v3's Service Design book has an appendix that briefly states some recommended sections for documented processes and procedures.
|
|||||||||