T-Minus: 시스템 가동, 하이퍼케어 및 T-Plus
T-0 시점의 상황, 일상적인 관리부터 흡수까지의 하이퍼케어, T-Plus 단계, 아티팩트 카탈로그, 프로젝트 계획 워크북 사용, 그리고 사전 준비부터 하이퍼케어 종료까지의 배포 체크리스트에 대해 설명합니다.
T-0: 진짜로 연습된 전환
- 기존 시스템은 합의된 마감 시간에 동결되고 읽기 전용으로 설정됩니다.
- 최종 마이그레이션 콕핏 적재 - 시간 측정 예행연습의 반복.
- 재무관리자가 시산표를 대조하고 서명했습니다.
- 통합 기능이 프로덕션 엔드포인트로 전환되었습니다.
- 사용자들이 로그인하면 첫 번째 송장이 시스템에 등록되는데, 보통 점심시간 전에 이루어집니다.
산출물: 전환 실행 기록부의 마지막 열, 서명된 대조표, 하이퍼케어 예외 로그 열기, 그리고 KPI(최초 청구서 발행까지 소요된 일수)입니다. 시간별 진행 순서는 모의 로드, 대조표 및 전환 실행 기록부를 참조하십시오.
기존 아카이브가 읽기 전용으로 전환된 후에도 쿼리 가능한 상태를 유지해야 합니다. 규칙 4는 기록이 마이그레이션되지 않고 계속 사용 가능한 상태를 유지하는 데 달려 있습니다.
하이퍼케어: 일상에서 흡수까지 (제안된 기본값)
| 언제 | 운율 | 집중하다 |
|---|---|---|
| T+1 → T+10 | 매일 15분 스탠드업 회의 | 어제 발생한 예외 사항, 수정 사항, 당일 구성 변경 사항 |
| T+11 → T+20 | 주 2회 | 동향; 첫 월말 결산 준비 |
| T+21 → T+30 | 흡수됨 | 정상 작동 리듬; T-Plus 파형 계획 |
| 예외 유형 | 예 | 담당자: |
|---|---|---|
| 게시 또는 조정 | 일치하지 않는 은행 한도, 미결제 잔액 | 재무 핵심 사용자 + 원장 설계자 |
| 사용자가 작업을 완료할 수 없습니다. | 허가 누락, 절차 불명확 | 입양 안내자(ASK, 역할 설정) |
| 통합 메시지 실패 | 은행 서류가 거부되었습니다. | Ops Pilot + 파트너 |
| 구성 변경 요청 | 새로운 승인 수준 | Ledger Architect, 같은 주 |
증거에 기반한 철저한 검토가 이루어지며, 날짜에 얽매이지 않습니다. 예외 사항은 5영업일 동안 임계값 미만이어야 하고, TRANXACT에서 첫 번째 월말 결산이 완료되어야 하며, 중대한 결함이나 심각한 결함이 없어야 합니다.
이것이 서비스 계약에 어떻게 적용되는지 설명드리겠습니다. T-Minus 하이퍼케어(T+1~T+30)는 방법론의 일부입니다. 합의된 기간(일반적으로 4~8주) 동안 매일 점검을 포함한 확장된 출시 후 지원은 역할 및 책임 워크북에 별도로 계약된 하이퍼케어 패키지(H1)입니다. 하이퍼케어 이후에는 출시 후: 서비스 운영에 설명된 안정 상태 서비스가 이어집니다.
T-Plus 웨이브(제안된 기본값)
Fit Ledger에서 T-Plus 백로그 확인 → 카운트다운 담당자와 우선순위 지정 → 웨이브별 미니 카운트다운 진행 → 변경 사항 예행연습 → 변경 사항 활성화.
| 범위 출처 | 추가되는 것 |
|---|---|
| 지연 적합 원장 라인 | 1차 출시된 모든 T-Plus 제품 라인을 가치 순으로 나열했습니다. |
| 더 많은 개체 및 지역 | 추가 법인, 통화 및 언어 |
| 추가 모듈 | 제조, EHR, 학생 생애주기, HRMS를 토글 스위치로 활용 |
| 기간 및 기록 보관소 후속 조치 | 새 보고서에 필요한 경우 추가 기간 잔액 |
하이퍼케어가 종료되기 전, 카운트다운 팀이 아직 함께 있을 때 첫 번째 T-Plus 단계를 계획하십시오. 각 단계는 동일한 Fit Ledger, 계획 및 산출물을 재사용합니다. 성장은 재구현을 유발하지 않으며, 측정 기준은 재구현 없이 분기별 활성화된 모듈 수입니다.
유물 목록
| 인공물 | 생성됨 | 소유자 | 어디 |
|---|---|---|---|
| 카운트다운 프로젝트 계획 (소스 시스템별) | 티-27 | 비행 선두 | 프로젝트 계획서 · 출처별로 한 장씩 |
| 비행 전 및 배치 체크리스트 | 비행 전 | 비행 선두 | 툴킷 · 배포 체크리스트 |
| 핏 레저 | T-27 → T-18 | 카운트다운 소유자 | 툴킷 · 핏 레저 |
| 마이그레이션 범위 결정 및 객체 등록 | 티-24 | 마이그레이션 지휘자 | 툴킷 · 마이그레이션 범위, 객체 레지스터 |
| 구성 워크북 | T-17 → T-11 | 원장 설계자 | 툴킷 · 구성 워크북 |
| 테스트 계획 및 스크립트 | 티-17 | 원장 설계자 | 툴킷 · 테스트 계획 |
| TB 및 보조원장 대조 | 티-10 → 티-0 | 재무 관리자 | 툴킷 · 시산표 대조, 보조원장 대조 |
| 전환 실행 계획서 | 티-8 | 마이그레이션 지휘자 | 툴킷 · 전환 실행 설명서 |
| 리허설 대본 및 진행/중단 게이트 | T-5 → T-1 | 카운트다운 소유자 | 툴킷 · 리허설 대본, 합격/불합격 판정 |
| 도입, 변화의 영향, 이해관계자, 커뮤니케이션 | T-27에서 | 입양 안내자 | 툴킷 · 4장 |
| RAID, 카운트다운 보드, 하이퍼케어 로그, T-Plus 백로그, KPI | T-27 → T+30 | 비행 선두 | 툴킷 · 5장 |
프로젝트 계획 통합 문서 사용
- 설정 시트에 서비스 개시일과 공휴일을 입력하세요. 그러면 모든 작업 날짜가 해당 T-day를 기준으로 근무일 기준으로 계산됩니다.
- 고객의 소스 시스템에 대한 시트는 유지하고, 나머지는 삭제한 다음, 두 번째 인스턴스(예: 두 개의 회사 코드 그룹)가 있는 경우 시트를 복제하십시오.
- TRANXACT 팀과 고객을 담당자로 지정하고 작업별 상태를 추적하세요.
- 대시보드를 매일 확인하세요. 소스별 출시까지 남은 근무일수, 완료된 작업 및 기한 초과 작업, 모든 소스의 게이트 상태를 확인할 수 있습니다.
배포 체크리스트
| 비행 전 | (T-27→T-18)을 찾아보세요 | 구성(T-17→T-11) | T-11번 게이트 |
|---|---|---|---|
| 계약 및 감사된 수익 | 각자의 역할에서 핵심 사용자 | 구조 및 자금 구성됨 | 모든 구성 작업이 완료되었습니다. |
| 보드에 게시된 출시 날짜 | Fit Ledger 태그 및 서명 완료 | 역할 및 승인 | T-Plus 목록 합의됨 |
| 카운트다운 소유자 및 비행 책임자 | 객체별 마이그레이션 범위 | ASK를 통한 마스터 데이터 | M1 매핑 서명됨 |
| 테넌트 프로비저닝, SSO | 첫 번째 시도에서 변경 사항의 영향 | 통합 및 대기열 | 테스트 계획 완료 |
| 기존 추출 액세스 | 통신 T-27 및 T-18 전송됨 | 구성 검사 통과 | 리허설 역할이 알려졌습니다 |
| 전환 (T-10→T-3) | 리허설 (T-2→T-1) | 정식 출시(T-0) | 하이퍼케어(T+1→T+30) |
|---|---|---|---|
| M1과 M2가 장전됨 | 실제 하루 대본대로 진행됨 | 기존 파일은 동결되어 읽기 전용입니다. | 일일 예외 상황 보고 |
| TB 차이 0, 하위 원장 연결 | T+1의 모든 사용자가 참여했습니다. | 최종 적재량 확인 및 서명 완료 | 첫 번째 월말 마감 |
| 통합 및 역할 테스트 | 결과는 기존 방식과 일치합니다. | 운영 엔드포인트가 활성화되었습니다. | KPI 기록됨 |
| 윈도우 내에서 드라이런 시간 설정 | 수정 목록은 당일 마감되었습니다. | 사용자 활성화됨, 통신 전송됨 | T-Plus 1차 계획 |
| 연속성 검사 완료 | GO는 증거와 함께 기록되었습니다. | 첫 번째 송장 게시됨 | 하이퍼케어 탈퇴 서명 완료 |
언제 서비스를 시작하나요? 애초에 프로젝트 기간은 중요하지 않았습니다. 날짜를 정하고 카운트다운 담당자를 지정하세요. 사전 점검을 완료하고 시작 27분 전부터 시간을 재기 시작하세요. 필요한 소스 시스템 시트를 복사하고, 콘솔에서 모든 스탠드업 미팅을 진행하세요. 그리고 리허설을 통해 날짜를 결정하세요.
제안된 기본값으로 표시된 값은 해당 방법론에서 권장하는 시작점입니다. 각 작업별로 값을 확인해야 하며, 계약서, 주문서 및 서비스 수준 계약(SLA)이 우선합니다.