Should Standard Change procedures be stored in the CMDB

By ITIL® from Experience©

By definition a document can also be a Configuration Item1 . Although most ITSM tools can attach a document/file to a Configuration Item (CI) record, many cannot control access to CI records in the CMDB based on roles or without creating security zones which increases the complexity of the tool’s administration and usage. As a result detailed procedures that include administrator passwords or instructions to modify firewall ports should not be included in procedures unless they are stored outside of the CMDB. Since most ITSM Tools supports hyperlinks (i.e. URL) a workaround is to have a hyperlink in the CI record to the document stored in a third party external repository.

Another reason to store procedures externally to the CMDB is that many ITSM tools do not have the required functionality to manage the lifecycle of a document without customization (See Why a process to maintain standard changes should be implemented). Thus, if the ITSM tool cannot support the maintenance process have a URL in the CI record link where it is stored and use that repository's functionality to manage its lifecycle. For this reason using group-based network shares or Collaboration portals are usually not suitable while a Records and/or Document Management System (RDMS) are well suited to the task since they can usually kick off a workflow and assign tasks to the document author when the review date has been reached (see What is the content of a standard change). These tools usually have access controls based on roles and group memberships to restrict access.

The following should be considered when deciding where to store Standard Change procedures:

Will people have read-access to the procedures they need and prevented to access restricted procedures?
Can authors have permissions to only modify their procedures and not others?
How and who will manage and control access permissions?
If stored outside of the CMDB, will the hyperlink between the CI be broken if the document is reclassified (e.g. moved) or renamed in the repository?
Does the repository have the required functionality to manage the maintenance and lifecycle process for Standard Changes?
Does the repository enable the Change Management process to comply with the organization's information/records retention policies?
Are additional licenses required to use that repository?

Regardless of the system used, leverage when possible what is already in place. However, the solution must not only meet the standard change process requirements but it should also be well used and accepted in the organizations. If the RDMS has adoption problems you may need to consider other options to achieve success and discipline with Change Management. Otherwise change management will inherit that tool’s resistance as well.

At minimum, the Standard Change procedure should have a record in the CMDB regardless if it's document is sotred in it or not.

Plugin disabled

Plugin footnotearea cannot be executed.

Disclaimer

<HR>