축하해요. 문제, 프로젝트, 예산 및 기한이 있습니다. 몸을 던지는 대신 소프트웨어가 해결책이지만 이제는 구축할지 구매할지 결정해야 합니다. 그것이 문제입니다. 아니면? 더 이상 명확한 결정인지 확신할 수 없습니다.
필요한 시스템을 코딩하기 위해 사내 프로그래머를 고용하는 것을 의미하는 빌드 사용과 구매 및 실행할 수 있는 기성품을 의미하는 구매를 참조하십시오. 이는 회계 시스템, 거래 시스템, CRM, 보고,
대출, 추심, CLM 등 우리는 지금 코딩 경험이 필요하지 않은 무언가를 구축하는 로우 코드 환경에 살고 있습니다. 드래그 앤 드롭이 가능합니다. 당신이
잘 구축했습니다. 그렇다면 건설 또는 구매 결정을 내리기 위해 우리는 어디에서 떠나게 될까요? 실제로 필요한 것이 무엇인지 살펴보겠습니다.
어떤 최신 시스템도 더 이상 단일 진입점에 의존할 수 없습니다. 고객의 기대에 따라 다양한 채널이 필요합니다. 대면, 직접 전화 또는 콜 센터, 이메일, 소셜 미디어, SMS, 웹, 모바일, 태블릿 – 모바일 지원 및 네이티브
콘텐츠나 컨텍스트를 잃지 않고 상호 교환이 가능해야 합니다. 지점/매장에서 시작하거나 직접 방문하지만 약속을 위해 자리를 비워야 하는 고객은 그날 늦게 온라인으로 로그인할 때 중단한 부분을 선택할 수 있기를 원합니다. 또는
온라인에서 시작했지만 좌절하고 도움을 요청하는 경우 처음부터 프로세스를 시작하고 싶지 않습니다. 이는 내부 이해관계자에게도 적용됩니다. 조직 내의 정보 사슬은 고객이 직면하는 만큼 유연해야 합니다.
옵션을 제공합니다.
그렇다면 어디에서나 데이터 입력을 시작하기 위한 다음 단계는 무엇일까요? 음, 애초에 그 데이터가 필요한 이유가 있습니다. 신규 고객이 조직과 협력하기를 원하든, 기존 고객이 새로운 제품이나 서비스를 원하든, 아니면 일상적인 질문, 불만 사항
또는 정보 요청. 이 모든 것은 가능한 한 효율적이고 쉽게 요청을 완료하기 위해 정의되었지만 유연한 프로세스를 시작해야 합니다. 프로세스는 일반적으로 정의되며 일반적으로 직원은 미리 결정된 작업을 완료하기 위해 일련의 작업을 따르도록 교육받습니다.
특정 데이터 입력에 기반한 조치.
최종 고객이나 시스템 사용자는 정보가 이미 어딘가에 캡처된 경우 어디서든 정보를 다시 입력할 필요가 없습니다. 실제로 정보가 조직 내 어디에서나 데이터 제공자, 신용 조사 기관,
필요한 모든 사용자가 프로세스 전반에 걸쳐 액세스할 수 있어야 합니다. 프로세스는 정의되지만 터치포인트는 전체적으로 상호 교환 가능해야 하며 수집된 데이터는 가능한 경우 통합되고 허용되는 경우 구조화되어야 합니다.
드롭다운 메뉴, 조회 값, 날짜 필드 및 제어된 자유 텍스트 값을 통해 최대한 많은 데이터 품질을 미리 캡처할 수 있습니다. 이를 통해 프로세스 전반에 걸쳐 훨씬 더 많은 자동화가 가능하고 예외 처리가 줄어듭니다.
이제 데이터가 적극적으로 캡처되거나 업데이트되는 과정에 있으므로 인공 지능을 적용할 수 있습니다. 직원은 모든 세부 사항을 알 필요가 없으며 시스템이 정책 코딩 규칙을 사용하기 때문에 신입 회원도 더 복잡한 사례를 처리할 수 있습니다.
이전에는 직원이 처리할 광범위한 교육과 경험이 있어야 했던 결정을 자동으로 내리는 논리. 감독 및 품질 관리 검사 또는 필요한 경우 수동 개입을 위한 완전한 예외 대기열을 허용하면서 더 이상 실수가 없습니다.
이 모든 것은 체계적인 접근이 필요합니다. 고객 포트폴리오를 위해 직원 서랍에 있는 마닐라 폴더에 대한 오래된 아이디어는 구식이며 불필요한 위험을 초래합니다. 격리되어 처리되는 클라이언트는 제한적일 수도 있고 중복적일 수도 있습니다.
동시에. 기업 고객의 이사가 여러 다른 고객과 함께 있는 경우 각 개별 검토가 더 큰 그림을 무시하는 이유는 무엇입니까? 또한 모든 관계에서 동일한 감독을 여러 번 검토할 건가요, 아니면 할 수 있나요?
한 번만 수행하고 조직 전체에서 해당 정보를 재사용합니까?
혜택이 명백해지기 위해 공통 관련 당사자가 있을 필요조차 없습니다. 유사한 산업, 유사한 고객 고객, 고객 벤더/공급업체가 고객이기도 한 경우에는 어떻게 됩니까? 이를 통해 정보를 처리하는 방법을 알 수 있습니다.
오늘날 조직이 소프트웨어를 고려할 때 기업 전체를 살펴봐야 하는 이유. 문제를 따로따로 보고 예산을 설정하고 각 CRM, Fincrime, Client Outreach 구성 요소에 대한 RFP를 발행하는 것으로 취급하면 결국
처음에 기대했던 잠재적인 절약보다 더 많은 자원을 사용하여 모든 것을 통합하려고 합니다. 이제 별도의 예산과 감독을 받을 수 있는 모든 지역 또는 비즈니스 라인에 적용하면 8개 버전이 생성됩니다.
영역당 과도한 사용자 정의로 인해 자체적으로 통합해야 하는 동일한 소프트웨어의 경우 달성할 수 있는 규모의 경제를 제거합니다.
매년 또는 다른 방식으로 검토해야 하는 서랍의 폴더로, 직원은 무엇을 언제 수행해야 하는지 교육을 받아야 합니다. 전체 리뷰(또는 새로운 온보딩/추가 제품/서비스/등)는 복합적인 부분으로 나눌 수 있습니다.
다른 사람/팀에서 처리할 수 없습니다. 그런 다음 시스템은 작업이 완료되는 시기 또는 입력을 위해 다음 사람에게 보낼 충분한 데이터가 캡처되는 시기를 결정할 수 있습니다. 이 모든 것은 내부의 사례 및 하위 사례로 구성됩니다. 이렇게 각 요소의
사례에는 고유한 기한, 에스컬레이션 경로, 담당자 및 승인자가 있을 수 있습니다. 직원이 완료 방법과 내부의 다양한 요소에 대해 누구에게 가야 하는지를 알기에 충분히 경험해야 하는 하나의 큰 작업 대신 이제 시스템에서 작업을 할당합니다.
의사 결정권자가 중요한 일에 집중할 수 있도록 가능한 한 많은 작업을 자동화하여 회사 전체에서 적시에 완료되도록 합니다.
이것은 비즈니스 관점에서 볼 때 모두 훌륭하고 좋습니다. 작업이 알려져 있고 수행해야 할 작업이 있습니다. 그러나 우리가 소프트웨어를 직접 구매해야 하는지 또는 직접 구축해야 하는지를 결정할 때 그것이 어떻게 영향을 미칩니 까? 여러 소스가 있다고 가정해 봅시다.
여러 시스템에 걸친 데이터. 모든 최신 시스템은 API 기반이며 코드가 적거나 코드가 없는 기능이 있어야 합니다. 더 빠르고 유연한 소프트웨어에 대한 합리적인 가정. 오늘날의 모든 것은 피하기 위해 일종의 마이크로서비스로 취급되어야 합니다.
구식 소프트웨어 모놀리식. 소프트웨어는 필요에 따라 변경 사항에 적응할 수 있는 최고의 가용성과 미래 경쟁력을 갖추었기 때문에 설치하고 사용해야 합니다. 너무 많은 제품이 너무 어렵고 시간이 많이 걸리기 때문에 확고하고 유지 관리됩니다.
교체. 이것의 대부분은 규칙이 하드 코딩되어 있고 아마도 데이터 자체와 얽혀 있기 때문입니다.
전체 시스템이 중단될 수 있습니다. 오래된 사고 과정이 너무 많습니다. 깨지지 않았다면 고치지 마십시오. 실제로 필요한 것은 이러한 모든 구성 요소가 마이크로서비스가 되어 필요한 데이터를 가져오고 자동화된 규칙 또는 사용자 입력/검토를 적용하는 것입니다.
다음 마이크로서비스로 전달합니다. 데이터는 둘 이상의 위치에 저장되어서는 안 됩니다. 연합될 수 있지만 백업 외부에서 복제되지는 않습니다. CRM, 온보딩, KYC, 클라이언트 아웃리치 등의 시스템은 필요한 데이터에만 액세스해야 합니다.
하나를 선택하지 않는 한 데이터 저장소 자체가 됩니다. 여러 위치에 걸쳐 동일한 데이터를 복제하고 이를 관리하는 규칙은 추가되는 모든 추가 시스템이 관련 복잡성을 배가시키므로 무의미한 작업입니다.
이것은 우리에게 최종 고려 사항을 제공합니다. 신뢰할 수 있는 단일 출처/Golden Copy 또는 이를 업데이트할 수 있는 여러 개의 중복 및 경쟁 레코드 및 시스템이 있든 관계없이 계속해서 요구 사항의 라인을 기반으로 하는 또 다른 계층의 요구 사항에 직면하게 됩니다.
비즈니스, 관할권, 클라이언트 유형 및 제품/서비스. 개인은 회사 또는 신탁과 다르게 취급되며 요구 사항 및 적합성에 대해 소비자/소매, 상업 또는 기업 비즈니스 라인에 따라 다릅니다. 가장 기본적인 예에서
우리는 10가지 유형의 고객(개인 – 독신, 기혼 등, 개인 회사, 공기업, 신탁, 자선 단체 등)을 보유하고 있으며 귀하는 10개 지역에서 운영할 수 있으며 10가지 유형의 제품/서비스를 제공할 수 있습니다. 우리는 이미 잠재적으로 1000개 이상의 규칙
에 쓰이는. 지역, 비즈니스 라인, 고객 유형 및 제품 또는 서비스에 대한 규칙을 정의하고 대신 시스템이 요구 사항을 해결하도록 하는 것이 훨씬 더 쉽지 않을까요? 중복 제거 및 이전에 사용했던 데이터 포인트 재사용
제공. 이는 데이터 계층에서 프로세스와 규칙을 추상화하는 이점입니다.
이제 소프트웨어 구매 또는 구축에 대한 오래된 질문을 고려할 때 옴니 채널 오케스트레이션, 가능한 경우 프로세스 자동화, 유연한 규칙 논리, 감독 및 감사 가능성을 위한 사례 관리, 로우 코드 및 API 기반, 추상화가 필요하다는 것을 알고 있습니다.
데이터 계층 및 다른 논리 계층에서 상속할 수 있는 지능형 규칙 엔진. 기술 시장은 생각할 수 있는 모든 틈새 문제를 기꺼이 만족시키는 혁신가들로 가득 차 있지만 어느 시점에서 '기성품'이 이치에 맞지 않게 됩니까?
직접 구축하는 대신 모든 제품을 맞춤화하고 서로 통합해야 합니다. 로우 코드 플랫폼을 사용하면 요구 사항의 80%를 사용할 수 있으며 델타는 20%만 구성하면 됩니다. 두 세계의 장점은 낮은
다른 사람들도 재사용 가능한 구성 요소를 구축한 코드 플랫폼이므로 직원 또는 인증된 제3자가 특정 요구 사항의 나머지 부분을 구축할 수 있는 기능을 보유하면서 비즈니스를 위한 가속기로 '기성품' 제품을 얻을 수 있습니다.
당신의 조직에. 구매할 것인가, 구축할 것인가? 정말 둘 다여야 합니다.
