병행입양
Parallel adoption |
병행채택은 조직의 대상(IT) 시스템으로 이전하는 방식이다. 리스크를 줄이기 위해, 구식 시스템과 신식 시스템은 일정 기간 동안 동시에 운영되며, 이후 새로운 시스템의 기준을 충족하면 구식 시스템은 비활성화된다. 그 과정은 세심한 계획과 통제를 필요로 하고 노동시간에 상당한 투자를 해야 한다.
개요
이 항목은 병렬 채택의 일반 프로세스에 초점을 맞춘다. (실제) 예는 필요한 경우 프로세스의 더 의미 있는 해석에 사용된다. 또한 프로세스 데이터 모델은 병렬 채택에 관련된 모든 단계의 전체 개요를 제공하기 위한 프로세스를 시각화하는 데 사용되지만, 병렬 채택의 고유한 특성에 중점을 둘 것이다. 네 가지 일반적인 채택 유형 모두에 적용되는 구현 전략을 정의하는 몇 가지 일반적인 특성은 채택(소프트웨어 구현)에 설명되어 있다.
기타입양종류
병행 채택 외에도 세 가지 다른 일반 채택 종류를 확인할 수 있다. 특정 채택 방법에 대한 선택은 조직의 특성에 따라 달라진다. 이 주제에 대한 더 많은 통찰력이 아래에 제공될 것이다. 세 가지 다른 채택 방법은 다음과 같다: 제품 소프트웨어 채택: 빅뱅 채택(직접 전환, 슬램덩크 또는 콜드터키 전략이라고도 함), 단계별 채택 및 파일럿 채택.
- 제품 소프트웨어 채택: 빅뱅 채택/확장 채택: 빅 뱅 채택은 조직 전체를 이전 시스템에서 새로운 시스템으로 즉시 전환하도록 한다. 이것이 가장 저렴한 선택이지만 만약 새로운 시스템이 실패한다면, 그 조직은 큰 곤경에 처하게 된다. 그것은 또한 시스템이 사용자들에게 받아들여지지 않을 위험을 열어준다. 그러나 두 시스템이 공존할 수 없거나 새로운 시스템을 활성화하는 것이 비상사태일 때 취할 수 있는 유일한 접근법일 수 있다.
- 단계적 채택(단계적 전환이라고도 함): 단계별 채택 구현에서, 조직은 모듈이나 하위 시스템별로 다른 단계별로 점차 새로운 시스템으로 이전하고 있다. 일부 시스템은 전체 시스템에 너무 의존적이기 때문에 조각조각 도입될 수 없다. 단계적 채택을 사용하면 리스크는 적지만 기존 시스템에서 새로운 시스템으로 이전하는 데 가장 많은 시간이 소요돼 가장 큰 차질을 빚는다.
- 파일럿 채택: 시범입양 방식은 여러 개소나 독립부서가 많은 대규모 조직에 활용된다. 새로운 시스템은 위치나 부서 중 하나에 도입되고 시간이 지남에 따라 다른 위치나 부서로 확장된다. (새로운 시스템이 고장인 경우 제한적 경계) (터번, 2002)
병렬 변환을 실행 가능한 변환 전략으로 간주할 수 없는 몇 가지 경우가 있다. 먼저 새 시스템에 상당한 스키마 변경 사항이 포함되어 있는지 고려하십시오. 다른 시스템에 의해 채워지지 않는 한 시스템에 의해 요구되는 데이터 요소는 기껏해야 데이터의 부정확성과 최악의 데이터 손상으로 이어질 수 있다. 또 다른 우려 사항은 시스템이 소비자에게 의존하는 경우(COTS)이다. COTS 공급업체의 문서에 둘 이상의 애플리케이션이 동일한 데이터베이스를 공유할 수 없다고 명시되어 있는 경우, 병렬 변환은 옵션이 아니다. Oracle의 Siebel 제품이 그 예일 것이다. 패치 또는 주요 업그레이드에 고유한 라이센스 키가 필요한 경우 다른 COTS 제품도 제한을 둘 수 있다. 일단 적용되면, 그들은 응용 프로그램이 동일한 데이터베이스에 대해 실행 중인 병렬 시스템을 라이선스 제어를 이용하려는 시도로 잘못 탐지하여 시스템을 비활성화할 수 있는 데이터베이스 변경을 할 수 있다.
구현 프로세스 배치
병행입양 과정에 대한 관례는 거의 없는 것 같다. 여러 출처(예: 터번, 2002, Eason, 1988, Rooijmans, 2003, Brown, 1999)은 하나의 프로세스 설명 이름을 사용하지 않는다. 병렬 채택이라는 용어는 병렬 변환, 병렬 실행, 섀도 실행, 병렬 컷오버 및 병렬 구현과 같이 각 소스별로 일관되기는 하지만 이러한 소스에서 언급된다. 공정에 대한 일반적인 설명은 구별되는 분류를 필요로 하지 않기 때문에 이러한 경우가 있는 것으로 보인다. 다른 채택 기법이 설명되지만 종종 실제 상황에서 다른 채택 기법이 설명되는 표준 구현 방법들이 꽤 있다; 실제 사례 시나리오 또는 Regatta와 같은 보다 포괄적인 구현 기법 집합: 채택 방법, SIM 및 PRINS2. 일반적으로 병렬 채택은 새로운 시스템의 구현을 위한 시스템 엔지니어링 방법으로 가장 잘 볼 수 있다.
원칙적으로 병행채택 방식은 조직 내 시스템 변경 결정과 다르며 그 목표를 달성하기 위한 하나의 가능한 수단으로 볼 수 있다. 그러나, 최선의 이행 전략을 결정하는 데 고려되고 있는 몇 가지 요인들이 있다. 더욱이 성공적인 구현은 채택 방법에 크게 좌우될 수 있다. (리, 2004)
프로세스
병렬 채택 프로세스는 실제 전환 전 단계, 즉 전환 시나리오의 구축과 모든 요구 사항의 식별 및 시험에 주의를 기울이지 않고는 나타낼 수 없다. 따라서 이 프로세스는 식별된 변환 전략 중 하나에 필요한 공통 활동을 간략하게 다루면서 그림 1의 식별된 모든 프로세스를 통해 설명된다.
그림 1은 병렬 채택 프로세스의 개요를 보여준다. 왼쪽은 그 과정에 기여하는 활동의 흐름을 그린다. 동시에 진행되는 활동에는 굵은 블랙 라인이 선행된다. 활동의 병렬적인 실행이 끝나면, 그 활동들은 유사한 검은 선으로 다시 결합된다. 활동에서 다른 활동으로의 화살표가 없을 때, 이것은 그들이 위의 더 큰 활동의 집합체임을 나타낸다. 활동은 크게 네 가지 단계로 나뉜다.
- 실행해야 하는 구현 전략의 종류를 다루는 구현 전략을 정의한다.
- 사전 구현. 구현에 관련된 모든 측면과 요구 사항에 대한 계획을 수립하는 것과 관련이 있다.
- 조직 준비 이전 단계에 따라 조직을 적절하게 준비해야 한다.
- 변환은 실제 변환 프로세스와 변환 프로세스를 종결하는 것을 다루고, 새로운 시스템을 진행한다.
주요 단계는 표 1-1에서 1-4에 간략하게 설명될 다른 활동에서 세분된다.
모델의 오른쪽은 프로세스에 관련된 데이터를 설명한다. 겹치는 열린 직사각형의 한 쌍으로 묘사되는 이러한 개념들 중 일부는 둘 이상의 개념으로 세분될 수 있다. 겹치는 닫힌 직사각형의 쌍은 닫힌 개념을 나타내며, 이는 더 많은 개념으로 세분될 수 있다는 것을 의미하지만, 병렬 채택 과정에서는 더 이상 관심이 없다. 다이아몬드 모양 도형은 그것과 연결된 개념, 총체적인 개념의 역할을 하며 이 개념들이 다른 개념들로 구성되어 있음을 나타낸다. 마지막으로 열린 화살표는 슈퍼 클래스 하위 클래스 관계를 나타낸다. 화살과 연결된 개념은 그것과 연결된 개념의 슈퍼클래스다. 그림 1의 이 구문은 UML(Unified Modeling Language) 표준에 따른 것이다. 그림 1의 개념은 표 2에 정의되어 있다. 프로세스에서 이러한 하위 활동에 대한 더 많은 컨텍스트가 표 아래에 제공될 것이다.
| 활동 | 설명 |
|---|---|
| 구현 전략 정의 | 이행 전략은 이 초기 단계에서 결정된다. (브라운, 베시, 1999) |
| 마스터 구현 스크립트 작성 | 첫 번째 초기 요구사항 분석이 수행되며, 아래 요구사항으로 구성된다. (벤처, 2004) |
| 시간 계획 구성 | 이행 프로세스의 첫 번째 시간 계획이 수립되고 있다. (Roijmans, 2003) |
| 조직 요구 사항 정의 | 조직 요건은 여기에서 정의된다(Roijmans, 2003). |
| IT 요구사항 정의 | IT 요구사항 결정(Roijmans, 2003) |
| 활동 | 설명 |
|---|---|
| 설치 요구 사항 | 조직을 준비하기 위해 규정된 요건을 설치한다. 조직은 준비되고 있으며 IT는 테스트 기계에 설치된다. (Roijmans, 2003, Eason, 1988, Microsoft, 2004) |
| 시험요구사항 | 요구 사항을 테스트하여 조직이 구현 준비가 되었는지 확인한다(Roijmans, 2003). |
| 마스터 구현 스크립트 재정의 | 마스터 이행 대본은 아래의 활동과 함께 새로운 정보를 수집하여 정비한다. (Roijmans, 2003) |
| 기준 지표 정의 | 새로운 시스템을 테스트하기 위해 기준 지표가 만들어지고 있다. (Roijmans, 2003, Microsoft, 2004) |
| 해결 방법/롤백 계획 수립 | 또한 롤백 시나리오가 있는 해결책이 만들어진다. 이러한 계획으로, 조직은 각각 프로세스의 특정 단계에서 구현이 실패할 경우 발생하는 실수 및 후퇴를 시정할 수 있다. (Microsoft, 2004, Roijmans, 2003) |
| 수행(세그먼트) 시험전환 | 매우 복잡한 조직에서는 "실행"하기 전에 테스트 전환을 수행하는 것이 유익할 수 있다. (Microsoft, 2004, Roijmans, 2003) |
| 활동 | 설명 |
|---|---|
| 따라잡기 | 변환 프로세스가 시작되고 여러 활동이 병렬로 실행된다. 이 단계에서 캐치 업은 구식 시스템을 사용하여 만들어지고 있다. 구식 체계가 앞서고 있지만, 새 체제는 평행하게 달린다. 시스템의 모든 변화는 새로운 시스템에 적용되어야 한다. (Microsoft, 2004, Roijmans, 2003) |
| 제어 시스템 | 그 시스템은 항상 제어 시스템에 의해 제어되고 있다. 정의된 지표와 시스템 실행 특성으로 오류와 실수가 추적된다. (Microsoft, 2004, Roijmans, 2003) |
| 선행 기존 시스템 실행 | 구식 시스템이 주도하고 있다; 실제 데이터를 처리한다. |
| 새 시스템 실행 | 새 시스템은 구 시스템과 병렬로 작동하며 면밀하게 모니터링된다. (Microsoft, 2004, Roijmans, 2003) |
| 새 시스템에서 캐치업 번역 | 기준을 충족하면 새로운 시스템에서 캐치업(catch up)을 번역·이전하고, 전환과정은 그 다음 단계로 들어온다. (Microsoft, 2004, Roijmans, 2003) |
| 해결 방법/롤백 전략 실행 | 기준을 충족하지 못하면 오류의 특성에 따라 해결 전략이나 롤백 전략이 수행된다. (Microsoft, 2004, Roijmans, 2003) |
| 따라잡기 | 캐치업(catch up)은 새 시스템이 선두에 설 때에도 안전을 위해 만들어진다. (Microsoft, 2004, Roijmans, 2003) |
| 이전 시스템 실행 | 이전 시스템은 안전을 위해 백업으로 실행됨 |
| 선도적인 새 시스템 실행(1) | 그 새 시스템은 선도적이고 완전하게 운영되고 있다. 모든 거래와 시스템의 변경은 여기서 처리되고 있다. (Microsoft, 2004, Roijmans, 2003) |
| 활동 | 설명 |
|---|---|
| 선도적인 새 시스템 실행(2) | 모든 캐치업과 제어장치가 폐쇄되었다. 새 시스템은 가동 중인 유일한 시스템이다. (Microsoft, 2004, Roijmans, 2003) |
| 이전 시스템 사용 안 함 | 구식 시스템은 더 이상 필요하지 않고 사용할 수 없다. (Microsoft, 2004, Roijmans, 2003) |
그림 1의 개념은 아래 표 2-1에 정의되어 있다.
| 개념 | 정의 |
|---|---|
| 구현 전략 | 새로운 시스템을 구현하기 위해 선택될 전략. 옵션은 빅뱅, 단계별, 병렬 채택, 파일럿 전환 또는 이들 4개의 조합이다. (터번, 2002, Roijmans, 2003) |
| 구현 스크립트 | 조직 요구사항, IT 요구사항 및 초기 시간 계획으로 구성된 실제 전환 시나리오의 원시 버전. (Venture, 2004, Eason, 1988) |
| 조직 요구 사항 | 성공적인 구현을 위해 존재해야 하는 조직 내부의 요구 사항. 그들은 새로운 시스템을 위한 조직을 최적화하는 것을 다룬다. 관련된 문제는 다음과 같을 수 있다. 인적자원관리, 조직문서의 변화, 새로운 사업구조. (Rooijmans, 2003) |
| IT 요구사항 | 정보 기술 요건은 예산과 기존 시스템을 고려한 소프트웨어 및 하드웨어 요건, 플랫폼 선택이다. (Roijmans, 2003) |
| 시간 계획 | 활동을 완료해야 하는 기간을 할당하여 가능한 시간에 대한 실행 프로젝트의 전체적인 그림을 제공하는 계획. (Eason, 1988) |
| 요구 사항들 | |
| 적합성 | 순응은 모두 요건을 충족시키는 것이다.(ISO 9000) |
| 전환 시나리오 | 요구사항의 적합성을 고려하여 재 정의한 구현 스크립트. 더욱이 전환 시나리오는 해결책과 롤백 계획으로 구성된다. 전환 시나리오는 이행 프로젝트의 청사진이다.(Roijmans, 2003) |
| 해결 전략 | 변환 시나리오에서 백업 계획, 변환 프로세스의 오류를 방지하고 이러한 프로세스에서 작업을 시도하여 구현이 여전히 성공할 수 있도록 하기 위한 전략. (Roijmans, 2003) |
| 기준지표 | 요구사항과 관련하여 수량화 가능하고 측정 가능한 기준, 구현 프로세스의 성공 여부 판단(Roijmans, 2003) |
| 롤백 계획 | 데이터나 정보의 손실 없이 이전 시스템으로 되돌아가기 위해 복제의 방향을 되돌리는 것을 용이하게 하는 계획. (마이크로소프트, 2004) |
| 시험전환 | 부분 테스트 변환은 실제 변환이 이루어지기 전에 실제 변환 프로세스의 불확실성 또는 문제에 대해 더 잘 대비하는 것을 목표로 한다. (마이크로소프트, 2004) |
| 구제도 | 이전 시스템: 선행 = 참일 때, 이전 시스템이 시스템 트랜잭션을 실시간으로 처리함: 제품을 구성하는 주요 기능 개체(예: 하드웨어, 소프트웨어) 또한 과제(예: 실패 보고 시스템)를 달성하기 위한 체계적이고 규율적인 접근방식(ISO 9000) |
| 새로운 시스템 | 새 시스템(골): 새로운 시스템은, 선두가 될 때, 진실일 때, 새로운 시스템은 시스템 거래를 실시간으로 처리한다. 제품을 구성하는 주요 기능 개체(예: 하드웨어, 소프트웨어) 또한 과제(예: 실패 보고 시스템)를 달성하기 위한 체계적이고 규율적인 접근방식(ISO 9000) |
| 컨트롤 | 성능 지표와 신뢰성 평가 및 캐치업으로 구성된 전반적인 제어 시스템. 제어 시스템은 매우 광범위하며, 병렬 채택 과정에서 구형 시스템을 변환하고 새로운 시스템을 관리하는 중앙 명령 시스템이다. (Roijmans, 2003, Microsoft, 2004) |
| 퍼포먼스 | 구형 및 신형 시스템의 성능에 대한 계량 가능한 평가는 제어 시스템의 입력 역할을 한다. (Roijmans, 2003) |
| 신뢰성평가 | 제품, 시스템 또는 그 부분의 신뢰성에 대한 정량적 평가. 이러한 평가에는 일반적으로 수학적 모델링, 제품에 대한 테스트의 직접 적용 가능한 결과, 고장 데이터, 추정 신뢰성 수치 및 비통계적 엔지니어링 추정치가 사용된다. (ISO 9000) |
| 따라잡기 | 캐치업(catch up)은 이전 시스템을 사용하여 시스템의 자동 또는 비자동으로 생성된 백업으로 구성되며, 이 백업은 새 시스템에서 번역된다. (Roijmans, 2003) |
| 자동 캐치업 | 자동으로 생성된 캐치업(Roijmans, 2003) |
| 손으로 따라잡다 | 수동 입력으로 생성된 캐치업(Roijmans, 2003) |
병렬 구현 전략 결정
병행채택은 병행채택을 위한 고유성이 아니라 조직이 진입하는 변경관리 프로세스의 일환으로 볼 수 있는 이행전략의 결정에 선행한다(이, 2004). 채택 방법에 관한 구현 전략을 결정하는 데 관련된 몇 가지 요인은 채택(소프트웨어 구현)에 더 자세히 설명되어 있다.
리스크 대 비용
조직이 파일럿 전환, 빅뱅 또는 단계적 채택을 위해 병렬 채택을 선택하는 이유는 종종 비용과 위험 사이의 절충이다(Andersson, Hanson, 2003). 가장 비용이 많이 드는 채택 방법(Chng, Vathanopas, 2002, Microsoft, 2004, Anderson 등, 2003)을 병행 채택하는 것은 두 시스템이 일정 기간 동안 병렬로 실행될 것을 조직에 요구하기 때문이다. 두 개의 시스템을 동시에 운영한다는 것은 인적자원에 대한 투자가 이루어져야 한다는 것을 의미한다. (추가)인력을 잘 준비하는 것 외에, 절차가 서로 교차하는 평행운행이라는 스트레스를 받는 시기를 겪어야 하는 것. (Roijmans, 2003, Eason, 1988) 두 시스템 간의 데이터 일관성과 데이터 손상을 방지하는 데 노력을 기울여야 한다. (Chng 등, 2002, Yusf, 2004) 변환 프로슈터뿐만 아니라,s 그 자체로, 또한 새로운 시스템을 다루기 위해 그들을 훈련시키기도 하다.
빅뱅 접근법에 따라 새로운 시스템이 구현될 필요가 있을 때, 실패의 위험이 높다(Lee, 2004). 조직이 이전 (레거시) 시스템의 변경을 크게 요구할 때, 덜 위험한 병행 접근법을 위한 추가 비용 간의 절충은 그러한 추가 비용을 선호해야 한다(리, 2004). 그럼에도 불구하고, ERP 채택은 대부분의 경우 큰 폭의 채택을 따른다(Microsoft, 2004, Yusf, 2004).
이는 조직이 구현 전략을 명확하게 생각하고 이러한 결정을 리스크 관리 또는 변경 관리 분석에 통합해야 한다는 것을 의미한다.
구현 스크립트 개발
IT 요구 사항
조직을 제대로 준비하기 위해서는 IT 요구사항과 조직 요구사항 모두에 대한 요구사항 분석이 필요하다. 요구사항 분석 및 변경 관리에 대한 자세한 내용은 다른 곳에서 확인할 수 있다. 병렬 채택의 경우, 가장 중요한 IT 요구사항(해당되는 경우)은 두 시스템을 동시에 실행하기 위한 주의사항이다. 전환 단계에는 구식 시스템이 선도적인 시스템인 타임슬롯이 있다. 후속 조치 기간 동안 이전 시스템에서 새 시스템으로 데이터를 전송하려면 사용 가능한 전환 모듈이 있어야 한다(Microsoft, 2004). 다른 구현 방법에는 직접적으로 이 요구사항이 없다. IT 요구사항에 대한 자세한 내용은 소프트웨어 엔지니어링에서 확인할 수 있다.
조직 요구 사항
IT 요구사항 외에도, 조직 요구사항은 인력 교육, 조직 구조 변화, 조직 유기적 조직 또는 기계론적 조직 특성(Daft, 1998)과 같은 인적 자원 관리 문제를 필요로 한다. 최고 관리 지원(Brown, Vessey, 1999). 브라운 외 연구진(1999)은 최고 경영진이 시작할 수 있는 두 가지 뚜렷한 역할, 즉 소위 스폰서와 챔피언 역할을 식별한다.
- 프로젝트 스폰서는 예산 지원과 주요 비즈니스 대표가 프로젝트 팀에 역할을 하도록 하는 역할을 담당한다.
- "프로젝트 챔피언은 프로젝트 팀의 정식 멤버가 될 수도 있고 아닐 수도 있지만, 변경 관리 노력에 핵심적인 역할을 할 수 있다."
병행입양 과정은 매우 스트레스를 많이 받고 있으며 보수적으로 구식 시스템에 열심이지 않고, 현재 일어나고 있는 실수를 처리할 수 있는 잘 준비된 직원들이 필요하다. (이슨, 1988년)
시간 계획
조직에서 새로운 제도를 실시하는 구체적인 계획을 세우는 것은 매우 중요하다(이, 2004, 이손, 1988). 병행 전환을 위한 시간 계획에서 가장 중요한 것은 일을 서두르지 말고 실제 전환 단계에서 발생할 수 있는 지연을 두려워하지 않는 것이다. (리, 2004) PRANS2 방식과 유사하게 명확하게 정의된 이정표(Rooijmans, 2003)로 작업하는 것도 매우 유익할 수 있다. 시간 계획에 대한 자세한 내용은 계획 및 전략 계획에서 확인할 수 있다.
조직 준비
요구사항평가
요구사항 평가에는 구현 스크립트를 재정의하는 작업이 포함된다. 만들어진 IT 및 (가능한 경우) 조직 요건을 시험해야 한다. IT 요구사항뿐만 아니라 조직의 책임을 평가할 수 있는 곳(Roijmans, 2003)에서 일부 테스트를 실행할 수 있다. 여기서 최고 경영진의 지원과 참여를 확보하는 것도 다시 중요하다(Eason, 1988). 만약 그들이 평가할 자원을 이용하지 않는다면, 구현은 직접적인 결과로 성공하지 못할 수 있다. 이 평가 후에 구현 스크립트는 보다 명확한 전환 시나리오로 재정의된다.
전환 시나리오
따라서 전환 시나리오는 모든 측면에서 조직적 변화에 대한 청사진으로 구성된다. 그러나 병행 채택 범위에서는 아직 마땅한 관심을 받지 못한 두 가지 주제가 있다.
- 해결 전략 / 롤백 계획: 다른 채택 시나리오와 구별되며, 변환 시나리오에도 통합되는 것이 롤백 계획을 사용한 해결 방법 또는 우발적 전략이다. 해결 전략은 다른 항목에서 보다 광범위한 범위로 정의되지만, 위의 표에서 정의한 대로 백업 계획, 전환 시나리오에서 전환 프로세스의 오류를 방지하고 이를 해결하기 위한 전략을 채택하여 구현이 여전히 성공할 수 있도록 한다(Microsoft, 2004). 롤백 계획은 가능한 해결 전략 중 하나로서 전환 단계에서 문제가 발생할 경우 시작된다. 두 시스템이 동시에 실행되므로, 병렬 채택으로 롤백 계획은 트랜잭션을 처리하는 데이터베이스나 다른 시스템이 레거시 시스템에서 완전히 재추적이 가능해야 함을 나타낸다(Microsoft, 2004). 실제로 병렬 채택은 선도적 시스템과 (비선도적) 백업 시스템의 특성 때문에 정의에 따라 롤백 계획을 제공한다.
- 기준 지표: 전환 시나리오는 두 시스템의 이전을 실행하는 청사진이기 때문에 수량화할 수 있는 기준도 수반된다. 재정의된 IT 및 조직 요구사항은 측정 가능한 구성요소로 이전되고 있다. 테스트 전환에서 기준을 충족하지 못할 때는 해결 전략을 전개해야 한다.
전환
실제 전환 단계는 이제 제자리걸음이다. 이 과정에서 조직은 스트레스를 많이 받는 시기에 있다(Eason, 1988, Roijmans, 2003). 두 시스템은 변환 시나리오에 따라 병렬로 실행되며, 새로운 시스템은 면밀히 감시되고 있다. 새로운 제도의 기준이 충족되면 구식 제도가 선도적인 제도가 중단되고 새로운 제도가 그 자리를 대신하게 된다. 해결 전략의 일부인 캐치업(catch up)은 기존 시스템의 백업이며 신뢰성 엔지니어링 및 데이터 복구 수단을 제공한다. 따라잡기 방법에는 자동 캐치업과 수작업으로 캐치업하는 방법 두 가지가 있다. (Rooijmans, 2003) 해당되는 경우 원격 백업 서비스도 구축할 수 있다.
제어 시스템
- 자동 캐치업: 조직 준비 단계에서 생성된 자동 시스템에 의해 전송되는 캐치업. 이 시스템은 이전 선도 시스템에서 새로운 선도 시스템으로 변환될 때 데이터나 정보를 자동으로 새로운 시스템으로 전송한다. 자동화된 시스템의 장점은 빠르고 정확하다는 것이다. 단점은 이전 단계에서 이적 제도를 생산하는 데 시간이 걸린다는 것이다.
- 손으로 따라잡기: 실제 전환에 소량의 시간이 수반되거나, 새로운 시스템으로 이전해야 할 정보의 복잡성이 작을 때, 조직은 수동으로 캐치업 전송을 선택할 수 있다. 이 절차의 장점은 정보를 전송하는 시스템(소프트웨어 프로그램)이 필요하지 않고 이러한 종류의 전송 프로그램과 함께 발생할 수 있는 문제가 없다는 것이다. 절충은 정확성과 시간이다. 캐치 업을 수동으로 전송하는 데는 상당한 시간이 걸리고 작은 인간의 실수에도 더 취약하다(Roijmans, 2003). 게다가, 노동 시간에 대한 추가 투자는 이미 높다; 수동적인 따라잡기 시스템은 인력에 훨씬 더 많은 압력을 가한다.
평가/실무적합성
사례 연구에서 배울 수 있는 몇 가지 교훈이 있다. 이씨(2004)가 기술한 네바다 DMV 시스템 사례는 새로운 프로세스에 대한 구현도 정치적 함의를 가질 수 있다는 것을 알게 된다. 바뀔 제도가 일반 대중에게 영향을 미치고, 변화되고 있는 내부 시스템만이 아니라 조직에 영향을 미치는 압력도 더 커진다. 이 경우 통신이나 상품 주문 등 고객이 더 많은 지연에 직면할 경우 회사 이미지와 평판으로서의 개념은 급격히 변화할 수 있다. 정치적으로 민감한 제도라면 전환 방식에 더 많은 관심을 기울여야 하며, 관련 리스크가 적기 때문에 가급적 병행 채택을 선택하는 것이 바람직하다는 것이다.
비즈니스 컨설팅 회사(Venture, 2004)가 수행한 여러 실제 사례 시나리오의 새로운 포트폴리오 시스템 구현에서 얻은 일련의 교훈은 현장에서 얻은 몇 가지 흥미로운 교훈을 보여준다. 그것들은 과학적 연구의 조합에 기초하여 일반적인 병행 채택 과정에 언급된 문제들과 완벽하게 들어맞는 것처럼 보인다. 요약하기
- 위험 평가 및 우발(해결 방법) 계획이 매우 중요함
- 프로젝트 팀 역할 할당
- 교육 및 테스트 계획을 포함하는 구체적인 이정표(PARINE2) 구성
- 잠재적 위험을 식별하고 필요한 경우 비상 계획을 실행하십시오.
- 프로젝트 상태 전달
- 변경 사항은 적절한 권한을 부여해야 한다.
- 변환 전략에서 데이터 요구 사항을 신중하게 검토해야 함
- 새 데이터 및 변경된 데이터를 검증 규칙에 따라 테스트해야 함
- 철저한 롤백 계획 구성
- 가능하면 파일럿 변환을 협상하십시오.
병렬 변환의 경우, 입력 내용이 펀치된 카드나 테이프의 렐로 구성되었을 때 산업 관행의 주요 요소였지만, 21세기에는 이를 실용화하지 못할 수 있는 최소 두 가지 어려움이 있다. 다음은 다음과 같다.
1. 최종 사용자가 고객, 생산 라인 근로자 또는 다른 거의 모든 사용자가 서로 다른 인터페이스를 통해 모든 거래를 두 번 입력하기를 기대하는 것은 비현실적이다.
2. 두 개의 다중 사용자 쌍방향 시스템 사이의 타이밍 차이는 두 시스템이 올바르게 작동하고 있고, 내부적으로 일관되며, 스스로 성공적으로 사용할 수 있는 경우에도 적절히 다른 결과를 산출할 수 있다.
그 결과, 병행 전환은 결과의 절대적 검증가능성이 의무적으로 요구되는 회계시스템, 사용자 모두가 조직 내부에 있고 이 요구사항을 이해하고 있는 회계시스템, 그리고 활동의 순서가 산출물에 영향을 미치도록 허용할 수 없는 경우와 같이 오늘날 몇 가지 특정한 상황으로 제한된다. 실제로 오늘날에는 파일럿 방식과 단계적 전환 방식이 더 적절하다.
참고 항목
참조
기사들
- 안데르손 1세 K. K. (2003) 한슨. 소프트웨어 조직에서의 기술 확산, 고테보리 대학 응용정보기술 자격논문
- 브라운, C.V. & Vessey, I. (1999년) ERP 구현 접근 방식: 비상사태 프레임워크를 향하여, 제20회 정보시스템 국제회의의 진행, NC, 12월 13-15일, 411-416.
- 칭, S, & 바탄노파스 V. (2002) 조직간 기업 시스템 구축: 포커스 그룹 연구. 제6차 아시아 정보 시스템 회의(PACIS 2002) 일본 도쿄 2002년 9월 2일-4일.
- 이씨, O. (2004) 네바다 DMV 시스템 사례 연구, 제3권, 비즈니스 및 경제 아카데미 저널
- 리버스, P. & Schoo, K.C. (2002) 복잡한 소프트웨어 구현 프로그램 설계, 제35회 하와이 국제 시스템 과학 회의(HICS'02) 제8권
- 유수프, Y. & 구나세카란, A. & 압토르페 M.S. (2004) 엔터프라이즈 시스템 프로젝트 구현: 롤스로이스의 ERP 사례 연구. 국제 생산 경제 저널, 87, 251-266.
책들
- 다프트, R.L. (1998년) 조직 이론과 설계. 웨스트: 인터내셔널 톰슨
- 이손, K. (1988) 정보 기술 및 조직 변화에서 "9장, 구현 및 지원". 런던: 테일러 & 프랜시스
- Turban, E. & Mcle, E. & Wetherbe J.(2002) "14장, 빌딩 정보 시스템" in: 관리를 위한 정보 기술. 뉴욕: John Wiley & Sons, inc.
- R., R., Thee, M. de, & Kop, R.(2003년). Regatta: ICT 구현 uitdaging voor een vier-met-stuurman. 헤이그: Ten Hagen en Stam Uitgevers.
