Làm thế nào AI có thể nâng khả năng đọc hóa đơn và báo cáo lên một tầm cao mới

Làm thế nào AI có thể nâng khả năng đọc hóa đơn và báo cáo lên một tầm cao mới

In
Hóa đơn và báo cáo rất khó giải mã
, chúng tôi lưu ý rằng rất khó đọc các hóa đơn và báo cáo từ ngân hàng, công ty thương mại điện tử, nhà bán lẻ và các ngành khác. Chúng tôi lấy hai ví dụ và tìm hiểu sâu để hiểu toàn bộ vấn đề không thể giải mã được:

  1. Hóa đơn thương mại điện tử
  2. Bảng sao kê ngân hàng

Trong bài đăng này, chúng tôi sẽ xem xét nguyên nhân cốt lõi của vấn đề này và đề xuất một số giải pháp.

----

Có một vài đặc điểm của hóa đơn và báo cáo - chính xác hơn là của hệ thống tạo ra chúng.

Hệ thống hồ sơ có những hạn chế 

Trước đây, hệ thống email chỉ hỗ trợ tám ký tự cho ID (tức là tên xuất hiện trước ký hiệu @ trong địa chỉ email). Kết quả là mọi người phải cắt bớt họ và tên của mình để khớp với giấy tờ tùy thân. Vì vậy, có những địa chỉ email như ravindrn@microsoft.com (anh họ của tôi, một trong 2000 nhân viên đầu tiên của Microsoft) và anilgods@ibm.com (khách hàng của tôi, một cựu chiến binh của IBM). (Cả hai email đều thay đổi để bảo vệ danh tính.)

Tương tự như vậy, thậm chí ngày nay, nhiều hệ thống hồ sơ có giới hạn độ dài ký tự cho các trường khác nhau, ví dụ: Mô tả SKU trong hệ thống nhập đơn hàng và kiểm kê. Tôi nghi ngờ ràng buộc này gây ra khả năng đọc hóa đơn thương mại điện tử kém trong ví dụ đầu tiên.

Hệ thống thanh toán ở hạ lưu

Hóa đơn và báo cáo không được tạo ra từ đầu. Thay vào đó, chúng được tập hợp lại từ dữ liệu được lấy từ các hệ thống xung quanh trong bối cảnh CNTT của các ngân hàng, nhà bán lẻ và các công ty trong các ngành khác. Vì vậy, chúng phải tuân theo câu ngạn ngữ cũ của khoa học máy tính: GIGO – Garbage In, Garbage Out. Mặc dù việc thiết kế lại các hóa đơn và báo cáo có thể cải thiện giao diện của chúng nhưng nó không thể giải quyết được vấn đề cơ bản về khả năng đọc do văn bản khó hiểu/thiếu/cắt xén nhận được từ các hệ thống ngược dòng gây ra.

Hệ thống âm thanh bao quanh nhiều công ty

Vấn đề này càng trở nên trầm trọng hơn khi các “hệ thống bao quanh” nói trên đi qua nhiều công ty, giống như trường hợp xảy ra với các báo cáo ngân hàng. Sự đa dạng của các hệ thống bao gồm ngân hàng lõi, ngân hàng số, các kênh, nhà cung cấp dịch vụ thanh toán và nhà điều hành chương trình, gây ra những thách thức bổ sung về khả năng đọc như sau:

  1. Tin nhắn khó hiểu được người dùng cuối nhập vào các trường văn bản dạng tự do, ví dụ: trường ghi nhớ trong đó người trả tiền nhập mục đích thanh toán. (Ở Úc, một số khách hàng thường xuyên sử dụng trường này để gửi

    tin nhắn lạm dụng
    cho vợ/chồng cũ!)
  2. Rò rỉ, hạn chế và bóp méo dữ liệu của các hệ thống ngược dòng.
  3. Ngắt kết nối do nhiều giao thức được sử dụng để nhắn tin giữa các hệ thống khác nhau, ví dụ: ISO 8587, SWIFT MT, ISO 20022. Mỗi giao thức có các thuộc tính riêng về độ dài trường, hỗ trợ các ký tự đặc biệt, v.v. Do đó, lời tường thuật do người trả tiền nhập vào hệ thống ngân hàng của anh ta không nhất thiết là lời tường thuật mà người nhận thanh toán nhìn thấy trong bảng sao kê tài khoản của ngân hàng. Tôi nghi ngờ điều này dẫn đến việc không thể giải mã được bảng sao kê ngân hàng trong ví dụ thứ hai.
  4. Tương tự như trên đối với các sản phẩm khác nhau, ví dụ: ISO 8587 cho ATM, SWIFT MT cho thanh toán xuyên biên giới, ISO 20022 cho chờ Godot. Do đó, lời tường thuật mà người nhận thanh toán nhìn thấy sẽ khác nhau tùy theo phương thức thanh toán, ví dụ: Tường thuật NEFT khác với tường thuật IMPS ngay cả khi người trả tiền đã sử dụng cùng một tường thuật từ phía mình trong khi bắt đầu cả hai MOP, như được nhấn mạnh trong

    Dữ liệu chuyển tiền nâng cao có thể nhân khối lượng chuyển tiền điện tử
    .
  5. Thiếu dữ liệu do các hạn chế do luật bảo mật dữ liệu áp đặt đối với loại dữ liệu có thể được chuyển từ hệ thống này sang hệ thống khác. Điều này đặc biệt đúng trong các ngành được quản lý như chăm sóc sức khỏe, ví dụ: EHR sẽ hiển thị toàn bộ lịch sử ca bệnh cho mọi bác sĩ điều trị nhưng chỉ giới hạn lịch sử ca bệnh cho các nhà thuốc.

