MBA Knowledge

Cách tôi build second brain

2026-07-31T14:12:08.278+07:00

Hôm nọ, tôi cần tìm lại một tài liệu mà mình đã làm cho một dự án cách đây vài năm. Tôi nhớ rõ nội dung của nó. Tôi nhớ mình đã tự vẽ sơ đồ quy trình, viết scope & timeline cho dự án, dành nhiều thời gian để làm risk management cho em nó. Tuy nhiên, phải mất hơn 30 phút lục tung ổ cứng, Google Drive, OneDrive, Dropbox tôi mới tìm thấy nó.

Đây không phải là lần đầu tiên chuyện này xảy ra. Và có lẽ cũng không chỉ mình tôi gặp phải. Sau hơn 20 năm làm việc trong ngành phần mềm, số lượng files tích lũy được đã lên đến hàng nghìn file, nằm rải rác nhiều nơi. Đó là các tài liệu dự án, ebooks, bài study/ research/ whitepaper, slide đào tạo, ghi chú cá nhân, email, quy trình, template, checklist, những bài viết đã từng đọc và cả những kinh nghiệm được đúc kết sau mỗi lần thành công hay thất bại. Tôi thấy mình không hề thiếu kiến thức hay khả năng tổ chức quản lý files. Điều tôi thiếu là khả năng tìm lại đúng thứ mình cần một cách nhanh nhất.

Lúc đó, tôi bắt đầu suy nghĩ đến việc quản lý tri thức cá nhân và tìm cách scale out RAM cho brain của mình lên dựa trên khái niệm Second Brain (bộ não thứ hai) được nói đến gần đây bằng việc tận dụng sức mạnh của AI. Sau đó, tôi bắt tay tìm hiểu và xây dựng một hệ thống có thể đọc, hiểu và kết nối toàn bộ kho tài liệu của mình. Tôi muốn khi đặt một câu hỏi, AI không chỉ trả về danh sách file liên quan mà còn có thể đọc hàng chục files, tổng hợp nội dung, so sánh, trích dẫn đúng nguồn và đưa ra một câu trả lời hoàn chỉnh. Nói cách khác, tôi không chỉ muốn một công cụ tìm kiếm. Tôi muốn một cộng sự có khả năng tư duy cùng mình và với chi phí thấp nhất. Mục tiêu là tất cả tài liệu trên máy tính sẽ được AI đọc và lập chỉ mục. Mỗi đoạn nội dung được chuyển thành các biểu diễn ngữ nghĩa để máy có thể hiểu ý thay vì chỉ hiểu từ khóa. Khi cần, tôi chỉ việc đặt câu hỏi bằng ngôn ngữ tự nhiên giống như đang trao đổi với một đồng nghiệp. Ví dụ, thay vì phải nhớ file nào chứa thông tin quản lý dự án cho 1 sản phẩm X nào đó, tôi chỉ cần nói: "Hãy tổng hợp những file liên quan đến product X, release SOP liên quan, scope & timeline như thế nào". Phần còn lại để AI xử lý.

Do làm theo cách tiết kiệm chi phí, vừa làm vừa học với kiến thức technical hạn hẹp do nhiều năm làm công việc PM, nên tôi thực hiện theo từng bước tùy theo mục đích sử dụng:

Step 1: Quét toàn bộ thư mục và tạo chỉ mục tìm kiếm từ khóa
- Quét toàn bộ thư mục (kể cả thư mục con), trích xuất nội dung văn bản từ từng định dạng file PDF, Word, PowerPoint, Excel và lưu vào một database có tính năng full text search bằng SQLite FTS5, đóng gói trong một file RT2Brain.db chẳng hạn.
- Kết quả khi cần gõ một cụm từ, nhận về ngay danh sách file chứa đúng cụm từ đó kèm đoạn trích ngữ cảnh, không cần AI, không tốn chi phí, tốc độ tức thời.
- Nếu nhu cầu tìm file nhanh, chỉ cần Step 1 này là đủ đáp ứng.

Step 2: Tóm tắt từng file bằng AI
Vì không thể đưa nội dung của hàng ngàn file vào một lệnh gọi AI duy nhất, tôi áp dụng mô hình hai tầng:
- Tầng 1: Tóm tắt từng file: với mỗi file, gọi AI để tóm tắt 3-5 câu kèm từ khóa chính, rồi lưu vào cùng file RT2Brain.db (ví dụ thêm summary, keywords).
- Tầng 2: Tổng hợp trên các bản tóm tắt, không phải nội dung gốc: khi cần một báo cáo insight hoặc một sơ đồ mindmap, tôi gộp các bản tóm tắt đã lọc theo từ khóa/thư mục và đưa cho AI tổng hợp một lần vì bản tóm tắt nhỏ hơn nội dung gốc hàng chục lần, việc này rất nhanh và rẻ dù xử lý trên hàng trăm file cùng lúc.

Step 3: Chuyển một phần xử lý về chạy local để bảo vệ dữ liệu nhạy cảm
- Vì một số dữ liệu nhạy cảm nên tôi thêm khả năng chạy AI hoàn toàn trên máy, không qua internet, bằng cách dùng Ollama.
- Cách phân chia: tóm tắt từng file (khối lượng lớn, tác vụ đơn giản) chuyển sang mô hình chạy cục bộ, dữ liệu không bao giờ rời khỏi máy. Bước tổng hợp insight/ mindmap cuối cùng (khối lượng nhỏ hơn nhiều, cần độ chính xác cao hơn) vẫn có thể dùng mô hình đám mây khi cần, vì lúc này dữ liệu đưa ra ngoài chỉ còn là bản tóm tắt đã cô đọng.

Step 4: Thêm tìm kiếm ngữ nghĩa (RAG) chạy hoàn toàn local
- Chia nhỏ nội dung mỗi file thành từng đoạn; biến mỗi đoạn thành một vector số học đại diện cho ý nghĩa (embedding) bằng bge-m3 chạy qua Ollama; và lưu vector đó ngay trong cùng file RT2Brain.db (thêm bảng chunks), không cần cài cơ sở dữ liệu vector chuyên dụng riêng, với quy mô vài chục ngàn đoạn văn bản, phép tính tương đồng cosine bằng thư viện số học thông thường (numpy) đã đủ nhanh.
- Khi truy vấn: câu hỏi được biến thành vector theo cùng cách, so khớp với toàn bộ vector đã lưu, trả về các đoạn liên quan nhất, kể cả khi không trùng từ khóa nào với câu hỏi. Có thêm một bước tùy chọn: đưa các đoạn tìm được cho một mô hình AI cục bộ để tổng hợp thành câu trả lời hoàn chỉnh, kèm trích dẫn tên file nguồn.

Step 5: Enhance performance bằng cách xử lý theo batch khi sinh vector cho hàng hàng file
Sau khi cả bốn steps hoạt động, phần việc còn lại là làm cho quá trình xử lý hàng loạt (tóm tắt, sinh vector cho hàng ngàn file) thực sự chạy nhanh ở máy Local để không ảnh hưởng đến các tác vụ khác:
- Chia batch khi chạy: mỗi file xử lý xong được lưu ngay lập tức, nên có thể dừng bất cứ lúc nào mà không mất tiến độ, và giới hạn số file xử lý mỗi lần chạy để không phải giữ máy chạy liên tục.
- Thử lại tự động: khi gặp lỗi mạng hoặc hết thời gian chờ tạm thời, script tự thử lại vài lần trước khi báo lỗi, kèm thời gian chờ có thể tùy chỉnh.
- Chia nhỏ mỗi lần gọi AI: với file có nhiều đoạn, gửi từng batch nhỏ (8 đoạn/lần) thay vì gộp cả file vào một yêu cầu duy nhất, tránh timeout với các mô hình chạy trên phần cứng yếu.
- Kiểm tra trước khi chạy hàng loạt: xác nhận AI models đã sẵn sàng trước khi bắt đầu xử lý hàng ngàn file, thay vì phát hiện lỗi sau khi đã xử lý dở dang.

Kết quả cuối cùng là một hệ thống search chạy bằng dòng lệnh, vận hành trên một file cơ sở dữ liệu duy nhất, cho phép tìm kiếm và tổng hợp tri thức từ toàn bộ kho tài liệu tích lũy suốt nhiều năm, chạy được cả bằng AI trên Cloud lẫn Local, tùy vào mức độ nhạy cảm của từng loại dữ liệu.

Step 6 tiếp theo là integrate vào Telegram chatbot hiện tại của tôi, để khi có việc ra ngoài thì vẫn có thể truy vấn khi cần thông qua điện thoại.

#AI #Transformation #PositiveLeadership #VuiVeKhongQuau #SecondBrain

Phương pháp training khi triển khai SAP/ ERP Project

2026-07-25T11:30:53.852+07:00

Trong các dự án SAP/ERP, Train-the-Trainer (TTT) là phương pháp đào tạo được áp dụng phổ biến nhất.

Thay vì để đội ngũ tư vấn đào tạo trực tiếp cho toàn bộ người dùng, SAP Functional Consultants sẽ đào tạo Business Key Users (hay Super Users). Sau đó, chính các Key Users sẽ tiếp tục đào tạo End Users theo từng vai trò nghiệp vụ, với sự đồng hành và hỗ trợ của Consultants trong các giai đoạn quan trọng như Pilot Training và Go-Live.

Mô hình này mang lại nhiều lợi ích:

Dễ mở rộng cho các doanh nghiệp có hàng trăm hoặc hàng nghìn người dùng.
Chuyển giao tri thức cho doanh nghiệp thay vì phụ thuộc hoàn toàn vào đơn vị triển khai.
Tăng tỷ lệ người dùng chấp nhận và sử dụng hệ thống nhờ được đào tạo bởi chính những đồng nghiệp am hiểu cả quy trình nghiệp vụ lẫn SAP.
Giảm sự phụ thuộc vào đội ngũ tư vấn sau khi Go-Live.

Ngày nay, đào tạo trong các dự án SAP không còn dừng lại ở các lớp học truyền thống. Nhiều doanh nghiệp đang kết hợp Train-the-Trainer, Digital Adoption Platform (SAP Enable Now / WalkMe) và AI Copilot như SAP Joule để hỗ trợ người dùng học tập liên tục trước, trong và sau Go-Live.

Thực tế, mô hình Train-the-Trainer không chỉ giới hạn trong các dự án SAP hay ERP. Đây là cách phát triển năng lực đã được nhiều tổ chức áp dụng trong các lĩnh vực như chuyển đổi số, quản lý dự án, Lean, Six Sigma, Agile hay các chương trình phát triển lãnh đạo. Doanh nghiệp thường cử một nhóm nhân sự nòng cốt tham gia các khóa đào tạo bên ngoài, sau đó những người này sẽ trở thành Internal Trainers, tiếp tục đào tạo và chia sẻ kiến thức cho đồng nghiệp. Cách làm này vừa tiết kiệm chi phí, vừa giúp tri thức được duy trì và phát triển ngay trong nội bộ doanh nghiệp.

Tuy nhiên, để làm tốt vai trò đó, kiến thức chuyên môn thôi là chưa đủ. Một Internal Trainer cũng cần có kỹ năng Facilitation, thiết kế workshop, thuyết trình, giao tiếp, đặt câu hỏi, xử lý tình huống, dẫn dắt thảo luận và tạo sự tương tác với học viên. Khi những kỹ năng này được kết hợp với chuyên môn, việc đào tạo sẽ không còn đơn thuần là truyền đạt kiến thức, mà trở thành quá trình giúp người học hiểu, áp dụng và từng bước thay đổi cách làm việc.

Bản thân tôi cũng có cơ hội trải nghiệm mô hình này trong công việc. Trong nhiều năm, tôi được công ty đầu tư tham gia các khóa đào tạo về Facilitation, Workshop Design, System Thinking, The 7 Habits of Highly Effective People, Agile/ Scrum/ Kanban/ LeSS, và một số chương trình phát triển kỹ năng khác. Sau mỗi khóa học, tôi thường đảm nhận vai trò Internal Trainer, trực tiếp tổ chức các workshop và chia sẻ lại kiến thức cho đồng nghiệp. Chính những trải nghiệm đó giúp tôi nhận ra rằng, giá trị lớn nhất của một khóa đào tạo không nằm ở chứng chỉ hay số giờ học, mà ở việc kiến thức có được lan tỏa, áp dụng và tạo ra thay đổi tích cực trong tổ chức hay không.

