Sản phẩm hóa doanh nghiệp dịch vụ: từng quy trình một

Tại sao cố gắng số hóa mọi thứ lại thất bại

Cố gắng thay đổi cả doanh nghiệp cùng lúc nghe có vẻ hiệu quả. Thực tế, điều đó thường che giấu vấn đề thực sự.

Hầu hết doanh nghiệp dịch vụ không chỉ có một hệ thống bị hỏng. Họ có một đống những khe hở nhỏ làm công việc chậm lại mỗi ngày. Một báo giá mất quá nhiều thời gian để phê duyệt. Một biểu mẫu khách hàng thiếu thông tin quan trọng. Một bàn giao giữa bán hàng và triển khai nằm trong inbox của ai đó. Khi tất cả những điều đó được gộp vào một dự án số lớn, các phần lộn xộn biến mất dưới công đoạn cấu hình phần mềm, các cuộc họp và quy tắc mới.

Các nhóm cũng giữ thói quen cũ trong khi học công cụ mới. Ai đó nhập cùng thông tin khách hàng ở hai chỗ. Người khác vẫn xin phê duyệt qua chat vì cảm thấy nhanh hơn. Thay vì một quy trình gọn gàng, bạn sẽ chạy hai hệ thống song song. Công việc trở nên nặng nề hơn trước khi tốt lên.

Chi phí xuất hiện sớm, trong khi kết quả thường đến muộn. Bạn phải trả cho việc thiết lập, đào tạo, thay đổi quy trình và thời gian mọi người mất khi thích nghi. Nếu điều đầu tiên đội nhận thấy là sự bối rối chứ không phải nhẹ nhõm, niềm tin giảm nhanh. Đó là một lý do khiến các dự án chuyển đổi lớn bị đình trệ.

Những điều thường hỏng đầu tiên khá đơn giản:

• Mọi người được yêu cầu thay đổi quá nhiều bước cùng lúc.
• Những quyết định quy trình tệ bị đóng đinh vào công cụ mới.
• Nhân sự tạo ra các cách làm tạm để họ vẫn phục vụ khách hàng.
• Lãnh đạo kỳ vọng tiết kiệm trước khi quy trình ổn định.

Niềm tin là thứ khó giành lại nhất. Nếu lần triển khai đầu cảm thấy lộn xộn, người ta ngừng tin thay đổi tiếp theo sẽ giúp được gì. Khi đó ngay cả bản cập nhật tốt cũng gặp sự chống đối.

Cách tiếp cận tốt hơn là nhỏ hơn và thực dụng hơn. Bắt đầu với một quy trình mà mọi người đã cảm nhận hằng ngày. Một quy trình báo giá, onboarding khách hàng, hoặc luồng phê duyệt dễ thử hơn, dễ cải thiện hơn và dễ được đội chấp nhận hơn.

Ngay cả với công cụ xây dựng nhanh như Koder.ai, thay thế mọi quy trình cùng lúc thường tạo nhiều tiếng ồn hơn tiến triển. Một chiến thắng rõ ràng tạo động lực. Một cuộc đại tu toàn công ty thường thiêu rụi nó.

Sản phẩm hóa một quy trình thực sự có nghĩa là gì

Sản phẩm hóa một doanh nghiệp dịch vụ không có nghĩa là biến toàn bộ công ty thành phần mềm qua đêm. Nó nghĩa là lấy một phần công việc lặp lại và khiến nó chạy cùng một cách, mỗi lần.

Công việc không còn chỉ sống trong đầu một người. Nó trở thành một chuỗi rõ ràng: thứ gì đến, chuyện gì xảy ra tiếp theo, ai kiểm tra, và thứ gì được giao ở cuối.

Một quy trình tốt có điểm khởi đầu và vạch kết thúc. Một quy trình báo giá có thể bắt đầu khi một khách hàng tiềm năng điền một bản tóm tắt ngắn và kết thúc khi khách nhận được giá, phạm vi và thời gian họ có thể phê duyệt. Nếu những điểm đó mơ hồ, công việc vẫn sẽ lộn xộn.

Sản phẩm hóa cũng có nghĩa là dùng cùng đầu vào mỗi lần. Nếu mỗi khách gửi thông tin khác nhau dưới nhiều định dạng, đội của bạn lãng phí giờ theo đuổi thông tin thiếu. Một biểu mẫu ngắn, một danh sách kiểm tra hoặc một mẫu yêu cầu chuẩn có thể khắc phục nhanh.

