Câu hỏi vĩnh cửu về việc nên mua hay xây dựng phần mềm của bạn (James Monaghan)

Chúc mừng. Bạn có một vấn đề, một dự án, ngân sách và thời hạn. Thay vì ném xác vào nó, phần mềm là giải pháp nhưng bây giờ bạn cần quyết định xây dựng hay mua, đó là câu hỏi. Hoặc là nó? Tôi không chắc đó là một quyết định rõ ràng nữa.
Xây dựng được sử dụng để chỉ việc thuê các lập trình viên nội bộ để viết mã cho bất kỳ hệ thống nào cần thiết và mua được đề cập đến các sản phẩm có sẵn có thể được mua và chạy. Điều này có ý nghĩa khi chúng ta nói về hệ thống kế toán, Hệ thống giao dịch, CRM, Báo cáo,
Cho vay, Bộ sưu tập, CLM, v.v. Hiện chúng ta đang sống trong môi trường mã thấp, nơi việc xây dựng thứ gì đó không yêu cầu kinh nghiệm viết mã. Nó có thể được kéo và thả. Kết hợp điều đó với việc mua các giải pháp giảm giá cuối cùng được tùy chỉnh đến mức bạn có thể
cũng đã xây dựng nó. Vì vậy, điều đó khiến chúng ta phải đưa ra quyết định xây dựng hay mua ở đâu? Hãy nhìn vào những gì chúng ta thực sự cần.

Không có hệ thống hiện đại nào có thể dựa vào một điểm vào duy nhất nữa. Kỳ vọng của khách hàng chỉ ra rằng các kênh khác nhau là cần thiết. Trực tiếp, qua điện thoại trực tiếp hoặc tổng đài, email, mạng xã hội, SMS, web, điện thoại di động, máy tính bảng – cả hỗ trợ di động và bản địa
ứng dụng, tất cả đều cần có thể hoán đổi cho nhau mà không làm mất nội dung hoặc ngữ cảnh. Một khách hàng bắt đầu tại chi nhánh/cửa hàng hoặc trực tiếp nhưng phải đến một cuộc hẹn muốn có thể tiếp tục ở nơi họ đã dừng lại khi họ đăng nhập trực tuyến vào cuối ngày hôm đó. Hoặc
nếu họ bắt đầu trực tuyến nhưng cảm thấy thất vọng và gọi trợ giúp, họ không muốn phải bắt đầu quá trình từ đầu. Điều này cũng áp dụng cho các bên liên quan nội bộ. Chuỗi thông tin trong một tổ chức cần phải linh hoạt như khách hàng phải đối mặt
tùy chọn. 

Vì vậy, điều gì tiếp theo cho đầu vào dữ liệu bắt đầu ở bất cứ đâu của chúng tôi? Vâng, có một lý do chúng tôi cần dữ liệu đó ngay từ đầu. Cho dù khách hàng mới muốn làm việc với tổ chức, khách hàng hiện tại muốn có sản phẩm hoặc dịch vụ mới hay thậm chí chỉ là những thắc mắc, khiếu nại hàng ngày
hoặc yêu cầu thông tin. Tất cả những điều này nên bắt đầu các quy trình được xác định nhưng linh hoạt để hoàn thành yêu cầu một cách hiệu quả và dễ dàng nhất có thể. Quy trình này được xác định chung và nhân viên thường được đào tạo để tuân theo một chuỗi các nhiệm vụ nhằm hoàn thành nó với các mục tiêu được xác định trước.
hành động dựa trên đầu vào dữ liệu nhất định. 

Cả khách hàng cuối và người dùng hệ thống đều không phải nhập lại thông tin chính ở bất kỳ đâu nếu thông tin đó đã được ghi lại ở đâu đó. Trên thực tế, nếu thông tin có sẵn ở bất kỳ đâu trong tổ chức hoặc từ các nguồn bên thứ 3 như nhà cung cấp dữ liệu, văn phòng tín dụng,
sàng lọc các nhà cung cấp dịch vụ, v.v. nó sẽ có thể truy cập được trong suốt quá trình cho tất cả những người dùng cần nó. Quy trình được xác định nhưng các điểm tiếp xúc phải được hoán đổi cho nhau trong suốt quá trình và dữ liệu thu thập được phải được tích hợp khi có thể và có cấu trúc khi được phép.
Menu thả xuống, giá trị tra cứu, trường ngày tháng và giá trị văn bản tự do được kiểm soát để đảm bảo chất lượng dữ liệu được thu thập trước nhiều nhất. Điều này cho phép tự động hóa nhiều hơn trong suốt quá trình và xử lý ngoại lệ ít hơn.

