빅뱅의 도입
Big bang adoption빅뱅 도입 또는 직접 전환은 새로운 시스템이 이전 시스템과 새로운 시스템 [1][2][3]간에 전환 기간이 없이 즉시 채택되는 것입니다.
조직에 새로운 시스템을 도입할 필요가 있는 경우, 이 새로운 시스템을 도입하는 방법에는 빅뱅 도입, 단계적 도입, 병행 도입의 3가지가 있습니다.병행 도입의 경우, 낡은 시스템과 새로운 시스템이 병행하고 있기 때문에, 모든 유저가 새로운 시스템에 익숙해져, 낡은 시스템을 사용해 작업을 실시할 수 있습니다.단계적 도입이란 도입이 여러 단계로 이루어지기 때문에 각 단계 후에는 시스템이 완전히 도입되는 데 조금 더 가까워지는 것을 의미합니다.빅뱅의 도입으로 기존 시스템을 사용하는 것과 새로운 시스템을 사용하는 것의 전환은 단일 날짜에 이루어지며, 이른바 시스템의 즉각적인 전환이라고 불립니다.모든 사람이 같은 날짜에 새로운 시스템을 사용하기 시작하고 그 순간부터 이전 시스템은 더 이상 사용되지 않습니다.
빅뱅 도입의 장점은 새로운 시스템이 교체되는 오래된 시스템과 호환되거나 연결할 필요가 없다는 것입니다.이것에 의해, 특히 복수의 호환성이 없는 시스템으로 가동하고 있는 조직에서는, 새로운 시스템의 설계가 큰폭으로 심플화됩니다.그러나 빅뱅 채택 유형은 접근법에 통합된 학습 기회가 적기 때문에 다른 채택 유형보다 위험하므로 빅뱅에 도달하기 위해서는 [1]더 많은 준비가 필요하다.이 준비는 빅뱅 도입의 프로세스 데이터 모델에 의해 설명됩니다.
실행
경영진이 빅뱅 방식을 채택하기로 결정하고 이에 필요한 변경을 지원하면 진정한 변경 프로세스가 시작될 수 있습니다.이 프로세스는 시스템 전환, 시스템 부품 릴리스 및 미래 사용자 [1]교육 등 여러 단계로 구성됩니다.
프로세스의 액티비티는 아래 표에 설명되어 있어 명확하게 기술할 수 있습니다.활동 실행에 사용되는 개념은 대문자로 표시됩니다.
| 활동 | 서브액티비티 | 묘사 |
| 관리 준비(입양 참조) | 조직 변경 결정 | 빅뱅을 가능하게 하고 조직변화 보고서를 작성하기 위해 필요한 변경을 결정하는 프로세스 |
| 조직 변경에 합의하다 | 빅뱅을 도입하기 위해서는 계약으로 이어지는 변경안에 대한 합의가 있어야 한다.합의가 없는 경우, 새로운 합의 회의가 필요하거나 변경 사항이 반복적으로 결정되어야 하며, 합의 계약이 작성될 때까지 계속 결정해야 합니다. | |
| 시스템 변환 | 미래의 사용자를 위한 계획 수립 | 새로운 시스템을 처리해야 하는 담당자를 위한 계획을 작성하여 향후 발생할 이벤트에[1] 대한 개요를 파악합니다. |
| 기존 시스템에서 데이터 변환 | 새로운 시스템에서 사용할 수 있도록 이전 시스템의 데이터를 변환합니다(Koop, Roimans 및 de Thee, 2003). | |
| 새 시스템에 데이터 로드 | 변환된 데이터를 새 시스템에[1] 로드합니다. | |
| 새로운 시스템에서 데이터 테스트 | 새로운[1] 시스템에서 데이터를 사용할 수 있는지 여부를 알 수 있도록 데이터를 테스트합니다. | |
| 오프라인 평가판 실행 | 시스템 및 시스템 사용자와 함께 트라이얼을 실행하여 시스템이 올바르게 작동하는지[1] 확인합니다. | |
| 유효성을 확인하려면 체크합니다. | 시스템을 출시할 수 있도록 유효성 확인(Koop, Roimans and de Thee, 2003) | |
| 부품을 해방하다 | 변환된 데이터베이스 해제 | 이전[1] 데이터베이스에서 변환된 새 데이터베이스 해제 |
| 릴리즈 생성 어플리케이션 | 스탭용으로[1] 작성된 어플리케이션을 공개합니다. | |
| 릴리스 인프라스트럭처 | 새로운 인프라스트럭처의[1] 릴리스 | |
| 사용자 준비 | 경험이 풍부한 스탭의 버퍼 유지 | 새로운 시스템 사용 훈련을 받아야 하는 사람의 업무를 인계할 수 있는 완충 인원을 만들어 일상 업무를 계속할[1] 수 있도록 한다. |
| 사용자 훈련 | 시스템의 대규모 릴리스에 대비하여 사용자를 훈련하고 훈련받은 사용자의 목록을 작성합니다. |
시스템 변환
우선, 전체 입양 과정에 대한 계획이 필요하다.이 계획을 통해 미래의 사용자는 어떤 일이 일어날지, 언제 특정한 변화를 예상해야 하는지 알 수 있으며, 이는 불필요한 불확실성을 피하고 따라서 더 나은 작업 환경을 만들 수 있습니다.이 계획은 또한 실제 채택 시기가 언제인지 명확히 하고 미래의 사용자가 이러한 [1]변화에 대비할 수 있는 기회를 제공합니다.아래 모델은 활동(회색 상자 내)이 결과(회색 상자 옆 상자 내)로 이어져 부분 결과를 얻을 수 있음을 보여 줍니다. 변환된 시스템
계획이 수립되고 모두에게 기대되는 것이 무엇인지 알게 되면 기술적 전환이 시작될 수 있습니다.먼저 오래된 데이터를 새로운 시스템의 데이터로 사용할 수 있는 형태로 변환해야 합니다(Koop, Roimans 및 de Thee, 2003).그런 다음 이 데이터를 새 시스템에 로드해야 합니다. 그러면 소위 로드된 데이터가 생성됩니다.이 로드된 데이터를 테스트하여 데이터의 효율성을 확인하고 향후 사용자의 이해도를 테스트해야 합니다.오프라인 평가판을 실행하여 시스템과 사용자가 함께 작업할 수 있는지 확인해야 합니다.효율성과 이해도를 테스트해야 할 뿐만 아니라 데이터 검증 수준을 명확히 [1]하기 위해 타당성을 테스트해야 합니다.데이터가 유효하지 않은 경우 경영진은 변경 사항을 다시 판단해야 하며 조직은 빅뱅 도입을 실행하는 다른 방법을 준비해야 합니다.
시스템의 부품을 분리합니다.
모든 데이터가 유효할 경우 시스템의 개별 부품을 분리할 수 있습니다.이전 데이터베이스에서 변환된 데이터베이스를 해제해야 새 데이터에 액세스할 수 있습니다.다음으로 제작한 어플리케이션을 출시해야 새로운 어플리케이션도 사용할 수 있습니다.시스템의 모양과 모든 것이 어떻게 연결되어 있는지를 명확하게 하기 위해 완전히 새로운 시스템의 인프라스트럭처도 공개해야 합니다(Koop, Roimans and de Thee, 2003).이 단계에서는 아직 새로운 시스템을 형성하지 않고 일부만 출시됩니다.이 모든 것은 오프라인에서 발생합니다.사용자가 오래된 시스템에서 작업하고 있는 동안 시스템 개발자만 볼 수 있습니다.위의 모델은 시스템 컨트롤러가 어떤 작업을 수행해야 하는지(회색 상자 안에 표시) 보여 줍니다.이 작업을 통해 부품을 방출할 수 있는 결과를 얻을 수 있는 결과를 얻을 수 있습니다.부품의 릴리스에 실패했을 경우는, 경영진은 새로운 변경을 재차 결정할 필요가 있습니다( 「채택;채택할 조직의 준비」를 참조해 주세요.
조직의 시스템 사용 훈련
개별 부품의 릴리스에 성공했을 경우는, 유저의 준비를 실시합니다.완전히 새로운 시스템을 도입하기 위해서는, 즉, 모든 사용자가 새로운 시스템을 사용하는 훈련을 받아야 합니다.조직의 생산 레벨에 큰 영향을 주지 않고, 트레이닝을 필요로 하는 유저의 일상 업무를 계승할 수 있는 경험이 풍부한 스탭이 있는 경우에만, 모든 유저를 트레이닝 할 수 있습니다.즉, 트레이닝을 필요로 하는 모든 사람에게, 업무를 인계할 수 있는 스탭이 있기 때문에,[1] 업무의 큰 지연은 없습니다.인사부는 경력직의 버퍼(회색상자 내 활동)를 작성하기 위해 지원자를 모집한다.그런 다음 사용자를 교육하고 교육받은 사용자를 나열할 수 있으므로 사용자 준비 보고서를 작성할 수 있습니다.
FoxMeyer의 사례에서 알 수 있듯이, 트레이닝이 불충분하면 조직에 나쁜 결과가 초래될 수 있습니다(Scott, Vessey, 2000).이 회사는 빅뱅 방식을 사용하여 ERP(Enterprise Resource Planning) 시스템을 구현했습니다.잘못된 교육이 제공되었고, 사용자가 이미 충분히 알고 있으며 잘못된 기술을 가르쳤다고 가정했습니다.또한 Dow Corning은 빅뱅 ERP 구현 과정에서 필요한 기술을 습득하는 데 큰 문제가 있었습니다(Scott, Vessey, 2000).새로운 시스템을 사용하려면 다양한 기술과 지식이 필요한데, 경우에 따라서는 전환 관리자에 의해 과소평가되는 경우가 있습니다.
기술
새로운 시스템을 구현하기 위한 몇 가지 기술이 있습니다.도입 단계는 전체 구현의 한 단계일 뿐입니다.Regatta(Koop, Roimans and de Thee, 2003)는 예를 들어 시스템을 구현하기 위해 개발된 방법이다.Sogeti가 개발한 이 방법은 전환 작업을 하나의 프로젝트로 취급하고, 도입 준비 단계나 도입 방법의 수용 등 이 프로젝트의 여러 단계에 초점을 맞춥니다.SAP 구현은 SAP AG 소프트웨어의 구현 및 채택에 특화된 또 다른 기술로, 몇 가지 기술로 나뉩니다.
리스크
즉각적인 전환으로 인해 모든 작업은 정해진 시간 스케줄에 따라 수행되어야 합니다.이것은 위험한 작업입니다.조직은 아직 이에 대한 준비가 되어 있지 않거나, 경험 부족과 시작 문제로 인해 잘못된 데이터 세트가 사용되거나 정보 시스템이 고착될 수 있습니다.또한 불가능한 폴백 방법은 빅뱅을 사용하는 시스템을 구현할 때 위험이 될 수 있다(Koop, Roimans 및 de Thee, 2003).
영국 주식 시장, 1980년대
1986년 런던 증권거래소는 금요일 밤에 문을 닫았고 그 다음날 월요일 [4][5]아침에는 컴퓨터가 모두 켜졌다.이로 인해 [citation needed]큰 손실이 발생했다는 주장이 제기되어 왔다.
다우 코닝
Dow Corning은 이전에 특정 부서에 초점을 맞춘 시스템을 사용했습니다.경영진은 하나의 정보 시스템, 즉 엔터프라이즈 리소스 플래닝(ERP) 시스템만을 사용하는 진정한 글로벌 기업이 되기로 결정했습니다.이 새로운 ERP 시스템을 도입하기 위해 이들은 빅뱅 도입 유형을 사용했으며 비즈니스 프로세스를 재검토하는 데 상당한 시간과 노력을 들였습니다.동사는, 도입의 준비를 갖추어, 최초로 3개의 파일럿 실장을 실시한 후, 글로벌 조직 전체에 새로운 시스템을 도입했습니다.(Scott, Vessy, 2000)
다우 코닝은 지속적으로 진행 상황을 관찰하고 마감일이 지켜질 수 있도록 결정을 내렸습니다.이것은 피드백과 좋은 의사소통이 있어야만 가능했다.(Scott, Vessey, 2000)
또 다른 위험한 전략은 결과를 달성하는 방법이 아니라 결과에만 초점을 맞추고 사용자의 학습 과정을 과소평가하는 것입니다.학습이나 지식을 계획하는 것은 매우 어렵지만, 이러한 것들은 빅뱅 전환을 실행하기 위해 필요하다.
폭스마이어
FoxMeyer는 야심찬 창고 자동화 소프트웨어를 갖춘 ERP 시스템을 채택하여 빅뱅을 채택하여 경쟁 우위를 확보했습니다.그러나 폭스마이어는 비현실적인 기대와 함께 지나치게 낙관적인 경영을 하고 있는 것 같다. 즉, 변화가 너무 크고 너무 극심하다는 것이다.그 결과, 모든 종업원의 납기일을 맞추어야 하는 업무상의 압박이 매우 높아졌습니다.따라서 경영진의 비현실적인 기대도 리스크입니다(Scott, Vessy, 2000).
FoxMeyer는 빠르고 효과적인 피드백을 제공하기 위해 필요한 의사소통과 관심을 갖지 못했습니다.대신 이를 무시해 문제를 최소화하려 했고, 비판의 화살을 던져 모호한 피드백을 낳았다.이것은 조직적인 학습에 방해가 되었고, 이것은 조직적인 변화에서 매우 중요한 것입니다.따라서 빅뱅이 있는 시스템을 채택할 때는 커뮤니케이션 불량과 애매한 피드백도 리스크가 됩니다(Scott, Vessey, 2000).
「 」를 참조해 주세요.
레퍼런스
- ^ a b c d e f g h i j k l m n Eason, 1988
- ^ Copley, Steve. "Implementing the New System". IGCSE ICT. Retrieved 13 August 2011.
- ^ Wainwright, Stewart (2009). IGSCE and O Level Computer Studies and Information Technology. Cambridge University Press. p. 29.
- ^ "How technology has influenced The Stock Market. – Computers in the City". www.citc.it. 18 September 2015. Retrieved 19 June 2017.
- ^ "Today's News".
- Eason, K.(1988) 정보기술과 조직의 변화, Taylor & Francis.
- Roimans R. 및 de Thee, M.(2003) Regatta: ICT 구현 및 Uitdaging voor een vier-met-stuurman, S.D.U. Uitgeverij.ISBN 90-440-0575-8.
- Scott, J.E., Vesey, I. (2000) "엔터프라이즈 자원 계획 시스템 구현: 실패로부터 배우는 역할", 정보 시스템 프런티어, vol.2(2), 페이지 213-232.