Digital Immigrants, Digital Natives và hành trình Digital Transformation

2026-07-22T23:09:35.527+07:00

Bạn có biết mình đang làm việc cho Digital Natives hay Digital Immigrants?

Tôi biết tới hai khái niệm này khi đọc cuốn sách SAP Business Technology Platform.

SAP sử dụng hai thuật ngữ này để mô tả điểm xuất phát của doanh nghiệp trong kỷ nguyên số.

Digital Natives là những doanh nghiệp được sinh ra trong thời đại Internet. Họ đã xây dựng mô hình kinh doanh dựa trên Cloud, Mobile, Data và API ngay từ những ngày đầu. Công nghệ không chỉ là công cụ hỗ trợ mà chính là nền tảng cốt lõi của doanh nghiệp. Những cái tên như Uber, Netflix, Amazon hay Grab là những ví dụ điển hình. Ở thời đại AI ngày nay, những doanh nghiệp này sẽ bứt phá nhanh và tạo lợi thế cạnh tranh rõ rệt.

Ngược lại, Digital Immigrants là những doanh nghiệp đã tồn tại từ trước kỷ nguyên số. Họ sở hữu các hệ thống di sản (legacy system), quy trình nghiệp vụ và hạ tầng CNTT đã được xây dựng trong nhiều năm, chẳng hạn như SAP ECC, Oracle hay Mainframe. Phần lớn các tập đoàn sản xuất, bán lẻ, ngân hàng hay logistics trên thế giới đều thuộc nhóm này. Dù đang giữ vai trò trụ cột kinh tế, nhóm này đối mặt với nguy cơ suy vong lớn. Nếu không chủ động hiện đại hóa, họ rất dễ đi vào con đường diệt vong của những cái tên từng thống trị một thời như Blockbuster hay BlackBerry, những "khủng long kỹ thuật số" (Digital Dinosaurs) thất bại vì chậm thích ứng.

Trong quá trình hiện đại hóa, thông thường các Digital Immigrants sẽ trải qua ba cấp độ của quá trình dịch chuyển công nghệ:

Digitization ──► Digitalization ──►Digital Transformation

Trong đó:

Digitization (Số hóa dữ liệu): Dịch chuyển thông tin từ dạng vật lý/ analog sang dạng số (ví dụ: chuyển từ thư tay sang email, từ hóa đơn giấy sang hóa đơn điện tử).
Digitalization (Ứng dụng số): Sử dụng máy tính và phần mềm để đơn giản hóa, tự động hóa quy trình làm việc hiện tại mà không làm thay đổi bản chất của mô hình kinh doanh (ví dụ: tra cứu hồ sơ khách hàng bằng phần mềm thay vì tìm trong tủ tài liệu).
Digital Transformation (Chuyển đổi số): Thay đổi tư duy kinh doanh dựa trên năng lực công nghệ. Doanh nghiệp tái cấu trúc hoàn toàn quy trình và tạo ra các giá trị, chuỗi cung ứng hoặc nguồn doanh thu mới (ví dụ: Netflix chuyển từ cho thuê đĩa DVD sang nền tảng phát trực tuyến và tự sản xuất nội dung dựa trên phân tích dữ liệu người dùng).

Tuy nhiên, đối với các doanh nghiệp Digital Immigrants, việc đập bỏ toàn bộ hệ thống cũ để làm lại từ đầu là điều bất khả thi. Lời giải chiến lược được Gartner đề xuất chính là vận hành Bimodal IT (IT Lưỡng chế):

Chế độ 1 (Mode 1 - Stability): Tập trung vào tính ổn định, an toàn và độ tin cậy. Nhiệm vụ chính là duy trì hoạt động ổn định cho các ứng dụng cốt lõi (Keep the lights on).
Chế độ 2 (Mode 2 - Agility): Tập trung vào đổi mới sáng tạo, thử nghiệm nhanh và tính linh hoạt. Nhóm này ứng dụng các công nghệ tiên tiến như AI, Machine Learning, Big Data để tạo ra trải nghiệm người dùng hiện đại và mô hình tăng trưởng mới.

Điều này lại dẫn đến thách thức khác là nhà lãnh đạo khó lòng chỉ chọn 1 trong 2, mà phải xây dựng một nền tảng kết nối (Platform Bridge) đóng vai trò chiếc cầu nối giữa hệ thống di sản (Mode 1) và các ý tưởng đổi mới (Mode 2).

Vì lý do này mà SAP Business Technology Platform (SAP BTP) ra đời.

SAP BTP không nhằm thay thế các hệ thống ERP hiện có của Digital Immigrants mà đóng vai trò là cây cầu kết nối giữa hệ thống legacy và các công nghệ hiện đại như AI, Automation, Integration, Analytics và Cloud, giúp doanh nghiệp hiện đại hóa từng bước thay vì bắt đầu lại từ đầu.

P/PC Balance trong kỷ nguyên AI

2026-07-21T12:12:31.858+07:00

Một trong những khái niệm trong The 7 Habits of Highly Effective People của tác giả Stephen Covey là P/PC Balance.

1) Covey kể một câu chuyện ngụ ngôn:
Một người nông dân mỗi ngày đều có một quả trứng vàng từ con ngỗng của mình. Ban đầu ông ta rất hạnh phúc. Nhưng rồi lòng tham xuất hiện. Ông ta bắt đầu nghĩ:"Nếu mỗi ngày chỉ có một quả thì quá chậm. Chắc chắn trong bụng con ngỗng còn rất nhiều vàng."
Thế là ông ta mổ con ngỗng với hy vọng lấy tất cả số vàng cùng một lúc.
Kết quả? Không có thêm vàng, và con ngỗng cũng không còn.

Đó chính là điều Covey gọi là P/PC Balance.
- P (Production) là quả trứng vàng.
- PC (Production Capability) là con ngỗng tạo ra những quả trứng.

Muốn có nhiều quả trứng hơn, phải chăm sóc con ngỗng trước.
Đừng vì muốn tăng P mà phá hủy PC.

2) Khi AI xuất hiện, bài học có vẻ cũng tương tự.
Khi đó, kỳ vọng của nhiều lãnh đạo tổ chức gần như trở thành:
- "Giờ đã có AI, phải delivery nhiều hơn với cùng hoặc ít nhân lực hơn."
Đây là kỳ vọng hoàn toàn dễ hiểu.

Thực tế, AI có thể giúp tăng PC ngay ở một số công việc như viết tài liệu, lập trình, phân tích dữ liệu hay tự động hóa các tác vụ lặp lại.
Tuy nhiên, điều đó không có nghĩa PC của toàn tổ chức đã tăng đủ nhanh để đáp ứng ngay kỳ vọng về P.

Nếu tổ chức chỉ tập trung tăng KPI hoặc cắt giảm nhân sự mà chưa đầu tư để mở rộng PC tương ứng, vòng lặp sau rất dễ xảy ra:
=> Có AI -> Tăng KPI/ Lay off -> Nhân viên làm nhiều hơn -> Burnout -> Nhân viên nghỉ việc/ Phá hoại -> Mất knowledge -> Hiệu suất toàn tổ chức giảm

=> Cuối cùng, lãnh đạo muốn tăng P nhưng vô tình phá hủy PC của tổ chức.

3) Tôi nghĩ điều này xảy ra do có sự nhầm lẫn giữa "Có AI" & "Có năng lực làm việc cùng AI"
Có AI trong tay giống như phát cho con ngỗng một liều thuốc tăng tốc, nó khiến ngỗng đẻ nhanh hơn thật, nhưng thuốc không tự biến thành thức ăn, sức khỏe hay thời gian nghỉ ngơi mà con ngỗng cần để duy trì nhịp độ đó lâu dài.

Muốn PC thực sự tăng lên, cần thời gian transformation để:
- Học cách cộng tác với AI
- Biết cách đặt câu hỏi đúng
- Biết kiểm chứng kết quả của AI,
- Biết scale kết quả của AI làm ra
- Thiết kế lại quy trình & automation làm việc cùng AI
- Tích lũy knowledge base
- Thay đổi cách tư duy và ra quyết định
Và trên hết, cần một thỏa thuận ngầm Win/Win: tổ chức đầu tư PC, nhân viên cam kết tạo ra P tương xứng, chứ không phải một bên áp đặt lên bên còn lại.

Vì với thời đại AI, PC giờ đây là tổng hòa của: năng lực con người, khả năng cộng tác với AI, quy trình làm việc, automation, tri thức được tích lũy, và khả năng phục hồi sau cường độ làm việc cao.

Do đó, AI không làm cho P/PC Balance trở nên lỗi thời mà khiến bài học của Stephen Covey trở nên quan trọng hơn.
Vì trong kỷ nguyên AI, có thể tổ chức chiến thắng không phải là tổ chức đòi hỏi nhiều "quả trứng vàng" nhất. Mà là tổ chức biết cách nuôi dưỡng những "con ngỗng" đủ khỏe để cộng tác cùng AI, tạo ra nhiều quả trứng vàng hơn, một cách bền vững hơn.

8 Trụ cột cần kiểm soát trong Fixed-Price Project

2026-07-20T17:20:40.979+07:00

Trong fixed-price project, người quản lý dự án cần vận hành một hệ thống kiểm soát gồm nhiều trụ cột liên kết với nhau, nơi một lỗ hổng ở bất kỳ trụ cột nào cũng có thể tác động trực tiếp đến margin của dự án.

1. Scope Control

Ranh giới giữa in-scope và out-of-scope phải được xác định rõ ràng và minh bạch. Baseline scope cần được bảo vệ như bảo vệ chính hợp đồng, vì đó là điều khách hàng đã mua và vendor đã cam kết cung cấp.

2. Cost & Margin Control

Margin không phải là con số chỉ được tính khi ký hợp đồng rồi bỏ quên. Actual Cost cần được đối chiếu với Planned Cost theo tuần, không phải đợi đến các milestone. Một PM giỏi không đợi đến cuối dự án mới biết dự án lãi hay lỗ; họ nhìn thấy xu hướng đó từ rất sớm thông qua Burn Rate, Forecast Cost và Forecast Margin.

3. Resource Optimization

Đội dự án không phải nguồn lực miễn phí. Mỗi giờ over-allocation hay under-utilization đều làm tăng chi phí. Resource loading cần được cân bằng với effort estimate, đúng người, đúng kỹ năng và đúng thời điểm, thay vì để những "buffer ẩn" trong lịch làm việc của từng cá nhân.

4. Schedule Management

Trễ tiến độ trong Fixed-price không chỉ ảnh hưởng đến uy tín. Nó kéo dài thời gian burn cost của PM, BA, Developer, QA, hạ tầng và các chi phí vận hành khác mà không tạo thêm doanh thu. Điều quan trọng không phải là một Gantt Chart đẹp, mà là kiểm soát được Critical Path và các milestone quan trọng.

5. Risk Management

Risk Register phải là một công cụ sống, không phải một tài liệu được tạo ra để hoàn thành quy trình. Mỗi rủi ro cần được lượng hóa về xác suất, mức độ tác động và phương án giảm thiểu. Escalation nên diễn ra khi các chỉ số bắt đầu chạm ngưỡng cảnh báo, thay vì đợi rủi ro trở thành issue.

6. Change Management

Mọi thay đổi cần được đánh giá tác động về Scope, Cost, Schedule và Risk, đồng thời thống nhất cơ chế thương mại trước khi trở thành cam kết thực hiện. Trong một dự án Fixed-price, mỗi thay đổi phạm vi nên được nhìn nhận như một quyết định kinh doanh, không chỉ là một quyết định kỹ thuật.

7. Quality Management

Rework là một trong những kẻ thù thầm lặng nhất của margin. Càng phát hiện lỗi muộn, chi phí sửa càng cao. Đầu tư vào review, testing, automation và knowledge sharing từ sớm gần như luôn rẻ hơn rất nhiều so với việc sửa lỗi ở cuối dự án.

8. Continuous Productivity Improvement

