Lập kế hoạch quy trình số hướng đến khách hàng an toàn

Đây là gì

Một quy trình hướng đến khách hàng có thể trải rộng trên cổng thông tin, dịch vụ web, trải nghiệm di động, backend, API, nhà cung cấp thanh toán, quy trình hỗ trợ và đội ngũ quản trị. Việc lập kế hoạch cần xác định vai trò người dùng và ranh giới truy cập; xác thực và khôi phục; biểu mẫu, tệp, tin nhắn, bảng điều khiển và trạng thái; các luồng thanh toán, gói đăng ký, hóa đơn, hoàn tiền, hủy gói và quyền sử dụng; quyền sở hữu và thời gian lưu giữ dữ liệu; các tích hợp bên thứ ba; và trách nhiệm vận hành. Kế hoạch cũng cần quyết định di động hay web là phù hợp, backend và API hiện có đã sẵn sàng hay chưa, và ai sẽ phụ trách ghi log, hỗ trợ, thay đổi và bàn giao. Rà soát bảo mật và triển khai phần mềm có thể là các phạm vi riêng biệt.

Dành cho ai

Hướng dẫn này giúp các đội ngũ đang lập kế hoạch:

• Một cổng thông tin khách hàng hoặc đối tác, quy trình tiếp nhận, bảng điều khiển, hành trình thanh toán, chuyển đổi từ web sang di động hoặc ra mắt ứng dụng
• Quyền truy cập theo vai trò, khôi phục tài khoản, tệp, thông tin trạng thái, hỗ trợ và trách nhiệm quản trị
• Một thay đổi sản phẩm liên quan đến backend, API, nhà cung cấp bên thứ ba, trạng thái tính phí hoặc dữ liệu khách hàng hiện có
• Một ranh giới rõ ràng hơn giữa khám phá, thiết kế, triển khai, tăng cường bảo mật, rà soát và quyền sở hữu vận hành sau này

Giúp làm rõ điều gì

Các câu hỏi lập kế hoạch giúp làm rõ:

• Người dùng, vai trò, quy tắc truy cập, khôi phục tài khoản, quyền sở hữu dữ liệu và thời gian lưu giữ đã được hiểu rõ trước khi bắt đầu triển khai hay chưa
• Những biểu mẫu, tệp, tin nhắn, bảng điều khiển, chế độ xem trạng thái, trạng thái thanh toán và quyết định về quyền sử dụng nào vượt qua ranh giới giữa các hệ thống
• Các tích hợp, backend/API, triển khai di động, giai đoạn ra mắt, ghi log, hỗ trợ và quyền sở hữu thay đổi đã sẵn sàng cho một bước tiếp theo có phạm vi hay chưa
• Đội ngũ cần một sprint cổng thông tin, rà soát thanh toán, chuyển đổi từ web sang di động, rà soát mức độ sẵn sàng ra mắt, tăng cường bảo mật website hay công việc khám phá/bản thiết kế sớm hơn

Những gì được bao gồm

• Một danh sách kiểm tra cho người mua bao gồm hành trình, vai trò, truy cập, xác thực, khôi phục, biểu mẫu, tệp, tin nhắn, bảng điều khiển, trạng thái, thanh toán, gói đăng ký, hóa đơn, hoàn tiền, hủy gói, quyền sử dụng, dữ liệu và tích hợp
• Các gợi ý lập kế hoạch về quyền sở hữu quản trị, mức độ sẵn sàng của backend/API, di động so với web, giai đoạn ra mắt, ghi log, hỗ trợ, kiểm soát thay đổi và bàn giao
• So sánh khi nào Secure Client Portal Sprint, Subscription & Payment Infrastructure Security, Secure Web-to-Mobile Launch, App Launch Readiness và Website Performance & Security Hardening có thể phù hợp
• Lời nhắc rằng quy trình, vai trò, tích hợp hoặc quyền sở hữu chưa rõ ràng có thể đòi hỏi công việc khám phá hoặc lập bản thiết kế trước khi triển khai

Những gì không được bao gồm