Bây giờ dữ liệu đang trong quá trình được thu thập hoặc cập nhật tích cực, trí tuệ nhân tạo có thể được áp dụng. Nhân viên không cần phải biết tất cả các chi tiết và thậm chí các thành viên mới hơn có thể làm việc với các trường hợp phức tạp hơn vì hệ thống đang sử dụng các quy tắc được mã hóa chính sách
logic để tự động đưa ra các quyết định mà trước đây nhân viên phải được đào tạo chuyên sâu và có kinh nghiệm mới xử lý được. Không còn sai sót trong khi vẫn cho phép giám sát và thậm chí kiểm tra kiểm soát chất lượng hoặc xếp hàng ngoại lệ hoàn toàn để can thiệp thủ công nếu cần.

Tất cả điều này đòi hỏi một cách tiếp cận có hệ thống. Ý tưởng cũ về một thư mục manilla nằm trong ngăn kéo của nhân viên cho danh mục khách hàng của họ đã lỗi thời và tạo ra rủi ro không cần thiết. Các máy khách được xử lý riêng biệt có thể vừa hạn chế vừa dư thừa
đồng thời. Nếu một khách hàng doanh nghiệp có các giám đốc ngồi chung với nhiều khách hàng khác, thì tại sao mỗi đánh giá riêng lẻ lại bỏ qua bức tranh toàn cảnh hơn. Bạn cũng sẽ xem xét cùng một giám đốc nhiều lần trong mọi mối quan hệ hay bạn có thể
làm điều đó một lần và sử dụng lại thông tin đó trong toàn tổ chức?

Họ thậm chí không cần phải có các bên liên quan chung để có được lợi ích rõ ràng. Các ngành tương tự, các khách hàng khách hàng tương tự nhau, điều gì sẽ xảy ra nếu chính các nhà cung cấp/nhà cung cấp khách hàng của bạn cũng là khách hàng? Điều này đưa chúng tôi đến cách bạn cần xử lý thông tin
và tại sao ngày nay các tổ chức cần xem xét toàn bộ doanh nghiệp khi xem xét phần mềm. Nếu bạn xem xét một vấn đề một cách cô lập và xử lý nó như vậy, thiết lập ngân sách và phát hành RFP cho từng thành phần CRM, Fincrime, Tiếp cận khách hàng, bạn sẽ kết thúc
với việc chi tiêu nhiều nguồn lực hơn để cố gắng tích hợp mọi thứ lại với nhau hơn bất kỳ khoản tiết kiệm tiềm năng nào được kỳ vọng ban đầu. Bây giờ hãy áp dụng điều đó cho mọi khu vực hoặc lĩnh vực kinh doanh có thể có ngân sách và sự giám sát riêng biệt và bạn sẽ có 8 phiên bản
của cùng một phần mềm cần được tích hợp với chính nó do tính tùy chỉnh cao trên mỗi khu vực loại bỏ mọi nền kinh tế theo quy mô mà chúng có thể đạt được.

Một thư mục trong ngăn kéo cần được xem xét hàng năm hoặc theo cách khác, với nhân viên cần được đào tạo về những việc cần làm và khi nào nên làm. Toàn bộ đánh giá (hoặc giới thiệu mới/sản phẩm/dịch vụ bổ sung/v.v.) có thể được chia thành các phần tổng hợp có thể hoặc
có thể không được xử lý bởi những người/nhóm khác. Sau đó, hệ thống có thể xác định khi nào một nhiệm vụ hoàn thành hoặc khi nào đủ dữ liệu được thu thập để gửi cho người tiếp theo để họ nhập dữ liệu. Tất cả những thứ này được cấu trúc thành các trường hợp và trường hợp phụ bên trong. Bằng cách này, mỗi phần tử của
trường hợp có thể có thời hạn riêng, lộ trình leo thang, người được giao và người phê duyệt. Thay vì một nhiệm vụ lớn mà một nhân viên cần phải có đủ kinh nghiệm để biết cách hoàn thành và liên hệ với ai đối với các yếu tố khác nhau bên trong, giờ đây hệ thống sẽ phân công công việc
và đảm bảo hoàn thành kịp thời trên toàn công ty với càng nhiều nhiệm vụ được tự động hóa càng tốt để những người ra quyết định rảnh tay tập trung vào những việc quan trọng.

