Tóm tắt
- Đừng chờ quy trình hoàn hảo trên giấy mới build, vì quy trình thật chỉ lộ khi thấy sản phẩm chạy.
- Coi app như công cụ khám phá quy trình, đưa vòng chỉnh sửa vào kế hoạch từ đầu.
- Chia hành trình thành 5 giai đoạn: khảo sát, thiết kế lại, bản mẫu, xây và lặp, vận hành.
- Chốt ngân sách hiệu chỉnh 20 đến 30% từ đầu để thay đổi không thành thương lượng căng thẳng.
- Giá trị lớn nhất là quản đồng thời kỳ vọng, phạm vi và quy trình.
Bạn quyết định số hóa quy trình doanh nghiệp. Đội phát triển hỏi quy trình hiện tại, bạn gửi tất cả những gì đang có: vài file Excel, một sơ đồ cũ, dăm ba quy định rời rạc. Họ build theo đó. Đến lúc bạn ngồi test bản đầu tiên, mọi thứ vỡ ra: chỗ này phải sửa, chỗ kia không giống thực tế, một nửa các bước trên giấy thật ra công ty đã bỏ từ lâu. Bạn phải ngồi viết lại quy trình, đội phát triển báo phát sinh chi phí, và không khí bắt đầu căng.
Đây không phải lỗi của bạn, cũng không phải đội làm ẩu. Đó là bản chất của việc số hóa mà rất ít người nói thẳng.
Trả lời nhanh. Số hóa quy trình doanh nghiệp là chuyển cách vận hành thực tế của công ty thành một hệ thống phần mềm. Nó hay đổ vỡ vì doanh nghiệp cố chờ một quy trình hoàn chỉnh trên giấy trước khi build, trong khi quy trình thật chỉ lộ ra khi nhìn thấy sản phẩm chạy. Cách làm mượt là chia hành trình thành nhiều giai đoạn và đưa vòng lặp chỉnh sửa vào kế hoạch ngay từ đầu.
Mục lục
- Vì sao số hóa quy trình doanh nghiệp hay đổ vỡ giữa chừng
- Đổi tư duy: app là công cụ để lộ ra quy trình thật
- Lộ trình 5 giai đoạn để số hóa quy trình doanh nghiệp mượt mà
- Cách moi ra quy trình thật, không phải quy trình trên giấy
- Quản lý thay đổi và chi phí mà không gây căng thẳng
Vì sao số hóa quy trình doanh nghiệp hay đổ vỡ giữa chừng
Có một câu ai làm chuyển đổi số cũng từng nghe: muốn số hóa thì quy trình phải được chuẩn hóa rõ ràng trước đã. Nghe rất hợp lý. Vấn đề là kỳ vọng viết xong quy trình, duyệt xong, rồi mới chuyển thành app gần như không bao giờ chạy đúng như thế.
Lý do thứ nhất: quy trình thật của một doanh nghiệp nằm trong đầu người làm và trong thói quen hàng ngày, không nằm trên giấy. Khi bạn hỏi quy trình của mình là gì, nhân viên mô tả cái quy trình lý tưởng mà họ nghĩ họ đang làm, không phải cái họ thực sự làm mỗi ngày. Khoảng cách giữa hai thứ đó chính là nơi các dự án số hóa vấp ngã.
Lý do thứ hai: con người không biết chính xác mình muốn gì cho đến khi nhìn thấy một thứ cụ thể để phản ứng. Vì vậy phản hồi thật chỉ xuất hiện khi khách sờ được sản phẩm chạy. Đây là quy luật tâm lý, không phải sự khó tính.
Số liệu ủng hộ điều này. Trong nghiên cứu kinh điển CHAOS của Standish Group, nhóm nguyên nhân thất bại hàng đầu của các dự án phần mềm là yêu cầu không đầy đủ và yêu cầu thay đổi liên tục. Yếu tố quyết định thành công lại là sự tham gia của người dùng và một bản mô tả yêu cầu rõ ràng.
Ở tầm rộng hơn, McKinsey và BCG nhiều năm liền cho thấy khoảng 70% dự án chuyển đổi số không đạt mục tiêu đề ra. Điểm chung của phần lớn ca đổ vỡ không phải công nghệ yếu, mà là nền quy trình chưa vững và kỳ vọng không được quản. Bạn càng cố ép hành trình thành duyệt xong quy trình mới đụng tay vào app, bạn càng chống lại quy luật, và tự tạo khổ cho cả hai bên.
Đổi tư duy: app là công cụ để lộ ra quy trình thật
Đây là chỗ tôi muốn bạn nhìn lại. Cái app không phải là bản sao của một quy trình có sẵn. Nó là công cụ giúp moi ra quy trình thật vốn đang ẩn trong cách công ty vận hành.
Điều đó không có nghĩa vứt bỏ khâu quy trình. Nó có nghĩa bạn đưa việc phát hiện quy trình vào kế hoạch một cách chủ động, thay vì để nó bùng lên như một cú sốc lúc test. Vòng chỉnh sửa không phải tai nạn. Nó là một giai đoạn đã được dự tính và tính chi phí từ trước.
Cách nghĩ này quan trọng vì nó đổi luôn thái độ của cả hai phía. Khi bạn coi bản đầu tiên là bản để học, mỗi lần khách nói cái này cần sửa là một lần hệ thống đang tiến gần thực tế hơn, không phải một lần dự án đi lệch. AI càng làm điều này rõ hơn: công cụ mới rút ngắn phần gõ code, nhưng phần tư duy và quy trình thì không rút gọn được, như tôi đã viết trong bài vibe coding cho doanh nghiệp.
Lộ trình 5 giai đoạn để số hóa quy trình doanh nghiệp mượt mà
Thay vì một cú nhảy từ quy trình sang app, hãy chia hành trình thành năm giai đoạn, mỗi giai đoạn có một mục tiêu và một cam kết riêng.
| Giai đoạn | Làm gì | Kết quả bàn giao |
|---|---|---|
| 1. Khảo sát | Quan sát cách làm thật, lấy các ca thực tế gần nhất kể cả ca lỗi | Bản đồ quy trình hiện tại (as-is) |
| 2. Thiết kế lại | Cắt bỏ bước thừa, chuẩn hóa quy trình mục tiêu | Quy trình cải tiến được duyệt |
| 3. Bản mẫu | Dựng bản clickable rẻ để khách phản ứng trước khi code | Danh sách chỉnh sửa lớn, giá rẻ |
| 4. Xây và lặp | Code phần lõi, chạy 2 đến 3 vòng hiệu chỉnh có kiểm soát | App bản chạy được, đã tinh chỉnh |
| 5. Vận hành | Đào tạo người dùng, theo dõi số liệu thực tế | Đội tự vận hành, không phụ thuộc một người |
Điểm mấu chốt nằm ở hai giai đoạn đầu. Giai đoạn 1 và 2 là nơi giá trị tư vấn cao nhất, và cũng là chỗ hay bị bỏ qua nhất. Đừng tự động hóa một quy trình đang lộn xộn, vì bạn sẽ chỉ có một mớ lộn xộn chạy nhanh hơn. Hãy chốt bản quy trình mục tiêu trước, rồi mới build. Khách duyệt bản mục tiêu cụ thể, không phải duyệt một bản mô tả mơ hồ. Muốn đi sâu hơn về việc gắn hệ thống với chuẩn vận hành, xem bài đào tạo AI gắn với quy trình vận hành.
Giai đoạn 3 là nơi phần lớn cú phải viết lại quy trình sẽ nổ ra. Điều bạn muốn là để nó nổ ra ở bản mẫu, chỗ mà sửa gần như miễn phí, thay vì nổ ra sau khi đã code xong và sửa rất đắt.
Cách moi ra quy trình thật, không phải quy trình trên giấy
Nếu quy trình thật không nằm trên giấy, thì hỏi quy trình của anh là gì sẽ không lấy được nó. Có ba cách hiệu quả hơn.
Thứ nhất, đi quan sát trực tiếp. Ngồi cạnh người làm và xem họ xử lý một ca thật từ đầu đến cuối. Cái bạn thấy sẽ khác cái họ kể. Người Nhật gọi cách này là gemba, tức đến tận nơi việc diễn ra.
Thứ hai, dùng các ca thật thay vì câu hỏi trừu tượng. Cho tôi xem năm đơn hàng gần nhất sẽ lộ ra tất cả các ngoại lệ mà không ai nghĩ tới khi mô tả quy trình lý tưởng. Chính các ngoại lệ đó, chứ không phải luồng chuẩn, mới là thứ làm hỏng app sau này.
Thứ ba, dựng bản mẫu sớm và rẻ. Một bản clickable đơn giản kéo phản hồi thật về sớm, lúc thay đổi còn rẻ. Nguyên tắc chung của số hóa quy trình doanh nghiệp là test ở quy mô nhỏ, thấy đúng rồi mới scale lên.
Quản lý thay đổi và chi phí mà không gây căng thẳng
Căng thẳng chi phí giữa người đặt app và đội phát triển gần như luôn đến từ một nguyên nhân: gắn một bài toán bản chất là khám phá vào một hợp đồng trọn gói cứng. Hai thứ đó không hợp nhau. Đội phát triển quản chi phí bằng danh sách tính năng, nên mỗi thay đổi là một lần thương lượng lại, và mỗi lần thương lượng là một lần quan hệ nóng lên.
Cách gỡ nằm ở cấu trúc hợp đồng và cách gọi tên thay đổi.
| Hợp đồng trọn gói cứng | Hợp đồng theo giai đoạn | |
|---|---|---|
| Phạm vi | Chốt cứng toàn bộ từ đầu | Chốt cứng khảo sát và bản mẫu, phần còn lại linh hoạt |
| Thay đổi | Mỗi lần là một cuộc thương lượng | Rút từ ngân sách hiệu chỉnh đã thỏa thuận |
| Không khí | Dễ căng, hai bên phòng thủ | Bình tĩnh, cùng nhìn về sản phẩm |
| Hợp với | Bài toán đã rõ hoàn toàn | Số hóa quy trình, vốn là khám phá |
Ba việc cụ thể giúp giảm căng thẳng. Một là báo giá cứng cho giai đoạn khảo sát và bản mẫu, vì phần đó xác định được, rồi để phần tinh chỉnh chạy theo sprint hoặc theo một ngân sách hiệu chỉnh chôn sẵn khoảng 20 đến 30% ngay trong báo giá đầu. Khi mỗi thay đổi rút từ một quỹ đã thống nhất thay vì đàm phán lại, căng thẳng biến mất.
Hai là giữ một nhật ký thay đổi minh bạch để cả hai bên thấy rõ cái gì đã đổi và vì sao. Ba là lập một danh sách chờ cho những ý tưởng ngoài phạm vi, để khách thấy mình được lắng nghe mà tiến độ không bị phá.
Đặt kỳ vọng ngay từ buổi khởi động cũng quan trọng không kém. Hãy nói thẳng với đội của bạn hoặc đối tác: bản đầu tiên không phải bản cuối, chúng ta sẽ có 2 đến 3 vòng chỉnh vì nhìn thấy sản phẩm sẽ làm mình đổi ý, và đó là chuyện bình thường đã nằm trong kế hoạch. Khi bạn gọi tên nó trước, nó thành một bước dự kiến. Khi bạn im, nó thành một cuộc cãi nhau về chuyện sao lại phát sinh.
Nhìn tổng thể, thứ thật sự quyết định một dự án số hóa mượt hay rối không phải là chọn được đội code giỏi, mà là có người quản đồng thời ba thứ: kỳ vọng, phạm vi, và quy trình. Đây cũng là lý do việc chọn mua một hệ thống có sẵn hay tự xây một app riêng cần cân nhắc kỹ ngay từ đầu, một chủ đề tôi mổ xẻ trong bài tự xây phần mềm cho doanh nghiệp.
Và nếu bản thân quy trình của bạn đang có vấn đề gốc, thì số hóa nó chỉ khuếch đại vấn đề, nên hãy giải bài toán quy trình trước bằng một cách tiếp cận có hệ thống như trong bài quy trình giải quyết vấn đề trong doanh nghiệp.
Số hóa quy trình doanh nghiệp không phải là dịch một tài liệu thành phần mềm. Nó là một hành trình khám phá có kỷ luật. Ai coi vòng chỉnh sửa là một phần của kế hoạch, chia hành trình thành các giai đoạn rõ ràng, và quản kỳ vọng ngay từ đầu, thì đi đến đích mà không phải trả giá bằng những tuần căng thẳng.
Nếu bạn đang chuẩn bị số hóa một quy trình và chưa chắc điểm nghẽn thật nằm ở đâu, hãy đặt lịch tư vấn 30 phút để cùng tôi soi lại quy trình trước khi đụng đến dòng code đầu tiên. Map đúng trước, build sau, đó là cách rẻ nhất.
Câu hỏi thường gặp
Có cần viết xong quy trình hoàn chỉnh rồi mới số hóa không?
Không. Quy trình thật nằm trong thói quen hàng ngày, không nằm trên giấy, và chỉ lộ ra đầy đủ khi nhìn thấy sản phẩm chạy. Thay vì chờ một bản hoàn hảo, hãy map quy trình hiện tại, thiết kế bản mục tiêu, rồi dùng bản mẫu để moi ra phần còn thiếu. Số hóa quy trình doanh nghiệp là hành trình khám phá, không phải một cú chuyển thể một lần.
Vì sao khách hàng luôn đòi chỉnh sửa nhiều sau khi test app?
Vì con người không biết chính xác mình muốn gì cho đến khi có một thứ cụ thể để phản ứng. Phản hồi thật chỉ xuất hiện khi họ sờ được sản phẩm. Đây là quy luật tâm lý, không phải sự khó tính. Cách xử lý là đưa 2 đến 3 vòng chỉnh sửa vào kế hoạch và ngân sách ngay từ đầu, thay vì coi đó là phát sinh ngoài dự kiến.
Làm sao tránh căng thẳng chi phí với đội phát triển khi phát sinh thay đổi?
Căng thẳng đến từ việc gắn một bài toán khám phá vào hợp đồng trọn gói cứng. Hãy báo giá cứng cho khâu khảo sát và bản mẫu, rồi chôn sẵn một ngân sách hiệu chỉnh khoảng 20 đến 30% cho phần tinh chỉnh. Khi mỗi thay đổi rút từ quỹ đã thống nhất thay vì đàm phán lại từng lần, quan hệ giữ được bình tĩnh.
Số hóa quy trình doanh nghiệp nên bắt đầu từ đâu?
Bắt đầu bằng quan sát trực tiếp cách làm thật, không phải bằng bản mô tả quy trình lý tưởng. Lấy vài ca thực tế gần nhất kể cả ca lỗi để lộ ra các ngoại lệ, vẽ bản đồ hiện tại, rồi thiết kế bản mục tiêu đã cắt bỏ bước thừa. Chốt quy trình mục tiêu trước, sau đó mới dựng bản mẫu và build.
Nguồn tham khảo
- CHAOS Report, The Standish Group
- Perspectives on transformation, McKinsey & Company
Nhận bài viết mới nhất từ Markus Lab
2-3 bài mỗi tuần về AI, build sản phẩm, và growth cho founder & SME Việt. Không spam, unsubscribe bất cứ lúc nào.