Fixed-price không thưởng cho việc làm nhiều hơn, mà thưởng cho việc làm thông minh hơn. Reuse, template, automation, AI và lessons learned giúp giảm effort, nâng cao năng suất và cải thiện khả năng estimate cho các dự án tiếp theo. Productivity không phải là kết quả của việc làm việc chăm chỉ hơn, mà là kết quả của việc liên tục cải tiến cách làm việc.

Sợi chỉ xuyên suốt: Giao tiếp và Đàm phán

Tám trụ cột trên đều có một điểm chung dễ bị bỏ qua: không trụ cột nào vận hành hiệu quả nếu thiếu giao tiếp và thương lượng.

Từ việc trao đổi với khách hàng về một Change Request, đàm phán lại timeline với stakeholder, cho đến việc giúp team cam kết effort một cách thực tế, tất cả đều là những cuộc hội thoại khó.

Thách thức không nằm ở việc nói "không", mà ở việc vừa bảo vệ được margin, vừa duy trì được niềm tin của khách hàng và đội dự án.

Một dự án thắng về tài chính nhưng đánh mất khách hàng chưa phải là một dự án thành công.

Và trước cả giao tiếp là khả năng lắng nghe

Lắng nghe khách hàng để hiểu điều họ thực sự cần, thay vì chỉ điều họ yêu cầu.

Lắng nghe stakeholder để nhận ra những dấu hiệu bất mãn trước khi chúng trở thành xung đột.

Lắng nghe đội dự án để phát hiện những estimate đang dần mất kiểm soát trước khi chúng trở thành rủi ro.

Phần lớn các vấn đề trong dự án không xuất hiện đột ngột. Chúng luôn để lại những tín hiệu rất sớm. Chỉ những người thực sự lắng nghe mới có thể nhận ra chúng đủ sớm để hành động.

Cuối cùng...

Tám trụ cột này không tồn tại độc lập.

Scope creep sẽ kéo theo Cost Overrun.

Risk không được kiểm soát sẽ làm trễ Schedule.

Quality kém sẽ tạo ra Rework.

Resource không tối ưu sẽ làm Burn Rate tăng nhanh hơn kế hoạch.

Điểm khó của một Fixed-price Project không nằm ở việc quản lý tốt từng trụ cột riêng lẻ, mà nằm ở khả năng nhìn chúng như một hệ thống.

Bởi cuối cùng, margin không biến mất vì một sai lầm lớn. Nó bị bào mòn bởi hàng trăm quyết định nhỏ được đưa ra mỗi ngày.

Đó cũng là khác biệt giữa một Project Manager quản lý dự án và một Project Manager quản trị một hợp đồng kinh doanh.

50 essential concepts every SAP/ ERP Project Manager should know

2026-07-18T11:15:40.232+07:00

A SAP Project Manager may not need to configure SAP like functional consultants. But they must understand how SAP works.

Behind every successful SAP implementation is a common language shared by Business, Consultants, Architects, Developers, and Project Managers.

Understanding concepts such as Fit-to-Standard, WRICEF, Cutover, Data Migration, Transport, UAT, Hypercare, and Governance enables PMs to communicate effectively, make informed decisions, anticipate risks, and lead transformation with confidence.

That's why I created this SAP PM Survival Guide, a concise reference of 50 essential concepts every SAP/ ERP PM should know.

Because the best PMs don't just manage projects, they connect people, processes, and technology well together.

Does Inventory Cost Exist in Software Development?

2026-07-17T20:56:35.203+07:00

In manufacturing, we may know the principle: "Inventory is expensive".
Raw materials, work-in-progress, and finished goods all represent capital that has already been invested but has not yet generated business value.
That's why manufacturers continuously reduce inventory, to improve cash flow and accelerate value realization.

But how about in software industry?
Software has no warehouse, no physical inventory. So does Inventory Cost exist?

We believe it does.

Imagine a feature that has already consumed 40 man-days of engineering effort.
The code is finished. Testing is done.
But the feature is still waiting for UAT, for release approval, or the next deployment because dependencies with others.

Customers still cannot use it. The business receives no value.

Yet the engineering investment has already been made.
In other words, the inventory isn't sitting in a warehouse, it is sitting inside the delivery pipeline.

This inspired an internal management metric that we temporarily call Engineering Inventory:
- Engineering Inventory = Total engineering effort (hours or man-days) invested in features that have not yet been released to customers.

Instead of measuring Story Points or Pull Requests, that many people say they are meaningless, we simply tracked the trend every week.

If Engineering Inventory kept increasing, it was a signal that engineering investment was accumulating faster than customer value was being delivered.

Interestingly, the biggest impact wasn't the metric itself, it was the conversations it created.

Instead of focusing on how much work was completed, teams began thinking about how quickly engineering investment could be converted into customer value.
- Can we split this Epic into smaller features?
- Can we release every Sprint instead of every month?
- Why are completed features still waiting?
- Where is the bottleneck in our delivery pipeline?

Without changing development methodology, this single metric naturally encouraged Lean behaviors, and encouraged teams to think differently: favoring smaller batch sizes, more frequent releases, faster customer feedback, and ultimately, better value delivery.

We may know that we have lots of software metrics measure activity like {Lines of Code, Story Points, Pull Requests, Commits}, some measure delivery like {Lead Time, Cycle Time, Deployment Frequency}, but Engineering Inventory measures something different:
- How much engineering investment has not yet become customer value?

Perhaps software organizations shouldn't focus only on building software faster.
Perhaps we should also measure how quickly engineering investment is transformed into business outcomes.
Because, ultimately, that's what top leaders care about.

#softwaredevelopment #lean #leadership #management #transformation

Typical SAP Implementation Approach

2026-07-15T15:55:37.101+07:00

Một project SAP implementation chuẩn theo phương pháp ASAP (Accelerate SAP) thường được triển khai theo một lộ trình gồm 5 giai đoạn chính:
1. Project Preparation → 2. Blueprint → 3. Realization → 4. Final Preparation → 5. Go-Live & Hypercare.

Mỗi giai đoạn đều có mục tiêu rõ ràng, các hoạt động trọng tâm, deliverables cần hoàn thành và các "decision gates" trước khi chuyển sang bước tiếp theo.

1) Project Preparation: tập trung vào việc xác định phạm vi, mục tiêu, governance và kế hoạch triển khai.
2) Blueprint: là giai đoạn thiết kế quy trình TO-BE, chuẩn hóa nghiệp vụ và thống nhất giải pháp giữa business và IT.
3) Realization: chuyển các thiết kế thành cấu hình hệ thống, phát triển các đối tượng mở rộng, tích hợp và kiểm thử.
4) Final Preparation: là lúc doanh nghiệp xác nhận dữ liệu, đào tạo người dùng, diễn tập cutover và đánh giá mức độ sẵn sàng trước Go-Live.
5) Go-Live & Hypercare: không phải là điểm kết thúc, mà là giai đoạn đảm bảo hệ thống vận hành ổn định và chuyển giao sang đội ngũ vận hành lâu dài.

Đó là quy trình chuẩn mà hầu hết các project triển khai SAP đều apply, dù được triển khai theo SAP Activate hay được tùy biến bởi các đối tác như Accenture, Deloitte, PwC, EY hay IBM.

Ngoại trừ 5 phase chuẩn cần phải plan rõ ràng và theo dõi sát sao, để dự án thành công thì người quản lý dự án cần phải vượt qua các thách thức đến từ những yếu tố khác như:
- Dữ liệu chưa được làm sạch và chuẩn hóa.
- Các đơn vị kinh doanh chưa thống nhất quy trình.
- Integration & phối hợp giữa các Functional Consultants
- Người dùng chưa sẵn sàng thay đổi.
- Các quyết định quan trọng bị chậm trễ.
- Governance thiếu rõ ràng giữa Business, IT và đối tác triển khai.
- V.v.

Vì thế, các Project Manager giàu kinh nghiệm thường dành nhiều thời gian cho Steering Committee, Risk Review, UAT Readiness, Cutover Planning và Change Management để đảm bảo Scope, Timeline, Issues/ Risks, v.v. của dự án được minh bạch, rõ ràng và được giải quyết kịp thời khi có bất kỳ blockage nào xảy ra.

Some metrics that modern Delivery Leaders should measure

2026-07-11T15:58:12.049+07:00

Many project managers are evaluated by three familiar metrics: scope, schedule, and budget.

But in today's enterprise environment, where technology teams continuously build new capabilities, maintain legacy systems, and keep mission-critical platforms running 24/7, these measures tell only part of the story.

Modern Delivery, Program, and Transformation leaders are increasingly expected to manage business outcomes, not just project outputs.

That is why organizations are shifting toward operational and flow-based metrics such as:

1) MTTR (Mean Time to Recovery): How quickly can we restore service when failures occur?
2) MTBF (Mean Time Between Failures): How reliable are our systems over time?
3) Service Availability: Are critical platforms consistently available to the business?
4) Lead Time: How long does it take to turn a business request into production value?
5) Deployment Frequency: How rapidly can we deliver improvements?
6) Change Failure Rate: How often do releases create new problems?
7) Incident Rate & SLA Achievement: Are we improving service quality while meeting business commitments?
8) Backlog Health & Demand Throughput: Are we delivering the work that matters most?
9) Resource Utilization: Are we balancing capacity without overloading our teams?
10) Business Value Delivered: Are our initiatives creating measurable impact beyond technical completion?

None of these metrics should be viewed in isolation. Increasing deployment frequency means little if change failures also increase. Improving utilization is not a success if it leads to burnout. Shortening lead time matters only when business value and system stability are maintained.

Ultimately, high-performing organizations do not optimize for a single KPI, they optimize the entire delivery system.

The role of today's delivery leader is no longer limited to managing projects. It is about balancing speed, stability, quality, capacity, and business value to enable sustainable organizational performance.

Because successful delivery is not measured by how many projects are completed, but by how consistently technology creates value for the business.

#Transformation #DigitalTransformation #ProjectManagement #EnterpriseDelivery #Leadership #Management

A Day in the Life of an SAP PM

2026-07-10T09:21:57.535+07:00

Điều gì khác biệt với một PM trong môi trường Software Development?

Là một PM kinh nghiệm chiến trường nhiều năm trong lĩnh vực software development/ maintenance & implementation, tôi từng cho rằng công việc của một SAP PM không khác biệt quá nhiều. Dù ở lĩnh vực nào, mục tiêu vẫn là quản lý phạm vi, tiến độ, nguồn lực và rủi ro để dự án được triển khai thành công.

Nhờ có cơ hội tiếp xúc với lĩnh vực SAP & ERP gần như mỗi ngày trong hàng chục năm, bên bàn ăn, bên bàn nhậu, v.v., từ những câu chuyện về risk & issue management, workshop với business users đến integration giữa các modules, tôi dần nhận ra sự khác biệt không nằm ở công nghệ, mà ở góc nhìn về chuyển đổi.

Trong môi trường software development, đặc biệt với các hệ thống vận hành 24/7, PM phải cân bằng giữa tốc độ triển khai và sự ổn định của hệ thống. Bên cạnh delivery, họ còn quản lý release planning, tuân thủ Release SOP, phối hợp Change và Incident Management nhằm hạn chế tối đa các sự cố P1, P2 hay P3 có thể ảnh hưởng đến hoạt động kinh doanh.

Trong các project triển khai SAP/ERP, những yếu tố đó vẫn rất quan trọng, nhưng trọng tâm được mở rộng hơn. Thành công không chỉ được đo bằng một lần Go-Live ổn định, mà bằng việc doanh nghiệp thực sự thay đổi cách vận hành sau khi hệ thống đi vào sử dụng. Vì vậy, một ngày làm việc của SAP PM thường xoay quanh các loại workshops, quản lý stakeholder, điều phối giữa các functional consultants, rà soát quy trình nghiệp vụ, đánh giá mức độ sẵn sàng của người dùng và hỗ trợ các quyết định xuyên phòng ban.

Có lẽ sự khác biệt lớn nhất nằm ở câu hỏi mà mỗi vai trò phải trả lời.
- Software PM: Làm thế nào để triển khai thay đổi một cách an toàn, đúng kế hoạch và không gây gián đoạn dịch vụ?
- SAP PM: Làm thế nào để doanh nghiệp sẵn sàng thay đổi và khai thác tối đa giá trị từ hệ thống mới?

