현재 소프트웨어 모델은 크게 3가지 개발 모델로 나눌 수 있다. 대규모 맞춤형 개발, 상용 소프트웨어의 소규모 맞춤형 개발, 그 사이 플랫폼의 소규모 맞춤형 개발이다.
커스터마이징 개발 시장은 점차 축소될 것입니다
과거에는 매우 매력적으로 보였던 개발 모델인 맞춤형 개발은 업계의 지속적인 표준화, 다양한 산업 소프트웨어의 지속적인 도입으로 점점 인기를 얻고 있습니다. 대규모 국내 및 국제 기업 관리 소프트웨어 제조업체의 출현으로 인해 맞춤형 개발 시장은 점차 축소되고 성숙한 제품 및 비즈니스 플랫폼으로 대체될 것입니다.
커스텀 개발의 사업 범위는 매우 제한적이다. 한편으로는 수백만, 수천만 달러 규모의 프로젝트를 커스터마이징해야 하는 경우에는 소규모일 수밖에 없다. 즉, 현재의 잦은 개·폐업 상황을 토대로 그러한 시스템을 개발하는 데 소요되는 개발 및 구현 시간은 소프트웨어 회사가 여러 번 문을 닫을 만큼 충분할 것으로 추정됩니다. 반면, 맞춤형 개발에 참여하려면 소프트웨어 회사의 종합적인 강점, 특히 업계 강점이 상대적으로 높습니다. 산업에서는 기본적으로 눈에 보이는 대로 주문을 합니다. 따라서 기본적으로 기업 비즈니스의 수동 시뮬레이션이며 수동 비즈니스를 실현할 수 있습니다. 전자화는 훌륭하지만 ERP의 고급 관리 개념과 아이디어를 어떻게 통합할 수 있습니까?
맞춤형 시스템의 유연성이 떨어져 기업의 발전을 따라잡을 수 없습니다. IT 부서에서 개발한 후 비즈니스 부서의 요구 사항이 변경되는 경우가 많습니다. 동시에 그룹은 계속해서 합병 및 재편성을 진행하고 있으며 다른 사업 영역으로 계속 확장하고 있습니다. 맞춤형 시스템의 확장성이 좋지 않고 적응성이 좋지 않다는 단점이 점점 더 두드러지고 있습니다.
IT 기술은 상상할 수 없는 속도로 발전하고 있습니다. 기업 자체의 IT 팀이 기술 발전 추세를 따라가는 것은 매우 어렵습니다. 발전하지 못하면 최신 정보기술을 십분 활용해 경영성과 생산성을 향상시키지 못하고 결국 쇼핑몰에 의해 도태될 수도 있다.
따라서 개발주기가 길고 산업 비즈니스에 대한 이해가 부족하며 기본적으로 전자 수작업으로 인해 맞춤형 개발에는 표준화 아이디어, 전체 품질 관리 아이디어와 같은 ERP 관리 소프트웨어의 고급 관리 아이디어가 통합될 수 없습니다. , 공급망 관리 아이디어가 여기에 통합됩니다. 동시에 성숙한 소프트웨어 제품의 지속적인 강화와 침해로 인해 맞춤형 개발은 점차 역사의 무대에서 물러날 것입니다.
플랫폼 모델은 미래 정보화의 주류가 될 것이다
플랫폼에 있어서 2001년은 투기의 가장 바쁜 해였다. 곧 플랫폼 개념은 ERP 투기만큼 인기를 끌었다. 너무 엉망이어서 어떤 시스템이던, 엑셀로 만든 매크로 파일 몇 개라도 플랫폼을 추가해야 한다.
플랫폼을 어떻게 이해하나요?
플랫폼에는 기본적으로 두 가지 개념이 있습니다. 하나는 빠른 개발을 기반으로 하며 일부 보조 개발 도구(예: 시스템 관리, 구성 요소 등)를 제공합니다. ) 이러한 종류의 개발 플랫폼은 기껏해야 개발 도구(예: Delphi)의 최적화일 뿐입니다. 개발 작업이 있을 때마다 모든 고객 비즈니스를 재개발해야 합니다(물론 일부 기술 플랫폼도 마찬가지입니다). 일부 시스템도 포함). 관리, 조직 권한 및 기타 비교적 일반적인 사항. 또 다른 종류의 플랫폼은 기술 플랫폼을 기반으로 개발되며 비즈니스 로직을 핵심으로 하는 비즈니스 관리 플랫폼입니다. 이 플랫폼의 특징은 좁은 의미의 기술 플랫폼일 뿐만 아니라 그 특성을 캡슐화한다는 것입니다. 업계(또는 일반적인 기업)에는 비교적 일반적인 비즈니스 로직이 많이 있으며 이러한 비즈니스 로직은 일반적으로 특정 업계에 대한 심층적인 연구의 결과입니다. 일반적인 예로는 Kingdee의 BOS 플랫폼, Neusoft의 VP.net 플랫폼 등이 있습니다.
물론 비즈니스 플랫폼에서는 고려해야 할 사항과 개선해야 할 부분이 많습니다. 그렇지 않으면 아무리 좋은 아이디어라도 '행동에는 결과가 있다'는 생각일 뿐입니다. 현재 비즈니스 플랫폼에는 주로 다음과 같은 주목할 만한 측면이 있다고 생각됩니다:
1. 한 가지 측면은 다양한 데이터베이스를 지원하는 것입니다. 데이터베이스마다 저장 프로시저(Procere) 및 트리거(Trigger)의 작성 및 실행이 다릅니다. 동시에 데이터베이스 트랜잭션 제어, 데이터 동시성 등도 매우 중요한 문제입니다.
한편, 데이터 저장의 문제인 비즈니스 데이터가 데이터베이스 테이블(Table)의 형태로 표현되는지 아니면 객체의 형태로 표현되는지는 장기적인 관점에서 객체로 표현될 수도 있지만, 객체를 이용하여 표현, 기술 어떻게 구현하고 얼마나 효율적인가요? 저자가 개발에 참여한 플랫폼은 데이터 바인딩에 완전한 객체 지향 접근 방식을 사용하므로 시스템 효율성이 크게 저하됩니다(특히 다음과 같은 경우). 데이터의 양이 많고, 객체의 패키징 및 언패킹이 매우 어렵고 시스템의 실행 효율성에 심각한 영향을 미치며 홍보가 어렵습니다.
2. 효율성 문제. 비즈니스 플랫폼은 특정 비즈니스를 대상으로 하지 않기 때문에 운영 로직은 더욱 복잡해집니다. 동시에 각 비즈니스 구성 요소는 서로 독립적이므로(독립적이어야 하는 이유를 설명) 비즈니스 플랫폼은 프레임워크로 개발됩니다. 모델을 만들고 "Haolaiwu 원칙"을 따릅니다. 제어는 프레임워크에 있습니다. 그렇지 않으면 당신은 나와 그를 사용해야 합니다. 당신과 나를 사용해야합니다. 그 경우에는 동일하지 않습니다.플랫폼) 시스템 간의 연결도 시스템의 효율성에 영향을 미칩니다.
3. 비즈니스 로직을 추출하는 것은 매우 어려우며 많은 기술 플랫폼이 비즈니스 플랫폼으로 전환할 수 없는 이유이기도 합니다. 먼저 비즈니스를 추출해야 하는데, 먼저 표준 ERP 이론에 따라 추출하고, 그 다음에는 관련 비즈니스 전문가에게 비즈니스 로직을 개선하고 구체화하도록 요청하는 것이 좋습니다. . 마지막으로, 실천에 적용해 보세요. "실천적 진실의 유일한 기준입니다." 두려움은 문제가 되지 않습니다. 절대 성공할 기회가 없습니다.
성숙한 ERP 제품은 완벽한 컨설팅 및 구현 서비스를 위한 탄탄한 기반을 제공합니다
플랫폼 모델에 따른 대규모 맞춤형 개발 및 기업 정보 구축과 비교하여 상대적으로 성숙한 제품이 갖는 고유한 특징은 다음과 같습니다. 이점. 물론, 이 제품이 반드시 구체적이고 실체적인 것일 필요는 없습니다. 우리의 솔루션일 수도 있고, 우리의 플랫폼일 수도 있고, 우리 에이전트의 제품일 수도 있습니다.