Phần giữa cũng quan trọng. Công việc lặp lại trở nên dễ hơn khi các kiểm tra xảy ra theo cùng một thứ tự. Bạn không loại bỏ phán đoán con người. Bạn quyết định phán đoán nên xuất hiện ở đâu thay vì để nó xuất hiện ngẫu nhiên.

Trong hầu hết trường hợp, một quy trình chắc chắn có năm phần:

• một kích hoạt rõ ràng để bắt đầu công việc
• thông tin tiêu chuẩn được thu thập ngay từ đầu
• một vài kiểm tra trước khi bất cứ điều gì tiến lên
• một chủ sở hữu cho mỗi bước
• một định nghĩa rõ ràng về khi nào là xong

Khi những mảnh đó được đặt vào, giá cả và thời gian trở nên dễ dự đoán hơn. Bạn bắt đầu thấy các mô hình: công việc mất bao lâu, nơi nào bị trì hoãn, và yêu cầu nào nằm ngoài gói chuẩn. Điều đó làm cho việc định giá tự tin hơn và quản lý kỳ vọng của khách dễ hơn.

Sở hữu cũng cải thiện. Khi mọi người biết ai chịu trách nhiệm xem xét, phê duyệt và bàn giao, ít công việc bị kẹt hơn.

Hãy hình dung một agency nhỏ gửi đề xuất. Trước khi sản phẩm hóa, mỗi báo giá được xây từ đầu, phê duyệt diễn ra qua chat, và không ai biết ai nên theo dõi. Sau khi sản phẩm hóa, agency dùng một biểu mẫu tiếp nhận, một bước review, một quy tắc phê duyệt và một định dạng đề xuất. Dịch vụ vẫn mang tính tùy chỉnh, nhưng quy trình không còn hỗn loạn.

Đó là sự chuyển dịch thực sự: không phải bớt chăm chút, mà bớt đoán mò.

Chọn quy trình đầu tiên để sửa

Nơi tốt nhất để bắt đầu không phải là vấn đề lớn nhất trong công ty. Mà là nhiệm vụ xuất hiện hàng tuần, theo một mẫu quen thuộc, và lãng phí thời gian cùng cách lặp lại mỗi lần. Tìm công việc lặp trước khi tìm công việc hoàn hảo.

Một quy trình đầu tiên mạnh thường có hai dấu hiệu. Nhân viên đã biết các bước theo trí nhớ vì họ làm quá thường, và khách hàng cảm nhận được sự chậm trễ khi nó hỏng. Điều đó làm giá trị hiển thị ngay lập tức.

Báo giá là điểm khởi đầu tuyệt vời cho nhiều đội. Một cuộc gọi bán hàng diễn ra, thu thập chi tiết, ai đó định giá công việc, và một báo giá được gửi đi. Nếu điều đó mất hai ngày trong khi lẽ ra mất hai giờ, cả đội và khách đều cảm nhận được.

Onboarding và phê duyệt cũng là lựa chọn tốt. Chúng thường bao gồm quyết định đơn giản như có hay không, hoàn chỉnh hay chưa, phê duyệt hay trả lại. Quyết định rõ ràng dễ chuyển thành quy trình lặp hơn so với công việc phụ thuộc nhiều vào phán đoán mỗi lần.

Trước khi chọn quy trình, kiểm tra vài dấu hiệu cơ bản:

• Nó xảy ra ít nhất hàng tuần.
• Trì hoãn làm nhân viên hoặc khách bực bội.
• Các bước hầu hết giống nhau mỗi lần.
• Có các điểm quyết định rõ ràng.
• Thành công dễ đo lường.

Tránh dự án hiếm, các trường hợp méo mó và công việc tùy biến cao ở giai đoạn đầu. Nếu mỗi yêu cầu khác nhau, bạn sẽ mất nhiều thời gian xử lý ngoại lệ hơn là cải thiện quy trình. Điều đó thường tạo ra một hệ thống lộn xộn mà chẳng ai tin tưởng.