• Sự đảm bảo về bảo mật, sự phù hợp với quy định, việc thanh toán được chấp thuận, phòng chống gian lận, doanh thu, việc được cửa hàng phê duyệt, thành công khi ra mắt, thời gian hoạt động, hiệu năng hoặc vận hành không gián đoạn
• Tuyên bố rằng một sprint cổng thông tin là một nền tảng SaaS đầy đủ, rằng rà soát thanh toán là chứng nhận PCI hay hoạt động chống gian lận, hoặc rằng triển khai di động tự động làm cho sản phẩm sẵn sàng ra mắt
• Gợi ý rằng tăng cường bảo mật thay thế cho thiết kế ứng dụng, kiểm thử tải, ứng phó sự cố hoặc vận hành liên tục
• Giả định rằng triển khai phần mềm, rà soát bảo mật, phê duyệt của nhà cung cấp và quyền sở hữu lâu dài là một phạm vi tự động duy nhất

Khi nào nên chọn

Hãy sử dụng hướng dẫn này trước khi một thay đổi hướng đến khách hàng trở thành một danh sách tính năng rời rạc. Hướng dẫn hữu ích khi đội ngũ đang quyết định có nên xây dựng một cổng thông tin, thay đổi quyền truy cập, giới thiệu gói đăng ký, mở rộng dịch vụ web sang di động, chuẩn bị ra mắt ứng dụng hay cải thiện website. Nếu quy trình cơ bản, quyền sở hữu, tích hợp hoặc vai trò người dùng vẫn chưa rõ ràng, công việc khám phá hoặc lập bản thiết kế sản phẩm thường có giá trị hơn việc triển khai sớm. Sau đó, một đợt rà soát có phạm vi có thể được thực hiện khi một câu hỏi cụ thể về bảo mật hoặc vận hành đã sẵn sàng.

Phương pháp của chúng tôi

Hãy lập bản đồ hành trình trước khi chọn phương thức triển khai. Bắt đầu với người dùng, vai trò của họ, quyết định truy cập, dữ liệu họ cung cấp hoặc xem, hệ thống sở hữu trạng thái tiếp theo, và đội ngũ chịu trách nhiệm khi có điều gì thay đổi. Theo dõi các trạng thái thanh toán và quyền sử dụng một cách cẩn thận như các màn hình giao diện. Sau đó, xác định các phụ thuộc vào nhà cung cấp và backend, nhu cầu hỗ trợ và ghi log, ràng buộc về di động, quyền sở hữu bản phát hành và yêu cầu bàn giao. Điều này làm rõ quyết định tiếp theo là về triển khai cổng thông tin, logic thanh toán, công việc chuyển đổi từ web sang di động, mức độ sẵn sàng ra mắt, tăng cường bảo mật website hay công việc khám phá sớm hơn. Nó cũng ngăn việc một dịch vụ có phạm vi bị nhầm là trách nhiệm không giới hạn về sản phẩm, vận hành hoặc tuân thủ. Một bản đồ quy trình bằng văn bản cũng có thể ghi lại các luồng thông thường và ngoại lệ: một người dùng mới, một khoản thanh toán thất bại, một lần hủy gói, một tài khoản bị mất, một tệp bị thiếu, sự cố từ nhà cung cấp hoặc một yêu cầu hỗ trợ. Bản đồ cung cấp cho các đội sản phẩm, vận hành, kỹ thuật và hỗ trợ một nơi chung để xác định quyền sở hữu trước khi khách hàng bị ảnh hưởng. Sự rõ ràng đó có thể giảm tình trạng phạm vi bị trôi trong công việc triển khai sau này. Khi kế hoạch phát triển, hãy xem lại bản đồ mỗi khi nhà cung cấp, mô hình thanh toán, vai trò, quy tắc truy cập, API, kênh phát hành hoặc quy trình hỗ trợ thay đổi. Một quy trình trông đơn giản trên sơ đồ có thể có những ngoại lệ quan trọng trên production. Ghi lại những ngoại lệ đó giúp dễ dàng quyết định phạm vi tiếp theo là thiết kế, triển khai, rà soát, tăng cường bảo mật, kiểm thử hay chuẩn bị vận hành. Nó cũng giúp người mua yêu cầu đúng bằng chứng từ nhà cung cấp trước khi đưa ra quyết định. Cuối cùng, hãy dùng bản đồ để quyết định những gì sẽ được đo lường sau khi triển khai và ai sẽ hành động khi có một phát hiện, khoản thanh toán thất bại, tín hiệu hỗ trợ hoặc yêu cầu thay đổi. Một bản bàn giao vững chắc hơn khi nó nêu tên người phụ trách, một mốc rà soát và một ranh giới đã thống nhất, thay vì chỉ liệt kê các tính năng.

Câu hỏi thường gặp

Bài viết liên quan