Dù xuất phát từ hai góc nhìn khác nhau, thành công của một PM giỏi lại được đo bằng cùng một tiêu chí: khả năng biến chiến lược thành kết quả kinh doanh. Điều đó đòi hỏi không chỉ năng lực lập kế hoạch hay quản lý tiến độ, mà còn là khả năng kết nối con người, điều phối các bên liên quan, quản trị rủi ro và dẫn dắt tổ chức vượt qua sự thay đổi.

Có lẽ trong kỷ nguyên Digital Transformation và AI Transformation, ranh giới giữa hai vai trò sẽ ngày càng mờ đi. Một PM xuất sắc không chỉ cần hiểu công nghệ hay quy trình nghiệp vụ, mà phải biết kết nối cả hai để tạo ra giá trị bền vững cho doanh nghiệp.

Cuối cùng, cả hai đều hướng đến cùng một mục tiêu: tạo ra giá trị kinh doanh thông qua chuyển đổi. Một bên nhìn từ technology-driven transformation, bên kia từ business process-driven transformation. Hai góc nhìn khác nhau, nhưng ngày càng hội tụ trong các chương trình chuyển đổi doanh nghiệp hiện đại.

LỜI NGUYỀN KIẾN THỨC - CoK

2026-06-10T09:22:58.807+07:00

Nay ngồi tâm sự với em ChatGPT, biết được thêm một khái niệm có tên gọi là Curse of Knowledge - CoK (Lời Nguyền Kiến Thức)

Ai có ghé qua thì đọc chơi tham khảo giải trí nhé, xem mình có bị CoK ở chỗ nào không!

————————————

Trong các nghiên cứu về tâm lý học nhận thức, CoK mô tả hiện tượng một người khi đã biết điều gì đó sẽ rất khó hình dung cảm giác của những người chưa biết điều đó.

Nói nôm na là càng hiểu sâu về một vấn đề, chúng ta càng dễ đánh giá quá cao mức độ hiểu biết của người khác.

Khái niệm này thường được minh họa bằng những ví dụ quen thuộc:

- Chuyên gia giải thích quá nhiều thuật ngữ cho người mới.

- Người quản lý giao việc nhưng bỏ qua các bước trung gian.

- Tác giả viết tài liệu mà chỉ chính họ mới hiểu.

Còn trong môi trường cty, CoK không chỉ xuất hiện ở kiến thức chuyên môn. Nó còn xuất hiện ở một dạng khác liên quan kiến thức về bối cảnh tổ chức, khi mọi người đang sống trong những phiên bản khác nhau của cùng một câu chuyện

Ví dụ một người quản lý đang cố gắng hỗ trợ sự phát triển nghề nghiệp của một nhân viên.

Người quản lý biết nhiều điều mà nhân viên không biết:

- Định hướng nhân sự của công ty.

- Những vị trí có khả năng mở trong tương lai.

- Các giới hạn ngân sách.

- Những cuộc thảo luận ở cấp lãnh đạo.

- Những ràng buộc chính trị giữa các bộ phận.

- Những cơ hội mà hiện tại chưa thể công bố.

Từ góc nhìn đó, người quản lý có thể đề xuất cho nhân viên một công việc hoàn toàn khác với mong muốn hiện tại của họ.

Không phải vì đánh giá thấp năng lực của nhân viên.

Ngược lại, có thể vì họ nhìn thấy một lộ trình phát triển dài hạn tốt hơn.

Nhưng vấn đề nằm ở chỗ: Người quản lý không thể giải thích toàn bộ bối cảnh đó.

- Có những thông tin mang tính bảo mật.

- Có những quyết định chưa được phê duyệt.

- Có những yếu tố thuộc phạm vi quyền hạn của người khác.

Kết quả là nhân viên chỉ nhìn thấy phần nổi của tảng băng. Họ không nhìn thấy những gì đang diễn ra phía sau. Từ đó xuất hiện một câu chuyện hoàn toàn khác.

Người quản lý nghĩ: Tôi đang cố gắng giúp họ.

Nhân viên nghĩ: Tôi đang bị cản trở.

Người quản lý nghĩ: Tôi không có quyền quyết định việc đó.

Nhân viên nghĩ: Họ không muốn tạo cơ hội cho tôi.

Người quản lý nghĩ: Tôi đang cân nhắc lợi ích dài hạn.

Nhân viên nghĩ: Người khác đang được ưu ái hơn tôi.

Điều đáng chú ý là cả hai bên đều có lý khi nhìn từ lượng thông tin mà họ đang sở hữu.

Đây không phải là vấn đề giao tiếp đơn thuần.

Nhiều người cho rằng những tình huống như vậy xuất phát từ giao tiếp kém.

Thực tế, nguyên nhân sâu xa hơn nằm ở sự kết hợp của hai hiện tượng: Curse of Knowledge và Information Asymmetry.

Information Asymmetry là hiện tượng các bên sở hữu lượng thông tin khác nhau.

Curse of Knowledge khiến người sở hữu nhiều thông tin nhất lại đánh giá thấp việc người khác đang thiếu thông tin đến mức nào.

Đó là lý do một câu nói tưởng như rất rõ ràng:

- “Tôi nghĩ đây là cơ hội tốt cho bạn.”

Có thể được hiểu thành:

- “Tôi không muốn bạn làm công việc mà bạn thực sự mong muốn.”

Khoảng cách không nằm ở ngôn từ.

Khoảng cách nằm ở dữ liệu nền mà mỗi người dùng để diễn giải câu nói đó.

Vì sao vấn đề này càng nghiêm trọng ở cấp quản lý?

Khi thăng tiến lên các vị trí lãnh đạo, lượng thông tin một người tiếp cận tăng lên theo cấp số nhân.

Họ bắt đầu nhìn thấy:

- Chiến lược dài hạn.

- Kế hoạch kế nhiệm.

- Các ưu tiên của ban điều hành.

- Những giới hạn về ngân sách và nguồn lực.

- Các cuộc thương lượng giữa các phòng ban.

Trong khi phần lớn nhân viên chỉ nhìn thấy những gì ảnh hưởng trực tiếp đến công việc của họ. Khoảng cách nhận thức ngày càng lớn.

Và nghịch lý xuất hiện:

Người có nhiều thông tin nhất thường tin rằng quyết định của mình là hiển nhiên.

Trong khi người có ít thông tin nhất lại cảm thấy quyết định đó hoàn toàn vô lý.

Bài học cho nhà quản lý

Lời nguyền kiến thức không thể bị loại bỏ hoàn toàn. Sẽ luôn tồn tại những thông tin không thể chia sẻ.

Nhưng các nhà quản lý hiệu quả thường cố gắng giải thích nhiều hơn về:

- Ý định.

- Nguyên tắc ra quyết định.

- Những giới hạn quyền hạn của mình.

- Điều họ có thể và không thể ảnh hưởng.

Không phải để khiến mọi người đồng ý với quyết định. Mà để giúp mọi người hiểu được logic đằng sau quyết định đó.

Bởi trong tổ chức, con người hiếm khi phản ứng với sự thật khách quan. Họ phản ứng với câu chuyện mà họ có đủ dữ liệu để xây dựng. Và khi dữ liệu còn thiếu, bộ não sẽ tự lấp đầy khoảng trống bằng những giả định của riêng mình.

Đó là lúc CoK bắt đầu hoạt động. Không phải bằng việc khiến người khác thiếu hiểu biết. Mà bằng việc khiến những người hiểu nhiều nhất quên mất rằng người khác không nhìn thấy thế giới theo cách họ đang nhìn thấy.

Những Từ Mới Của Kỷ Nguyên AI: Workslop, Thinkslop và AI Sycophancy

2026-06-02T15:24:18.874+07:00

Nay đọc được một article trên HBR (How people are really using AI in 2026), biết được thêm vài terms mới từ bài viết như Workslop, Thinkslop, AI Sycophancy, v.v. Và cũng nhột nhột nhìn lại mình xem có đang bị giống vậy không?

1. Workslop là những thứ do AI tạo ra trông có vẻ rất chuyên nghiệp, rất chỉn chu, nhưng thực chất chứa rất ít giá trị hoặc góc nhìn mới. Những bản báo cáo, email, performance review, hay slides/ documents "đọc rất mượt nhưng chẳng đọng lại gì" là ví dụ điển hình.

2. Thinkslop còn đáng lo hơn. Nếu Workslop là output đầu ra, thì Thinkslop là sự lười biếng trong tư duy khi con người ngày càng giao quá nhiều việc suy nghĩ cho AI. Thay vì tự phân tích vấn đề, hình thành quan điểm và phản biện các giả định của mình, chúng ta có khuynh hướng mở ChatGPT ngay từ đầu và chấp nhận câu trả lời đầu tiên có vẻ hợp lý.
=> Hệ quả lâu dài của Thinkslop là thứ mà các nhà nghiên cứu gọi là Cognitive Debt (nợ tư duy). AI có thể giúp giải quyết vấn đề nhanh hơn hôm nay, nhưng có thể khiến năng lực suy nghĩ độc lập suy giảm trong tương lai.

3. AI Sycophancy (AI nịnh hót): xu hướng AI luôn đồng tình, khen ngợi và củng cố niềm tin của người dùng. Điều này tạo cảm giác dễ chịu nhưng cũng có nguy cơ biến người dùng ảo giác về năng lực của mình.

Bài báo cũng cho thấy use case phổ biến nhất của AI hiện nay không phải lập trình hay tự động hóa, mà là Therapy & Companionship (điều trị tâm lý và đồng hành cảm xúc).
AI đang dần trở thành một "Emotional Decoder" giúp con người giải mã email của sếp, tin nhắn của người yêu hay những cuộc hội thoại khó xử trong công việc.
=> Ví dụ: Trước đây, giao tiếp diễn ra theo mô hình: Người A → Người B, thì hiện nay, ngày càng nhiều tương tác diễn ra theo mô hình: Người A → AI → Người B

Ở góc độ doanh nghiệp, bài báo cũng chỉ ra rằng phần lớn tổ chức hiện vẫn đang dùng AI để làm việc cũ nhanh hơn thay vì thiết kế lại cách làm việc. Đa phần chỉ là đang tối ưu hóa quy trình hiện tại bằng AI, nhưng chưa thực sự tái tư duy về quy trình đó. (Automation but not Transformation)

Ngoài ra, bài báo nhắc lại Shadow AI trong tổ chức là nhiều nhân viên dùng AI bí mật như xử lý công việc nhanh gấp đôi, tự động hóa công việc của mình bằng AI cá nhân nhưng không báo cho sếp biết. Nguyên nhân có thể là {Chính sách công ty chưa rõ ràng, Lo ngại mất việc, Sợ bị đánh giá là gian lận, Hệ thống AI nội bộ quá kém so với bên ngoài như ChatGPT}

Quan điểm và Mô thức

2026-05-31T17:10:14.802+07:00

Trong các cuộc tranh luận ở doanh nghiệp, người ta thường nhầm lẫn giữa hai khái niệm tưởng chừng giống nhau: quan điểm và mô thức.
Sự nhầm lẫn này không chỉ gây ra những cuộc thảo luận vô ích kéo dài hàng giờ mà còn là nguyên nhân sâu xa khiến nhiều tổ chức mắc kẹt trong những vòng lặp ra quyết định không đi đến đâu.

1. Quan Điểm Là Bề Mặt, Mô Thức Là Nền Tảng
Quan điểm là lập trường của một cá nhân về một vấn đề cụ thể. Nó có thể thay đổi sau một cuộc trò chuyện, một bài phân tích, hay một trải nghiệm mới. Khi một nhà quản lý nói "tôi cho rằng làm việc từ xa làm giảm năng suất," đó là quan điểm. Nó có thể bị thuyết phục bởi dữ liệu, bởi ví dụ thực tế, bởi nghiên cứu đối lập.

Mô thức thì khác. Đó là hệ thống niềm tin nền tảng chi phối cách một người nhìn nhận thế giới, đặt câu hỏi, và diễn giải thông tin. Nó không hiện diện trên bề mặt. Nó là cái khuôn vô hình tạo ra mọi quan điểm.