Một agency nhỏ là ví dụ tốt. Thay vì cố tự động hóa đề xuất, triển khai, thanh toán, tuyển dụng và báo cáo cùng lúc, họ bắt đầu với phê duyệt thay đổi phạm vi. Một sửa đơn lẻ như vậy cắt bớt trao đổi qua lại, cho khách câu trả lời nhanh hơn, và tạo hồ sơ rõ ràng.

Nếu bạn dùng Koder.ai để xây công cụ nội bộ hoặc ứng dụng đơn giản cho khách, một quy trình tập trung cũng dễ ra mắt nhanh. Một quy trình lặp với kết quả rõ ràng cho bạn điểm bắt đầu sạch và cho thấy điều cần cải thiện tiếp theo.

Vẽ sơ đồ quy trình trên một trang

Trước khi tự động hóa bất cứ điều gì, đưa quy trình ra khỏi đầu mọi người và lên một trang. Điều đó đủ để cho thấy chuyện gì thực sự xảy ra từ đầu đến cuối mà không che giấu các phần lộn xộn.

Giữ nó đơn giản. Mở một tài liệu, bảng trắng hoặc ghi chú và viết các bước bằng ngôn ngữ đơn giản, theo cách đội của bạn sẽ nói to: "khách yêu cầu báo giá," "bán hàng xem lại phạm vi," "đề xuất được phê duyệt," "hóa đơn được gửi."

Với mỗi bước, ghi lại năm thứ:

• chuyện gì xảy ra
• ai đang làm nó hiện nay
• cần thông tin gì
• nơi nào thường xảy ra trì hoãn
• bước đó có thực sự tạo giá trị rõ ràng không

Nhiều doanh nghiệp phát hiện vấn đề thực sự ở đây. Vấn đề thường không nằm ở công việc mà là sự chờ đợi, trao đổi qua lại, hoặc chi tiết quan trọng nằm trong inbox hay ký ức ai đó.

Một ví dụ đơn giản làm rõ điều này. Hãy tưởng tượng một agency nhỏ tạo báo giá. Một lead đến, một account manager hỏi vài câu, một designer đưa ước tính, nhà sáng lập kiểm tra giá, rồi báo giá được gửi. Trên giấy tờ điều đó nghe ổn. Nhưng sơ đồ có thể cho thấy designer chờ hai ngày vì thiếu chi tiết dự án, và nhà sáng lập kiểm tra lại giá đã được phê duyệt tháng trước.

Loại sơ đồ đó cho bạn thứ hữu ích: danh sách điểm ma sát bạn thực sự có thể sửa. Có thể biểu mẫu tiếp nhận cần thêm ba câu hỏi. Có thể phê duyệt chỉ cần cho các dự án vượt một mức nhất định. Có thể một bàn giao hoàn toàn có thể bị loại bỏ.

Hãy nghiêm khắc trong việc loại bỏ các bước không thay đổi kết quả. Nếu một bước tồn tại chỉ vì "chúng ta luôn làm thế," xem đó là dấu hiệu cảnh báo. Giữ lại phần giảm rủi ro, cải thiện chất lượng, hoặc giúp khách. Cắt bỏ phần còn lại.

Nếu bạn dự định xây quy trình trong Koder.ai, bản đồ một trang đó cũng trở thành một brief xây dựng vững chắc. Bạn đã biết các bước, người tham gia, đầu vào và quy tắc. Điều đó làm phiên bản đầu dễ tạo và thử hơn.

Cách biến nó thành một sản phẩm đơn giản

Khi quy trình rõ, hãy cho nó một đường đi mặc định. Mục tiêu không phải bao phủ mọi ngoại lệ. Mục tiêu là làm cho trường hợp phổ biến trở nên dễ, nhanh và nhất quán.

Bắt đầu bằng việc chọn một cách tiêu chuẩn để nhận yêu cầu. Nếu khách có thể gửi email, nhắn tin, gọi và ghi âm giọng nói, đội của bạn sẽ tiếp tục đoán thiếu gì. Một biểu mẫu tiếp nhận đơn giản hoặc trang yêu cầu hướng dẫn hiệu quả hơn vì nó hỏi cùng thông tin mỗi lần.

Tiếp theo, định nghĩa phạm vi cố định cho các công việc bạn gặp lại nhiều lần. Thay vì nói "báo giá tùy chỉnh có sẵn," bạn có thể cung cấp ba gói cập nhật website với giới hạn rõ, khung giá và thời gian hoàn thành. Điều đó giúp khách dễ chọn và đội của bạn dễ định giá hơn.

