제품 소프트웨어 구현 방법

Product software implementation method

제품 소프트웨어 구현 방법은 소프트웨어 기반 서비스 또는 구성요소를 조직 구조 또는 개별 최종 사용자의 워크플로우에 효과적으로 통합하기 위한 체계적인 접근방식이다.

이 항목은 "대규모"(복잡성 차이에 설명됨) 제품 소프트웨어 구현의 프로세스 모델링(프로세스 모델링) 측면을 중점적으로 다루며, 엔터프라이즈 리소스 계획 시스템의 구현을 주요 사례로 사용한다.

개요

제품 소프트웨어 구현 방법은 사용자 및/또는 조직이 특정 소프트웨어 제품을 사용하여 실행되도록 하기 위한 청사진이다.

이 방법은 소프트웨어 제품을 구현할 때 발생하는 가장 일반적인 문제에 대처하기 위한 규칙과 관점의 집합이다: 조직적 관점에서 비즈니스 조정과 인간적 관점에서 수용이다.

소프트웨어 생산의 배치 사슬의 최종 연결고리로서 제품 소프트웨어의 구현은 재정적인 관점에서는 주요한 이슈다.

(제품)소프트웨어의 구현은 소프트웨어 구매 예산의 최대 1/3을 소비한다고 명시되어 있다(하드웨어와 소프트웨어 요건을 합한 것 이상).

구현 복잡성 차이

제품 소프트웨어 구현의 복잡성은 몇 가지 문제에 따라 다르다.예: 제품 소프트웨어를 사용할 최종 사용자의 수, 구현이 최종 사용자에 대한 태스크와 책임의 변화에 미치는 영향, 소프트웨어를 사용할 조직의 문화와 무결성, 제품 소프트웨어 취득에 사용할 수 있는 예산 등이다.

일반적으로 차이는 크기(더 큰, 더 작은, 더 큰, 더 많은, 더 적은)로 식별된다."더 작은" 제품 소프트웨어의 예는 사무실 패키지의 구현이다.그러나 조직에 최종 사용자가 많을 수 있으며, 최종 사용자의 일상적인 워크플로우가 크게 변화하지 않기 때문에 최종 사용자의 태스크 및 책임에 미치는 영향은 그리 심하지 않을 것이다."더 많은" 제품 소프트웨어의 예는 엔터프라이즈 자원 계획 시스템의 구현이다.구현은 제품 자체의 구조뿐만 아니라 조직의 아키텍처에 대한 심도 있는 통찰력을 필요로 한다.다음으로, ERP 시스템의 사용은 새로운 업무와 책임이 생성되거나 이동될 것이기 때문에 최종 사용자의 훨씬 더 많은 헌신을 수반한다.

다른 "더 많은" 제품 소프트웨어의 예는 다음과 같다.

소프트웨어 사용자 정의 및 비즈니스 프로세스 재설계

제품 소프트웨어와 조직 구조를 조정하는 데 사용되는 프로세스 모델링은 제품 소프트웨어와 조직 구조가 소프트웨어가 구현될 만큼 충분히 정렬되지 않는다는 결론을 도출할 때 주요 문제를 수반한다.이 경우, 소프트웨어의 맞춤화 또는 조직 구조의 재설계, 즉 비즈니스 프로세스의 두 가지 대안이 가능하다.

소프트웨어 사용자 정의는 표준화된 소프트웨어 개념이 더 이상 적용되지 않기 때문에 실제로 맞춤 제작된 소프트웨어에서 제품 소프트웨어를 변형시킨다.이로 인해 소프트웨어 사용에 문제가 발생할 경우 소프트웨어에 대한 지원이 상실되고 컨설팅을 취득해야 할 필요성이 발생할 수 있다.그러나 사용자 정의하면 조직 무결성이 조정되지 않아 워크플로우의 변경이나 이동이 덜 필요하기 때문에 최종 사용자에게 부담이 덜해지는 상황이 발생한다.이러한 사실은 사용된 새로운 (제품) 소프트웨어 애플리케이션의 수용에 긍정적으로 추가될 수 있으며, 따라서 구현 예산의 부드러운 측면에서 구현 시간과 예산을 감소시킬 수 있다.

