Case Study: Enterprise Internal Product
Mẫu & ví dụ Product OKR Case StudiesEnterprise internal product đo behavior change thay vì chỉ đo system deployed.
Mẫu, ví dụ đã điền và cách dùng
Case Study: Enterprise Internal Product
Case này minh họa cách biến internal software thành measurable product outcome với cycle time, adoption và manual hours saved.
Business context và pain
| Business context | Finance team trong enterprise dùng Excel ngoài hệ thống vì close tool chậm và thiếu exception workflow. |
| User/stakeholder pain | Month-end close mất 8 ngày, nhiều reconciliation manual, audit trail thiếu nhất quán. |
| Evidence observed | 62% reconciliation tasks được track ngoài hệ thống; 18% task có rework; finance analysts mất 320 giờ/tháng cho manual consolidation. |
| Assumptions | Nếu workflow exception và bulk validation tốt hơn, analysts sẽ bỏ Excel workaround và close nhanh hơn. |
| Open questions | Task nào nên automate trước? Excel workaround nào là do UX, policy hay missing data? Audit requirement nào bắt buộc? |
OKR structure và decisions
| Objective | Make month-end close faster and more auditable without increasing rework. |
| KR 1 | Close cycle time 8 days -> 5 days. |
| KR 2 | Manual consolidation hours 320/month -> 160/month. |
| KR 3 | Active finance users in system 54% -> 85%. |
| Final artifact | Internal Product Value Canvas + Ops Metric Dashboard + Adoption Plan. |
Success metrics và cách track
| Metric | Cách đo |
|---|---|
| Cycle time | Median days from close start to close complete. |
| Manual hours saved | Task volume x minutes saved per task / 60, validated by Finance. |
| Adoption | Active finance users completing target workflow in system / target users. |
Cách triển khai trong 30-60-90 ngày
- First 30 days: process mapping, baseline, Excel workaround analysis.
- Days 31-60: pilot exception workflow with 2 finance teams and train champions.
- Days 61-90: sunset top Excel workaround and run benefit realization review.
Pitfalls và lesson learned
- Lesson: internal product success is behavior change plus business process improvement.
- No-no: calling deployment successful while users still work outside the system.
- Advanced move: use audit findings reduced as a risk metric.
Điều đã xảy ra — hệ thống tốt, không ai dùng
Hệ thống quản lý yêu cầu nội bộ được xây trong 8 tháng, đúng tiến độ, đúng ngân sách, không lỗi nghiêm trọng. Sáu tháng sau khi ra mắt, 3 trong 11 phòng ban dùng nó; phần còn lại vẫn gửi email.
| Chỉ số đội theo dõi | Kết quả | Chỉ số lẽ ra phải theo dõi |
|---|---|---|
| Tính năng giao đúng hạn | 100% | Tỉ lệ yêu cầu đi qua hệ thống thay vì email |
| Lỗi nghiêm trọng | 0 | Thời gian xử lý một yêu cầu, trước và sau |
| Hệ thống hoạt động | 99,9% | Số phòng ban ngừng dùng cách cũ |
Nguyên nhân tìm được: hệ thống bắt điền 14 trường bắt buộc; email chỉ cần viết một câu. Với người gửi yêu cầu, hệ thống mới đắt hơn cách cũ — và lợi ích (theo dõi được, không thất lạc) thuộc về người nhận, không thuộc về người gửi.
Đây là dạng thất bại điển hình của sản phẩm nội bộ: chi phí và lợi ích rơi vào hai nhóm người khác nhau, và chỉ nhóm chịu chi phí mới phải hành động.
Thay đổi đã làm và kết quả
- Rút từ 14 trường bắt buộc xuống 3. Phần còn lại người nhận bổ sung sau, vì họ mới là người cần dữ liệu đó.
- Cho phép gửi yêu cầu bằng email và hệ thống tự tạo phiếu. Không ép đổi thói quen — gặp người dùng ở nơi họ đang đứng.
- Gửi lại cho người gửi một lợi ích thật: thông báo tự động khi yêu cầu của họ được xử lý. Trước đây họ phải tự đi hỏi.
| Chỉ số | Trước | Sau 3 tháng |
|---|---|---|
| Phòng ban dùng hệ thống | 3/11 | 10/11 |
| Tỉ lệ yêu cầu qua hệ thống | ~18% | ~86% |
| Thời gian xử lý trung bình | 6,2 ngày | 2,9 ngày |
Không có tính năng lớn nào được thêm. Thay đổi lớn nhất là bỏ bớt — và việc chấp nhận rằng người dùng sẽ không đổi thói quen chỉ vì hệ thống mới tốt hơn về mặt tổ chức.
Bài học và cách áp dụng
- Với sản phẩm nội bộ, hỏi ai chịu chi phí và ai hưởng lợi. Nếu hai nhóm khác nhau, bạn cần trả lại cho nhóm chịu chi phí một lợi ích cụ thể.
- Không đo việc hệ thống chạy — đo việc cách cũ biến mất. Chừng nào email vẫn còn được dùng, hệ thống chưa thành công.
- Ép dùng không hiệu quả trong tổ chức lớn. Người ta sẽ tuân thủ hình thức và làm thật bằng cách cũ.
- So sánh chi phí thao tác với cách cũ, từng bước. Nếu cách mới tốn nhiều thao tác hơn, không có lý do nào khiến người dùng chọn nó.
Danh sách kiểm trước khi ra mắt một sản phẩm nội bộ
Rút ra trực tiếp từ ca này. Mỗi mục ứng với một điểm đã hỏng.
| Câu hỏi | Trả lời "không" nghĩa là | Sửa trước khi ra mắt |
|---|---|---|
| Người gửi/người thao tác có được lợi gì trực tiếp không? | Họ chịu chi phí, người khác hưởng lợi — họ sẽ không đổi | Trả lại cho họ một lợi ích cụ thể, dù nhỏ |
| Số thao tác có ít hơn cách cũ không? | Cách mới đắt hơn với người dùng | Cắt bớt trường bắt buộc; bổ sung sau bởi người cần dữ liệu |
| Có cho phép dùng cách cũ và tự chuyển đổi không? | Bạn đang yêu cầu đổi thói quen cùng lúc với đổi công cụ | Gặp người dùng ở nơi họ đang đứng |
| Có đo được việc cách cũ giảm đi không? | Bạn sẽ không biết mình thành công hay thất bại | Đặt chỉ số đo tỉ lệ đi qua hệ thống |
Về 14 trường bắt buộc: con số đó không do một người quyết. Nó là tổng hợp mong muốn của nhiều phòng ban, mỗi bên thêm vài trường "cho đầy đủ", và không ai kiểm tổng chi phí mà người dùng phải trả. Đây là dạng lỗi tích tụ mà không bước nào trong quy trình bắt được — trừ khi có người hỏi thẳng: người gửi phải làm bao nhiêu thao tác so với trước?
Definition of done
- Đã xác định ai chịu chi phí và ai hưởng lợi; nếu khác nhau, người chịu chi phí được trả lại lợi ích cụ thể.
- Số thao tác của cách mới không nhiều hơn cách cũ.
- Chỉ số chính đo việc cách cũ biến mất, không đo việc hệ thống hoạt động.
- Cho phép người dùng tiếp tục cách cũ trong giai đoạn chuyển tiếp.
- Mỗi trường bắt buộc đều có người chịu trách nhiệm giải thích vì sao nó bắt buộc.
- Đã đo thời gian xử lý trước khi ra mắt, để có điểm so sánh sau này.
Vì sao vai trò của bạn cần cái này
| Vai trò | Bạn dùng nó để |
|---|---|
| Product Owner nội bộ | Đo việc cách cũ biến mất, không đo việc hệ thống chạy |
| Business Analyst | So sánh số thao tác giữa cách mới và cách cũ, từng bước |
| Team Lead | 14 trường bắt buộc thường là tổng hợp mong muốn của nhiều bên, không ai kiểm chi phí |
| Quản lý phòng ban | Ép dùng cho ra tuân thủ hình thức, không cho ra thay đổi thật |
| Người dùng nghiệp vụ | Việc bạn vẫn dùng email không phải bảo thủ — đó là tín hiệu sản phẩm đang đắt hơn cách cũ |
| Giám đốc tài chính | Dự án nội bộ hoàn thành đúng hạn vẫn có thể là dự án thất bại hoàn toàn |
Thảo luận & tài liệu thêm 0
Chia sẻ kinh nghiệm, đặt câu hỏi, hoặc đính kèm tài liệu/YouTube giúp người khác học kỹ năng này.