Tomorrow Marketers – Mô hình Issue Tree và nguyên tắc MECE là các công cụ hữu ích trong việc phân tích và xác định vấn đề. Dù vậy, khi chưa nắm rõ các cấu trúc logic và hướng tiếp cận hợp lý, nhiều người vẫn thường mắc phải một số lỗi sai khiến các công cụ này không được sử dụng hiệu quả. Trong bài viết dưới đây, hãy cùng Tomorrow Marketers tìm hiểu một số ví dụ về Issue Tree và các lỗi sai thường gặp nhé!
Đọc thêm: 3 kỹ thuật lập Issue Tree để xác định và giải quyết vấn đề
1. Các ví dụ của Issue Tree
Bài viết sẽ sử dụng các ví dụ khác nhau để bạn có thể thấy rõ cách các nguyên tắc, kỹ thuật được áp dụng cho các loại tình huống khác nhau.
Ví dụ #1 – Chi phí nhiên liệu cho máy bay tăng đột biến
Đây là một case về ngành hàng không: Giả sử chi phí nhiên liệu cho máy bay gần đây có xu hướng tăng, và CEO mong muốn bạn tìm ra đâu là nguyên nhân đằng sau của vấn đề.
Bước đầu tiên để lập Issue Tree là xác định vấn đề. CEO quan tâm tới tổng chi phí cho nhiên liệu vì chỉ số này có thể tác động tới lợi nhuận của các chuyến bay. Do đó, consultant đã đặt câu hỏi và xác nhận vấn đề là tốc độ tăng của chi phí nhiên liệu nhanh hơn so với tốc độ tăng của doanh thu.Vấn đề đặt ra là một metric, vì vậy người lập Issue Tree sau đó đã sử dụng kỹ thuật Math Tree cho hai tầng đầu tiên để có thể định lượng chi tiết hơn chính xác vấn đề bắt nguồn từ đâu. Tiếp đó, Issue Tree phát triển nhờ kỹ thuật Sử dụng từ trái nghĩa (Opposite Words) và kỹ thuật Khung khái niệm (Conceptual Framework) cho tầng thứ 3 và 4.
Có ba điều có thể rút ra từ ví dụ này:
#1: Chia nhỏ một vấn đề toán học theo cách sử dụng công thức toán học – sau đó phát triển các tầng/lớp bằng cách sử dụng kỹ thuật thứ 2 – xếp chồng 5 cách tiếp cận theo nguyên tắc MECE
Quy tắc này không được áp dụng cho mọi vấn đề cần tới problem-solving mà chỉ phù hợp với một số vấn đề có thể giải quyết tốt với cấu trúc định tính. Và bạn không bắt buộc phải thực hiện các lớp định tính sau đó.
Thông thường, cách tốt nhất để chia nhỏ một vấn đề toán học là nhìn nhận vấn đề như một phương trình toán học, vì bạn có thể định lượng có bao nhiêu yếu tố tác động tới vấn đề. Thông thường, nếu chỉ sử dụng riêng kỹ thuật này sẽ không đủ để giúp bạn nhìn nhận đầy đủ các vấn đề có ý nghĩa.
Ví dụ, trong trường hợp này, nếu chúng ta chỉ nhìn nhận dưới góc nhìn của toán học, Issue True sẽ bỏ sót các yếu tố định tính quan trọng thể hiện trực giác trong kinh doanh, ví dụ như các yếu tố “bảo trì”, “trọng lượng của máy bay” và “sự kết hợp của các máy bay trong một hạm đội bay”.
#2: Dừng lại ở từng tầng khi đã tìm ra yếu tố có thể giải thích hợp lý nguồn gốc của vấn đề
Bạn có thể thấy số layer có sự khác nhau giữa các tầng ở Issue Tree trên và muốn đặt câu hỏi “Issue Tree cần có bao nhiêu tầng để được coi là hoàn thiện?” Câu trả lời ở đây là: Hãy dừng lại khi các nhánh đã giải thích tầng vấn đề đó một cách hợp lý.
Ví dụ: Ở tầng thứ 2, bạn có nhóm vấn đề “số chuyến bay tăng” để giải thích vì sao chi phí nhiên liệu tăng, và coi lời giải thích này khá hợp lý. Bạn có thể tiếp tục đặt câu hỏi “tại sao số chuyến bay lại tăng lên” nếu đó là vấn đề thực sự đang xảy ra. Nhưng điều này có thể khiến mọi việc đang đi quá sâu và chi tiết một cách không cần thiết khi vấn đề đã được chứng minh nguyên nhân.
Ở tầng thứ 3, nguyên nhân “đổi sang tàu bay khác” có thể giải thích cho vấn đề chi phí nhiên liệu tăng, vì có khả năng loại máy bay mới có động cơ xử lý nhiên liệu kém hiệu quả hơn. Nhưng trong trường hợp vẫn “giữ nguyên tàu đó trước đó”, câu trả lời về động cơ xử lý nhiên liệu có thể không đủ thuyết phục. Vì vậy, cần phải đào sâu với các vấn đề chi tiết hơn như: trọng lượng hành khách/hàng hóa, thời gian bảo trì, độ cao khi bay, tình trạng bay phải đối mặt (ví dụ: bầu khí quyển dày hơn) hoặc thay đổi tốc độ trong chế độ bay.
#3: Bạn vẫn có thể đào sâu vấn đề hơn
Giả sử, vấn đề ở đây là máy bay đang bay với trọng lượng lớn hơn và bạn vẫn cần phải tìm ra nguyên nhân gốc rễ của vấn đề này. Bạn có thể tiếp tục chia nhỏ vấn đề thành các yếu tố có thể làm tăng trọng lượng của máy bay: con người, hàng hóa, thiết bị, nhiên liệu (máy bay tốn thêm nhiên liệu để cất cánh khi dư thừa nhiên liệu).
Hoặc giả sử, vấn đề nằm ở việc giá nhiên liệu đã tăng mặc dù hãng hàng không vẫn mua cùng một loại nhiên liệu từ cùng một nhà cung ứng. Vấn đề này có thể được chia nhỏ tiếp tục: hoặc chi phí của nhà cung ứng đã tăng lên (ví dụ, vì dầu thô tăng giá) hoặc tỷ suất lợi nhuận của họ cao hơn (ví dụ, vì hãng hàng không không đàm phán để giảm giá).
Bạn vẫn có thể đào sâu hơn từng yếu tố nếu cần thiết, dù vậy vẫn cần lưu ý về mức độ cụ thể để tìm ra vấn đề thực sự là gì.
Ví dụ #2 – Cải thiện hiệu quả làm việc của consultant khi quá tải công việc
Hãy thử tự lập Issue Tree trước khi xem hướng giải đáp cho ví dụ này nhé: Lấy ra một tờ giấy và viết ra tất cả những ý tưởng có thể giúp bạn làm việc hiệu quả hơn, khi bạn ở trong vai trò của một consultant.
Thông thường, những ý tưởng nảy ra chỉ là một danh sách dài các hành động thiếu gắn kết và không liên quan tới nhau, do đó bạn sẽ rất khó để nhìn ra kết quả sẽ cải thiện như nào khi thực hiện hành động đó, và cũng sẽ rất khó để sắp xếp thứ tự các hành động cần ưu tiên.
Sử dụng Issue Tree sẽ giúp sắp xếp các ý tưởng đó và có thể gắn những suy nghĩ đó với vấn đề trong thực tế để cải thiện năng suất làm việc. Đây là lúc một Issue Tree có thể giải quyết một bài toán định tính hơn so với ví dụ #1 và vẫn sử dụng các kỹ thuật đã nêu.
Bước đầu tiên, bạn cần xác định vấn đề cụ thể ở đây là gì. Sau đó, đặt giả định là tính hiệu quả = khối lượng công việc được chuyển giao trong khoảng thời gian consultant này sẵn sàng làm việc trên mỗi tuần để biến vấn đề trở thành một metric định lượng.
Bước tiếp theo là xác định tầng thứ hai của Issue Tree – tách nhỏ vấn đề thành hai hướng tiếp cận dựa trên giả định đã đặt. Sau đó bóc tách vấn đề theo kỹ thuật xếp chồng 5 cách tiếp cận theo nguyên tắc MECE.
Ví dụ #3 – Giúp chính phủ giải quyết nạn mù chữ ở trẻ em
Đây là một ví dụ về vấn đề trong dịch vụ công. Issue Tree trong ví dụ này đặc biệt chỉ sử dụng duy nhất một kỹ thuật: tách nhỏ từng vấn đề thành hai loại vấn đề đối lập ngay từ tầng đầu tiên, và tiếp tục lặp đi lặp lại ở các tầng sau đó.
Đọc thêm:
- Sử dụng Issue Tree và Yes/No Tree để xác định và giải quyết vấn đề
- Cách trả lời câu hỏi xác định vấn đề sử dụng Issue Tree
2. Các lỗi sai và câu hỏi thường gặp
Lỗi sai là một phần của quá trình học hỏi. Học hỏi từ lỗi sai của người khác có thể giúp bạn tránh được điều này.
Dưới đây là một số lỗi sai phổ biến và một số câu hỏi mà mọi người thường thắc mắc trong quá trình xây dựng Issue Tree.
Giả sử, có một vấn đề của doanh nghiệp có thể được hỏi trong case interview: Bạn đang thực hiện một dự án với Amazon và công ty đã phàn nàn về tình trạng thường xuyên xảy ra trộm cắp trong kho hàng – và nguyên nhân nào dẫn tới điều này?
Bạn sẽ đặt ra các câu hỏi gì để tìm ra câu trả lời? Có rất nhiều người đã tham gia và đưa ra câu trả lời cho tình huống này, và hầu hết các Issue Tree của họ đều mắc lỗi, ví dụ như:
Lỗi sai #1 – Bỏ qua việc định nghĩa vấn đề
Nhìn có vẻ là một Issue True khá tốt đấy nhỉ? Issue Tree này mô tả khá tốt quy trình vận hành của một nhà kho.
Tuy nhiên có thể không hẳn vậy đâu.
Issue Tree này đang mắc phải lỗi: bỏ quên tính cụ thể của vấn đề. Issue Tree này chỉ đang xác định nguyên nhân của việc trộm cắp – chứ không phải về vấn đề mất hàng trong kho. Những gì Issue Tree này đang nói về chỉ xoay quanh thiệt hại, hư hỏng, sơ suất, sai sót của máy móc, v.v. – những thứ không liên quan trực tiếp đến vấn đề và bỏ qua rất nhiều điều quan trọng.
Một vấn đề thứ hai: mặc dù Issue Tree này mô tả rất rõ về quá trình lưu kho diễn ra như thế nào và nhờ đó có thể xác định vấn đề có thể xảy ra ở đâu, nhưng Issue Tree này không chỉ ra được lý do tại sao. Ví dụ, hệ thống an ninh kém, nhà kho ở khu vực có nhiều tội phạm, thiếu các cơ chế phạt,v.v. Những điều này có thể khiến bạn phải đặt ra câu hỏi tại sao.
Lỗi sai #2 – Sắp xếp lộn xộn thứ tự các tầng
Trong ví dụ này, vị trí địa lý không đủ quan trọng để được đặt lên hàng đầu trong Issue Tree. Việc chia nhỏ vấn đề theo khu vực địa lý sẽ không giúp giải quyết vấn đề tận gốc. Hơn nữa, tại sao lại chia vị trí địa lý theo lục địa chứ không phải theo quy mô các thành phố, theo thu nhập hoặc tỷ lệ tội phạm giữa các khu vực? Việc biết rõ vấn đề của các nhà kho sẽ cần thiết hơn.
Thay vào đó, bạn có thể lập ra Issue Tree cho một nhà kho cụ thể và đưa ra góc nhìn mở rộng và coi những nguyên nhân này có thể áp dụng cho tất cả nhà kho của Amazon theo khu vực địa lý, quy mô kho,v.v.
Lỗi sai thứ hai của Issue Tree này chính là việc đưa ra giải pháp cho từng nguyên nhân gốc rễ của vấn đề quá sớm – trước khi tìm hiểu sâu hơn về lý do đằng sau mỗi sự việc. Issue Tree cần trả lời cho câu hỏi TẠI SAO chứ không phải CẦN GIẢI QUYẾT NHƯ THẾ NÀO. Đưa ra các giải pháp trước khi tìm ra nguyên nhân gốc rễ có thể khiến công ty đang giải quyết sai vấn đề.
Ví dụ, giả sử nguyên nhân xuất phát từ vấn đề trộm cắp trong nhân viên nội bộ, Issue Tree cần đặt ra các giả thiết như (a) công ty ngừng kiểm tra lý lịch, (b) hoạt động kiểm tra lý lịch không đảm bảo chất lượng hoặc (c) công ty chưa bao giờ kiểm tra lý lịch chưa bao giờ được thực hiện.
Cuối cùng, sai lầm thứ ba liên quan đến việc định nghĩa vấn đề. Câu hỏi mà case đặt ra chưa có sự rõ ràng: cần quan tâm tới số vụ trộm cắp hay giá trị hàng hóa trong các vụ trộm cắp? Issue Tree phía trên mới nêu ra các yếu tố tác động tới số vụ trộm cắp, vì vậy Issue Tree cần thể hiện thêm các yếu tố liên quan tới giá trị bị trộm, ví dụ giá trị hàng hóa của mỗi vụ trộm cao hoặc số lượng hàng hóa trong mỗi vụ trộm nhiều.
Lỗi sai #3 – Lỗi ngụy biện
Có nhiều lỗi sai có thể nhận ra ở Issue Tree dưới đây, ví dụ:
- Phân khúc theo khu vực ngay từ đầu khi đây không phải yếu tố thực sự quan trọng và bao quát để giải thích vấn đề
- Phân khúc theo khu vực không tuân theo nguyên tắc MECE (Issue Tree bỏ qua các quốc gia mới phát triển ở châu Âu và những quốc gia phát triển ở châu Á)
- Thiếu đề cập tới thiệt hại của các sản phẩm bị trộm
- Phá vỡ cấu trúc quy trình để giải thích sự gia tăng số lượng vụ trộm trên mỗi kho hàng không sâu sắc và liên quan
Vẫn còn một lỗi sai khác trong Issue Tree dưới đây: hãy gọi nó là lỗi “ngụy biện”.
Giả sử, nếu số lượng trạm xăng trong một thành phố tăng gấp 2 lần trong một năm, liệu doanh số bán xăng có tăng gấp 2 lần không, hay nó sẽ tăng 10% hay 20%?
Thực tế, nhiều trạm xăng hơn không làm tăng nhu cầu về nhiên liệu (trừ khi có rất ít trạm xăng và lại cung cấp xăng với giá cao trong thị trấn, nhưng hãy bỏ qua các kịch bản cực đoan sang một bên).
Nhà cung ứng có thể tăng gấp đôi số lượng trạm xăng vì nhu cầu tăng vọt; hoặc cũng có thể xảy ra trường hợp các trạm xăng là một ngành kinh doanh thực sự có lãi và các doanh nhân vẫn tiếp tục tham gia vào thị trường này dù nhu cầu không tăng.
Vì vậy, nếu bạn muốn tìm hiểu xem nhu cầu về khí đốt có tăng lên trong một thị trấn hay không, một cấu trúc MECE có thể sử dụng là “số trạm xăng * trung bình lượng xăng bán ra trên mỗi trạm”, nhưng đây không phải hướng tiếp cận tốt nhất. Tại sao? Bởi số trạm xăng không thúc đẩy nhu cầu – nhiều trạm xăng hơn không giúp số lượng ô tô và mức sử dụng mỗi ô tô nhiều hơn.
———-
Tương tự với vấn đề phía trên: Nhiều nhà kho hơn không dẫn đến nhiều hành vi trộm cắp hơn ở Amazon. Giả sử nếu Amazon đã cơ cấu lại hoạt động và công ty đã chuyển từ 10 kho hàng có quy mô khổng lồ sang 100 kho hàng nhỏ hơn, với mục tiêu giao hàng nhanh hơn, liệu trộm cắp có tăng gấp 10 hay 50 lần không?
Amazon có số lượng sản phẩm lưu kho và số lượng nhân viên ở mỗi nhà kho, và nếu họ có hệ thống an ninh, điều đó. Nhiều nhà kho hơn không đồng nghĩa với việc sẽ có nhiều vụ trộm hơn. Nhà kho và trạm xăng ở đây chỉ đơn thuần là nơi tập trung của hàng hóa. Đây là lý do vì sao lỗi sai này được gọi là “sự ngụy biện” – nghĩ rằng số lượng của một yếu tố tăng lên có thể gây ra vấn đề. Để khắc phục lỗi sai này, hãy cố gắng tập trung với các mối quan hệ nhân quả được chứng minh là có liên quan.
Trong ví dụ về trạm xăng, đó sẽ là “số ô tô * nhiên liệu được sử dụng cho mỗi ô tô”. Trong ví dụ trộm cắp ở Amazon, bạn có thể sử dụng “số sản phẩm trong kho * tỷ lệ trộm cắp” nếu bạn cho rằng càng nhiều sản phẩm thì càng có nhiều nhu cầu đối với kẻ trộm, hoặc “tỷ lệ tội phạm trung bình khu vực đặt kho của Amazon * % tội phạm xảy ra ở kho hàng Amazon” trong trường hợp bạn cho rằng tỷ lệ tội phạm đã được cố định và chỉ có thể kiểm soát mức độ % giữa số tỷ lệ tội phạm tại kho hàng của Amazon với số tội phạm tại khu vực.
Lỗi sai #4 – Không tuân theo nguyên tắc MECE
Issue Tree này mắc lỗi MECE ngay ở tầng đầu do:
(1) Khăng khăng sử dụng kỹ thuật Khung khái niệm (đây là kỹ thuật khó nhất trong 5 cách tiếp cận theo nguyên tắc MECE) trong khi không cần áp dụng tới kỹ thuật đó bởi đây là bài toán có thể sử dụng theo góc nhìn toán học.
(2) Không biết cách tạo ra khung khái niệm theo nguyên tắc MECE.
Lỗi sai #5 – Không chứng minh được mối quan hệ nhân – quả
Có nhiều lỗi sai trong Issue Tree này.
(1) Issue Tree này đã bóc tách vấn đề theo kỹ thuật Khung khái niệm – với nhóm yếu tố “các yếu tố phương tiện của nhà kho” và gặp khó khăn khi đào sâu và phát triển nó.
(2) Có sự trùng lặp giữa “Bảo mật” và “Bảo mật thông tin”.
(3) Có nhiều yếu tố không được xét đến ở đây (bao gồm cả hành vi trộm cắp của nhân viên nội bộ).
Nhưng có một lỗi sai quan trọng không kém nhưng lại khó nhận ra hơn ở tầng đầu tiên – Issue Tree này đã xác định hai yếu tố tội phạm bên ngoài và yếu tố trộm cắp trong nội bộ, dù vậy sẽ rất khó để kiểm tra yếu tố nào gây ra sự gia tăng số lượng trộm cắp bởi những yếu tố này rất khó để định lượng yếu tố này.
Cần xem xét dữ liệu tội phạm nào để chứng minh/bác bỏ nhận định thực tế là tội phạm đã gia tăng? Thực trạng này có đủ bao quát để chứng minh cho các vấn đề tội phạm, hay chỉ trộm cắp, và có đủ cụ thể để chứng minh sự gia tăng của tình trạng trộm cắp trong kho hàng?
Ngoài ra, dữ liệu về địa lý sẽ tính theo quy mô nào? Khu vực, thành phố hay tỉnh/bang? Sẽ rất khó để định lượng và đo lường các yếu tố phương tiện của nhà kho, nên bạn cũng khó có thể loại trừ toàn bộ nhánh này bởi không thể chứng minh mối quan hệ là sai.
Tạm kết
Nếu bạn muốn nâng cao kỹ năng và tư duy problem-solving trong môi trường kinh doanh, hãy tham khảo khóa học Case Mastery của Tomorrow Marketers! Với thiết kế lộ trình bài bản 10 buổi học, đi qua các dạng Model và Business Case khác nhau, khóa học Case Mastery sẽ giúp học viên nâng cao tư duy Problem-Solving, tự tin chinh phục các cuộc thi và chương trình tuyển dụng như Management Trainee/Management Consultant.
Bên cạnh việc bổ sung kiến thức, việc tham khảo các bài làm mẫu cũng là một cách tốt để thí sinh nắm được cách trình bày và hơn hết là học tập cách tư duy hợp lý, logic. Với mục tiêu giúp các bạn newbies nói riêng cũng như các bạn sinh viên nói chung bớt lúng túng trong những lần thi đầu, đồng thời cải thiện được thành tích của mịn, tham khảo ngay Case Mastery Resource Hub từ Tomorrow Marketers
Đây là thư mục miễn phí tổng hợp đề thi và hơn 30 bài làm đạt giải cao từ nhiều cuộc thi như Marketing Arena, CMO, Think & Action, L’Oréal Brandstorm, NielsenIQ Case Competition và nhiều cuộc thi uy tín khác
Bài viết bởi Crafting Case và được biên dịch bởi Tomorrow Marketers, xin vui lòng không sao chép dưới mọi hình thức!