비즈니스 프로세스의 변경은 제품 소프트웨어의 최종 사용자에 대한 업무와 책임을 변경하기 때문에 비즈니스 프로세스를 재설계하는 것이 제품 소프트웨어 사용에 대한 저항을 유발하는 데 더 합리적이다.하지만 제품 소프트웨어가 변경되지는 않았지만 더 나은 지원, 교육 및 서비스 레벨이 가능하다...소프트웨어의 특정 무결성에 대한 지원이 생성되었기 때문이다.

구현 프레임워크

지도원리 대 직업

제품 소프트웨어의 구현 프로세스에 대한 또 다른 문제는 구현 방법을 어느 정도까지 사용해야 하는가에 대한 선택 또는 사실상의 문제다.

이행 방법은 한편으로는 지침원리로 사용될 수 있으며, 이는 이 방법이 어떤 프로젝트의 이행 단계가 어떻게 실행되어야 하는지에 대한 세계적인 아이디어로 작용함을 나타낸다.이러한 선택은 선택된 방법에서 고려하지 않는 상황적 요인에 대한 여지를 더 많이 남기지만, 실행 과정의 실행에서 의문이 발생할 때 모호함을 초래하게 된다.

반면 방법은 직업으로 활용할 수 있는데, 이는 방법을 엄정히 취하여야 하며, 방법의 사용은 지도원리가 아니라 직업으로 삼아야 한다는 뜻이다.이 관점은 구현 과정이 매우 복잡하고 정확하고 정확한 연기에 매우 의존하는 경우에 매우 유용하다.조직 및 품질 관리는 어떤 방법을 엄격하게 사용하면 조직 수준이 보다 명확해질 수 있기 때문에 이 관점을 수용하게 될 것이다.그러나 변경 관리는 구현 방법에서 더 많은 유연성이 구현 프로세스의 부드러운 측면을 위한 더 많은 여지를 남긴다는 것을 나타낼 수 있다.

구현 프레임워크

특정 제품이나 서비스를 구현하기 위한 규칙 집합의 역할을 하는 구현 방법과는 별도로, 구현 프레임워크는 시간, 예산 및 품질에서 구현 단계를 정의하는 프로젝트 관리 구조 역할을 한다.

몇 가지 프로젝트 관리 방법이 실행 방법을 수행하는 기반이 될 수 있다.이번 엔트리는 제품 소프트웨어 구현에 초점이 맞춰져 있기 때문에 구현 단계 지원에 적합한 최적의 프로젝트 관리 방법은 소프트웨어와 정보 시스템 자체에도 초점을 맞춘 프로젝트 관리 방법이다.프로젝트 관리 방법 프레임워크로 동적 및 정적 시스템 개발 방법(DSDM)과 Prince2를 사용한 예에 의해 구현 방법의 적용 가능성을 명확히 한다.

DSDM

동적 시스템 개발방식의 강점은 이 방법이 반복과 증분가치의 원칙을 사용한다는 것인데, 이는 각 단계가 프로젝트에 가치를 추가하는 반복적인 단계에서 프로젝트가 수행된다는 것을 의미한다.이러한 방식으로 이행 단계는 점진적으로 수행될 수 있으며, 모든 증가 [F] 내에서 수용 정도, 인식 및 기술과 같은 중요한 프로젝트 측면에 가치를 더할 수 있다.Von Meyenfelt, Basickennis 프로젝트 관리, Academic Service 1999].기회 범위 관리 외에도, 구현 단계의 프로세스 모델링 범위에서도 증분을 사용할 수 있다.단계별로 세부사항을 더 추가하면 두 모델이 더 가까워질수록 비즈니스 아키텍처와 제품 소프트웨어의 프로세스 모델을 조정할 수 있다.또한 DSDM은 단계별 교육, 문서화 및 검토를 위한 여지가 있다.

프린스2

