이상적으로는 주요 시스템 전환은 학교가 비교적 한산하고 교직원들이 교육할 시간을 확보할 수 있으며 학생들의 실시간 기록을 관리할 필요가 없는 여름 방학 동안 이루어져야 합니다. 그러나 현실적으로 학교는 기존 시스템의 실패, 긴급한 운영상의 필요성 또는 미룰 수 없는 전략적 결정 등으로 인해 학기 중에 플랫폼을 도입하거나 변경하는 경우가 많습니다.

학기 중 플랫폼 전환은 여름에 깔끔하게 시작하는 것보다 복잡하지만, 올바른 접근 방식을 사용하면 충분히 관리할 수 있습니다. 이 글은 학기 중에 플랫폼을 변경해야 하는 학교 관리자와 IT 관리자를 위해 시기, 단계, 데이터 연속성 및 커뮤니케이션에 대해 다룹니다.

연중 시스템 전환 시 가장 큰 위험은 데이터 연속성 확보입니다. 즉, 기존 시스템에서 생성된 기록이 전환 과정에서 손실되거나 중복되거나 접근할 수 없게 되는 것을 방지해야 합니다. 무엇보다 먼저 이 부분을 계획해야 합니다.

연중 전환이 정말 필요한가?

연중 출시를 확정하기 전에, 해당 결정에 대한 스트레스 테스트를 해보는 것이 좋습니다. 다음과 같은 질문들을 고려해 보세요:

• 현행 시스템이 완벽하지는 않더라도 학년말까지 버틸 수 있을까요? 만약 그렇다면, 여름에 전환하는 것이 위험 부담이 훨씬 적을 것입니다.
• 대기 시간으로 인한 비용은 무엇일까요? 직원 시간, 데이터 품질, 또는 운영상의 어려움 측면에서 말입니다. 만약 현재 시스템이 실제로 피해를 야기하고 있다면, 상황은 달라집니다.
• 학사 일정상 학기 사이 방학, 학기 경계, 성적 발표 주기 등과 같이 보다 안전한 전환 기간으로 활용될 수 있는 자연스러운 전환점이 있을까요?

첫 번째 질문에 대한 답이 '예'이고 기다리는 데 드는 비용이 감당할 수 있는 수준이라면, 여름 방학이나 학기말 방학까지 단계적으로 전환하는 방식이 일반적으로 더 바람직합니다. 학기 중 전환이 불가피한 경우에는 아래 프레임워크에 따라 진행하십시오.

전환 모델을 선택하세요

연중 플랫폼 전환에는 크게 세 가지 접근 방식이 있으며, 각 방식은 위험도와 복잡성 측면에서 차이가 있습니다.

급격한 전환

정해진 날짜에 기존 시스템은 폐기되고 새로운 시스템이 유일한 플랫폼으로 사용됩니다. 이는 소통과 관리가 가장 간편한 모델이지만, 전환일 이전에 새로운 시스템이 완벽하게 구성되고 모든 데이터가 이전되었으며 모든 직원이 교육을 완료했다는 확신이 필요합니다. 이러한 조건 중 하나라도 충족되지 않으면 상당한 위험이 발생할 수 있습니다.

병렬 실행

두 시스템은 일반적으로 2~6주 정도의 정해진 기간 동안 동시에 운영되며, 이 기간 동안 직원들은 업무 흐름을 새로운 플랫폼으로 점진적으로 전환합니다. 이는 위험을 줄여주지만 관리 부담을 두 배로 늘립니다. 직원들은 두 시스템에서 동시에 기록을 관리해야 하므로 피로도가 증가하고 두 시스템 간의 데이터 불일치가 발생할 가능성이 있습니다. 따라서 병행 운영은 시작 시점에 명확한 종료일을 설정해야 합니다.

기능별 단계별

새 시스템은 한 번에 하나의 기능이나 부서에 도입되고, 나머지 모든 기능은 기존 시스템을 유지합니다. 예를 들어, 입학 관련 업무는 OpenApply 로 이전되지만, 학기말까지는 기존 시스템을 통해 학적 관리가 이루어질 수 있습니다. 이러한 방식은 특정 부서에 대한 혼란을 최소화하지만, 전체적인 전환 기간을 연장시키고 두 시스템 간의 데이터 불일치를 방지하기 위해 세심한 조정이 필요합니다.

