용어 연장을 조사하여 확장에 대한 논의를 시작합니다. 확장이란? 구체적으로 무엇을 확장해야 할까요? 그리고 가장 중요한 것은 왜 확장해야 할까요?
모든 소프트웨어는 범위를 염두에 두고 설계되었습니다. 이 범위는 다음 두 가지를 정의합니다.
- 소프트웨어가 제공하는 고객의 결과
- 소프트웨어가 그러한 결과를 제공하는 방법
고객의 관점에서 볼 때 가치를 창출하는 것은 결과의 이행입니다. SAP와 같은 소프트웨어 공급업체의 경우 범위는 고객에게 제시된 가치 제안의 기초가 되며 소프트웨어 디자인 프로세스의 중요한 부분입니다.
의심의 여지없이 SAP ERP의 가장 큰 장점 중 하나는 그 범위였습니다. 물류, 재무, 인사 관리 영역에서 거의 모든 비즈니스 프로세스를 처리할 수 있도록 고안된 제품을 제공하는 것은 매우 중요한 작업입니다. SAP의 고객 기반은 30개가 넘는 다양한 산업을 포괄하고 있으며 작업의 규모가 더욱 명확해진다는 사실을 덧붙입니다. 각 산업에는 특정 비즈니스 프로세스(예: 은행이 정부 기관이나 군대와 다르게 조달 프로세스를 설계 및 실행할 수 있음)를 실행하는 고유한 특수 방법이 있으며, 같은 산업 내에서도 개별 회사는 프로세스를 다르게 설계하고 실행할 수 있습니다. 그러나 범위의 과제는 SAP가 피한 적이 없었습니다. 상당히 반대로 – 그것은 열정으로 포용되었습니다.
유연성의 필요성
의심할 여지 없이 SAP 애플리케이션이 다루는 범위의 범위는 고객이 SAP 솔루션을 채택하는 데 있어 중요한 요인이지만, 또 다른 요인도 있습니다. 유연성: 고유한 요구사항에 맞게 제공된 범위를 조정할 수 있습니다. 따라서 고객에게 범위를 제공할 뿐만 아니라 고객의 고유한 요구사항에 따라 해당 범위를 조정할 수 있는 유연성도 제공합니다. SAP는 범위와 마찬가지로 열정으로 유연성 문제를 수용했습니다. 그러나 이러한 과제를 해결하기 위해서는 SAP 부분에 몇 가지 "바로 사용 가능한 디자인적 사고"가 필요했습니다.
한 가지 잠재적인 해결책은 일단 설치 및 가동되면 소스 코드가 "동결"되는 시스템을 고객에게 제공하는 것이었습니다. 고객은 이 코드를 조정하거나 변경할 수 없으며 일상적인 유지보수, 업데이트, 업그레이드에만 더 많은 관심을 가질 것입니다. 대부분 단순하고 번거로운 일입니다. 시스템 유지보수를 담당하는 IT 부서에서는 단순히 관련 패치를 적용하거나, 적절한 시점에 소프트웨어를 업그레이드하기만 하면 됩니다. 그런 다음 빠른 테스트를 수행하여 모든 것이 정상이고 작업이 완료되었는지 확인합니다. IT는 사용 편의성 측면에서 이러한 접근 방식에 만족하지만 비즈니스 이해 관계자 및 가장 중요한 최종 사용자(소프트웨어 시스템의 진정한 가치가 실현됨)는 두 그룹 모두 조정과 관련하여 더 유연한 소프트웨어 패키지를 필요로 하기 때문에 그렇지 않을 것입니다. SAP는 이러한 접근 방식을 채택하지 않았습니다.
또 다른 잠재적인 해결책은 스펙트럼의 반대편에 있다: 코드의 기준선 저장소와 함께 제공되는 시스템, 그러나 그 코드는 "제안"이다. 이 시스템은 모두에게 무료입니다. 변경, 수정 및 코드의 도매 삭제는 공정한 게임이 될 것입니다. 이 환경에서는 SAP가 간단한 유지보수 릴리스(간단한 기술적 패치를 적용하여 버그 수정만 가능)도 불확실성에 빠질 수 있습니다. 이러한 패치를 적용하는 데 몇 분 정도 걸릴 수 있습니다. 완전한 업그레이드는 악몽일 수 있습니다. 고객의 범위에 따라 단순 업그레이드에서 수행된 변경에는 반년이 걸릴 수 있습니다. 이러한 유형의 접근법과 관련된 비용은 SAP와 고객 모두에게 상당한 비용입니다. IT가 단순한 운영 작업에 많은 시간을 할애해야 하는 재무 비용 외에도 시장 변화에 신속하게 대응할 수 없는 시스템을 갖춰 신속하게 적응할 수 있는 기회 비용도 있습니다. 첫 번째 접근법과 마찬가지로 SAP에서는 이 방식도 채택하지 않았습니다.
필요했던 것은 다음 세 집단의 요구가 균형을 이루는 "골딜록스" 접근법이었다:
- 단순하고 사용하기 쉬운 일관된 사용자 환경을 갖춘 소프트웨어를 원하는 최종 사용자(이후 소단원에서 자세히 설명)
- 안정적이지만 비즈니스 프로세스를 실행하고자 하는 고유한 방식에 맞게 조정할 수 있는 비즈니스 이해관계자(특히 프로세스 소유자)입니다.
- 시스템을 설치하고 유지보수해야 하는 IT 부서로서, 앞에서 언급한 두 그룹의 요구사항을 충족하지만 이러한 비용이 비즈니스에 가장 적합한 방식으로 관리되어야 합니다.
이 접근법은 고객이 시작한 코드 조정과 같은 결과를 낳습니다. 시스템이 표준 기능(Best Practices 기반)과 함께 설치되었지만 고객이 (명확하고 통제된 방식으로) 이 기능을 조정하여 비용 효율적인 방식으로 이해관계자의 요구사항에 맞게 원하는 결과를 달성할 수 있도록 했습니다. 처음에는 이러한 접근법이 불가피하게 들릴 수 있지만, 수십 년 전에 SAP R/3이 시장에 도입되었을 때 이는 혁명적이라고 여겨지는 것을 잊기 쉽습니다. 하지만 시간이 지남에 따라 이러한 균형 잡힌 접근 방식은 SAP ERP의 놀라운 성공을 위한 가장 중요한 요소 중 하나가 되었다고 하는 것은 공정합니다.