Do những đặc thù này, các mục trong hóa đơn và báo cáo được định hình bởi chất lượng và số lượng dữ liệu trong hệ thống nguồn.

Điều này khiến các công ty thương mại điện tử, ngân hàng và những người khác hầu như không thể tự mình đảm bảo trải nghiệm dễ đọc của hóa đơn / bảng sao kê tổng thể. (Vì lý do ít nhiều giống nhau, việc đối chiếu ngân hàng không đơn giản như người ta thường nghĩ.)

----

Thật hấp dẫn khi tin rằng các nhà bán lẻ, ngân hàng, PSP, nhà cung cấp công nghệ và nhà điều hành chương trình có thể ngồi lại với nhau và thiết kế lại hệ thống của họ sao cho các vấn đề nói trên được hạn chế ngay từ đầu.

Nhưng những người trong ngành sẽ biết rằng niềm tin này gần giống với hy vọng sâu sắc của cựu Phó Tổng thống Hoa Kỳ, Dan Quayle, vào thời điểm xung đột Ả Rập-Israel lên đến đỉnh điểm vài thập kỷ trước:

Tại sao người Do Thái và người Ả Rập không thể ngồi lại với nhau và giải quyết những khác biệt của họ như những Cơ đốc nhân trung thực?

Đó là bởi vì một chương trình thiết kế lại như vậy sẽ tốn rất nhiều tiền và không mang lại lợi nhuận tương xứng.

Các nhà bán lẻ được VC hậu thuẫn không chịu áp lực kiếm lợi nhuận và có thể thực hiện một chương trình như vậy.

Tuy nhiên, các ngân hàng - những người tài trợ cho các quỹ đầu tư mạo hiểm - đang chịu áp lực nặng nề trong việc công bố lợi nhuận hàng quý và thường không chi quá nhiều chất xám hoặc sức mạnh tiền bạc chỉ để ngăn cản khách hàng của họ gãi đầu. Mặc dù, đôi khi, họ vẫn nói suông để làm cho cuộc sống của khách hàng trở nên dễ dàng thông qua những sáng kiến ​​mà bằng cách nào đó dường như không bao giờ thấy được ánh sáng trong ngày, chẳng hạn như các sáng kiến. ISO 20022, Dữ liệu chuyển tiền nâng cao ở Vương quốc Anh.

----

Bất cứ khi nào có vấn đề tồn tại, các công ty khởi nghiệp sẵn sàng nhảy vào cuộc để giải quyết chúng và từ đó ra tay phá hoại những công ty đang hoạt động.

Khả năng đọc hóa đơn và báo cáo cũng không ngoại lệ.

Họ được các VC khuyến khích trong việc theo đuổi mục tiêu này.

@rajeshsawhney: Các ngân hàng không đổi mới. Một chút suy nghĩ và việc thiết kế lại đơn giản các báo cáo ngân hàng có thể mang lại rất nhiều giá trị và niềm vui.

Tuy nhiên, như chúng ta đã thấy ở trên, việc không thể giải mã được không phải là một vấn đề dễ giải quyết.

Chỉ khi các công ty khởi nghiệp xây dựng hệ thống và cố gắng tích hợp chúng với các hệ thống cốt lõi, họ mới nhận ra rằng mình đã đánh giá thấp mức độ nghiêm trọng của vấn đề về khả năng đọc.

Một trong hai điều sau đây xảy ra kể từ đó trở đi.

Tính thanh khoản cao, các công ty khởi nghiệp có đủ vốn để giải quyết vấn đề. Phụ lục A: PayPal.

@gtm360: Sự thiếu hiểu biết có thể là một đức tính tốt cho các công ty khởi nghiệp trong nhiều ngành được quản lý. Như Reid Hoffman đã từng nói, “nếu chúng tôi biết về các quy tắc gian lận thẻ tín dụng, chúng tôi đã không thành lập PayPal”.

Tính thanh khoản thấp, nguồn vốn cạn kiệt trước khi giải quyết được vấn đề, các quỹ đầu tư mạo hiểm chuyển sang ngành khác và các công ty khởi nghiệp này phải đóng cửa. Triển lãm A: Các công ty khởi nghiệp về quản lý tài chính cá nhân (PFM) đã cố gắng phân loại các loại chi phí thành nhiều loại khác nhau dựa trên các mục trong báo cáo ngân hàng. Nhưng họ đã bị cản trở bởi khả năng đọc báo cáo kém từ các ngân hàng, quỹ, công ty môi giới và các tổ chức tài chính khác. Thiếu tính năng sát thủ này, chúng đã không thể trở thành xu hướng chủ đạo.

----

Nhưng mọi thứ chưa hẳn đã mất.

Có một thể loại khởi nghiệp ETL mới hứa hẹn sẽ sử dụng các kỹ thuật AI / ML tiên tiến để cải thiện chất lượng dữ liệu được các hệ thống hạ nguồn, ví dụ:
Tệp phẳng
OneSchema.

Làm thế nào AI có thể nâng khả năng đọc hóa đơn và báo cáo lên cấp độ tiếp theo Thông minh dữ liệu PlatoBlockchain. Tìm kiếm dọc. Ái.

AI / ML có tính đặc thù tên miền cao. Nếu các công cụ ETL này hoạt động trên các hệ thống hồ sơ trong ngân hàng, thương mại điện tử và các ngành khác, cuối cùng chúng có thể giải quyết được vấn đề không thể giải mã và nâng khả năng đọc hóa đơn và báo cáo lên một tầm cao mới.

Dấu thời gian:

Thêm từ tài chính