Mẫu sẵn mang phần lớn công việc tiếp theo. Dùng thông điệp có sẵn cho xác nhận, theo dõi, yêu cầu phê duyệt và bàn giao. Dùng biểu mẫu chuẩn để khách biết cần gửi gì và quản lý biết cần xem gì. Khi mỗi bước có mẫu, dịch vụ bắt đầu có cảm giác như sản phẩm.

Một thiết lập đơn giản thường có:

• một biểu mẫu tiếp nhận cho yêu cầu mới
• hai hoặc ba lựa chọn dịch vụ tiêu chuẩn
• mẫu tin nhắn cho mỗi giai đoạn
• quy tắc phê duyệt cho yêu cầu rủi ro thấp và cao

Bước phê duyệt quan trọng hơn nhiều đội nghĩ. Một số yêu cầu nên tiến tự động, như thay đổi nhỏ dưới một mức ngân sách hoặc công việc lặp cho khách cũ. Những yêu cầu khác cần dừng lại để xem xét, nhất là khi giá, phạm vi hoặc thời hạn nằm ngoài phạm vi bình thường.

Lấy ví dụ một agency thiết kế xử lý nhiều chỉnh sửa một trang. Họ có thể tạo biểu mẫu yêu cầu chuẩn, một gói cố định cho "tối đa 3 thay đổi," và quy tắc tự phê duyệt cho khách quay lại dưới một mức tiền nhất định. Chỉ những yêu cầu lớn hơn mới đến tay quản lý. Điều đó đã cắt giảm trì hoãn và trao đổi qua lại.

Nếu bạn xây trong Koder.ai, nó có thể trở thành một ứng dụng nội bộ đơn giản với biểu mẫu, cập nhật trạng thái và logic phê duyệt trong một chỗ. Trước khi triển khai rộng, thử với một nhóm nhỏ khách hoặc một đội trong một hoặc hai tuần. Thường lúc đó các bước mơ hồ, trường thiếu và quy tắc bất tiện sẽ lộ ra.

Ví dụ: một agency nhỏ bắt đầu với báo giá

Một agency nhỏ thường nhận thấy cùng một mẫu đầu tiên: mỗi lead mới kích hoạt cùng chuỗi email. Dự án thuộc loại nào? Ngân sách ra sao? Ai cần phê duyệt? Có hạn chót không? Đội trả lời cùng câu hỏi nhiều lần, nhưng báo giá vẫn mất vài ngày.

Vì vậy báo giá thường là nơi dễ bắt đầu. Nó lặp lại, dễ đo lường và liên quan trực tiếp đến doanh thu.

Thay vì trao đổi email không dứt, agency tạo một biểu mẫu tiếp nhận ngắn. Nó chỉ hỏi những thông tin thực sự ảnh hưởng đến giá và phạm vi: loại dự án, số trang, tính năng cần thiết, ngày ra mắt mục tiêu, và khách đã có nội dung/nhận diện thương hiệu chưa.

Bây giờ cuộc trao đổi đầu tiên rõ ràng hơn. Bán hàng không phải đi hỏi các thông tin cơ bản, và khách biết thông tin nào quan trọng ngay từ đầu.

Với các yêu cầu phổ biến, agency đặt khung giá trước. Một site marketing đơn giản có thể nằm trong một mức, gói landing page ở mức khác, và build tùy chỉnh lớn hơn ở mức cao hơn. Báo giá không còn là phỏng đoán. Nó bắt đầu từ một mô hình rõ ràng.

Điều đó thay đổi vài thứ cùng lúc. Công việc tiêu chuẩn chạy nhanh hơn vì giá đã được định hình. Khách được trả lời nhanh hơn và ít thông tin mâu thuẫn. Đội cũng phát hiện lead không phù hợp sớm hơn.

Quản lý chỉ can thiệp khi có điều khác thường như hạn chót gấp, tích hợp tùy chỉnh hoặc phạm vi mơ hồ. Điều đó giữ cho phê duyệt tập trung vào ngoại lệ thay vì mọi lead.

Đội thậm chí có thể biến điều này thành một ứng dụng nội bộ nhẹ. Với Koder.ai, một quy trình báo giá như vậy có thể được xây từ prompt chat thành thứ thực tế mà không biến nó thành dự án phần mềm khổng lồ.