Nhà vật lý Thomas Kuhn, người đặt nền móng cho khái niệm này trong tác phẩm The Structure of Scientific Revolutions, mô tả mô thức như một "bản đồ nhận thức" mà cộng đồng khoa học dùng để xác định đâu là câu hỏi đáng đặt ra và đâu là câu trả lời hợp lệ. Khi bản đồ đó sai, mọi hành trình dù có cố gắng đến đâu cũng dẫn đến nhầm chỗ.

Stephen Covey đã mang khái niệm này vào lĩnh vực phát triển con người và lãnh đạo. Trong The 7 Habits of Highly Effective People, ông lập luận rằng mô thức chính là lăng kính mà qua đó chúng ta nhìn nhận thế giới, và mọi thay đổi hành vi bền vững đều phải bắt đầu từ việc thay đổi lăng kính đó, không phải từ việc điều chỉnh hành vi bề mặt. Covey dùng hình ảnh một tấm bản đồ: nếu bạn đang ở Chicago nhưng tay cầm bản đồ Detroit, thì cố gắng hơn hay thái độ tích cực hơn cũng không giúp bạn đến đúng nơi cần đến. Vấn đề không phải ở người đi. Vấn đề là ở bản đồ.

Xu hướng AI hiện nay là minh chứng rõ ràng cho sự phân biệt này. Khi một lãnh đạo nói "tôi cho rằng AI sẽ thay thế phần lớn nhân sự trong vòng 5 năm," đó là quan điểm. Có thể thay đổi sau một báo cáo, một cuộc trò chuyện, một dự án thực tế. Nhưng mô thức nằm sâu hơn: người đó nhìn AI như một lực lượng thay thế con người, hay như một công cụ khuếch đại năng lực con người? Hai mô thức đó tạo ra hai chiến lược nhân sự hoàn toàn khác nhau, dù quan điểm bề mặt có vẻ giống nhau.

2. Khi Hai Người Dùng Hai Bản Đồ Khác Nhau
Hãy xem xét một tình huống quen thuộc trong môi trường doanh nghiệp. Hai nhà quản lý tranh luận về chiến lược tăng trưởng. Người thứ nhất cho rằng cần mở rộng thị trường nhanh chóng, chấp nhận thua lỗ ngắn hạn. Người thứ hai nhất quyết rằng phải củng cố nền tảng tài chính trước khi mở rộng. Cuộc tranh luận kéo dài, không bên nào thuyết phục được bên kia, và cả hai đều rời phòng họp với cảm giác người kia "không hiểu vấn đề."

Thực ra, họ hiểu vấn đề rất rõ. Nhưng họ đang đứng trên hai mô thức hoàn toàn khác nhau. Người thứ nhất vận hành trong mô thức "thị trường là cuộc đua, kẻ chậm chân sẽ thua." Người thứ hai vận hành trong mô thức "tăng trưởng bền vững là tài sản duy nhất có giá trị lâu dài." Họ không tranh luận về chiến lược. Họ đang va chạm hai hệ giá trị cốt lõi mà không ai trong số họ nhận ra.

Đây chính là lý do tại sao nhiều cuộc họp chiến lược tốn kém thời gian nhưng không tạo ra sự đồng thuận thực sự. Người ta tranh luận ở tầng quan điểm trong khi xung đột thực sự đang xảy ra ở tầng mô thức.

Điều tương tự đang xảy ra trong hàng nghìn tổ chức khi triển khai AI. Nhóm công nghệ và nhóm vận hành ngồi cùng bàn, cùng nói về "ứng dụng AI để tăng hiệu quả," nhưng thực ra đang vận hành trong hai mô thức khác nhau hoàn toàn. Nhóm công nghệ xuất phát từ mô thức "tự động hóa là đích đến." Nhóm vận hành xuất phát từ mô thức "con người là trung tâm, công nghệ là phương tiện." Kết quả là những dự án AI được triển khai về mặt kỹ thuật nhưng thất bại về mặt con người, không phải vì thiếu ngân sách hay thiếu năng lực, mà vì hai bên chưa bao giờ thực sự nói chuyện với nhau ở tầng mô thức.

3. Tại Sao Mô Thức Khó Thay Đổi Hơn Rất Nhiều
Quan điểm có thể bị thuyết phục bởi logic và bằng chứng. Mô thức thì không. Nghiên cứu của Carol Dweck tại Stanford cho thấy ngay cả khi con người tiếp nhận thông tin mâu thuẫn trực tiếp với niềm tin cốt lõi của mình, não bộ có xu hướng tìm cách diễn giải thông tin đó sao cho phù hợp với mô thức hiện có, thay vì cập nhật mô thức.

Điều này giải thích một nghịch lý phổ biến trong lãnh đạo: một nhà quản lý có thể đọc hàng chục cuốn sách về trao quyền, tham dự đủ loại hội thảo về văn hóa tin tưởng, nhưng vẫn liên tục micromanage nhân viên. Không phải vì họ thiếu thông tin. Mà vì mô thức nền tảng của họ, "kiểm soát là trách nhiệm của người lãnh đạo", chưa thay đổi. Họ đang nạp quan điểm mới vào một hệ điều hành cũ.

Mô thức chỉ thực sự thay đổi khi có đủ áp lực từ thực tế: một cuộc khủng hoảng, một thất bại đủ lớn, hoặc một trải nghiệm đủ sâu để hệ thống niềm tin cũ không còn có thể giải thích được những gì đang xảy ra.

Trong bối cảnh AI, nghịch lý này càng hiện rõ hơn. Nhiều nhà quản lý cấp trung hiểu rõ về lý thuyết AI, tham dự đủ loại hội thảo chuyển đổi số, nhưng vẫn tiếp tục ra quyết định theo cách cũ. Không phải vì họ phủ nhận AI. Mà vì mô thức nền tảng của họ, "kinh nghiệm và trực giác cá nhân là nguồn ra quyết định đáng tin cậy nhất", chưa bị thực tế thách thức đủ mạnh. Họ dùng AI như một công cụ trang trí cho quyết định đã có sẵn, thay vì để AI thực sự thay đổi cách họ tư duy.

4. Ứng Dụng Trong Thực Tiễn Lãnh Đạo
Nhận ra sự khác biệt này mang lại hai lợi thế thực tiễn quan trọng.

Thứ nhất, nó giúp lãnh đạo chẩn đoán đúng nguyên nhân của xung đột. Khi một cuộc tranh luận cứ lặp đi lặp lại mà không có giải pháp, câu hỏi cần đặt ra không phải là "ai đúng ai sai" mà là "chúng ta đang vận hành trong những mô thức nào và chúng có tương thích không." Đây là sự khác biệt giữa việc giải quyết triệu chứng và điều trị căn nguyên.

Thứ hai, nó đặt ra một tiêu chuẩn cao hơn cho sự phát triển cá nhân. Thay đổi quan điểm là học. Thay đổi mô thức là trưởng thành. Một tổ chức có thể đào tạo nhân viên thay đổi quan điểm thông qua các khóa học và hội thảo. Nhưng để thay đổi mô thức, cần những trải nghiệm thực tế được phản tư một cách có chủ đích, đây là lý do các chương trình lãnh đạo hiệu quả nhất luôn kết hợp giữa học lý thuyết và dấn thân vào môi trường thực tế đầy thách thức.

Với làn sóng AI đang tái định hình mọi ngành nghề, câu hỏi chiến lược quan trọng nhất mà một tổ chức cần đặt ra không phải là "chúng ta đang dùng công cụ AI nào" mà là "mô thức nào đang chi phối cách chúng ta nhìn nhận vai trò của AI trong tổ chức." Một công ty có thể đầu tư hàng triệu đô vào hạ tầng AI, nhưng nếu mô thức lãnh đạo vẫn là "kiểm soát thông tin là quyền lực," thì AI chỉ trở thành một lớp công nghệ mới phủ lên một văn hóa cũ. Công nghệ thay đổi nhanh. Mô thức thay đổi chậm hơn rất nhiều. Và khoảng cách đó chính là nơi hầu hết các chiến lược chuyển đổi số thất bại.

P/S:
Lần cuối bạn thay đổi quan điểm là khi nào? Còn lần cuối bạn thay đổi mô thức? 👇
Nếu câu trả lời thứ hai khó nhớ hơn rất nhiều thì đó chính là vấn đề.

What Really Happens in a SAP Implementation Project?

2026-05-31T10:29:57.592+07:00

Many people outside the ERP world think a SAP implementation project starts with consultants configuring the system and ends when the system goes live.

In reality, a SAP implementation follows a highly structured lifecycle, often spanning months or even years.
A typical enterprise SAP program progresses through several major phases:

1. Initiation & Mobilization
The organization defines business objectives, project scope, governance structure, budget, timeline, and project team.
- Key deliverables: {Project Charter, Governance Model, High-Level Plan, RACI Matrix}
- Key stakeholders: {Executive Sponsors, Steering Committee, Program Manager, Business Leaders}

2. Discovery & Blueprint (Explore)
This phase focuses on understanding current processes (AS-IS) and designing future processes (TO-BE).
- Key deliverables: {Process Maps, Functional Specifications, WRICEF Inventory, Solution Design Documents}
- Key stakeholders: {Business Process Owners, SAP Functional Consultants, Solution Architects, Key Users}

3. Realization (Build)
Configuration, development, integration, security setup, and migration preparation take place.
- Key deliverables: {Configuration Documents, Technical Specifications, Interfaces, Reports, Migration Programs}
- Key stakeholders: {SAP Consultants, ABAP Developers, Integration Teams, Security Teams}

4. Testing & Data Migration
Organizations validate end-to-end business scenarios through SIT, UAT, performance testing, and multiple mock migrations.
- Key deliverables: {Test Scripts, Defect Logs, Reconciliation Reports, Data Sign-Off}
Key stakeholders: {Business Users, Data Owners, Testing Teams, Project Managers}

5. Cutover & Go-Live
The project transitions from preparation to execution.
- Key deliverables: {Cutover Runbook, Rollback Plan, Go/No-Go Assessment, Go-Live Report}
- Key stakeholders: {Entire Project Team, Business Leaders, Executive Sponsors}

6. Hypercare & Support Transition
The focus shifts from delivery to stabilization and operational support.
- Key deliverables: {Incident Logs, Knowledge Transfer Documents, Support Model, SLA Agreements}
- Key stakeholders: {Support Teams, Operations Teams, Business Owners}

At first glance, the process appears highly methodical and predictable.
In reality, it is usually an organizational negotiation project disguised as a system implementation.

The technical part such as configuration, development, integration is often complex, but still manageable. Large enterprises can always hire experienced consultants, architects, and delivery teams to solve technical problems.

But the harder challenge is alignment.
1. Alignment between business units that have operated differently for years.
2. Alignment between global standards and local practices.
3. Alignment between finance, operations, procurement, compliance, and technology.

That is why SAP programs rarely fail because "the system cannot work".
They fail because organizations underestimate four things:

1. Data quality
2. Process standardization
3. Change management
4. Operational readiness before go-live

As projects move closer to deployment, the real pressure often shifts away from technology itself.

The critical conversations become:
1. Are key users truly ready?
2. Can the business operate under the new process tomorrow morning?
3. Is the migrated data trustworthy enough for financial reconciliation?
4. Do leaders fully understand the operational impact of the cutover decision?

This is also why experienced SAP leaders spend enormous amounts of time on governance: {Steering committees, Risk reviews, UAT readiness, Cutover simulations, Hypercare planning}. Not because they enjoy meetings, but because enterprise transformation is fundamentally a coordination problem at scale.

The interesting lesson is this, ERP transformation is not primarily about implementing software. It is about redesigning how an organization makes decisions, moves information, and coordinates work under a shared operational model.

SAP simply becomes the platform where those organizational decisions are made visible.

#SAP #ERP #DigitalTransformation #EnterpriseArchitecture #ProjectManagement #SAPS4HANA

Manage Oneself in AI Era

2026-05-29T15:27:13.230+07:00

Peter Drucker viết bài viết Managing Oneself đăng trên tạp chí HBR vào 1999, với nội dung xoay quanh một luận điểm cốt lõi trong nền kinh tế tri thức, thành công thuộc về những người hiểu rõ bản thân như điểm mạnh, giá trị, và cách mình làm việc hiệu quả nhất.