대부분의 연중 전환 과정에서는 위험도가 낮거나 시간적 촉박성이 덜한 영역부터 단계적으로 기능별로 접근하는 방식이 신중함과 진전을 동시에 달성하는 데 가장 좋은 균형을 제공합니다.

데이터 연속성 계획

시스템 전환을 하기 전에, 단순히 원칙만 제시하지 말고 다음 질문들에 대한 답변을 서면으로 작성하십시오.

학사일정 내 시기

연중 전환기라 하더라도 타이밍은 중요합니다. 어떤 시기는 다른 시기보다 훨씬 안전합니다.

• 성적 보고 기간을 피하세요 . 교사들이 성적을 입력하는 동안 성적표나 학사 관리 시스템을 변경하는 것은 위험 부담이 큽니다. 보고 주기를 고려하지 않고 계획을 세우세요.
• 학기 사이 방학을 활용하세요 . 일주일 정도의 방학이라도 시스템 전환, 데이터 검증 및 초기 문제 해결을 위한 부담이 적은 기간을 제공합니다.
• 입학 지원이 가장 많은 시기를 피하세요 - OpenApply 또는 유사한 입학 지원 플랫폼으로 전환하는 경우, 학교의 주요 입학 지원 기간은 피하는 것이 좋습니다.
• 시스템 도입 전 2~3주 정도의 직원 준비 기간을 두세요 . 연중 도입이라 하더라도 직원들이 실제 업무에 새로운 시스템을 사용하기 전에 교육을 받고 질문할 시간이 필요합니다.

팁 및 고려 사항

• 미리미리 자주 소통하세요 . 연중 시스템 변경에 당황하는 직원들은 준비 기간이 짧더라도 마음의 준비를 할 시간을 가진 직원들보다 더 부정적인 반응을 보입니다.
• 전환 기간 동안 프로세스를 관리하고, 질문에 답변하며, 문제가 발생할 경우 보고하는 책임을 맡을 전환 조정 담당자를 지정하십시오 . 이는 기존 정규직 업무에 추가되는 부가적인 역할이 되어서는 안 됩니다.
• 두 시스템을 동시에 운영하는 경우, 기존 시스템의 종료일을 명확히 설정하고 이를 공지하고 시행해야 합니다.
• 학교에서 Faria 플랫폼으로 전환하는 경우, 전환 기간 동안 FariaSupport 적극적으로 활용하세요 . 지원 플랜에는 구현 과정에서의 지원이 포함되어 있으므로 문제가 발생하기 전에 사전에 지원을 받는 것이 중요합니다.

요약하자면

• 여름철에 전환이 가능하다면 거의 항상 여름철 전환이 바람직합니다. 기다리는 데 드는 비용이 전환 비용보다 훨씬 더 클 경우에만 연중 중간에 전환을 진행하십시오.
• 위험 감수 수준과 운영 환경에 따라 하드 컷오버, 병렬 운영 또는 기능별 단계적 전환 모델 중에서 선택하십시오.
• 데이터 연속성 계획은 전환 전에 수립해야 합니다. 백업을 내보내고, 마이그레이션된 데이터를 검증하고, 롤백 계획을 정의해야 합니다.
• 학사 일정의 자연스러운 휴식 기간을 활용하여 전환 시기를 정하고, 성적 보고 기간 및 입학 성수기를 피하십시오.

FariaSupport 연중에 ManageBac+ , OpenApply , Atlas 또는 SchoolsBuddy 로 마이그레이션하는 경우에도 마이그레이션 계획, 데이터 유효성 검사 및 출시 지원을 통해 시스템 중단 위험을 최소화할 수 있도록 도와드립니다.

관련 기사

• 새로운 기술 도입을 위한 전교 차원의 변화 관리 계획을 수립하는 방법
• 학부모, 교직원 및 학생에게 시스템 변경 사항을 전달하는 방법
• 순조로운 새 학년 시작을 위한 준비
• 데이터 관리 모범 사례