국내 최대 금융업계 BPO 회사에서 일정 기간 일한 후, 나는 직접 그곳에 수요 분석팀을 구성하여 그곳의 수요 분석을 무에서 유무로, 미성숙에서 성숙으로 옮겼다. 나는 지금 그곳의 사장이 얼마나 만족하는지 생각할 수 없다. 그것은 내가 신입생으로부터 조금씩 길러낸 것이다. 그러나 중국 생명 보험 업계의 BPO 는 여전히 많은 문제와 어려움에 직면해 있으며, 아직 성숙한 업종이라고 할 수 없다. 업계의 성격에 관한 몇 가지 문제는 이전에도 그곳의 지도자들과 언급했지만, 여러 가지 이유로 어떤 것들은 개선되지 않았다. 먼저 BPO 구현 후 생명보험회사에 가져온 문제와 BPO 핵심 처리 시스템 자체의 폐단에 대해 살펴보겠습니다. BPO 통합 처리 시스템과 생명 보험 회사의 핵심 비즈니스 시스템 간에 근본적인 차이가 있기 때문에 생명 보험 비즈니스 프로세스 아웃소싱은 생명 보험 회사에 1, 데이터 수준의 문제 사례 수가 급격히 증가할 수 있습니다. 차분하게 말하자면, 모두 아웃소싱 회사의 문제가 아니라 생명 보험 회사 업무가 표준화되지 않은 이유도 있다. 일반적으로 아웃소싱의 원인은 비교적 많다. 그렇다면 무엇이 문제건수의 급증을 초래했을까요? 나의 과거 경험으로 볼 때, 주로 A, 필연적인 현상, 생명보험회사가 BPO 를 실시하기로 선택한 것은 새로운 계약 처리 프로세스의 필연적인 성장과 과정의 증가를 의미한다. 이는 처리 체인, 통신 체인, 오류 수정 체인의 증가를 의미하므로 문제의 증가는 필연적인 현상이 된다. B, 인간의 요소, 기술이 아무리 진보하더라도, 인간은 여전히 가장 중요한 요소, 즉 이 영원한 진리이다. 생명보험회사의 배경은 BPO 를 실시하기 전에 어떤 수준입니까? 무슨 학력? 당신은 자기 회사의 규칙에 대해 어느 정도 알고 있습니까? 생명보험회사는 BPO 회사의 투입인력에 그 수준을 기대할 수 없다. 그렇지 않으면 BPO 회사는 비용 이점이 없을 것이다. C, 시스템 격차, BPO 는 일반적으로 자신의 종합 입력 플랫폼을 사용하여 다가인 생명회사의 단필록 업무를 처리하는데, 이런 종합 처리 플랫폼의 규칙 통제는 생명보험회사의 생산 시스템과 비교할 수 없는 것이다. (알버트 아인슈타인, Northern Exposure (미국 TV 드라마), 시스템명언) 사실 BPO 가 자신의 노력으로 메울 수 있는 곳이기도 하다. 현재 BPO 처리 시스템의 현재 상황은 입력 작업을 핵심으로 하고, 최소 세분성을 필드로 하는 종합 처리 시스템을 통해 데이터 입력을 실현하고, 각 고객의 요구 사항에 따라 특별히 일련의 출력 프로그램을 개발하는 것이다. 일반적으로 고객이 요구하는 규칙은 출력 프로그램에서 구현되며, 출력에 대한 논리적 검사도 출력 프로그램에서 구현되고 문제 항목에 플래그가 지정됩니다. 지금까지 내가 아는 한, 현재 어떤 BPO 회사도 규칙 엔진을 실현할 수 있는 능력을 가지고 있지 않다. 즉, 기본적으로 BPO 회사가 실현하는 규칙 검사는 사후 검사일 뿐, 표시 문제 부품은 생산 시스템이 보험 규칙을 통제하는 것과 같은 예방 검사가 될 수 없다. 이는 또한 BPO 가 구현하는 대부분의 규칙 검사 및 규칙 변환이 죽은 코드를 작성하여 이루어진다는 것을 의미합니다. 이 경우 BPO 는 매우 완전한 규칙 검사를 수행할 가능성이 거의 없으며 이로 인해 문제 건수가 증가합니다. 2. 일부 BPO 회사들은 생명보험회사 직원들이 이해할 수 없는 실수를 자주 범하기 때문에 더 많은 사람들이 이러한 문제를 제도적인 원인으로 귀결할 수 있다. BPO 가 저지른 실수들 중 일부는 생명 보험 회사의 백그라운드 직원들이 범하는 경우가 많기 때문에 생명 보험 회사 직원들에게는 이해하고 포용할 수 있는 실수들이 있다. 예를 들어, 보험 증권의 주소가 불분명하여 잘못 기입된 문제가 발생했는데, 지금까지 제도적 차원에서 이 문제가 완벽하게 해결되었다고 감히 말할 수 있는 사람은 아무도 없다. (윌리엄 셰익스피어, 햄릿, 보험, 보험, 보험, 보험명언) (여기에 한 가지 더 있습니다. 앞으로 판매 지원 시스템을 구축한 후, 판매 지원 시스템에서 보험 신청의 사전 입력 기능을 실현하면 이 문제와 앞서 언급한 데이터 수준 문제가 너무 많은 문제를 완벽하게 해결할 수 있다는 것을 알게 되었습니다. 하지만 이 아이디어는 이 대리인이나 고객의 수용 능력에 대한 도전에 직면해 있습니다.) 하지만 생명보험회사 직원들의 눈에는 불가능한 문제들이 있어 BPO 회사에 큰 압력을 가하고 있다. 이런 문제에 대해 A, 인적 요소 등 두 가지 주된 이유가 있다고 생각합니다. 이전과 마찬가지로 BPO 의 입학인원이 고등 교육을 받은 생명보험 회사의 배경과 같은 상식과 회사 규칙에 대한 이해를 기대할 수는 없습니다. B, 시스템 격차, 생명보험의 핵심 시스템과 BPO 의 통합 처리 플랫폼 사이에는 큰 차이가 있으며, 가장 중요한 것은 BPO 의 통합 처리 플랫폼에는 핵심 시스템의 영혼인 제품 모듈이 부족하다는 점이다. 즉, BPO 의 통합 처리 플랫폼은 제품 수준과 보다 세부적인 책임 차원의 규칙 검증 및 처리를 할 수 없으며, 보험 규칙의 일반 규칙의 일부만을 처리할 수 있으며, 보험 규칙에 익숙한 사람들은 보험 규칙의 약 20% 를 차지할 것으로 예상하고 있습니다 ... 3 ... 성수기의 위험 문제, 생명보험 회사 SOA 프레임워크의 관점에서 고려할 경우 생명보험 시스템 청구 구성 요소의 성능에 대해 논의하고 있습니다. 보험업계 사람들은 매달 25 일에 선적 피크가 있다는 것을 알고 있다. BPO 는 많은 생명 보험 회사에 서비스를 제공하기 때문에 많은 생명 보험 회사의 피크가 겹쳐져 더 큰 피크를 형성합니다. BPO 의 운영 제공 능력과 시스템 운반 능력에 큰 도전이 될 것입니다. 생명보험회사의 성수기는 매우 시효성이 있지만, 이 시간도 BPO 가 가장 문제가 생기기 쉬운 시기이기도 하다. 이때 가장 쉽게 발생할 수 있는 두 가지 문제가 있다: A, 운송 관리 자원 쟁탈. 생명보험회사가 대량의 보험 입력 작업을 하는 것은 자연스러운 일이며, BPO 가 회사 자체와 그 BPO 가 서비스하는 다른 생명보험회사에 대한 운영배달에 영향을 미칠 수밖에 없다. B, 시스템 운반 능력 문제로 인한 시스템 가동 중지, 대부분의 BPO 는 Oracle, DB2 와 같은 고성능 데이터베이스 소프트웨어나 소형 폼 팩터와 같은 고성능 하드웨어를 적용하지 않았습니다. 실제로 로드 밸런싱 없이 MS SQL 을 사용하여 여러 PC 서버에서 실행하는 것이 좋습니다. PC 서버는 고객별로 분류되기 때문에 한 고객의 업무량이 아무런 징조도 없이 갑자기 증가할 수 있다. 이렇게 많은 BPO 회사의 문제를 말했는데, 사실 업종 분업의 정교화를 부인할 수 없고, 로우엔드 인력이 비교 우위를 발휘할 수 있게 하는 것이 추세다. BPO 도 생명보험업 경영 발전의 중요한 추세 중 하나이다. 여기서 저는 제 경험으로 BPO 시스템의 미래에 대해 말씀드리겠습니다. 1, 시스템 방법론 개선-CMMI 를 포기하고 애자일 개발에 동참합니다. 생명 보험 회사에 비해 BPO 의 가장 큰 장점은 비용입니다. 일반적으로 BPO 는 생명보험회사를 위한 수출절차를 무료로 개발하기 때문에 개발하는 데 걸리는 시간이 중요해진다. 또한 생명 보험 회사의 규칙은 세계에서 가장 다양한 규칙일 수 있으며, 고객의 요구에 신속하고 정확하게 대응하는 방법이 중요해지고 있습니다. 이런 관점에서 볼 때, BPO 의 품제 인선은 ThoughtWorks 에서 고수를 찾아야 한다. 2. 펌웨어 및 어셈블리: 앞서 언급했듯이 BPO 는 고객별로 출력 프로그램을 작성합니다 (고객마다 요구 사항이 다르기 때문). 프로젝트간 출력 프로그램 중 약 60 ~ 70% 의 코드가 중복되므로 비즈니스 논리 처리를 추상화하여 출력 논리 구성 요소를 형성하는 것은 완전히 필요하고 가능합니다. 필요한 경우 구성 요소를 조립하여 테스트할 수 있습니다. 3. 상품화: BPO 회사는 많은 생명보험 업무 논리를 실현할 수 없다. 심층적인 이유는 생명보험 경영 논리의 영혼, 즉 제품 개념의 결핍이다. BPO 가 새로운 계약 업무에서 한 단계 더 나아가야 하는 경우 이 구성 요소 또는 모듈을 구현해야 합니다. 또한 현재 많은 BPO 회사들이 청구 BPO 를 비즈니스의 새로운 성장점으로 삼고 있으며, 여기에 제품화에 대한 수요가 더욱 커지고 있습니다. 제품은 배상 청구의 기초이며,' 단순한 조정 비역사적 청구' 를 실현하려면 제품 이념의 실현을 전제로 해야 합니다. 4. 업계 데이터 교환 기준의 출현을 기대합니다. 현재 BPO 회사와 생명보험회사 간의 데이터 교환은 기본적으로 XML 을 통해 이루어지고 있습니다. XML 의 형식과 데이터 전송 방식은 생명보험회사의 핵심 시스템이 BPO 회사에 제공하는 것입니다. BPO 는 발언권이 없고, 사실상 2 차 개발의 작업량을 증가시켰습니다. 비교적 좋은 생명보험회사들은 BPO 은보통의 업계 규범을 아웃소싱된 데이터 교환 규범으로 줄 것이다. 이 규범 구조는 핵심 플랫폼과 상관없이 과학적이지만, A, 안전한 운영 거래 데이터 형식 정의가 너무 간단해서 은보의 안전 요구 사항을 충족시킬 수 있지만 일반 생명 보험의 복잡한 안전 요구 사항은 충족시킬 수 없다는 한계가 있습니다. 청구 작업 및 거래에 대한 데이터 정의는 없습니다. 현재 모든 청구 BPO 는 데이터 전송을 위해 Excel 을 사용하고 있으며, 데이터 전송의' 칼과 불씨' 시대에 속한다. C. 거래에 대한 조회는 너무 간단해서 배상 청구' 사건 중심' 의 역사적 배상 금액에 대한 조회를 만족시킬 수 없고, 청구 BPO 를 복잡한 방식으로 조정할 수 없고 생명보험 회사 운영 중 가치 사슬 고급으로 나아갈 수 없게 된다.