ITSM is a core process area of IT service management based on ITIL Best Practices. It consists of various processes such as service request, change management (application and infrastructure), incident management, and problem management. Each process has its own unique characteristics and objectives, and all processes operate in an integrated manner—this is the defining feature of ITSM.

In this article, I will focus on Application Change Management, which can be considered the core of ITSM, and explain it based on a real-world implementation case from the “IT Service Management Culture Improvement Project” for Company A Life Insurance.

Purpose of Application Change Management

The goal of this process is to establish methods and procedures that ensure all changes occurring during IT service operations are standardized, efficient, and quick, while minimizing the impact of changes. It also aims to provide a systematic approach for resolving issues that extend from incidents to problems and changes, effectively supporting other processes.

Company A previously used the ADAMS system for application change management, but due to operational issues and the need for improvement, the company initiated a project to upgrade to our E-GENE ITSM solution. Key issues included:

- Dual system structure: business requests via groupware, actual processing in ADAMS

- Lack of clear requirements and difficulty tracking history

- Need to redefine change types and processing standards

- Absence of development effort estimation standards

- Need for flexibility in change processes

- Enhanced user convenience

Types of Application Change Management

Company A categorized changes into:

- Development requests

- Business requests

- Data changes

- Report generation

- Large-scale data extraction

Among these, development requests and data changes are the most frequently used and critical for application system development and operations. Let’s examine how these were improved through process implementation.

Development Requests

Development requests occur when source code modifications or new development are needed for a business system. This is the most complex and frequently used process type.

The overall process flow:

Request → Acceptance → Analysis & Design → Development → Testing → Verification → Validation Testing → Deployment

The ultimate goal is the operational deployment of source resources. During the process, a change plan is created, and depending on the impact, the request goes through CAB (Change Advisory Board) review. At specific stages, integrations occur with other systems for configuration management and source code vulnerability checks.

Configuration management handles check-in/check-out of source resources, version control, and tracking changes to resource lists. Thus, ITSM (which controls change procedures) and configuration management (which controls source resources) are closely linked.

[Figure 1: Development Request Process]

As shown above, Company A’s development request process includes integration with source code vulnerability checks, followed by security review. A dedicated Testing Group (TEG) conducts specialized testing of developed and deployed content, strengthening security and testing.

Data Changes

Data changes occur when operational data in business systems needs modification. While the process is simpler than development requests, it is critical due to the sensitivity of operational data.

Approval requirements (e.g., IT auditors) are stricter, but the overall flow remains straightforward. During processing, integration occurs with the data ledger change system, enabling actual data modifications.

[Figure 2: Data Change Process]

As shown above, Company A’s data change process includes IT auditor approval. The ITSM interface displays results from the data ledger change system, and if no integration result exists, the process is blocked—ensuring control.

Integration with Other Systems

Application change management focuses on procedural control, but functional execution requires integration with multiple systems. As shown below, integrations occur with configuration management, metadata, ERD modeling, application impact analysis, source vulnerability checks, batch management, data ledger changes, and file transfer systems at various stages.

[Figure 3: Integration with Other Systems]

Although this article covered only development requests and data changes, application change management is a complex process requiring multiple integrations. However, understanding ITIL’s objectives and key tasks beforehand greatly aids implementation.

In this project, I leveraged ITIL principles and knowledge from previous implementations to quickly understand user needs and configure processes flexibly for Company A.

Since application change management processes and integration methods are often similar across ITSM projects, documenting the overall flow can be highly beneficial for future implementations. Of course, understanding ITIL’s conceptual foundation remains essential.

STEG Solution Service Division – PS1 Team, Taemin Jeon