Ông chia thành 5 câu hỏi nền tảng:

1. Điểm mạnh của tôi là gì? Cách duy nhất để khám phá điểm mạnh là phân tích phản hồi (feedback analysis): mỗi khi đưa ra quyết định quan trọng, hãy ghi lại kỳ vọng, rồi 9-12 tháng sau đối chiếu với kết quả thực tế. Ông khuyến nghị tập trung vào điểm mạnh thay vì lãng phí công sức cải thiện những lĩnh vực yếu kém.

2. Tôi làm việc hiệu quả theo cách nào? Đây là câu hỏi quan trọng hơn cả điểm mạnh. Mỗi người có phong cách khác nhau: đọc hay nghe, làm việc độc lập hay theo nhóm, ra quyết định hay tư vấn, cần áp lực hay cần cấu trúc rõ ràng.

3. Giá trị của tôi là gì? Ông dùng "bài kiểm tra gương": buổi sáng nhìn vào gương, bạn muốn thấy mình là người như thế nào? Làm việc trong một tổ chức có hệ thống giá trị xung đột với giá trị cá nhân sẽ dẫn đến thất vọng và kém hiệu quả.

4. Tôi thuộc về đâu?

Khi đã hiểu:

Điểm mạnh
Cách làm việc
Giá trị

…thì bạn sẽ biết môi trường nào phù hợp nhất với mình. Nhiều người không thất bại vì kém năng lực; họ thất bại vì ở sai nơi.

5. Tôi nên đóng góp điều gì? Không chỉ hỏi "tôi muốn làm gì" mà phải hỏi "hoàn cảnh đang cần gì, tôi có thể tạo ra tác động lớn nhất ở đâu, và kết quả đó có thể đo lường được không?"

Đây là sự chuyển dịch từ tư duy “công việc cho tôi điều gì” sang “tôi tạo giá trị gì”

Tuy nhiên, ông mất trước khi thời đại AI xảy ra, nên nếu ánh xạ bài viết của ông vào năm 2026, thì có lẽ sẽ có thêm câu hỏi khác: Khi AI ngày càng làm tốt nhiều công việc hơn con người, điều gì vẫn khiến bạn trở nên khác biệt?

Bấy lâu nay, chúng ta vẫn được dạy rằng: học kỹ năng, tích lũy kinh nghiệm, rồi leo dần từng bậc thang sự nghiệp. Nhưng AI đang phá vỡ lối mòn đó. Nó không chỉ làm thay việc lặp đi lặp lại, mà còn bắt đầu thâm nhập vào những mảng tưởng là “của riêng” lao động trí óc: viết lách, phân tích số liệu, lập trình, nghiên cứu, thậm chí cả việc ra quyết định.

Trong bối cảnh đó, lời dạy quan trọng của Drucker lại càng đúng: đừng cố giỏi hơn người khác, hãy hiểu cách bạn tạo ra giá trị tốt nhất.

Khi AI có thể hỗ trợ viết code nhanh hơn, tổng hợp thông tin tốt hơn và xử lý khối lượng dữ liệu vượt xa khả năng con người, cuộc cạnh tranh không còn đơn thuần là “ai làm nhanh hơn”. Nó chuyển thành câu hỏi khác: ai hiểu điểm mạnh của mình đủ rõ để kết hợp với AI một cách hiệu quả nhất?

Có người giỏi kết nối, có người thấy được cái trật tự trong đống hỗn độn, có người biết đặt câu hỏi đúng khi mọi thứ còn mơ hồ. Những thứ đó chẳng hề biến mất khi AI xuất hiện. Ngược lại, chúng càng trở nên quý hơn. Bởi AI có thể khuếch đại năng lực, nhưng không thể tự quyết định phương hướng nào bạn sẽ đi.

Đó chính là nghịch lý lớn thời AI: không phải là máy móc ngày càng thông minh, mà là khi máy móc mạnh lên, con người lại càng cần phải hiểu mình hơn.

Nhiều người hiện tại có thể đang dành hàng giờ mỗi tuần để cập nhật tool AI mới, mô hình mới, xu hướng mới. Làm thế không sai. Nhưng với Peter Drucker, có lẽ ông sẽ hỏi: bạn có dành thời gian tương đương để hiểu chính mình không?

Vì suy cho cùng, sự nghiệp bền vững không phải do chạy theo từng con sóng công nghệ, mà đến từ việc bạn hiểu mình giỏi cái gì, làm việc tốt nhất theo cách nào, và ở đâu thì điểm mạnh của bạn được phát huy được tối đa nhất.

AI có thể thay đổi việc làm rất nhanh. Nhưng thấu hiểu bản thân vẫn là lợi thế cạnh tranh dài hạn khó bị thay thế nhất.

Cognitive Surrender

2026-05-28T11:52:48.899+07:00

Bạn đang dùng AI để suy nghĩ, hay để khỏi phải suy nghĩ?

Vô tình đọc được bài viết trên blog của Addy Osmani, kỹ sư tại Google, biết thêm được nhiều khái niệm thú vị như Cognitive Offloading, Cognitive Surrender, Comprehension Debt (như Technical Dept)

Luận điểm trung tâm của tác giả là phân biệt hai trạng thái hoàn toàn khác nhau.
1. Cognitive offloading: bạn giao phần "làm thế nào" cho AI, nhưng vẫn giữ quyền phán xét kết quả. Giống dùng máy tính bỏ túi: bạn vẫn biết đáp số đúng trông như thế nào.
2. Cognitive surrender: bạn ngừng tự hình thành câu trả lời. Output của AI trở thành output của bạn. Không có gì để phản bác, vì bạn chưa từng có quan điểm độc lập.

Phần đáng lo nhất không phải lý thuyết mà là các con số từ thống kê. Nghiên cứu từ Wharton (UPenn) với 1.372 người cho thấy: khi AI đưa ra câu trả lời sai, 73% người vẫn chấp nhận. Tệ hơn: độ tự tin của họ tăng lên. Họ đang mượn sự tự tin của AI, một thứ AI luôn sẵn sàng cho vay, và xem đó là của mình.

Osmani cũng đưa ra khái niệm Comprehension Debt, nợ hiểu biết, term này tương tự Technical Debt (nợ kỹ thuật). Mỗi lần bạn chấp nhận code, quyết định, hay phân tích mà không thực sự hiểu, bạn vay thêm một khoản nhỏ. Cộng dồn theo thời gian, đến khi hệ thống hỏng, không ai trong team còn có thể tái dựng lại từ đầu.

Điều này không chỉ đúng với lập trình viên. Nó đúng với bất kỳ ai đang dùng AI để ra quyết định, viết báo cáo, hay phân tích dữ liệu.

Câu hỏi Osmani để lại bổ sung thêm:
1. Nếu code, hay quyết định, bạn đang ship ra ngoài, nhưng hiểu biết của bạn về hệ thống đang thu hẹp: bạn đang trả bằng Comprehension Debt.
2. Nếu ngược lại, bạn hiểu hệ thống sâu hơn, bạn đang dùng AI đúng cách

Công cụ giống nhau. Thái độ và growth mindset mới là thứ tạo ra sự khác biệt.

Source: Cognitive Surrender — Addy Osmani (addyosmani.com)
CriticalThinking AIProductivity DeepWork FutureOfWork Knowledge

Process-Centric vs Product-Centric

2026-05-26T22:38:00.980+07:00

Trong nhiều năm, phần lớn kiến trúc doanh nghiệp được xây dựng theo tư duy process-centric (đôi khi còn được gọi là business process segmentation).

Các projects triển khai ERP, mô hình vận hành và hệ thống lõi được thiết kế xoay quanh những luồng nghiệp vụ đầu-cuối như Order-to-Cash (O2C), Procure-to-Pay (P2P) hay Record-to-Report (R2R). Tư duy này bắt nguồn từ BPM (Business Process Management) và Lean/Six Sigma, với giả định cốt lõi: doanh nghiệp tạo ra giá trị thông qua các quy trình lặp lại, vì vậy hệ thống nên phản ánh cách công việc vận hành.

Sau đó, Agile Manifesto (2001) và làn sóng Lean Startup (2011) tạo ra một sự dịch chuyển đáng kể.

Trọng tâm không còn chỉ là vận hành nội bộ, mà chuyển dần sang kết quả đầu ra cho khách hàng. Đội ngũ được tổ chức quanh product, trải nghiệm và hành trình người dùng, thay vì các quy trình tác nghiệp cố định. Thành công không còn được đo bằng hiệu suất hay SLA đơn thuần, mà bằng mức độ sử dụng (adoption), khả năng giữ chân người dùng (retention), và tốc độ học hỏi từ thị trường.

Thoạt nhìn, hai cách tiếp cận này có vẻ đối lập. Nhưng trên thực tế, chúng trả lời hai câu hỏi khác nhau.
- Theo process-centric: "Doanh nghiệp vận hành như thế nào?", tạo ra sự rõ ràng về ownership, governance, khả năng mở rộng và tính ổn định hệ thống.
- Theo product-centric: "Điều gì thực sự tạo ra giá trị cho khách hàng?", thúc đẩy thử nghiệm, khả năng thích nghi và tốc độ đổi mới.

Nhiều tổ chức mạnh ngày nay không còn cố ép kiến trúc và delivery vào cùng một cấu trúc. Thay vào đó, họ áp dụng phân tầng rõ ràng hơn:
- Tư duy process-centric phù hợp với systems of record như ERP, Finance, Compliance, nơi ổn định và nhất quán là tối thượng.
- Tư duy product-centric phù hợp với systems of engagement, các sản phẩm hướng khách hàng, nơi tốc độ thử nghiệm và khả năng thích nghi tạo ra lợi thế cạnh tranh.

Biết phân biệt tầng nào cần tư duy nào, và không áp đặt mô hình của tầng này lên tầng kia, đang trở thành một năng lực kiến trúc quan trọng của các tổ chức hiện đại.

Để kết hợp có cấu trúc hai tư duy này vào mô hình vận hành, một trong những khung quản trị được xem xét áp dụng là Team Topologies (Matthew Skelton và Manuel Pais, 2019). Khung này giúp giải bài toán phối hợp bằng cách định hình rõ nét vai trò của các loại team cốt lõi:
- Stream-aligned teams: Chịu trách nhiệm chuyển giao theo hướng product-centric. Họ sở hữu trọn vẹn một luồng giá trị hướng đến khách hàng, đòi hỏi sự linh hoạt và tốc độ tối đa.
- Platform teams: Cung cấp hạ tầng, năng lực công nghệ và các dịch vụ cốt lõi nội bộ theo hướng process-centric. Họ đảm bảo tính reliability, compliance, dữ liệu chuẩn hóa và giảm tải cognitive load cho các đội nhóm khác.
- Enabling teams: Đóng vai trò là cầu nối, giúp các stream-aligned teams nhanh chóng hấp thụ và làm chủ các năng lực hoặc công nghệ mới mà không cần phải tự mày mò xây dựng lại từ đầu.

hashtagLeadership hashtagDigitalTransformation hashtagTeamTopologies hashtagProductCentric hashtagProcessCen

TẦN SỐ

2026-05-23T11:18:11.109+07:00

Chúng ta có còn cùng tần số không?

Trong vật lý, hai vật thể chỉ cộng hưởng khi dao động cùng tần số.
Hãy nhìn sóng biển. Hai con sóng cùng nhịp sẽ cộng lại, tạo thành đỉnh sóng cao hơn, mạnh hơn. Hai con sóng lệch pha sẽ triệt tiêu nhau, gặp nhau rồi tan biến, không để lại gì.

Không có con sóng nào "sai."
Chúng chỉ không thuộc về cùng một nhịp.
Quan hệ giữa người và người cũng vậy, cộng hưởng thì bùng lên, lệch pha thì lặng dần, dù hai người vẫn đứng gần nhau, vẫn thường xuyên thấy bài đăng trên FB của nhau.

Nhà tâm lý học Robert Cialdini gọi đây là hiệu ứng tương đồng, người ta bị thu hút bởi những ai có giá trị, nhịp sống, và cách nhìn thế giới giống mình.
Khi hai người "cùng tần số," giao tiếp trở nên dễ dàng.
Không cần giải thích nhiều. Không cần cố gắng.