Đây là tất cả tốt và tốt từ quan điểm kinh doanh. Công việc được biết và những gì cần phải được thực hiện. Nhưng khi chúng tôi đang cố gắng quyết định xem chúng tôi nên mua hay tự xây dựng phần mềm, thì yếu tố đó ảnh hưởng như thế nào đến mọi thứ? Chà, giả sử có nhiều nguồn
của dữ liệu trên nhiều hệ thống. Bất kỳ hệ thống hiện đại nào cũng phải được điều khiển bằng API và có khả năng mã thấp/không có mã. Một giả định hợp lý cho phần mềm nhanh hơn và linh hoạt. Mọi thứ ngày nay cần được coi là một loại dịch vụ siêu nhỏ để tránh
các nguyên khối phần mềm kiểu cũ. Phần mềm nên được cài đặt và sử dụng vì nó là phần mềm tốt nhất hiện có và được chứng minh trong tương lai để thích ứng với thay đổi khi cần thiết. Quá nhiều dịch vụ cố thủ và chỉ duy trì vì quá khó và tốn thời gian
thay thế. Hầu hết điều này là do các quy tắc được mã hóa cứng, có thể được gắn liền với chính dữ liệu, dữ liệu không chỉ được tích hợp mà còn được sao chép nhiều lần cho từng phần mềm riêng biệt trong chuỗi thông tin và nếu bạn cố gắng thay thế một phần,
toàn bộ hệ thống có thể phá vỡ. Tư duy cũ quá nhiều, không hỏng thì không sửa. Điều thực sự cần thiết là để tất cả các thành phần đó trở thành microservice, lấy dữ liệu cần thiết, áp dụng các quy tắc tự động hoặc đầu vào/đánh giá của người dùng và
chuyển nó đến microservice tiếp theo. Dữ liệu không nên được lưu trữ ở nhiều hơn một vị trí. Nó có thể được liên kết nhưng không được sao chép bên ngoài các bản sao lưu. Các hệ thống CRM, Onboarding, KYC, Client Outreach, v.v. của bạn chỉ nên truy cập vào dữ liệu họ cần chứ không phải
tự trở thành kho lưu trữ dữ liệu trừ khi bạn đã chọn một kho dữ liệu. Sao chép cùng một dữ liệu trên nhiều địa điểm và các quy tắc chi phối dữ liệu đó là một bài tập vô ích vì mọi hệ thống bổ sung được thêm vào sẽ nhân lên gấp bội sự phức tạp liên quan.

Điều này đưa chúng ta đến sự xem xét cuối cùng. Cho dù bạn có một nguồn sự thật/Bản sao vàng hay nhiều hồ sơ và hệ thống cạnh tranh và dư thừa có thể cập nhật chúng, bạn vẫn sẽ thấy mình ở một lớp yêu cầu khác dựa trên dòng
kinh doanh, quyền tài phán, loại khách hàng và sản phẩm/dịch vụ. Một cá nhân được đối xử khác với một công ty hoặc quỹ tín thác và khác nhau tùy theo ngành nghề kinh doanh của người tiêu dùng/bán lẻ, thương mại hoặc công ty về các yêu cầu và sự phù hợp. Ở những ví dụ cơ bản nhất nếu
chúng tôi có 10 loại khách hàng (cá nhân - độc thân, đã kết hôn, v.v., công ty tư nhân, công ty đại chúng, ủy thác, từ thiện, v.v.) và bạn có thể hoạt động ở 10 khu vực và bạn có thể cung cấp 10 loại sản phẩm/dịch vụ, chúng tôi đã sẵn sàng có khả năng hơn 1000 quy tắc có thể
được áp dụng. Sẽ không dễ dàng hơn nhiều nếu xác định các quy tắc cho một khu vực, cho một ngành kinh doanh, cho một loại khách hàng và các sản phẩm hoặc dịch vụ và để hệ thống giải quyết các yêu cầu thay thế? Loại bỏ các điểm trùng lặp và sử dụng lại các điểm dữ liệu trước đây
cung cấp. Đây là lợi ích của việc trừu tượng hóa quy trình và quy tắc của bạn từ lớp dữ liệu của bạn. 

Vì vậy, bây giờ khi chúng tôi xem xét câu hỏi cũ về việc mua hoặc xây dựng phần mềm, chúng tôi biết rằng chúng tôi cần điều phối đa kênh, tự động hóa quy trình nếu có thể, logic quy tắc linh hoạt, quản lý trường hợp để giám sát và khả năng kiểm toán, mã thấp và điều khiển API, một bản tóm tắt
lớp dữ liệu và một công cụ quy tắc thông minh có thể kế thừa từ các lớp logic khác nhau. Thị trường công nghệ có rất nhiều nhà đổi mới, những người sẵn sàng đáp ứng mọi vấn đề ngách có thể nghĩ đến nhưng tại thời điểm nào thì việc 'ra khỏi giá' không còn ý nghĩa nữa
tất cả các sản phẩm cần được tùy chỉnh và tích hợp với nhau thay vì tự xây dựng. Các nền tảng mã thấp có thể cho phép bạn có sẵn 80% yêu cầu của mình và bạn chỉ cần định cấu hình 20% đồng bằng đó. Điều tốt nhất của cả hai thế giới là mức thấp
nền tảng mã mà những người khác cũng đã xây dựng các thành phần có thể tái sử dụng để bạn có thể lấy các sản phẩm 'có sẵn' làm công cụ tăng tốc cho doanh nghiệp của mình đồng thời giúp nhân viên của bạn hoặc bên thứ ba được chứng nhận có khả năng xây dựng phần còn lại của các yêu cầu cụ thể
cho tổ chức của bạn. Để mua hoặc để xây dựng? Nó thực sự nên là cả hai.