ITSM Needs to Be Planned from the Organization\'s Overall Goals

· Insights

The purpose of the ITSM management system is to establish a system that enables IT work to adapt and self-optimize amid constantly changing external and internal conditions, rather than a rigid, fixed model. This requires digitizing the overall ITSM work process and resources, and ultimately forming data feedback is key.

Implementing the ITSM management system through software is not only to solidify the control points of management systems and the closed loop of workflows, but also to digitize work processes and resources. ITSM data digitizes business users\' experience, quantifies IT resource performance and promotes risk and incident management, and advances requirements and problem management. Through ITSM data feedback, assessment is promoted, and project construction and system development work are carried out.

Software digitizes the entire ITSM process, enabling continuous measurement of full-lifecycle data, assessment of key events, and guidance for establishing and tracking goals and plans. The “measurement,” “assessment,” and “guidance” of IT processes and resources form a closed loop of continuous construction and management using data.

Measurement

Measuring IT work allows management to learn about the occurrence of important events more promptly, improving the efficiency of assessment and decision-making. At the same time, quantifying work efficiency and visualizing work progress maximizes information sharing among relevant roles, promotes transparency, enables roles to understand each other\'s current status and changes, and facilitates more efficient collaboration among roles.

ITSM measurement should provide real-time feedback of high-level performance metrics to management. These metrics should cover three aspects: first, progress of requirements and projects; second, system incidents, problems, and existing risks; third, current process efficiency. For example:

  1. Count of projects with risks and difficulties, and projects with schedule deviations, by priority;
  2. Count of requirements not completed within the development plan, and current backlog of defects (technical debt), by priority;
  3. Count of new incidents today, current pending incidents, overdue incidents, incidents with no progress in 7 days, incidents with no progress in 30 days, and incidents with no defined cause, by priority;
  4. Current backlog of risks, count of unconfirmed risks, new risks today, risks with no progress in 14 days, and risks with no progress in 60 days, by priority;
  5. Count of unresolved problems, problems with no progress in 14 days, and problems with no progress in 60 days, by priority;
  6. Count of service requests with low satisfaction feedback and overdue service requests, by business department;

The above are high-level metrics. Each high-level metric can be drilled down to view related detailed secondary metrics. Metrics are fed back in two forms: first, via SMS, summarizing the day\'s information to management; second, via real-time dashboards for visual display.

Assessment

Important events identified during operations require special attention, and the “opportunities” and “risks” within these important events need to be assessed, including:

  1. Opportunities: important business requirements and possibilities for key technical improvements;
  2. Risks: reviews of major-impact incidents and incidents whose problems were not found, frequent problems and high-priority risks, and schedule deviations of important development and projects;

Collect and summarize these important events that need assessment in the current period as reference for assessment meetings.

  1. List important requirements to be assessed, requirements with development effort exceeding 20 days (Epic);
  2. List L1 and L2 major incidents (Major Incident) requiring review;
  3. List high-frequency problems (Problem) requiring assessment;
  4. List projects with high-level risks (Risk) and difficulties (Issue), or major schedule deviations;
  5. List high-level system risks (Risk) requiring assessment;

Guidance

Based on assessed decisions, establish goals and sub-goals in the system, and create subsequent projects and plans to track subsequent work progress and risks. “Goals” organize subsequent work into plans, while also clarifying the meaning of the plans. Through the cascade of “goals” and “sub-goals,” the progress of all work and the distribution of resources are summarized.

  1. “Goals” derive “projects,” e.g., new system construction and system replacement;
  2. “Goals” derive “continuous improvement plans” and “planned changes,” e.g., system optimization or preventive work;
  3. “Goals” derive “standard changes,” e.g., resource applications and parameter changes;
  4. “Goals” derive “development backlog items”;

IT management needs to implement process control points through technology-driven approaches, drive continuous improvement through process-driven approaches, and form data feedback through data-driven approaches.

Want to see how NI-System v7.0 solves your IT management challenges?

Book a demo, we tailor communication based on your industry and scenario