Nhưng con người không đứng yên.
Mỗi người thay đổi theo trải nghiệm riêng, công việc, thành công, thất bại, tình yêu, mất mát, đau thương của riêng mình.
Tần số theo đó cũng dịch chuyển theo.

Đây là lý do bạn bè, đồng nghiệp lâu năm đôi khi bỗng dưng... xa lạ. Không ai làm gì sai. Chỉ là mỗi người đã đi theo các hướng khác nhau.
Tâm lý học gọi đây là "relationship drift", sự trôi dạt trong quan hệ.

Theo nghiên cứu của nhà xã hội học Gerald Mollenhorst, trung bình sau 7 năm, gần 50% mạng lưới bạn bè thân thiết của một người thay đổi hoàn toàn.
Không phải vì mâu thuẫn. Mà vì tần số không còn khớp.

Cảm giác ngồi cạnh nhau nhưng không còn gì để nói, thấy bài FB của nhau nhưng không muốn tương tác, đó không phải là sự thờ ơ. Đó là tín hiệu: hai người đang dao động ở hai dải sóng khác nhau.

Điều này không đồng nghĩa với việc tình bạn hay mối quan hệ đó vô nghĩa. Nó từng thật. Nó từng quan trọng. Nhưng con người trưởng thành không phải bằng cách giữ nguyên mọi thứ. Mà bằng cách biết đâu là tần số mình đang thuộc về, ở thời điểm này.

Đó có thể là lý do FB Groups xuất hiện ngày càng nhiều, để những người cùng tần số có thể chia sẻ với nhau một cách dễ dàng hơn.
Chúng ta có còn cùng tần số không?! 😆😜👇

#cuocsongthuongngay #NangLuongTichCuc #nangluongcuocsong #vuikhoe #positive

Seamless product integration into existing production ecosystem

2026-05-21T12:11:16.306+07:00

Tích hợp thêm một product mới vào production ecosystem của một tập đoàn lớn thường bao gồm những giai đoạn nào?

Nhiều người nghĩ việc thêm một sản phẩm mới vào hệ thống chỉ đơn giản là phát triển tính năng rồi deploy lên production. Nhưng ở các hệ thống lớn, đó thường không phải là bài toán "xây cái mới", mà là bài toán "thay đổi một hệ sinh thái đang vận hành".

Một product mới nhìn bề ngoài có thể chỉ là một tính năng nhỏ. Nhưng phía sau nó có thể liên quan đến hàng loạt thứ khác: dữ liệu, API, luồng xử lý, báo cáo, vận hành, trải nghiệm người dùng và nhiều hệ thống phụ thuộc khác. Chỉ cần một thay đổi nhỏ thiếu đánh giá tác động đầy đủ, hệ thống vẫn chạy, nhưng incidents cấp P1/P2 có thể xuất hiện ở những nơi ít ai ngờ tới sau khi go-live.

Vì vậy ở các tổ chức lớn, việc tích hợp product mới thường đi qua nhiều giai đoạn rõ ràng: bắt đầu từ đánh giá cơ hội và phạm vi, phân tích ảnh hưởng hệ thống, thiết kế giải pháp, lập kế hoạch triển khai, phát triển, kiểm thử, chuẩn bị go-live và cuối cùng là theo dõi sau triển khai.

Điều thú vị là những đội ngũ trưởng thành thường không xem deployment là đích đến. Sau go-live và tới giai đoạn đo performance & maintenance xử lý incidents phát sinh mới là lúc bài kiểm tra thực sự bắt đầu: theo dõi hệ thống, xử lý vấn đề phát sinh, tối ưu vận hành và rút kinh nghiệm cho lần tiếp theo.

Các tổ chức mạnh thường có một tư duy rất giống nhau: hệ thống cần phát triển liên tục nhưng sự ổn định không được đánh đổi. Một product mới lý tưởng nên xuất hiện giống như một phần mở rộng tự nhiên của hệ thống, thay vì tạo ra sự gián đoạn cho những thứ đang vận hành tốt.

Thách thức thật sự không nằm ở việc xây thêm cái mới. Thách thức nằm ở việc giúp hệ thống phát triển mà người dùng gần như không cảm nhận được sự thay đổi phía sau.

#Leadership #EnterpriseTechnology #ContinuousImprovement #Innovation #BusinessTransformation #ProductIntegration #ProjectManagement #SoftwareArchitecture #EngineeringManagement #BackwardCompatibility #DigitalTransformation

Facebook đã thay đổi như thế nào

2026-05-18T09:03:23.082+07:00

Năm 2021, người dùng TikTok dành trung bình 95 phút mỗi ngày trên ứng dụng.

FB chỉ 33 phút.

Cách nhau gần 3 lần, và CEO Mark biết rõ điều đó có nghĩa là gì.

Các nền tảng mạng xã hội không bán nội dung. Họ bán sự chú ý. Mỗi phút người dùng ở trên TikTok là một phút họ không ở trên FB. Mỗi phút đó là doanh thu quảng cáo bốc hơi.

Tháng 2/2022, Meta mất $232 tỷ USD vốn hóa chỉ trong một ngày, kỷ lục lịch sử chứng khoán Mỹ lúc bấy giờ. Cổ phiếu rơi 26%. Mark cá nhân mất gần $30 tỷ USD tài sản chỉ qua một đêm. Và trong cuộc gọi báo cáo lợi nhuận hôm đó, him nhắc đến TikTok đúng 5 lần.

Không phải vô tình.

Vấn đề cốt lõi là gì?

Suốt 15 năm, FB vận hành theo Social Graph, bạn đăng bài, người theo dõi thấy bài. Nhiều follower đồng nghĩa nhiều lượt xem. Cả một nền kinh tế FB hình thành xoay quanh số lượng followers đó.

TikTok không chơi theo luật đó. TikTok dùng Interest Graph, không quan tâm bạn quen ai, không quan tâm bạn có bao nhiêu follower, chỉ hỏi đúng một câu: nội dung này có giữ người lạ ở lại không? Đó là thứ tạo ra 95 phút mỗi ngày. Không phải mối quan hệ. Từ chất lượng nội dung thuần túy.

Chính Mark thừa nhận điều này vào tháng 10/2022: “Xu hướng mạng xã hội đã chuyển sang dùng feed để khám phá nội dung. Trong thế giới đó, việc ai tạo ra nội dung trở nên ít quan trọng hơn. Bạn chỉ muốn nội dung tốt nhất.”

Vậy Mark đã làm gì? Sao chép toàn bộ.

Reels ra mắt trên Instagram năm 2020, FB năm 2021, đó là phần dễ thấy. Phần vô hình hơn: FB âm thầm xây lại toàn bộ thuật toán từ gốc. Chuyển từ “hiển thị cho người theo dõi” sang “hiển thị cho người nào thấy quan tâm.”

Hiện nay tới 50% nội dung trên Feed FB đến từ tài khoản bạn chưa từng theo dõi. Thuật toán dùng hơn 100 mô hình dự đoán khác nhau, đánh giá từng nội dung theo tốc độ cuộn, thời gian xem, tỉ lệ chia sẻ, không phải số lượng follower.

Chỉ sau một đêm, luật chơi đã khác hoàn toàn.

Một trang 200 follower giờ có thể vượt trang 2 triệu follower, nếu nội dung được xây đúng cách. Nhưng hầu hết creator vẫn đang chơi theo luật cũ. Vẫn viết cho follower quen thuộc. Vẫn đăng kiểu cũ cho những người đang follow mình.

Trong khi thuật toán đang chờ để đẩy bất kỳ ai hiểu rằng: người đọc quan trọng nhất của bạn là người chưa từng nghe tên bạn bao giờ.

FB đã thay đổi từ lâu rồi như thế rồi.

Câu hỏi là bạn đang viết cho ai, người quen hay người lạ?

BA LÀN SÓNG CHUYỂN ĐỔI LỚN

2026-05-15T21:03:35.148+07:00

Trong hơn 2 thập kỷ, các doanh nghiệp toàn cầu đã trải qua ba làn sóng chuyển đổi lớn, chồng chéo lên nhau: Digital Transformation, Agile Transformation và hiện nay là AI Transformation.
Mỗi loại chuyển đổi giải quyết một bài toán khác nhau của tổ chức hiện đại. Tuy nhiên, chúng không diễn ra tuần tự; nhiều tổ chức có vẻ vẫn đang vật lộn với cả ba cùng một lúc.

Digital Transformation giúp doanh nghiệp số hóa vận hành, chuẩn hóa quy trình và khai thác dữ liệu hiệu quả hơn. Đây là nền tảng bắt buộc đối với các doanh nghiệp lớn còn phụ thuộc nhiều vào manual operation, legacy systems và data silo.

Agile Transformation xuất hiện khi thị trường thay đổi quá nhanh. Doanh nghiệp không chỉ cần vận hành hiệu quả mà còn phải thích nghi nhanh, release nhanh và phản hồi khách hàng liên tục. Agile giúp tổ chức chuyển từ mô hình quản lý cứng nhắc sang mô hình cộng tác linh hoạt và product-centric.
Trong khi đó, AI Transformation đang mở ra một cuộc chơi hoàn toàn mới: tái định nghĩa cách doanh nghiệp ra quyết định, xử lý tri thức và tự động hóa cognitive work. AI không chỉ hỗ trợ công việc mà đang bắt đầu thay đổi cấu trúc tổ chức và lực lượng lao động.

Điều đáng chú ý là AI không tự động giải quyết các vấn đề của doanh nghiệp. Nếu process hỗn loạn, dữ liệu kém chất lượng và governance yếu, AI sẽ chỉ "amplify chaos" nhanh hơn.

Trong 5 - 10 năm tới, những người có nhiều cơ hội sẽ không chỉ là AI engineers, mà còn là những người hiểu business, systems thinking, governance và có khả năng dẫn dắt transformation giữa con người, quy trình và AI.
Cuối cùng, doanh nghiệp thắng cuộc có thể không phải là doanh nghiệp triển khai AI nhiều nhất,, mà là doanh nghiệp thay đổi nhanh nhất trước khi thị trường buộc họ phải thay đổi.

---------------------------------------------------
P/S: Nhờ Claude tìm nguồn cho tập đoàn nào đã và đang thành công ở các làn sóng chuyển đổi thì em nó đưa ra ví dụ Microsoft cùng các case studies & URLs dẫn chứng, đọc cũng thấy thuyết phục.

Microsoft là ví dụ rõ nhất về ba làn sóng chuyển đổi diễn ra như thế nào trong thực tế.

Giai đoạn 1: Digital Transformation (trước 2014)
Microsoft của thời kỳ Steve Ballmer là một tập đoàn phần mềm khổng lồ đang mất phương hướng. Năm 2014, Microsoft đứng trước ngã tư đường: giá cổ phiếu đình trệ, chiến lược mobile thất bại, văn hóa nội bộ trở nên cứng nhắc và quan liêu. Công ty vẫn bám vào mô hình bán license phần mềm một lần trong khi thế giới đã chuyển sang cloud và subscription. Đây là bài toán Digital Transformation cốt lõi: thoát khỏi legacy business model và legacy systems để bước vào nền kinh tế số.

Giai đoạn 2: Agile Transformation (2014–2019)
Khi Satya Nadella lên làm CEO năm 2014, ông xác định ngay rằng vấn đề không phải là công nghệ, mà là con người và cấu trúc tổ chức. Nadella giải thể các business unit hoạt động như những vương quốc riêng biệt, tái cấu trúc Microsoft xung quanh các năng lực cốt lõi như cloud, AI và shared platform services, cho phép các nhóm kết hợp công nghệ nhanh hơn và deliver giải pháp tích hợp. Ông bỏ hệ thống đánh giá stack-ranking khét tiếng vốn khuyến khích cạnh tranh nội bộ, thay bằng văn hóa "learn-it-all", nền tảng tâm lý để Agile thực sự bám rễ trên toàn bộ các nhóm sản phẩm. Tổ chức IT nội bộ của Microsoft chuyển sang DevOps, Agile program management và user-centric design, không chỉ áp dụng cho team kỹ thuật mà cho toàn bộ cách công ty vận hành.