Thắng lợi thực sự xuất hiện sau khi báo giá gửi đi. Dự án khởi đầu ít bất ngờ hơn vì phạm vi đã được định hình trước. Đội đã biết điều gì được hứa, gói nào phù hợp và gì cần xem xét thêm.

Báo giá không trở nên phức tạp hơn. Nó trở nên nhất quán. Thường đó là dấu hiệu đầu tiên cho thấy tự động hóa quy trình dịch vụ đang hiệu quả.

Sai lầm thường gặp cần tránh

Rủi ro lớn nhất không phải là tiến quá chậm. Mà là cố gắng sửa quá nhiều cùng lúc và cuối cùng có hệ thống chẳng ai tin.

Một sai lầm hay gặp là chọn quy trình lộn xộn nhất trong công ty vì nó có vẻ quan trọng. Điều đó thường nghĩa là nhiều ngoại lệ, nhiều ý kiến và nhiều trì hoãn. Một chiến thắng đầu tiên tốt hơn là thứ xuất hiện thường xuyên, đơn giản và đủ gây đau đầu để mọi người muốn sửa, như báo giá, onboarding khách hàng hoặc phê duyệt nội bộ.

Một bẫy khác là thiết kế cho mọi kịch bản hiếm gặp ngay từ ngày đầu. Đội thường hỏi, "Nếu khách này yêu cầu bước tùy chỉnh?" hoặc "Nếu pháp lý cần xem xét đặc biệt?" Những trường hợp đó quan trọng, nhưng không nên định hình phiên bản đầu. Nếu 80% yêu cầu theo cùng một đường, hãy xây cho đường đó trước và xử lý ngoại lệ thủ công cho đến khi mô hình rõ ràng.

Cũng rất dễ nhảy vào công cụ trước khi quy trình được xác định. Một đội có thể bắt đầu xây biểu mẫu, tự động hóa hoặc ứng dụng tùy chỉnh trước khi giải thích được quy trình bằng ngôn ngữ đơn giản. Nếu bạn không mô tả được ai bắt đầu nhiệm vụ, chuyện gì xảy ra tiếp theo và thế nào là hoàn thành, công cụ chỉ che giấu sự bối rối.

Một quy tắc đơn giản giúp: định nghĩa các bước trước, đặt tên chủ sở hữu cho mỗi bước, thống nhất điểm bàn giao và quyết định thế nào là thành công.

Quyền sở hữu là nơi nhiều dự án quy trình thất bại sau khi ra mắt. Quy trình đi vào hoạt động, nhưng không ai rõ ràng chịu trách nhiệm duy trì, trả lời câu hỏi hay cập nhật khi doanh nghiệp thay đổi. Rồi các vấn đề nhỏ tích tụ, người ta quay về email và chat, và quy trình dần chết.

Các đội cũng theo dõi số liệu sai. Hoạt động có thể trông ấn tượng mà không cải thiện giao hàng. Nhiều lượt gửi, nhiều thông báo hay nhiều nhiệm vụ hoàn thành không có nghĩa quy trình tốt hơn.

Hãy theo dõi số liệu cho thấy cải thiện thực sự:

• thời gian từ yêu cầu đến hoàn thành
• số lỗi hoặc lần chỉnh sửa
• tần suất công việc bị kẹt
• tần suất mọi người bỏ qua hệ thống

Nếu một agency giảm thời gian trả lời báo giá từ hai ngày xuống hai giờ và giảm lỗi định giá, đó là tiến bộ. Nếu nó chỉ tạo thêm cập nhật nội bộ, đó là tiếng ồn. Những thay đổi quy trình tốt nhất cảm giác nhàm chán theo cách đúng: nhanh hơn, rõ ràng hơn và dễ lặp lại hơn.

Kiểm tra nhanh trước khi tự động hóa

Trước khi tự động hóa, thử xem quy trình đã đủ rõ để người khác có thể chạy mà không đoán mò chưa. Nếu nó vẫn sống trong đầu một người, tự động hóa chỉ che giấu sự bối rối và khiến việc sửa sau này khó hơn.

Một quy tắc tốt đơn giản: quy trình nên dễ giải thích trên một trang và dễ lặp lại trong một tuần làm việc bình thường.

