Policies are high-level organization-wide practices. Processes are generically specified by service management best practices and standards, with automation in mind to implement their logic and enforce their use. Procedures and consequent work instructions specify the human implementation of polices and processes. Policies can be written in DITA as collections of concept and reference topics, arranged in maps that reflect a logical hierarchy of corporate wide expectations of (IT) staff, and possibly corporate regulations in dealing with clients and business partners.
Procedures lend themselves to what DITA has been used for most since its inception. In spite of being a generic document architecture, DITA started with the task topic in mind, to support user, technical, and developer help guides of arbitrary complexities. task topic skeletons are very rich with elements that support sub-tasks and steps (for work instructions), pre and post requisties, results, and many more. Task topics are an excellent means of documenting, publishing, and managing corporate service provider procedures; specially those followed by contact center agents and tier-1 and 2 support staff, who are often not technical enough to action problem management spontaneosuly. The flexibility of easy single-sourced updates and the extensive linking capability make a very good case for ITSM procedures being implemented as DITA task topics.
Processes are probably the element that receives least added value of existing DITA topics. A process is a sustained activity with states, transitions, use cases, and instances. In ITSM contexts, they are often implemented as intranet applications/services. Process description is usually carried using UML activity diagrams. Other UML constructs are used to specify the correpsonding software implementation. Although there have been few debates, current DITA domain-specific (software) information types do not support UML constructs. They are rather geared towards documenting user interface constructs.
The application of DITA towards the actual organizational specification of P&P may be a contributor in more than one facet: from actual documentation of existing or evolving content, through acting as empty templates preset to support different practices, all way to being further specialized to name new elements that match a service provisioning branch of knowledge or a particular large organization (e.g. governmental) P&P naming and documenting conventions.