Giai đoạn 3: AI Transformation (2019–nay)
Nền tảng cloud Azure từ giai đoạn 2 trở thành bệ phóng cho AI Transformation. Nadella tích hợp AI vào Bing và Azure, đặt cược rằng AI sẽ tái định nghĩa productivity, và tuyên bố đây là "new day in search" khi tích hợp ChatGPT của OpenAI vào Bing năm 2023. Kết quả sau một thập kỷ chuyển đổi liên tục: doanh thu Microsoft đạt 281,7 tỷ USD, tăng 15%; Azure vượt 75 tỷ USD doanh thu với mức tăng 34%; và Microsoft hiện vận hành hơn 400 data center tại 70 khu vực trên toàn thế giới.
Bài học từ Microsoft là gì?

Ba làn sóng không chờ nhau. Digital Transformation tạo ra nền tảng dữ liệu và cloud. Agile Transformation tạo ra văn hóa và cấu trúc để học nhanh. AI Transformation scale mở rộng thêm vì hai tầng trước đã vững.

Kết quả: từ một công ty bị xem là "hóa thạch của thế kỷ 20", Microsoft đã trở lại vị trí một trong những công ty có giá trị nhất thế giới, cạnh tranh ngang ngửa với Apple và Alphabet.
Và quan trọng hơn: không có làn sóng nào được gọi là complete. Đến năm 2025, Microsoft vẫn đang Digital Transformation (tiếp tục khai tử legacy systems), vẫn đang Agile (mở rộng mô hình squad ra toàn cầu), và đang dẫn đầu AI Transformation.
Bạn đã trải qua các làn sóng nào và đã bị sóng đánh đi đến đâu rồi?! 😜👇

#DigitalTransformation
#AITransformation
#projectmanagement
#agiletransformation
#HumanAI

(Infographics do ChatGPT tạo)

Tại sao AI vẫn chưa thay thế được vai trò của PM?

2026-05-14T11:57:16.643+07:00

1. Tại sao AI vẫn chưa thay thế được vai trò của PM?

Gartner 2024 ước tính 80% tác vụ lập lịch, tổng hợp tiến độ và tạo báo cáo có thể tự động hóa bằng AI.

Nhưng World Economic Forum 2024 chỉ ra con số phía bên kia: chưa đến 4% tác vụ liên quan đến đàm phán và lãnh đạo con người có thể bị AI thay thế.

Vì sao lại có khoảng cách lớn như vậy?

- Standish CHAOS Report 2022 ghi nhận chỉ 29% dự án phần mềm hoàn thành đúng hạn, đúng ngân sách và đủ scope.
- McKinsey chỉ ra 70% thất bại bắt nguồn từ vấn đề con người, không phải kỹ thuật.
- PMI bổ sung: 56% dự án đổ vỡ vì giao tiếp kém với các bên liên quan.

AI có thể tạo project plan trong vài giây. Nhưng AI không thể ngồi vào phòng họp thuyết phục các sponsors/ stakeholders rằng deadline hiện tại sẽ phá hỏng chất lượng sản phẩm hoặc gây ra các major incidents impact tới business operation.
AI cũng không thể đọc được chính trị nội bộ đằng sau một quyết định bị trì hoãn hay xử lý các drama/ tin đồn về tình hình layoff. AI không thể xây dựng lòng tin với một business owner/ stakeholder đang mất kiên nhẫn.

Đó là phần công việc không phần mềm nào làm thay được.

2. Vậy PM có cần học AI không?

Có và Phải học => để dẫn dắt thế hệ dự án tiếp theo.

- Microsoft Work Trend Index 2024 ghi nhận 75% knowledge worker đã dùng AI trong công việc hàng ngày.
- PMI AI in PM Survey 2024 cho thấy 82% tổ chức kỳ vọng PM của họ làm việc được với công cụ AI trong vòng 2 năm tới.

Không phải kỳ vọng PM trở thành kỹ sư AI. Mà kỳ vọng PM biết AI làm được gì, không làm được gì, và khi nào nên để AI xử lý thay vì tự làm.

3. Thế hệ dự án tiếp theo sẽ vận hành theo mô hình nào?

Không phải người thay AI, cũng không phải AI thay người. Mà là human-AI collaboration, trong đó PM điều phối cả hai phía.

AI xử lý status report, flag rủi ro dựa trên pattern lịch sử, cập nhật resource forecast, phát hiện dependency conflict trước khi nó xảy ra.
PM đưa ra quyết định từ những dữ liệu đó, giao tiếp với stakeholder, dẫn dắt team qua những thời điểm không chắc chắn, và chịu trách nhiệm cuối cùng với kết quả.

- Harvard Business Review 2023 khảo sát 800 knowledge worker và kết luận: hiệu suất cao nhất không đến từ người dùng AI nhiều nhất hay ít nhất, mà đến từ người biết phân định rõ ranh giới, việc nào giao cho AI, việc nào giữ lại cho judgment của con người.
- Gartner PM Skills Survey 2024 xác nhận điều đó: kỹ năng quan trọng nhất trong môi trường AI không phải là biết dùng tool hay prompt engineering. Mà là biết khi nào cần override AI, biết thiết kế human checkpoint trong AI workflow, và biết diễn giải tín hiệu rủi ro từ AI cho stakeholder không có nền tảng kỹ thuật.

Đó là lớp kỹ năng mới nằm giữa technical literacy và leadership judgment.

Những PM làm chủ được stakeholder management sẽ không bị AI thay thế.
Những PM làm chủ thêm human-AI collaboration sẽ là người định hình cách ngành PM vận hành trong thập kỷ tới.

The Messy Middle

2026-05-13T10:01:00.002+07:00

Bài viết có một khái niệm rất đáng chú ý là "the messy middle".

Nội dung tóm tắt đại loại là sau 2022, hơn 80% lãnh đạo đã dùng AI hàng tuần và 74% tin rằng có ROI tích cực. Nhưng thực tế, dưới 10% doanh nghiệp tạo ra được giá trị AI ở quy mô lớn. Vấn đề không nằm ở công nghệ, mà nằm ở khoảng cách giữa strategy và execution.

Khoảng cách đó thể hiện rất rõ: 45% lãnh đạo thấy AI có ROI, nhưng chỉ 27% quản lý cấp trung đồng ý. 56% lãnh đạo nghĩ họ đi nhanh hơn đối thủ, nhưng chỉ 28% managers thấy vậy. Cùng một AI, nhưng hai 'thực tế' hoàn toàn khác nhau.

Ở tầng trên, AI là công cụ chiến lược. Ở 'messy middle', nó là một mớ vấn đề: workflow bị gián đoạn, integration khó khăn, output chưa đáng tin. Và quan trọng nhất, khi AI sai, chính middle managers là người phải 'dọn dẹp'.

Trong khi đó, họ gần như không có thêm bandwidth: <30% thời gian cho leadership, ~50% cho admin và task cá nhân. Việc yêu cầu họ vừa chuyển đổi, vừa giữ vận hành ổn định chẳng khác gì 'build the plane while flying it'.

Đây là lý do nhiều công ty tưởng rằng mình đã 'adopt AI', nhưng thực tế chưa tạo ra value. Họ đo usage, nhưng không đo readiness. Và khi 76% lãnh đạo nghĩ nhân viên hào hứng với AI nhưng chỉ 31% nhân viên thực sự như vậy, thì rõ ràng vấn đề không còn nằm ở công nghệ.

AI không fail ở top. Nó fail ở messy middle, nơi chiến lược phải trở thành thực tế.

Source: https://hbr.org/2026/04/managers-and-executives-disagree-on-ai-and-its-costing-companies

Which one are you focusing on: CoC or CoI?

2026-05-13T09:24:00.004+07:00

In the age of AI, the biggest challenge for middle managers is not a lack of information, it is too much Circle of Concern (CoC) and too little Circle of Influence (CoI), a concept popularized by The 7 Habits of Highly Effective People.

Their CoC keeps growing: AI trends, new tools, market pressure, competitors, limited resources. There is always something new to worry about.

But their CoI stays mostly the same: their team, their process, their delivery quality, and how they make decisions.

This creates a common pattern: more awareness, but not more impact.

The issue is not that CoC is too big. CoC is useful, it works like a radar. It helps managers see what is happening outside.

The real problem is when CoC is not turned into action. Then it becomes noise.

Effective managers do one thing differently: they consistently turn CoC into CoI.

Instead of following everything, they focus.
Instead of discussing, they act.
Instead of waiting for big changes, they start small and build momentum.

In a fast-changing world, success does not come from knowing more.
It comes from acting better.

So a simple question to reflect on:
“What is your CoC right now, and what actions are you taking to turn it into CoI?”

NGÔN NGỮ CHỦ ĐỘNG

2026-03-05T10:16:00.001+07:00

NGÔN NGỮ CHỦ ĐỘNG

Khi có điều quan trọng xảy ra, đừng vội kể với ai.

Đặc biệt là khi bạn đang rất muốn chia sẻ.

Hãy để khoảnh khắc ấy lắng đọng bên trong bạn.

Im lặng giúp bạn bảo toàn năng lượng và sức mạnh của nó.

Không phải niềm vui hay thành công nào cũng cần được tán thưởng ngay lập tức.

Đôi khi, im lặng là cách bảo vệ tốt nhất.

Khi ai đó cố kéo bạn vào cơn bão cảm xúc của họ, hãy bình tĩnh.

Quan sát phản ứng của chính mình.

Đừng để sự lo lắng hay giận dữ của người khác chiếm lấy bạn.

Sự vững vàng thầm lặng sẽ tạo nên khác biệt lớn.

Ngôn ngữ bạn dùng mỗi ngày đang định hình cuộc đời bạn.

Những câu chuyện bạn lặp lại sẽ trở thành khuôn mẫu bạn sống theo.

Khi bạn nói "Tôi lúc nào cũng mệt mỏi", não bộ sẽ tìm cách chứng minh điều đó.

Khi bạn nói "Tôi không giỏi việc này", bạn đang tự giới hạn chính mình.

Thay đổi ngôn ngữ không làm thay đổi mọi thứ sau một đêm.

Nhưng nó thay đổi cách bạn đi qua thực tại.

Thay vì "Tôi phải làm", hãy nói "Tôi chọn làm".

Thay vì "Tôi đang thiếu thốn", hãy nói "Tôi đang xây dựng sự ổn định".

Sự khác biệt rất nhỏ, nhưng ý nghĩa thì rất lớn.

Một cách nói đặt bạn vào thế bị động. Cách kia trao cho bạn quyền chủ động.

Hãy cẩn thận với những gì bạn lặp lại mỗi ngày.

"Tôi ghét công việc này", "Tôi không đủ tiền", "Người ta luôn bỏ rơi tôi".

Những câu nói ấy trở thành kịch bản tâm lý.

Chúng ảnh hưởng đến cảm xúc, quyết định và cả sức khỏe của bạn.

Khi bạn buông lời nặng nề với ai đó, bạn không chỉ làm tổn thương họ.

Bạn đang đầu độc chính hệ thần kinh của mình bằng sự tức giận.

Trước khi nói, hãy dừng lại và hỏi: Điều này có xứng đáng với sự bình yên của tôi không?

Không phải mục tiêu nào cũng cần công bố.

Không phải chiến thắng nào cũng cần lên mạng xã hội.

Có sức mạnh lớn trong sự phát triển thầm lặng.

Có quyền năng to lớn trong việc chọn lọc lời nói.

Hãy nói những điều mang lại sự sống.

Hãy nói "Cảm ơn", "Tôi biết ơn", "Tôi tha thứ", "Tôi có thể".

Lòng biết ơn làm dịu hệ thần kinh.

Tình yêu xây dựng kết nối.

Sự tha thứ giải phóng tâm trí.

Bạn không cần thay đổi cả cuộc đời trong một đêm.

Chỉ cần bắt đầu bằng cách thay đổi cách bạn nói về nó.

Thay đổi ngôn ngữ. Thay đổi tư duy. Thay đổi hướng đi.

Khoảng cách giữa "người bất hạnh" và "người viên mãn"

Đôi khi chỉ là câu chuyện bạn tự kể với chính mình mỗi ngày.