Đây là bài kiểm tra áp lực nhanh:

• Một thành viên mới có thể theo các bước với hướng dẫn ngắn và hoàn thành công việc mà không cần trợ giúp liên tục không?
• Các đầu vào có rõ ràng và được thu thập cùng một cách mỗi lần không?
• Mỗi bàn giao có một chủ sở hữu rõ ràng không?
• Bạn biết ba ngoại lệ xuất hiện thường nhất không?
• Khách biết điều gì sẽ xảy ra tiếp theo và khi nào họ sẽ nhận được tin không?

Nếu ngay cả một trong những điểm đó mơ hồ, dừng lại trước khi thêm công cụ. Một quy trình onboarding khách lộn xộn không tự cải thiện chỉ vì giờ nó nằm trong một biểu mẫu hoặc bảng điều khiển.

Một agency nhỏ là ví dụ điển hình. Nếu đội muốn tự động hóa phê duyệt, trước khi xây bất cứ thứ gì họ nên xác nhận ai xem xét công việc, cái gì được tính là phê duyệt, chuyện gì xảy ra nếu phản hồi trễ, và khách thấy gì sau mỗi bước. Những chi tiết này nghe cơ bản, nhưng chính là nơi hầu hết vấn đề phê duyệt bắt đầu.

Đây cũng là lúc một nền tảng xây dựng có thể giúp, khi quy trình đã rõ. Koder.ai được thiết kế để tạo web, server và ứng dụng di động từ giao diện chat, nên nó phù hợp nhất khi bạn đã biết quy trình muốn biến thành thứ hữu dụng.

Bước tiếp theo của bạn

Đừng bắt đầu với một dự án hệ thống đầy đủ. Chọn một quy trình xảy ra thường xuyên, có bàn giao rõ ràng và gây cùng kiểu phiền toái mỗi tuần. Lựa chọn tốt ban đầu là báo giá, onboarding khách hoặc một luồng phê duyệt đơn giản.

Viết quy trình đó bằng không quá mười bước. Nếu bạn cần hơn mười bước, có lẽ quy trình vẫn còn quá lộn xộn để tự động hóa tốt. Giữ nó trên một trang và dùng ngôn ngữ đơn giản một thành viên mới có thể theo mà không cần trợ giúp.

Rồi chạy thủ công trong hai tuần.

Nghe có vẻ chậm, nhưng nó tiết kiệm thời gian sau này. Thử nghiệm thủ công cho thấy nơi mọi người bị kẹt, khách thường hỏi gì, và ngoại lệ nào xảy ra đủ thường để đáng để giải quyết.

Khi thử, giữ một ghi chú ngắn với ba thứ:

• các trì hoãn làm công việc chậm
• câu hỏi mọi người hỏi lặp lại
• các ngoại lệ phá vỡ luồng bình thường

Danh sách đó trở thành spec thực sự của bạn. Nó hữu dụng hơn nhiều so với kế hoạch lớn viết trước khi công việc bắt đầu.

Khi luồng cảm thấy nhàm chán và có thể dự đoán, thêm phần mềm.

Đó là lúc thích hợp để xây một công cụ nội bộ, biểu mẫu hoặc cổng khách xung quanh quy trình. Nếu bạn đã biết các bước, Koder.ai có thể giúp biến quy trình đó thành một ứng dụng nhẹ từ chat mà không phải vẽ bản đồ toàn bộ công ty trước.

Giữ phiên bản đầu nhỏ. Bạn không cần dashboard, phân quyền nâng cao hay mọi ngoại lệ ngay ngày đầu. Bạn cần một quy trình dễ chạy hơn, dễ giải thích hơn và dễ lặp lại hơn.

Một kiểm tra cuối giúp:

• Một người có thể theo mà không cần họp thêm không?
• Khách có thể thấy điều gì xảy ra tiếp theo không?
• Bạn có thể nhìn thấy nơi công việc đang chờ không?
• Bạn có thể hoàn thành nhiệm vụ với ít trao đổi qua lại hơn không?

Nếu câu trả lời là có, chuyển sang quy trình tiếp theo và lặp lại phương pháp. Đừng số hóa cả doanh nghiệp cùng lúc. Sửa một đường lặp, làm cho nó hữu dụng, rồi xây cải tiến tiếp theo trên nền đó.