DSDM과 마찬가지로 Prince2 방법은 구현을 방법 내의 한 단계로 인정한다.Prince2는 일련의 프로세스로 구성되며, 그 중 3개의 프로세스는 특히 구현을 위한 것이다.단계 제어, 제품 전달 관리 및 단계 경계 관리 프로세스는 시간과 품질이라는 요소와 함께 구현 프로세스를 상세히 기술할 수 있다.Prince2 방법은 반복적으로 수행될 수 있지만 공정의 정밀한 실행에도 적합하다.

프로젝트 관리 프레임워크에서 프레임에 포함되는 구현 프로세스의 수익은 다음과 같다.

명료함

구현 프레임워크는 시간, 품질, 예산 및 실행 가능성과 같은 요소와 함께 상세하게 설명될 수 있는 프로세스를 제공한다.

반복적이고 점진적인 접근 방식

설명했듯이, 구현 프로세스의 다른 단계를 반복적으로 실행할 수 있는 가능성은 최종 사용자(조직)와 구현될 제품을 점진적으로 정렬하여 프로세스를 실행할 수 있게 한다.

임베디드 & 일반 방법

제품 소프트웨어를 구현하는 한 가지 방법은 임베디드 방식이나 모델을 사용하는 것이다.임베디드 모델은 소프트웨어 패키지와 함께 제공되는 보조 재료(제품 소프트웨어 정의 참조)의 일부다.

임베디드 모델을 사용하여 소프트웨어 제품을 구현한다는 것은 모델이 특정 소프트웨어 제품과만 사용할 수 있을 뿐 아니라(대부분) 모델을 통해서만 구현될 수 있거나 구현되어야 한다는 것을 의미한다.따라서 임베디드 방식은 제품 소프트웨어를 구현하는 매우 구체적인 방법으로 볼 수 있다.

내장된 방법을 사용하는 소프트웨어 제품의 예는 다음과 같다.

ARIS 임베디드 모델을 사용하여 SAP(SAP R/3) 구현

DEM(Dynamic Enterprise Modeling)을 사용하여 Baan ERP 시스템 구현

Oracle E-Business Suite 구현(AIM(Autral Application Implementation Method) 사용

일반적인 구현 방법은 특정 소프트웨어 제품을 위한 것이 아니라 제품 소프트웨어 제품을 구현하는 데 있어 일반적인 사용을 위한 것이다.이 사용법은 객체 프로세스 방법론을 이용한 제품 소프트웨어 구현 사례에 대해 상세하게 설명될 예정이다.이 방법론은 ERP 모델링의 예: ERP 시스템을 조직 구조로 구현하기 위한 모델링에서 매우 유용하다.

평가

임베디드 메서드를 사용하면 메서드가 함께 제공되는 소프트웨어 제품을 구현하기 위해 메서드가 고안된 힘을 얻을 수 있다.이는 방법의 사용이 덜 복잡하고 지원 가능성이 더 높다는 것을 시사한다.임베디드 방식의 부정적인 측면은 분명히 그것이 특정 제품 소프트웨어에만 사용될 수 있다는 것이다.엔지니어들과 컨설턴트들은 여러 소프트웨어 제품들로 운영되며, 하나의 작업 방식만을 갖추기 위해 일반적인 방법을 더 많이 사용할 수 있다.

ERP 모델링과 같은 일반적인 방법을 사용하는 것은 그 방법이 여러 ERP 시스템에 사용될 수 있다는 힘을 가지고 있다.임베디드 방식과 달리 제네릭 방식의 사용은 여러 ERP 시스템을 고객 조직에서 구현하는 회사에서 운영하는 엔지니어 및 컨설턴트가 여러 임베디드 모델에 대한 기술을 습득할 필요 없이 하나의 구체적인 작업 방식에 적응할 수 있게 한다.그러나 일반적인 방법에는 구현 프로젝트가 너무 상황적이 되어 모델 프로세스 실행 시 어려움과 복잡성을 야기할 수 있다는 부족함이 있으며, 이는 보다 적은 지원을 이용할 수 있기 때문이다.