Case Study: Group Company Platform
Mẫu & ví dụ Product OKR Case StudiesGroup company dùng OKR cascade để build shared platform nhưng vẫn giữ local constraints của công ty con.
Mẫu, ví dụ đã điền và cách dùng
Case Study: Group Company Platform
Case này minh họa cách parent company cascade OKR xuống công ty con mà không copy mục tiêu máy móc.
Business context và pain
| Business context | Parent company muốn một customer identity platform chung cho 5 công ty con ở các thị trường khác nhau. |
| User/stakeholder pain | Platform team muốn standardize, công ty con cần local compliance và workflow riêng, dependency decisions bị kéo dài. |
| Evidence observed | 3 subsidiaries đã tự build identity workaround; cross-company decisions mất trung bình 21 ngày; duplicated vendor cost cao. |
| Assumptions | Nếu platform có core standard + local configuration, adoption sẽ tăng mà không vi phạm local compliance. |
| Open questions | Capability nào phải shared? Local workflow nào là compliance vs preference? Ai quyết conflict? |
OKR structure và decisions
| Objective | Increase group platform leverage while preserving local compliance. |
| KR 1 | 3 of 5 subsidiaries adopt shared identity for priority workflows. |
| KR 2 | Cross-company dependency SLA reaches 85%. |
| KR 3 | Local compliance exceptions resolved under 10 business days. |
| Final artifact | Group-to-Subsidiary Cascade + Portfolio Allocation Sheet + Cross-company Decision Log. |
Success metrics và cách track
| Metric | Cách đo |
|---|---|
| Subsidiary adoption | Subsidiaries using shared platform in target workflows / target subsidiaries. |
| Dependency SLA | Cross-company dependencies resolved within SLA / total dependencies. |
| Local fit | Critical local workflows supported / required workflows. |
Cách triển khai trong 30-60-90 ngày
- First 30 days: define shared vs local boundaries and conflict rule.
- Days 31-60: pilot with 1 subsidiary and track dependency SLA.
- Days 61-90: expand to 2 more subsidiaries and update platform allocation.
Pitfalls và lesson learned
- Lesson: group OKR needs local translation and conflict governance.
- No-no: forcing all subsidiaries to copy parent KR exactly.
- Advanced move: score portfolio health by strategic fit, adoption, dependency risk and investment.
Điều đã xảy ra — nền tảng chung không ai muốn dùng
Tập đoàn đầu tư xây nền tảng dùng chung cho 6 công ty con, với mục tiêu tránh việc mỗi công ty tự xây một hệ thống tương tự. Sau một năm: 2 công ty dùng, 3 công ty dùng hình thức nhưng vẫn giữ hệ thống riêng song song, 1 công ty từ chối thẳng.
| KR ban đầu | Kết quả | Vấn đề của KR đó |
|---|---|---|
| 100% công ty con tích hợp nền tảng | 5/6 "đã tích hợp" | Tích hợp không đồng nghĩa với sử dụng |
| Giảm 30% chi phí hạ tầng toàn tập đoàn | Giảm 8% | Hệ thống song song khiến chi phí tăng ở công ty con |
| Ra mắt 12 dịch vụ dùng chung | 12/12 | Đầu ra — không nói gì về giá trị |
Nguyên nhân gốc: nền tảng được đo bằng tỉ lệ tuân thủ. Công ty con đạt tỉ lệ đó bằng cách tích hợp tối thiểu rồi tiếp tục dùng hệ thống cũ cho công việc thật. Tập đoàn giờ có hai hệ thống thay vì một — tệ hơn điểm xuất phát.
Điều đã đổi ở năm thứ hai
- Đổi KR từ tuân thủ sang tự nguyện: "số công ty con TỰ CHỌN dùng cho ít nhất một quy trình quan trọng" — bỏ hoàn toàn chỉ tiêu 100%.
- Coi công ty con là khách hàng, không phải đơn vị phải tuân thủ. Đội nền tảng bắt đầu phỏng vấn họ như phỏng vấn người dùng.
- Tìm ra rào cản thật: nền tảng chung chậm hơn hệ thống cũ khoảng 3 lần ở thao tác dùng nhiều nhất, và không hỗ trợ một quy tắc nghiệp vụ mà hai công ty bắt buộc phải có.
- Sửa hai thứ đó trước khi làm thêm dịch vụ mới nào.
| Chỉ số | Cuối năm 1 | Cuối năm 2 |
|---|---|---|
| Công ty tự nguyện dùng cho quy trình quan trọng | 2/6 | 5/6 |
| Hệ thống song song còn tồn tại | 3 | 1 |
| Chi phí hạ tầng toàn tập đoàn | −8% | −27% |
Chi phí giảm được khi công ty con tự nguyện tắt hệ thống cũ — không phải khi họ bị yêu cầu tích hợp. Cùng một mục tiêu, khác hoàn toàn ở cách đo.
Bài học và cách áp dụng
- Nền tảng dùng chung phải cạnh tranh, không được ép. Nếu nó không tốt hơn lựa chọn hiện tại của người dùng, việc ép dùng chỉ tạo ra hệ thống ngầm.
- Đo bằng tự nguyện sử dụng, không đo bằng tỉ lệ tuân thủ. Tuân thủ đạt được rất dễ và không nói lên điều gì.
- Đếm hệ thống song song. Đó là chỉ số trung thực nhất cho biết nền tảng có được chấp nhận thật hay không.
- Đội nền tảng cần làm discovery như mọi đội sản phẩm khác. Người dùng nội bộ vẫn là người dùng.
Cách đội nền tảng tìm ra rào cản thật
Năm đầu, đội nền tảng hỏi công ty con: "Vì sao chưa chuyển sang dùng nền tảng?" và nhận về những câu trả lời lịch sự, chung chung — thiếu nguồn lực, đang bận, sẽ làm sau. Không có câu nào dùng được.
Năm thứ hai, đổi cách hỏi:
| Câu hỏi cũ | Câu hỏi mới | Kết quả |
|---|---|---|
| "Vì sao chưa chuyển sang?" | "Cho tôi xem anh/chị làm việc X hằng ngày ra sao" | Quan sát trực tiếp phát hiện thao tác chậm gấp 3 lần |
| "Nền tảng còn thiếu gì?" | "Lần gần nhất anh/chị định dùng nền tảng rồi quay lại hệ thống cũ là khi nào?" | Tìm ra quy tắc nghiệp vụ bắt buộc mà nền tảng không hỗ trợ |
| "Bao giờ chuyển được?" | "Nếu chúng tôi sửa hai thứ này, anh/chị có chuyển không?" | Cam kết cụ thể, có điều kiện — kiểm chứng được |
Điểm chuyển: đội nền tảng ngừng coi công ty con là đơn vị chưa tuân thủ và bắt đầu coi họ là khách hàng chưa bị thuyết phục. Cùng một tình huống, nhưng cách nhìn thứ hai dẫn tới việc đi quan sát, còn cách nhìn thứ nhất chỉ dẫn tới việc gửi thêm văn bản nhắc nhở.
Bài học chuyển được sang mọi nền tảng nội bộ: người dùng bị bắt buộc vẫn là người dùng, và họ vẫn bỏ đi — chỉ là họ bỏ đi bằng cách xây hệ thống song song thay vì huỷ hợp đồng.
Definition of done
- KR đo tự nguyện sử dụng, không đo tỉ lệ tích hợp hay tuân thủ.
- Có đếm số hệ thống song song còn tồn tại.
- Đội nền tảng có làm discovery với công ty con như với người dùng thật.
- Rào cản được tìm bằng quan sát, không bằng câu hỏi "vì sao chưa dùng".
- Chi phí chỉ được ghi nhận là giảm khi hệ thống cũ thật sự được tắt.
Vì sao vai trò của bạn cần cái này
| Vai trò | Bạn dùng nó để |
|---|---|
| Chủ sở hữu nền tảng dùng chung | Đo bằng tự nguyện; tỉ lệ tuân thủ là chỉ số tự lừa dối |
| Head of Product tập đoàn | Ép dùng tạo ra hai hệ thống thay vì một |
| Product Owner công ty con | Nêu rào cản cụ thể thay vì từ chối chung chung |
| Tài chính tập đoàn | Chi phí chỉ giảm khi hệ thống cũ được tắt, không khi hệ thống mới được tích hợp |
| Business Analyst | Rào cản thật tìm được bằng quan sát, không bằng khảo sát hay văn bản hỏi ý kiến |
| CEO tập đoàn | Chỉ tiêu 100% tuân thủ là chỉ tiêu dễ đạt nhất và vô nghĩa nhất trong toàn bộ bảng |
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.